#Eranga-subscriptions
nova ice
Hi there 👋 we can discuss going through the history of multiple objects to try figuring out why a subscription was cancelled, but before we do I want to run an alternative approach by you.
When you cancel the subscription because a user doesn't pay, you could add some information into the metadata field on the subscription to indicate this. Then you can just look to see if that information is present in the metadata field.
https://stripe.com/docs/api/subscriptions/object#subscription_object-metadata
carmine prawn
Thank you for replying. How can we differentiate a payment failure between the first invoice after the trial vs a normal payment failure?
I am open to discuss to sweep through the history of objects to understand what happened with the subscription as well. If there is an easy way, I am all ears 👂
Ah, reading your answer again, what you suggest is to set a key in metadata in the subscription, when I try to manually charge the customer if the payment failed?
nova ice
Correct
Then you can simply look to see if that key/value pair is present when looking at the canceled subscription.
carmine prawn
That is simple and elegant. Thank you @nova ice 🎉
nova ice
😄 Happy to help!
carmine prawn
Sorr to bother again, I have another question
*Sorry
I am listening to customer.subscription.updated event to check whether a subscription is moving from trialing to active
Then I am going to manually finalize the invoice like I mentioned earlier (because a subscription invoice takes about an hour to be finalized)
Then I am going to try to pay the invoice (everything happens in the backend)
My question is, when I receive the event customer.subscription.updated, can I be guaranteed that the invoice for the next billing cycle is created and will be on draft state
If the invoice is not available, my process would fail
nova ice
I wouldn't rely on that, that event triggers whenever a subscription is updated and so there is a chance it will be sent for a change other than the one you're expecting.
carmine prawn
Hmmm, so to do this, I need to listen to an event from invoice?
nova ice
invoice.created is the event that I'd suggest hooking onto:
https://stripe.com/docs/api/events/types?lang=python#event_types-invoice.created
carmine prawn
Hmmm, then I need to make sure that the invoice generated is a result of a trial being transfering from trialing to active
nova ice
Yeah, I've been trying to think of a good way to detect that state change.
carmine prawn
I'm wondering how to achieve this. We cannot even guarantee that I will receive customer.subscription.updated before invoice.created right? Because they are two seperate events
carmine prawn
What if we do this. At the moment, I am keeping track of the subscription status on our database as well. So when I create the subscription with the trial, in my local database, the status would be trialing.
Now I listen to invoice.created event. Then using that event I retrieve the linked subscription in Stripe. It will be active. But it will still be trialing in our database. Now I know for sure that this invoice is the first invoice for the subscription that the user has to pay. Then I finalize it manually.
lyric delta
Thinking on this. To be clear, by cancelled for any other reason do you mean cancelled in the customer portal?
carmine prawn
Most probably not
Other reasons might include user requesting cancellation, and we call subscription end on the end of the billing period for one example
Another could be payment failure but not the first invoice after the trial. But a one that comes after
carmine prawn
@gleaming chasm, @lyric delta Let me know if you guys can help out on this. I might be going out for the day, but will surely look again tomorrow
😊
lyric delta
Thanks for your patience on this. Sorry about the delay, busy day
carmine prawn
I understand, take your time. There is no hurry
lyric delta
I think your solution with your own DB sounds great. Was just double checking that there isn't some easy check on an Invoice to do