#chung-yi_best-practices
wise hillBOT
👋 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/1380182976523931801
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
velvet turret
Hi, are you asking if it's possible to ask to trigger 3DS when you capture the funds at a later time?
little garden
Hi my understanding is that 3DS can be triggered when confirming a setup intent or confirming a payment intent. Our flow include both steps in a checkout, and wonder if users will be asked to authenticate 2 times.
Ideally, if a user has authenticated when confirming a setup intent, in the same checkout flow, we don't want the user to have to auth again when submitting the order (in which we charge the card).
velvet turret
I see, that is possible. It's not up to Stripe, rather the issuing bank makes that determination. If you plan on charging the customer on the same flow as you collect the payment method details, you should update your integration to use ‘setup_future_usage’ when creating the PaymentIntent for the charge, https://stripe.com/docs/api/payment_intents/create#create_payment_intent-setup_future_usage. This allows you to talk to the bank once, and you can still save the payment method fo future use.
little garden
To clarify, you are suggesting to not using the setup intent but only use 1 single payment intent call with the param?
velvet turret
Yes, that is correct especially when you're collecting the payment method and charding the customer all at the same time.
little garden
Our flow does them in separate steps tho. Collecting payment info (and create the payment method) first, and then at the end of the flow charging the card when submitting the order.
We probably can't create a payment intent directly when collecting payment info because the user might change the payment method before submitting the order.
velvet turret
In this case, maybe you'd want https://docs.stripe.com/payments/build-a-two-step-confirmation flow. It allows you to collect the payment method details and the create the PaymentIntent
wise hillBOT
little garden
Right. The 2-steup-confirmation implementation does not create a setup intent after collecting payment info, and instead it relies on the confirmation token. So there is only that payment intent call at the end.
velvet turret
Yes
little garden
So it will not have the multiple SCA issue.
The reason we wanted to create/confirm a setup intent immediately after collecting payment info is to materialize the payment method (e.g. card).
little garden
Like creating a real payment method/credit card record on the Stripe side (and our side). With the confirmation token approach, my understanding is that payment methods/credit cards will not be created until the payment intent is created/confirmed at the end of the flow, right?
urban pewter
The confirmation token includes a payment_method_preview you can inspect to get information about the payment method for your business logic prior to confirming the payment
little garden
Yes. Let's say a user adds a new card via Payment Element but doesn't complete the checkout (or changes to a different credit card via Payment Element again), the entered credit card will simply be lost right? Like there won't be a credit card record on the Stripe side.
urban pewter
You determine that flow -- your "pay" or submit button triggers the sequence where you create the confirmation token and then confirm the payment
If you choose not to confirm, your customer could pick a new PM type and click again, and you'd get a new preview
little garden
Yes, with the confirmation token we can get a new preview. But if we'd like to persist every single credit card (with association to external stripe card) that the user tried in the same flow, we can't, right? Because my understanding is that only the credit card that's eventually been used to confirm the payment will have a real credit card record on Stripe. All other credit cards tried will not have corresponding credit card records.
urban pewter
If you attempt the payment confirmation with the confirmation token, i believe it will create a payment method object you'd be able to see, but you'd need to test that.
If they don't actually try to confirm, or your don't try with the token, what is your use case for wanting any kind of record of that?
little garden
Business logic might prefer persisting all credit cards on file right after users enter credit card info.
So it seems like it's a tradeoff we need to decide here. If we choose to do the create/confirm setup intent + create/confirm payment intent approach to persisit all credit cards in the flow, we have the risk of triggering 3DS auth in the same checkout 2 times.
urban pewter
Business logic might prefer persisting all credit cards on file right after user...
This is pretty aggressive, and i don't recommend it, but you could listen for payment element change events, and when you observe complete=true you can call stripe.createPaymentMethod(...) to get a "snapshot" of the payment method entered, even if the customer doesnt clikc your pay/confirm/submit button.
little garden
That's interesting. I can give that a try. Now I feel I should go back to the drawing board to re-evaluate the tradeoffs here.
My above understanding above is correct, right?
So it seems like it's a tradeoff we need to decide here. If we choose to do the create/confirm setup intent + create/confirm payment intent approach to persisit all credit cards in the flow, we have the risk of triggering 3DS auth in the same checkout 2 times.
urban pewter
yes, we don't recommend back to back setup intent and payment intent, it can be a really poor customer experience
payment intent + setup_future_usage to save the card for later is the recommendation if thats what you need
your case/need for setup is a little different though, with the 2-step flow being the way to address inspecting card details before payment completion
little garden
Sounds good. Now thinking about it, persisting only a few more credit cards in the flow is probably not worth the risk of multiple 3DS auth issue.
Thank you for talking through it (and @velvet turret too)!
urban pewter
NP, happy to help!