#bharatkilaru
pine rapids
reef lynx
Hi there!
What do you mean by "when I create the setup intent"? You shouldn't create a SetupIntent if you want to use Subscription with free trials. Instead you should use the SetupIntent contained in the subscription: https://stripe.com/docs/api/subscriptions/object?lang=dotnet#subscription_object-pending_setup_intent
frail wave
RIght, so I'm doing that - I create the subscription when the user selects a plan and then expand the setup intent (server side). Then once they fill the payment element, I use confirmSetup (client side).
That part is working well.
Where I'm having trouble is - then I'm trying to separate which customers have a subscription where confirmSetup was successful vs. ones where they were not.
Is there a property on the subscription object that helps you differentiate successful vs unsuccessfully set up trial subscriptions?
reef lynx
RIght, so I'm doing that - I create the subscription when the user selects a plan and then expand the setup intent (server side). Then once they fill the payment element, I use confirmSetup (client side).
Perfect!
Is there a property on the subscription object that helps you differentiate successful vs unsuccessfully set up trial subscriptions?
I guess you can check the status of thepending_setup_intentof the subscription?
frail wave
Yeah, like null means it was set up successfully?
Noticing this works, but is actually delayed. Like when I go to confirmation url, I need to wait a bit before subscription object's pending_setup_intent changes to null.
This process is super clear for non trials - just looking at subscription status going from incomplete to active.
But seemed confusing for trials
reef lynx
Yes since we don't require a payment in this case, the subscription automatically has a active status.
The only options I see is either checking the pending_setup_intent, or directly looking if the subscription (or customer) has a default payment method set.
frail wave
Okay, cool, was just going to say these are the only changing values I see:
"previous_attributes": {
"default_payment_method": null,
"pending_setup_intent": "X"
}
Thank you! That was helpful!
Another question - I have a UI where the user is switching between plans and then we render the payment element on that same sceren. Every time they switch plans, I'm cancelling incomplete subscriptions and creating new ones and expanding their payment or setup intents. Is this the best way to do it? It's creating a lot of cancelled items in my Stripe dashboard. Not sure if I should be updating subscriptions rather than cancelling them?
reef lynx
Yes that's annoying. You could try to use the brand new flow when you only create the Subscription after you collect the payment method: https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription
frail wave
Cool, thanks! And finally, we're evaluating payment element and checkout quite a bit. Are there non-ui conversion advantages to check out over payment element? e.g. more payment methods, etc. that are available on checkout or anything like that
reef lynx
We usually recommend Checkout Session because it's simpler to implement and is more powerful (handling tax, coupons, custom fields, etc.)