#brandontrytn_docs
split spruceBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1362482614300184720
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fiery oyster
Hi! Unfortunately there's no way to override what the issuing bank tells us to do; if it says you need to bring the customer back on-session to complete a payment, then that's what you have to do.
naive crest
payment intent: pi_3R9aY8BQJd0Qzfw20gLLlxu6
payment method: pm_1R9pmoBQJd0Qzfw2G6VINYUv
is there a way to detect a payment method requires additional verification so we can not store that payment method to the customer?
fiery oyster
I mean, any credit card could conceivably require it.
naive crest
but there's nothing stripe would return we could confidently look for to prevent storing payment methods that require additional verification
is there any documentation anywhere that outlines this specific flow I can point our support team to so if this comes up in the future they have something to reference?
specifically how the saved method may not work because it requires additional verification?
fiery oyster
This PaymentIntent is configured to accept payment methods enabled in your Dashboard. Because some of these payment methods might redirect your customer off of your page, you must provide a
return_url. If you don't want to accept redirect-based payment methods, setautomatic_payment_methods[enabled]totrueandautomatic_payment_methods[allow_redirects]toneverwhen creating Setup Intents and Payment Intents.
That was the error message in the failed confirmation request for the Payment Intent you mentioned. So you could do that and it would likely mostly eliminate the issue for you - but could create other issues, because a lot of cards may potentially require that.
At any time, for any card, for any reason, the issuing bank may require the user back on session to authorize the payment.
There is no way to know for sure or to guarantee it won't happen.
naive crest
right, ideally we continue to support redirects on the front of house, but don't store those that require it for back of house
fiery oyster
Sure, but that means you might as well just stop saving cards, as ~most cards now (and ~all cards eventually will) support or require 3D Secure.
naive crest
is there any documentation outlining that timeline I can share?
fiery oyster
Here's a Stripe blog post on the topic from last year: https://stripe.com/blog/surprising-findings-from-our-analysis-of-3ds-transactions-in-the-us
TL;DR is: in the US, no one expects 3D Secure/SCA to happen; in the ~rest of the world, no one expects it not to happen. It is require in Europe, but not in the US.
naive crest
cool, yeah, europe always seems to be ahead on the payment protection front
fiery oyster
Arguably on the "everything protection" front but ... ya.
So you can opt out (per [this message](#1362482614300184720 message)) or you can add functionality to notify the user that they need to come back on-session to complete a payment by adding another payment method, and then handle that. Or you can do both. Or neither. 🙂
naive crest
yep, sounds good, thanks again for the help, this chat is so helpful to use
fiery oyster
Of course - I'm glad it's been useful for you! 🙂