#schteve

1 messages ยท Page 1 of 1 (latest)

subtle nightBOT
lofty walrus
#

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?

gray jewel
#

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

lofty walrus
#

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

gray jewel
#

Yeah, that's what I'm confused about as well.

But this can also happen when I create a PaymentIntent from a SetupIntents PaymentMethod?

lofty walrus
#

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.

gray jewel
#

Alright, the error happens quite often and on the SetupIntent so I don't think it actually happens on that step.

lofty walrus
#

Can you share the error you're referring to?

gray jewel
#

evt_1NuynDIIvUltmYEyLWbOj1xw

lofty walrus
#

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.

gray jewel
#

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?

lofty walrus
#

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.

gray jewel
#

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?

lofty walrus
#

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.

subtle nightBOT
gray jewel
#

Alright thank you very much! ๐Ÿ™‚