#stripe_connect_platform
rotund goblet
hexed bolt
Hi, you're wondering how you can identify cancelled subscriptions to then send an email to, is that correct?
lusty ore
We are a connect platform
My customer (standard Stripe account) wants to get an email when a subscription is canceled
They cannot do this in the Stripe dashboard (i.e. set Stripe to send the email) so I am looking at how to do this.
But you can cancel (A) immediately or (B) at period end. A is easy. My concern is how to do B.
My customer doesn't really understand the difference between A and B and I basically have to educate them and decide to send A or B or just A. I coded A. I am pondering B but i only get customer.subscription.updated which is a bucket for lots of things. And even if we look at the Sub, how could I know if the cause of the customer.subscription.updated was exactly a cancelation request :at_period_end and to differentiate from a sub that was updated by some other thing that sends that same bucketed webhook - we only want to send the email once and just for cancellation. i don't want to send an email every time a sub was updated.
If you sent a customer.subscription.canceled_at_period_end, we could do it, but the webhook is caused by any update to the sub, right? I may be wrong so that's why I am contacting you.
hexed bolt
We do not have a event called customer.subscription.canceled_at_period_end, you're right. Let me test this on my end and share next steps here.
lusty ore
You can look at the sub object yes. And you can know if the status of the sub is that it is set to cancel. But how do you know that the exact cause that just happened prior to the webhook was a cancellation? That is the challenge. I'm deciding whether just to email people when a Sub is cancelled, but the upset customer canceling is the event really, not 1 month or 1 year later when it cancels so for "service recovery" a Stripe account owner may wish to act when the customer "sets the sub to cancel" not when the "sub cancels" since that is the trailing event that happens a long time later (at the end of the pre-paid billing cycle).
hexed bolt
A work around is to listen to 'customer.subscription.updated', and look at the subscription object and identify what you're looking for by looking at "cancel_at_period_end": true'.
You'll see this in that event
lusty ore
Yes, but let's say they cancel. We send an email.
Then something else is updated on the sub. The Sub object still has those attrs so we send an email.
Repeat
Sending emails each time anything is updated.
What else can be updated on a sub after it is canceled at_period_end? If lots of things, then we send lots of emails.
And you can "uncancel" now. And cancel. It is just many complex use cases.
hexed bolt
I see your point here
lusty ore
Thank you. It is hard to explain.
If you understand and agree that it is really messy, then I will just not code this feature and table it. It is messy right?
And customers will just get an email when customer.subscription.deleted since that is binary and occurs in real time and only once. There must be an engineering term for this but I mean it can happen once and only once.
Whereas cancel can uncancel and also it is a general webhook for lots of events so we don't know the "immediate cause" of the webhook.
hexed bolt
Thank you for adding these details. Yes. Let me test one theory. What I'm thinking is when you get 'customer.subscription.updated' with "cancel_at_period_end": true'.. you make an a call to update the subscription to add the metadata. You can then look at the subsequent 'customer.subscription.updated' events and look at the metadata to confirm if you need to send an email or not.
lusty ore
Uncancel and cancel?
The metadata would be there so we wouldn't send the email the 2nd time.
Yeah, we could save a counter in the db too, but yeah, this is too complex for me. I am tabling this one I think.
I hate updating with metadata like that. It gets messy.
Ok my friend. I'm good. I just wanted to know if I was missing something.
👍