krupskis

[storm estuary]

👋 happy to help

[ocean stag]

"evt_1Nug57Hu8ZrDGEH9YQQqDDdp" This is event id testing env, you can sees tatus is incomplete

[storm estuary]

actually the best practice here is to use the invoice.paid events

[ocean stag]

And this is the production event: "evt_1NuryRHu8ZrDGEH9tNwPZK3P", status is active immediately

[storm estuary]

this way you're sure that the Subscription's invoice is paid and you can provide your services to your customers

[ocean stag]

What about checkout.session.completed?

[storm estuary]

checkout session completed means that we've collected successfully the payment method, but that doesn't mean the payment happened

especially if the PM is an asynchronous PM type (e.g. Direct Debit, Bank transfer, BNPL)

[ocean stag]

I see, I was reluctant to use invoice.paid, as subscription events seemed to be more intuitive to manage subscriptions

[storm estuary]

you can take a look at all of the subscription related events here https://stripe.com/docs/billing/subscriptions/webhooks and read about our recommendation

[ocean stag]

Cheers

[storm estuary]

let me know if you need any more help

just fyi, the reason why the subscriptions worked differently is because the one created in livemode there was a 100% discount

meaning that the first invoice had a 0 amount

in these cases we automatically put the subscription in an active state

[ocean stag]

That makes a lot of sense, thanks for letting me know

[storm estuary]

yes sure

this is why we rely on invoice.paid because it always fires when the invoice is paid whether it is a trial or a 100% discount or an invoice > 0,

[ocean stag]

@storm estuary On invoice.paid can I rely that when I query the subscription the current_period_start and current_period_end will be there?

Since it is not included in the invoice.paid itself

[storm estuary]

yes you can retrieve the subscription from the subscription property on the invoice