viper-invoice-events

[true nimbus]

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• vipera74, 1 day ago, 14 messages
• vipera74, 1 day ago, 7 messages
• vipera74, 2 days ago, 6 messages
• vipera74, 2 days ago, 6 messages
• vipera74, 2 days ago, 6 messages
• vipera74-customer-portal, 6 days ago, 22 messages

[frozen drift]

Hi 👋

What you need to listen to is customer.subscription.updated. That will alert you of the downgrades and you can decrement the credits in your system.

Here's the event
https://stripe.com/docs/api/events/types#event_types-customer.subscription.updated

I'm assuming you are using the Customer Portal to handle user modifications to their subscriptions?

[languid heath]

Yep, I currently am using Customer Portal.
The problem with customer.subscription.updated is however that it doesn't trigger on the normal automatic renewal of the plan. The only place in which I can restore user credits would be inside the invoice.paid event. Even if I use customer.subscription.updated to check that the plan changed, I still need some way to differentiate the invoice.paid event cause

[frozen drift]

1. I would listen to both, so you can catch subscription downgrades
2. The invoice.paid event returns an Invoice object which includes a billing.reason property. You can use this proprety to differentiate between subscription_cycle (normal renewal) and subsciprtion_update triggers https://stripe.com/docs/api/invoices/object#invoice_object-billing_reason

[languid heath]

Oh! That's totally what I needed.
Let me just sum up to double check:

1. Listen to invoice.paid and use the billing.reason property to differentiate between the two triggers. Restore user credits based on that.
2. Listen to customer.subscription.updated in order to catch the status of the subscription, the current plan, etc; this event is a bit less critical, and I should not use it to decide how many credits to give to the user.

Is this all correct, more or less?
I know that this is obviously all dependant on the various possible implementation, but I just wanted to get the rough idea

[frozen drift]

The customer.subscription.updated event will also catch any downgrades where you would want to reduce the number of credits for that customer

The Event object for any *.updated event includes a previous_attributes property that shows you what changed and what the values were for those properties before they changed

[languid heath]

Oh, alright. I currently am fetching the subscription itself in invoice.paid as well though, so I have access to the subscription information in that handler as well

[frozen drift]

Okay, in the customer.subscription.updated event the Object that is included is the Subscription so you would have access to that directly from the event

But I'm a fan of inspecting the previous_attributes to make tracking changes easier

[languid heath]

Yep, but since the order is not ensured I would prefer to keep credit calculation in one handler only, in order to ensure that it's correct

[frozen drift]

That makes sense

[languid heath]

Thank you for your precious help and time! I will make treasure of your tips and will now avoid revenue loss 😄 which is a good thing for my business ngl

May I use this ticket if I encounter further issues?

Or should I create a new one

[frozen drift]

Happy to do it, that's why we're here 🙂

If you encounter more issues you should ask a new question in the main channel

[languid heath]

Great! Thanks once again

[frozen drift]

No problem, best of luck.