#__leak__
1 messages · Page 1 of 1 (latest)
Hi 👋 I don't think Invoice Event types alone are enough, if you want to also be made aware of actions like a customer's subscription being cancelled/deleted (customer.subscription.deleted).
I would recommend using Test Clocks to run a Subscription from your account through it's full lifecycle, so you can see exactly what Events are generated and when, so you know whether there are more that you need to listen to.
https://stripe.com/docs/billing/testing/test-clocks
But when a subscription is getting cancelled shouldn't the user be able to use the better features until the subscription would end but the customer.subscription.update is only getting called then when the user clicks the update button and not then wehn the subscription has ended
I'm sorry, I'm not sure I'm following. You said it was crucial to track the cancelling of Subscriptions, and customer.subscription.deleted is triggered when the Subscription is cancelled.
but shouldn't the subscription be active until it is expired regardless of whether the user has deleted the subscription
I'm sorry, I don't understand what that means. In Stripe, the Subscription being cancelled is what moves it to a terminal state. There are a lot of different shapes that Subscription integrations can take, for instance you let customers end a Subscription immediately, or you can set it to end at the end of the current billing period. Without knowing the specifics of how you built your flow, and what you need to know about at each part of the flow, it will be hard for me to give good specific recommendations around what Event types to listen to. I would suggest running through your integration using a Test Clock, look at the Events that get generated, and see if there are any you feel you should be listening to but aren't.
Ok i will try that and hopefully this will help me with my problem. Thank you so much for taking the time to assist me.