#lerp
blazing thunder
Hello there
final swallow
Hello!
blazing thunder
Yep that is the general purpose of using a SetupIntent
slate merlinBOT
blazing thunder
Essentially we pass a 3DS exemption to the issuer since it has already been completed in the past
Most often the issuer honors this and there is no 3DS required
However, it is always up to the issuer here... they can always still force 3DS again if they want to so you should always be prepared to bring your customer back on-session if you need to
final swallow
Got it, thanks. Do you have any sense of how often issuers don't honor that exemption? Is it rare?
final swallow
Alright, thanks anyway. Very helpful. I have a couple more detailed follow-up questions about our implementation and some behavior we're seeing, should I ask them here or post them in the general chat?
blazing thunder
Yep you can ask them in this same thread
final swallow
Ok, thanks! First question, you pass that exemption to the issuer for all future payments, correct? Not just the next payment after 3DS?
blazing thunder
Correct
final swallow
Awesome
Second question: my team is testing out our setup intent/3ds integration, and we're seeing some strange behavior post-3DS. We're successfully triggering 3DS using credit card number 4000002500003155 and then saving the payment method without any issue. However, later when the PaymentIntent is confirmed off-session, the payment is failing and we're seeing that the payment has a status of "3D Secure attempt incomplete - The cardholder began 3D Secure authentication but has not completed it." in the Stripe Dashboard
Any idea what's going on here?
blazing thunder
Can you give me an example SetupIntent ID where you see that?
final swallow
Yes, seti_1O0lr9KvO0GKmvAM5NI54Ktx. I just created that one, but I haven't tried creating/confirming the PaymentINtent yet
blazing thunder
Can you run a quick test and create a new PaymentIntent for that Customer but also confirm it on creation instead of in a separate confirm request?
So basically just set confirm: true on creation
final swallow
Yes, just going to take us a few minutes
blazing thunder
I'm not seeing a reason why 3DS was requested here. I'll test too
final swallow
Should we be using a different test credit card number? The documentation says that 3155 is used to simulate the following scenario:
"This card requires authentication for off-session payments unless you set it up for future payments. After you set it up, off-session payments no longer require authentication."
blazing thunder
That is the right card
I think what is happening here is that the default for off_session is different between a PaymentIntent creation request and a PaymentIntent confirmation request
Which I didn't realize
So if you are going to confirm in a separate request (which I wouldn't really recommend to begin with as it is just more API calls) then you would need to specify off_session: true
final swallow
Where would we need to specify that?
blazing thunder
What I would recommend is to just remove your separate confirmation request
This request specifically: https://dashboard.stripe.com/test/logs/req_r1ScHQrdPBLaXa
Instead of doing that, just pass confirm: true in https://dashboard.stripe.com/test/logs/req_bOVwvz9rXfgKof
waxen thorn
Hey bismarck, I work with seabass and he asked me to chime in here. We can't combine PaymentIntent creation and confirmation into one step; in my testing I've discovered that payment amounts cannot be changed after the PaymentIntent is confirmed. This is important to our platform, because payment amounts may differ after a customer places order, e.g., shipping quotes may change, products may be customized, etc.
blazing thunder
Yeah that doesn't really make sense
If you are creating an off session PaymentIntent then you just wait until you are ready to charge to create/confirm the PaymentIntent
No reason to create one earlier in your flow
If you want to do it your way then you can, all you need to do is add off_session: true on confirmation: https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-off_session
But this is just an extra API request really which adds a small bit of latency and can potentially contribute to rate limits (if you are working at big scale) so that's why I don't recommend it.
waxen thorn
Thanks for the recommendation on rate limits. I'll discuss further with our team on how we want to handle this extra network request; at this point I've successfully confirmed a PaymentIntent using the off-session parameter so we'll pursue this approach for now.
blazing thunder
👍
final swallow
Thanks bismarck, very helpful