#Ammar-Setup-Intents
uneven basalt
The Setup Intent should handle the 3DS flow when it's processed. When you're confirming payments later with that payment method, you can set off_session to be true in which case we'll request a 3DS exemption. However, it's up to the issuer whether they require authentication on each transaction, so there is no way to guarantee that your customers won't need to complete a 3DS flow.
limpid kite
How often can I expect that to happen? The payments are usually around £15-£50. When it does happen. I want to be able to handle 3DS on session. Since the user will be logged in and on the device when making the payment.
Basically, when the user signs up they provide their card details. Then when they want to make a booking we use those card details and the setup intent that we created. The issue we are having is we don't want to send an email to the user that the payment requires additional authentication since the user might not read the email until later. We need to be able to handle this on session.
uneven basalt
It's hard to give you any sort of prediction, as it is up to the issuer so it could even fluctuate from one customer to the next. Since it sounds like your customers will be on-session when they make the booking, it should be possible to detect during the confirmation step whether they'll need to complete the 3DS flow and present it to them.
This section of our doc helps walk through how to do this for various platforms:
https://stripe.com/docs/payments/3d-secure#when-to-use-3d-secure
limpid kite
The confirmation step noted on that page is for the payment intent api. Will it also work for setup intents?
uneven basalt
The same approach is used but slightly different functions:
Client-side confirmation would use: https://stripe.com/docs/js/setup_intents/confirm_setup
Server-side confirmation would use: https://stripe.com/docs/api/setup_intents/confirm
limpid kite
Ok, do I just confirm the same setup intent multiple times?
Each time the user wants to make a payment?
limpid kite
Seems weird, unless I am missing something and I am supposed to create a payment intent from the setup intent each time?
limpid kite
Caught up?
rapid cedar
not yet, sorry there are 15 threads ongoing in real time
limpid kite
No worries
rapid cedar
okay sorry, threads are caught up, let me focus on yours for a few minutes
Okay, so I think you're mixing the 2 concepts a bit.
- SetupIntents are used to collect card details ahead of a future payment. Like imagine a trial period, I charge you in 2 weeks if you're happy, but I want your card details now. So I use SetupIntents, which will make me go through 3D Secure as needed
- PaymentIntents are used to accept a payment now, like if you want me to pay you $100 now
So if you collect card details upfront, you want to use SetupIntents. It will save card details, do 3DS as needed to allow you to charge the saved card in the future and hopefully skip 3D Secure.
It's possible that a future payment fails because the bank wants 3D Secure again. Or because the bank account has insufficient funds. Overall, you treat all of them as a simple decline. When the PaymentIntent gets declined, you email your customer, get them back to your website and have them go through the payment flow, enter new card details, etc. using the existing PaymentIntent that just failed (it's like a state machine for a payment). No need for a new SetupIntent
Does that make sense?
limpid kite
So for booking payments do I use the previously generated setupintent? Or do I generate a new payment intent?
rapid cedar
You generate a new PaymentIntent. There's no way to "re-use a previously generated SetupIntents" that doesn't make sense. After you collect card details, you get a PaymentMethod pm_123 and that's what you want to use for future payments
limpid kite
Ok, so I create a payment intent with the pm from the setup intent. And handle the 3D S during the confirmation step as outlined in the link sent by your colleague. FInal question. Is it better to confirm the payment intent on the client side or server side.
rapid cedar
That's a bit of a wrong question overall. What matters is the current payment flow: If the customer is on your website, paying for a service, you confirm client-side. On the other hand if you are charging async for a service and the customer is not on your app you charge server-side
limpid kite
Alright, thanks. The customer is on the app so client side it is. You have been a great help and have cleared things up. Thank you very much!
rapid cedar
Glad you got unblocked!