#antoineb_api
hoary lynxBOT
👋 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/1463892545342935214
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
distant girder
hey there! yes, SetupIntents support completing 3DS when saving a card, while the older method of creating and attaching PaymentMethods manually does not
the reason is that completing 3DS upfront increases the chance of a successful subsequent payment with the stored card - it also allows you to bypass 3DS more often for subsequent off-session payments
slate hatch
hey Glo! Thanks for your answer. But if user has a card that had a setup intent in the past (or had a payment in the past with setup_future_usage: off_session), and re-uses it again, do we need to create / confirm a setup intent again?
distant girder
no! once the card has been 'set up' previously (either with a SetupIntent, or setup_future_usage) then it's already optimised for future payments, so you don't need to use a SetupIntent again
I'm curious why this would happen in the first place? do you have a flow to 're-save' an already saved card?
slate hatch
ok thank you.
Currently the front always asks us for setup intent and uses it in PaymentElement even if the payment method has been previously saved. I'm not a frontend dev, but from what I understood our frontend didn't know how to "not" use a setup intent and just simply confirm that the payment method is to be used. So as you say, it "re-saves" the already saved card
From what I understand, this flow might be OK for paypal payment method, because user re-creates a paypal mandate for each time he buys something (we sell recurrences for cleaning session), but not for card then?
Do you think it might explain our conversion drop?
distant girder
hmmm, I'd need to take a look at a specific example payment to say for sure, but yes that sounds like it would be a likely explanation
hoary lynxBOT
distant girder
to confirm, your flow is passing the existing saved PaymentMethod ID to a new SetupIntent? is this happening when the customer checks out using a saved card, or are you triggering a payment from your side (i.e. a merchant-initiated transaction, where the customer is offline)?
slate hatch
yes, front asks to back to create an "empty" setup intent, then uses it with PE and pass the existing saved payment method ID. he checks out using a saved card, because a lot of our payments happen offline so we just register PM_ID for later usage
I hope I'm clear enough 🙂
let me try to find an example payment
if I'm not mistaken, seti_1SrwMtBBURfSZNfgYEbbnV37 uses a previously setup payment method
wary hare
hi there, I'm taking over for Glo as they have to step away. give me a couple minutes to catch up
slate hatch
sure! let me know if you need more details. I'm trying to find examples meanwhile
wary hare
thanks for providing that example Setup Intent. it doesn't look like it's passing a previous payment method, however you should only have to use a Setup Intent to set up a payment method for future usage once
Setup Intents will normally send an auth request to the bank, which would trigger 3DS more often
slate hatch
ok
and is it possible to use stripe payment element without passing a setup intent if user select an already saved card, so that the front just sends it to the back without going through stripe at all then?
wary hare
yes, that is possible. I'm assuming you're using this saved payment method flow? https://docs.stripe.com/payments/existing-customers
slate hatch
we use the custom flow in the page you show me (so no checkout object)
and in the example I gave you, req_e8cYFVkvSAFnEB is the call that the front does to stripe with the payment_method_id. And this payment_method was actually already setup 3 days ago
payment method is pm_1SqsoGBBURfSZNfg2xLdPGFJ
wary hare
got it. yeah, if the payment method was already set up, you shouldn't need to create another Setup Intent. you can likely lower the incidence of 3DS by not doing that
slate hatch
ok thank you!
wary hare
you're welcome!
slate hatch
hey again! (if you're still here)
we sometimes also do a payment_intent (if we want to make a preauthorization online)
If the user tries to make a preauth with PE with an existing saved payment method, should we refrain to put setup_future_usage for the same reason we shouldn't use a setup intent?
wary hare
if that existing saved payment method is already set up for future usage, and you're passing that payment method in the Payment Intent creation request, then yes, you should refrain from setting setup_future_usage
slate hatch
ok, thank you!
wary hare
you're welcome!