#cglacet
1 messages ยท Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- cglacet, 1 day ago, 5 messages
HI ๐
I"m a little confused by the flow you propose here. How would you be creating each hold?
We would create them on the server side, using the client initial payment method.
Okay so each one would represent a separate Payment Intent?
Customers are not present after the first authentication so we need a way to create a hold without a 3DS
Yes
Okay so for the first transaction you would want to use our flow for saving the Payment Method during payment here: https://stripe.com/docs/payments/save-during-payment
The key setting when creating the payment intent is setup_future_usage: 'off_session'
That indicates you will be using the payment method to create charges where the customer won't be on-session to authenticate
Sure ! Ok. I get this.
Would we effectively avoid 3DS on the 2nd, 3rd and 4th payment with this strategy?
You make it less likely. Ultimately an issuing bank can decide to force 3DS at any point
But when you save the payment method with that setting we pass the information that it will be used for off-session payments to the bank and they are less likely to require 3DS
Ok, I've read this paragraph, I though you might say that :D. In practice, do you have any idea how often we would require a 3DS for these subsequents payments?
We don't need any guarantee, we just need a rough estimate to base our decision on, switching from our current solution to this is not trivial for us so we are trying to understand as many things a we can
Honestly not really. It is relatively rare but banks can change their risk model at any time