#jtishler-migrate-subs-client-side-confirm

1 messages · Page 1 of 1 (latest)

livid dust
#

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

viscid wasp
#

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

livid dust
#

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.

viscid wasp
#

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)

livid dust
#

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 😉

viscid wasp
#

haha thanks

#

so my custom logic would be to call to the stripe API to update the tax status (or product) of the subscription

livid dust
#

Yep

#

The updatePaymentIntent JS method is the main new thing that the flow introduces

viscid wasp
#

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

livid dust
#

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

viscid wasp
#

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?

livid dust
#

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

viscid wasp
#

i see and that paymentintent is where the secret comes from

livid dust
#

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

viscid wasp
#

1/ the user can lie though with this model?

livid dust
#

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.

viscid wasp
#

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?

livid dust
#

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

viscid wasp
#

"PaymentIntent will automatically be confirmed/attempted" - meaning this will happen server side then when we create the subscription

livid dust
#

Yeah

viscid wasp
#

You use Payment Element with a SetupIntent to collect the PaymentMethod. - would i call updateSetupIntent or confirmSetup here

livid dust
#

confirmSetup on the client

viscid wasp
#

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?

livid dust
#

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)

viscid wasp
#

ok thanks so much for looking into all this!

#

if i have follow up questions later can i tag you specifically?

livid dust
#

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.

viscid wasp
#

gotcha thanks again!