thomas_58040

[velvet grove]

Hi again 👋 checkout.session.completed is triggered when the customer has completed the Checkout Session flow. If there were immediate failures, then the Checkout flow will surface those to the Customer and prompt them to take corrective action.

There is a possibility for asynchronous payments to fail later, and there are Events to listen for that so you can take corrective action if that occurs:
https://stripe.com/docs/api/events/types#event_types-checkout.session.async_payment_failed

[gleaming jackal]

Are these async payment methods like paypal and crypto, or can credit cards ever fall into this bucket?

So you are saying that when I get the checkout.session.completed event, I am safe to provision services. I speculate that that event will occur before the customer.subscription.created so it's better UX to provision immediately. And then what I guess I can just use the customer.subscription.created for what, fleshing out my subscription record?

[velvet grove]

Yeah, that sounds reasonable. You may not need to listen to customer.subscription.created if you don't need any details from it beyond what you're already receiving in the other Event(s). Where it may be useful to use customer.subscription.created as your provisioning trigger instead of checkout.session.completed is if you begin using Checkout Sessions for more than just Subscription flows.

[gleaming jackal]

I see. Yeah I have been thinking about adding a usage based product. In that case the checkout.session.completed event is going to be overloaded and it makes sense to push subscription provisioning into subscription events. Are there usage.* events, or will I need to continue to monitor checkout.session.completed and check productIds (or whatever the usage based equivalent of productId is, haven't looked into this as thoroughly) to see if the checkout is for a subscription or a usage based purchase?

[velvet grove]

It depends on what you're referring to by usage based product. If you're talking about our pricing models that are usage-based, then those will still be associated with Subscription objects:
https://stripe.com/docs/billing/subscriptions/usage-based
There aren't Event types specific to this flow, because in this flow you report the usage to us by making requests to do so, so there is no benefit in us echoing that information back to you in an Event.

If they are instead using Checkout Sessions to handle one-time payments, then that will still use Product objects (as does the approach referenced above). The key differentiator there will be the mode that the Checkout Session is created in.
https://stripe.com/docs/api/checkout/sessions/object#checkout_session_object-mode

[gleaming jackal]

Right now I use mode: subscription. Do you mean the usage based product would use a different type, eg setup, to set them up to be billed later?

[velvet grove]

I'm not exactly sure without having a clear understanding of what you're referring, but if you're using Checkout Sessions to process one-time payments then the mode would be payment in those cases. If you're always going to use it to create Subscriptions then mode will always be subscription.

[gleaming jackal]

Understood.