#branko1253
ripe sequoia
gritty creek
Can you share an example PI?
lofty vale
Its hard to share the complete code
gritty creek
I just need a pi_xxx that isn't behaving as you expect
lofty vale
alright, one moment. I do not think it related to the payment intent since none of them are working while confirming it via card payment
gritty creek
Well it would depends on which test cards you're using
lofty vale
for example this one pi_3NVXlGFeKZ5612QC0De9bFGd
I am using 4242 4242 4242 4242 visa card
gritty creek
Sure, there's no authentication/3DS needed on that card so there'd never be a redirect (and thus no need for a return_url). You can manually force that with handleActions: true (https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-options-handleActions)
lofty vale
isnt handleActions true by default?
gritty creek
Generally though you should be handling post-payment/fulfilment in a webhook
gritty creek
isnt handleActions true by default?
Sorry, yes I meant false
lofty vale
I tried that as well, but return_url was not called
we are handling post payments via webhooks indeed
this is just on our front end, once confirmCardPayment is completed we want to redirect to the receipts page
how can I trigger this redirect?
payment_method: savedPaymentMethodId,
return_url: `${window.location.origin}/booking/${props.bidId}/${paymentRecordId}/receipt`,
})```As explained, you need to use a card that actually requires next actions (i.e. 3DS/auth)
gritty creek
this is just on our front end, once confirmCardPayment is completed we want to r...
Then do that in your .then block when the confirmCardPayment Promise resolves
lofty vale
alright, I get it. and I appreciate your help.
however confirmPayment method is doing that by default
even though the same visa card is being used
4242 etc
gritty creek
Yep, that works differently as it is agnostic to payment method type and supports other types that require redirect (i.e. iDEAL etc)
So we always require a return_url
lofty vale
alright, good to know. Thank you very much
gritty creek
np!
lofty vale
do I need to use handleActions: false for that btw?
gritty creek
For which?
lofty vale
for conifrmCardPayment?
I assume sometimes redirect_url will be used and sometimes it wont, depending on the credit card
if I use handleActions: false, that means redirect_url wont be ever used and we have to handle redirections ourselves?
gritty creek
return_url will be used in scenarios where a redirect is required (when you do handleActions: false)
lofty vale
so if handleActions: true //default redirect_url will never be used?
gritty creek
As I understand it, yes
gritty creek
General recommendation would be to just use Payment Element with confirmPayment
lofty vale
I understand, however there is a request from product team to try to reuse the submitted payment methods if users decide to do so
gritty creek
You can do that with the Payment Element
lofty vale
something like this
how can I do that?
if users has previously entered a credit card and they clicked on remember my payment info we display design like this
so that they just need to click on the confirm booking button. For that I thought we have to use confirmCardPayment
lofty vale
amazing, let me try that
just to praise you, previously we were on Recurly, but Stripe is so much better
more strict though
just one more question, if we do have payment_method, then elements property needs to be excluded from the confirmPayment request?
will this cause any issues? const { error } = await stripe.confirmPayment({ elements, confirmParams: { payment_method: savedPaymentMethodId, return_url: `${window.location.origin}/booking/${props.bidId}/${paymentRecordId}/receipt`, }, })
should I remove elements from the call in the case? when payment_method is provided