#jtishler-migrate-subs-client-side-confirm
1 messages · Page 1 of 1 (latest)
Hi there
Hmm good question.
Give me a moment to think about the best way to handle this.
Needing the client secret to render Payment Element definitely makes this tricky
yep that is the issue i was seeing as well
i wasn't sure if there was some way to update the subscription product or tax status later in the process, though i'm not sure that would even work
I think the only way to really handle this is going to be to ask the customer for the country up front if you want to use this flow. Let me double check though
Ah actually
I think the other route here would be to use a SetupIntent
Okay nvm. Forgot we are just now releasing a flow to handle this exact situation with Payment Element.
So in this case you do end up confirming server-side, but it allows for utilization of Payment Element. And then you can confirm again client-side if next actions are required.
Give a read through that guide and let me know what you think.
You will need to reach out to our Support team to request early access for livemode, but you should be able to test it out fully.
if we still want to confirm client side can we use this https://stripe.com/docs/payments/build-a-two-step-confirmation
it seems to indicate on the page you sent that this is an option
also will both of these options work with setup intents and payment intents (we use both depending on free trial eligibility)
Ah! Forgot that was an option. I haven't played much with this flow yet since it is still in beta. Yes I do believe that would work, and yes SetupIntent should be supported (though I haven't tested that myself). I'd recommend testing it out. I'm going to later today as well when I get a moment as I clearly am not familiar enough with this 😉
haha thanks
so my custom logic would be to call to the stripe API to update the tax status (or product) of the subscription
gotcha that makes sense
so that adds the payment method to the payment intent without having to actually confirm it
and then we can do stuff in between
Hmm yeah that's the idea. That said, I'm a little unsure this fits the Subscription scenario.
The issue with the Subscription is that you will actually need a completely new Sub if you want to change the Price used...
Give me a few minutes. I have some time now and will do some testing
Yeah shoot now that I'm thinking about this it really won't work with Subscriptions
Since you would have to recreate a new Subscription
Okay okay sorry for leading you astray
Alright so back to the beginning
There are only two options to satisfy your use-case here with Payment Element
one of our engineers noticed this in your tax docs: "If you don’t want to create your products and prices upfront, you can pass price_data.tax_behavior and product_data.tax_code when creating subscriptions."
is that something we can update later or still no?
No
Once an invoice is finalized it creates the underlying PaymentIntent
That can't be updated
You would need a completely new Invoice and new PaymentIntent
i see and that paymentintent is where the secret comes from
Yep
So the two options are:
1/ You collect country up front from your Customer before you create the Sub and render Payment Element
2/ You use Payment Element with a SetupIntent to collect the PaymentMethod. Then you create the Sub and confirm the PaymentIntent using that PaymentMethod.
With 2: The SetupIntent should handle 3DS if it is required and the customer shouldn't be prompted for 3DS again. However, this is possible if the issuer prompts for 3DS during the PaymentIntent confirmation. In that case you would confirm the PaymentIntent again client-side to handle 3DS on the actual payment attempt.
That is the only real downside of the SetupIntent approach
1/ the user can lie though with this model?
Yes.
In which case you would need to have a flow in place to handle that... mostly updating the Sub to the correct Product for the next invoice most likely.
But that depends up to you for how you would want to handle.
2/ so i just create a setup intent unattached to a subscription and use that to render the payment element. then i create the subscription on the server and pull the payment method from the setup intent to attach to that sub? and confirm the resulting payment/setup intent for the subscription client side or server side?
You can set the PaymentMethod as the Subscription's default_payment_method when you create the Sub and then the initial invoice's PaymentIntent will automatically be confirmed/attempted.
But overall, yes.
You could also set the Customer's invoice_settings.default_payment_method if you want that payment method to be used across Subscriptions
"PaymentIntent will automatically be confirmed/attempted" - meaning this will happen server side then when we create the subscription
Yeah
You use Payment Element with a SetupIntent to collect the PaymentMethod. - would i call updateSetupIntent or confirmSetup here
confirmSetup on the client
and then we would need to pass the setup intent id to the server to use it to get the payment method later when creating the subscription?
Yep. You'll likely want to set redirect: 'if_required' on confirmSetup
And then pass the SetupIntent back, grab the PaymentMethod, create the Sub, and if the Subscription is active then show the customer a success message (or redirect at that point)
ok thanks so much for looking into all this!
if i have follow up questions later can i tag you specifically?
Happy to help!
Feel free to post in the main channel with follow up questions and someone will be around to help (other than on weekends)
I may not be, so don't recommend tagging me directly.
gotcha thanks again!