#morunas
slate socket
warm trench
Hello, we actually recommend against creating a SetupIntent in scenarios when you actually want to take payment for exactly this reason. Banks can always request 3DS auth even if the customer just completed it seconds ago. It is much less likely in the real world but is still a strong possibility and is frustrating when it happens
sturdy quest
Hi Pompey 🙂
warm trench
So here, what we would typically recommend is waiting until the subscription is created and using its first invoice's payment intent to collect the card details and make the payment at the same time
hello 👋
sturdy quest
hmm but then I don't have tax info, right? Just so I understand what you are suggesting:
- user picks plan and I immediately create a customer and an incomplete subscription
- I then present a form that the user fills (where they will also put e.g. VAT ID and choose a country, etc)
- then I get the upcoming invoice for that same subscription which will include the applicable tax rates
- then the user presses submit...
But where here should the Stripe Elements be used? If I put the Stripe Elements before showing the upcoming invoice... well I end up in the same scenario of double authentication... if I put them after (or together with), does that mean that I need to have two forms: first, billing info without payment details... and then once I have the billing info and can calculate the tax rates... then show the payment form?
upper jacinth
Hello 👋
When you create an incomplete subscription, the latest invoice has a PaymentIntent object created for the due amount.
You can use that to render Elements and collect PaymentMethod for initial payment. If the PaymentMethod is saved correctly then subsequent payments should not trigger 3DS auth again
sturdy quest
Ya the recurring part not requiring 3DS on off-session charges of fixed price subscriptions I think I understand. The main challenge here was that I was doing, as Pompey described to not, SetupIntent > confirmCardSetup... but instead I guess use confirmCardPayment using the client_secret from the lastest invoice's payment intent? as described here https://stripe.com/docs/billing/migration/strong-customer-authentication#scenario-1-handling-sca
upper jacinth
yup that's correct if you want to use cardElement, if you want to use the PaymentElement then you'd likely need to pass that client_secret in while initialising elements
sturdy quest
and as I understand, the consequence here is that I can't really show the "billing info form" together with the stripe Elements for collecting card details... if I want to show tax rates on the payment preview before checkout
I am using the CardElement atm
upper jacinth
Yeah I believe that's a drawback at the moment
sturdy quest
Sorry I don't follow. Is there a draw back to use the card element? Should I not be able to just use the card element and then call confirmCardPayment passing the client_secret from the latest invoice of the not yet active subscription?
upper jacinth
No, like not being able to show "billing info form" along with Stripe Elements is the drawback
sturdy quest
ahhh ok got it. alright, and just to confirm... if I use the confirmCardPayment, the returned successful PaymentIntent can then be used to set the default payment method on the customer right? It's not "exclusive" to that one subscription, or is it?
By that I mean if the client then wants to for example change the subscription by choosing a new price offering (e.g. yearly with X% discount), which they do on-session of course, is there a chance they will need to re-authenticate?
(FYI I'll need to be away for a while but please do reply to the above and I'll check when I return. Thanks!)
upper jacinth
If you're setting subscription.payment_settings.save_default_payment_method to on_subscription then its linked to that one subscription as a default
Otherwise you'd need to set it as default on customer.invoice_settings.default_payment_method