#schteve
1 messages ยท Page 1 of 1 (latest)
Hi ๐ can you tell me a bit more about your flow that uses a Checkout Session but then also manually interacts with that Payment Intent?
Hi :), I create a CheckoutSession that generates a SetupSession to save the PaymentMethod, that PaymentMethod then needs to be checked for the card network used (this is the reason I use a SetupIntent in the first place). If the card network is right a PaymentIntent is created with the PaymentMethod of the SetupIntent. After some time the PaymentIntent will be charged with a certain amount.
In this flow the problem arises, when the SetupIntent is created as it gets a status of requires_action
Hm, I'm not sure how you have both Setup Intents in a requires_action state, and are using Checkout Sessions in setup mode. Checkout would handle the 3DS challenge there, or at least that's what I would have expected.
In general though, when processing those later Payment Intents you do need to be prepared for the case where an issuer requires additional authentication before they approve a transaction. In those cases you need to bring your customer back on-session (onto your site) and provide them with a way to complete that authentication. Typically that is done with stripe.js, our frontend library, which has functions for handling 3DS challenges:
https://stripe.com/docs/js/payment_intents/handle_next_action
Alternatively you can handle that without using stripe.js, and that process is described here:
https://stripe.com/docs/payments/3d-secure#when-to-use-3d-secure
Yeah, that's what I'm confused about as well.
But this can also happen when I create a PaymentIntent from a SetupIntents PaymentMethod?
Yes, issuing banks can require authentication be completed on any transaction, though they typically don't when the Payment Method was set up via a Setup Intent.
Alright, the error happens quite often and on the SetupIntent so I don't think it actually happens on that step.
Can you share the error you're referring to?
evt_1NuynDIIvUltmYEyLWbOj1xw
The Setup Intent that is being referenced there, is in a succeeded state now. It looks like that Event was emitted while the Checkout Session was handling the 3DS process. It doesn't look like you would need to take any action for that intent.
Ah yeah I see, thanks.
I had some instances where the paymentIntent that was created after failed (like evt_3NuvU0IIvUltmYEy1Nc7qWJb). Do you reckon that this happened because the bank asked for 3DS again when creating the PaymentIntent and that was not handled?
Yup, that seems to be the case. You can look in the last_payment_error hash on that Event to see why the payment failed. The transaction was declined with a decline code indicating authentication needs to be completed.
Alright thank you ๐
Do you know what to do with the next_action of use_stripe_sdk?
I would rather like to use redirect_to_url is there a way to accomplish that?
The guide I pointed to before (pasting again for convenience) explains how to handle the intents so you get access to the authentication URL directly:
https://stripe.com/docs/payments/3d-secure#when-to-use-3d-secure
When making the request to confirm the Payment Intent, you'll want to pass the return_url parameter. That should cause next_action to populate with a redirect_to _url hash instead of use_stripe_sdk.
Alright thank you very much! ๐