#joshuacs94
reef wren
hi!
so Im expecting any on-session one-time payment made with that card to not require 3DS
it doesn't work that way, for that test card only off-sessions payments get the exemption
wheat current
hmmm, so the issue has to do directly with the test card?
reef wren
well there's multiple layers to it, but my question would be why do you use a SetupIntent and then immediately charge the card on-session? That's almost always not the right choice and it's a common mistake people make in their integration, and it leads to customer confusion like getting asked for 3DS twice in a row or seeing 3DS for $0(the SI) and then actually getting charged on their bank statement.
wheat current
nono, the setup flow is separate 😅
reef wren
makes sense. Then yeah that's just how it works really, we don't have card specifically that test on-session payments not requiring 3D Secure(beyond of course just using a regular card like 4242424242424242)
on-session payments getting an exemption is not something directly controlled by your integration (instead it's up to the bank and things like if they consider it low-risk or low-amount or the context of the customer), but off-session is infuenced by if your integration does the setup part correctly, so there's a test card for testing that
wheat current
So do you think that in production with regular cards, this situation where the customer is asked to authenticate twice wont happen too often?
reef wren
no, I think it will happen often and I see reports of it from merchants and end-customers semi-frequently
under the scope of SCA, by default on-session payments require 3D Secure, unless the bank exempts them because of low-risk/low-amount exemptions (https://stripe.com/ie/guides/strong-customer-authentication#exemptions-to-strong-customer-authentication) , there's nothing really directly you control there.
There are exemptions for off-session payments like recurring subscriptions if you integrate in the correct way that lets us claim those, and sounds like you have that part working.
as I said though, you should definitely never do "use a SetupIntent and then immediately charge the card on-session" if that's what you're doing. In most use cases that should be replaced with doing a PaymentIntent with setup_future_usage instead.
wheat current
hmmm, I thought doing the setup part (its a complete different flow that will happen first) before charging the customer would "skip" over 3DS in most cases, since the card was already setup
feral oracleBOT
reef wren
nope, that's not how it works. the setup can only lead to off-session payments getting exemptions
the letter of the law is that on-session payments(including on saved cards) generally always require authentication unless the bank chooses to exempt it
wheat current
so there is nothing to do from our side to make that process more frictionless right?
reef wren
nope, just make sure you're able to handle 3D Secure on that on-session payment
which should happen fine if you're using our stripe.js library( with e.g. https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-existing for a saved card on-session on the frontend)
gotta run sorry but @worthy relic can help with anything further
worthy relic
👋
wheat current
yeah, just trying to get this process as more frictionless as I can
worthy relic
Gotcha. As my colleague mentioned earlier, there's not much you can do about this.
As long as you're using Stripe.js library to confirm payments, you should be good to go.
wheat current
actually we are creating / confirming payments backend-side using the Stripe Node SDK
and leaving up to the frontend the setup of the PMs and 3DS parts
worthy relic
Gotcha. So for on-session payments when 3DS gets prompted, you'd need to handle that client-side by using handleNextAction
https://stripe.com/docs/js/payment_intents/handle_next_action