#karina-6458_api
vague tangleBOT
👋 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/1356706142100787264
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
deft flame
Hello
If you specify the newly saved payment method when calling the /pay endpoint - https://docs.stripe.com/api/invoices/pay#pay_invoice-payment_method
You likely can override the payment method associated with the underlying PaymentIntent and confirm it -- which should pay the invoice
minor pier
do you know if i can reliably test this with a particular set of test cards?
deft flame
Hmm, you could use 3184 card - https://docs.stripe.com/testing#regulatory-cards:~:text=always require authentication.-,Always,-authenticate
for SCA trigger
and then use 3155 card - https://docs.stripe.com/testing#regulatory-cards:~:text=Filter...-,Authenticate,-unless%20set%20up with a SetupIntent
minor pier
for instance, i used 3220 when creating a setup intent, and it did challenge me for SCA as expected, but then i created a subscription and the first invoice is still requiring SCA.
ah ok, those are new cards! i will try that out
deft flame
And pass resulting pm_xxx from the SetupIntent to payment_method param when calling /pay endpoint
3220 triggers 3DS based on your radar rules
By default, it triggers 3DS on each attempt with that card - https://docs.stripe.com/testing#regulatory-cards:~:text=to be successful.-,By default%2C your Radar rules request 3D Secure authentication for this card.,-3DS Required
minor pier
oh interesting, i thought 3DS and SCA were effectively the same thing?
kk, let me try this flow with these other cards
deft flame
It kinda is when you think about cards
Card issuers trigger 3DS for SCA (Strong customer authentication).. Other payment methods require different type of authentication (like 2fa codes, login etc etc)
minor pier
oh interesting, based on the description for 0446 "This card is already set up for off-session use. It requires authentication for one-time and other on-session payments. However, all off-session payments succeed as if the card has been previously set up."
this implies to me that once i create a payment method via setup intents, and as an end user go through SCA, it should not trigger any off session challenges.
deft flame
correct
deft flame
It however depends on the card issuer.. They could trigger 3DS for an off-session payment too
NP! Happy to help 🙂
minor pier
oh right, so that is the crux of my question. if i have an invoice that triggered off session SCA. can i reliably say that a user could create a new payment method via setup intent, pass the SCA challenge there, and then my app uses that new payment method to pay off that invoice that originally triggered off session SCA
(i know ideally we just want to handle the invoice's SCA challenge directly, but my team is really tring to cut scope to hit a deadline 😢 )
deft flame
IMO it'd be easier to handle SCA / 3DS than building a new flow with SetupIntent and calling the /pay endpoint
minor pier
it would be easier, but we have already implemented the new flow with setup intent and /pay. this is how we handle normal payment failures.
deft flame
All you need to do is re-confirm the PaymentIntent once the customer is on-session OR you can use handleCardAction - https://docs.stripe.com/js/payment_intents/handle_card_action
Stripe.js handles 3DS stuff automatically.
it would be easier, but we have already implemented the new flow with setup intent and /pay. this is how we handle normal payment failures.
Gotcha. The flow with the SetupIntent should work but again -- depends on the issuer.. If they trigger SCA/3DS again then your customer will need to provide a 3rd payment method
minor pier
yeah, i think it is safer to just bite the bullet and implement it properly here
deft flame
Yup
Here's the doc - https://docs.stripe.com/payments/3d-secure/authentication-flow?platform=web#when-to-use-3d-secure
It's quite straightforward
You don't need to read "Redirect to bank website" etc sections
just need to call handleCardAction or confirmCardPayment on the invoice's PaymentIntent client-secret
minor pier
i know, we implemented it elsewhere. was trying to understand for my team mates if there was a short cut considering what they already implemented
for now i'll say their attempted shortcut would be unreliable
deft flame
Yup, Stripe does not control when 3DS/SCA is triggered. So we canonically recommend having a flow that allows customers to come back on session and authenticate.
They'll be around to provide a new payment method anyway (in the proposed alternative).