#lerp
empty isle
empty hill
Hey there
It looks like an authentication_required decline when you attempt to charge the PaymentIntent off_session
You can test this easily by using the 4000002760003184 test card
obtuse blaze
Ok, so the payment intent will have an authentication_requiredstatus? How do we initiate a re-authorization once we have the user back on-platform?
empty hill
I believe the PaymentIntent moves back to a requires_payment_method status if I remember correctly, but yeah you should test that. After you bring the customer on-session you use confirmPayment() client-side and pass the client_secret and PaymentMethod ID (https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-confirmParams-payment_method)
obtuse blaze
The client secret from the original setup intent?
obtuse blaze
Ok. So first we fetch the payment intent using the client secret and payment method ID, and then we check for a requires_payment_methodstatus. Are there any other data points on the payment intent we should look at to determine if it's a 3DS reauthorization scenario?
empty hill
Well you don't really want to check for requires_payment_method as a status -- that is the base status for a PaymentIntent so it doesn't necessarily indicate that 3DS is required.
obtuse blaze
I see
empty hill
If you want to use the flow you just described then you likely want to look at last_payment_error: https://stripe.com/docs/api/payment_intents/object#payment_intent_object-last_payment_error
Which should be authentication_required
obtuse blaze
Cool that makes sense
Ok so we check that, and if 3DS is required we call confirmPayment on the client with the client secret and the payment method ID. That'll trigger another 3DS authorization flow, and if that is successful the payment will confirm and all will be well with the world. Sound about right?
obtuse blaze
Groovy, we'll give that a try. Thanks bismarck!