tounka

[dry rose]

Yes, as a side effect of how those upgrades work. When you update from one billing cycle to another, the new billing cycle is charged for immediately

So as long as that charge succeeds you will get an invoice.paid event

[hard basin]

Is there any reason to listen for the customer.subscription.updated event then? I am only concerned with knowing what new subscription the user currently has

[dry rose]

That depends on your needs. customer.subscription.updated makes sense to use to listen for the updates themselves. Some updates won't trigger an invoice so that event can help if subscription changes are being made that won't do that.

I am assuming that you are working with the customer portal and seeing when users change their subscriptions through there?

[hard basin]

yea i'll be using the customer portal

if a user cancel's their subscription which event would i get

[dry rose]

Depends on your customer portal settings. If you have it cancel the subscription immediately you will get a customer.subscription.deleted event, if you have it cancel at the end of the month you will get a customer.subscription.updated where cancel_at_period_end is the field that changes

[hard basin]

it sounds like if the subscription is set to cancel at the end of the period, listening to the customer.subscription.deleted event notifies me when the user should no longer have access to my product so i can remove their access. Does that sound correct?

And if a user upgrades their subscription from say monthly to yearly, listening to the invoice.paid event would allow me to provision their new access. It doesn't seem like i need to handle customer.subscription.updated event but just want to confirm

[dry rose]

Yep deleted would be the one about ending access either way. And yes invoice.paid would let you know to provision access to the updated subscription

So if that fits your use case it sounds like you don't need to listen for the updated event

[hard basin]

awesome thanks

was also wondering when i get thecheckout.session.completed webhook event will i also get the invoice.paid webhook event?

[dry rose]

Yes, you will get both for the initial payment on your subscription

[hard basin]

so i'm assuming the subscriptionID on both objects will be the same. which subscription object would be most up to date between? I don't want to make an API request to get the subscription details on both events

[dry rose]

The subscription ID will be the same on both events, it will not change so you can always use that ID to look it up

[hard basin]

gotcha, so retrieving the subscription object on either event would result in the exact same subscription data?

[dry rose]

Correct

[hard basin]

perfect and lastly: on the checkout.session.completed event the subscription status will ALWAYS be "active" correct?

[dry rose]

They can also be trialing if you ever use our free trial functionality

But yes, it will always be one of those two statuses because a checkout.session.completed event denotes a payment (or setup) success and the other statuses relate to payments being required/failed/etc

[hard basin]

i'm not using the free trial functionality. you lost me on the completed part

[dry rose]

Because you are not using trials, checkout.session.completed events will only happen on a successful payment, so you should only see subscriptions with an active status

Edited the original message for clarity as well

[hard basin]

got you. thank you for all your help. very helpful!