skoshkarli-subscription

[main lion]

hello! why do you want to pass the SetupIntent to a Subscription?

[frail crown]

my flow is as follows:

1. Create a customer
2. Create a setupIntent and use the client secret to render the form using StripeElements
3. Have customer make product selection and fill out payment information
4. call stripe.setupPayment to collect payment information
5. Create a subscription using that payment information

[main lion]

why not create the subscription and then collect payment information using the PaymentIntent created by the Subscription instead?

[frail crown]

because i dont know which product will be selected

I've tried that flow because i was told to it that way at first, but i could not achieve what i needed

so today i was told to do the steps above

[main lion]

the flow would be the customer makes the product selection, then you create a subscription, and collect the payment method

[frail crown]

that is not what i need

i've been over this with another rep and this is what they told me to do

and i believe its correct

i just need to figure out how to pass a setupIntent to a subscription

[main lion]

alright, if you want to follow your current flow - The SetupIntent is used to create a PaymentMethod. So you would follow this flow : https://stripe.com/docs/payments/save-and-reuse until step 6

[frail crown]

right i have the payment method id in the setup intent

which property do i pass it in to the subscription.create call?

[main lion]

if you want, you can set invoice_settings.default_payment_method [0] for the customer with that PaymentMethod id

[0] https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method

[frail crown]

trying to keep payment information at the subscription level

[main lion]

then create the subscription with the customer. If you set invoice_settings.default_payment_method, then you don't need to set default_payment_method

if you don't set invoice_settings.default_payment_method, then you need to set default_payment_method

[frail crown]

ok let me try one sec

worked like a charm!

thanks so much!

[main lion]

great!

[frail crown]

have one more follow up question

in regards to usage: 'on_session'

[cobalt socket]

what's the question?

[frail crown]

if a user is going through checkout then it should be on_session right?

so that i can do 3ds or whatever else needed to authenticate?

this is for creating a setupIntent

[cobalt socket]

right

to be clear it's completely wrong to do SetupIntent and then immediately create a Subscription and you should just not do that

you'll just get two 3D Secure windows in a row in many cases.

[frail crown]

why is it wrong?

i only call setupPayment once, thats the only thing that may cause 3d secure window

then i pass that info to create subscription call

or is there something else i am missing?

[cobalt socket]

no, creating the subscription can do 3D Secure.

since creating the subscription will charge the customer for the upcoming month, and that payment might require 3D Secure from the bank(regardless of any previous setup you may or may not do).

[frail crown]

but creating subscription doesn't happen in the UI, its all on the server

is there a reference to this in the docs somewhere?

[cobalt socket]

that doesn't change anything, since what happens if creating the subscription fails on the server?

for example what can and will happen is you'll create the subscription, it will try to charge for the first month, the bank will decline it requiring 3D Secure, and you get an incomplete subscription and have to handle the latest_invoice.payment_intent on the frontend to present 3DS and complete the payment to activate the subscription.

[frail crown]

but why would bank decline if i just ran setupPayment with an intent that has usage: 'on_session',

the point of usage: 'on_session', is that 3ds is verified

[cobalt socket]

not really no

the bank can do whatever they want , they have complete discretion in granting exemptions or not

[frail crown]

well, the other flow of creating a subscription first doesn't work for me, so i am forced to use setupIntent instead of paymentIntent

[cobalt socket]

doesn't work for me,
why not?

also why not use Checkout?

[frail crown]

because my product selection is on the payment page where the form is

we are using Custom checkout experience

[cobalt socket]

you could refactor it to split that into two pages, one for picking the product, then redirect to a payment page, that's what I would recommend, it works better with the current payment ecosystem and SCA requirements.

[frail crown]

thats a no go from Product team unfortunately

[cobalt socket]

then I suggest them convincing them really. We have our best practise and documented integration for a reason. You're free to build what you want but I'm just telling you that doing a SetupIntent and then a Subscription immediately is wrong and causes issues that I as someone doing support for Stripe sees all the time.

if it helps, if you ever move to interchange-based pricing, this costs you more money since you're doing an extra $0 validation charge via the SetupIntent, on top of the fee for actual subscription creation charge.

this also leads to the customer seeing a 3D Secure window with $0 in it and not the price of the actual subscription

here is an example of a customer complaining on this very server about the confusion that causes

[frail crown]

i have other challenges though creating a subscription before collecting payment

we offer producs with trial and without trial

and creating a subscription right off the bat with a trial causes it to go into 'trialing' (essentially active) without collecting payment information

[cobalt socket]

yep that's how trials work in our models

[frail crown]

this doesn't match our product model

[cobalt socket]

we are planning an improvement to Checkout actually to allow for the concept of a paid trial that only starts when payment info is created

[frail crown]

we'd need a trial on a subscription thats incomplete until payment is added

[cobalt socket]

then for that use case you'd use a SetupIntent and then only create the subscription object when it completes

if the customer is not using a trial, you don't use a SetupIntent and instead create the Subscription directly and confirm its PaymentIntent, you branch.

[frail crown]

as soon as you set trial days it puts it in trialing, no exceptions

[cobalt socket]

like I'm aware you're going to say that doesn't match your existing page and customer journey but I'm just telling you the recommended Stripe integration.

[frail crown]

so if i did what you are saying ( which i actually had built intially because someone else here told me, with exception of the fact that i had product selection on payment page) I'd have the following:

1. product selection page where user selects product
2. Payment page where i would create a subscription right away and render the form using that client secret from the subscription setup intent or the payment intent (depending on whether the product has trial)
3. call to confirmPayment/setupPayemtn on submit, based on whether product has trial

if #3 fails, then the customer is left with an active 'trialing' subscription

or if the customer quits the process and closes browser window

it doesn't really work

the concept of trial with payment, doesn't work very well in stripe api, which is disappointing.

[cobalt socket]

yep, it's not perfect