#village-wording-cancel
tranquil path
I have a few questions so you don't have to make blanket statements 🙂
lethal glade
cancel_at => Date at which the Subscription will be explicitly canceled if you want to control the exact timestamp
canceled_at => Date at which the subscription was marked to be canceled, whether immediately or in the future/end of the period
you can set the former, the latter we (Stripe) set it based on the API requests you made
tranquil path
No, i get all that. You should know by now my questions are nuanced. 🙂
lethal glade
Ack my bad then what's the question (also best to write it upfront that way I don't get ahead of the real question)
tranquil path
And what you just said isn't how i read the above, the way i read it, if a sub is set to expire in the future, like at end of current billing cycle, then doesn't just cancel_at get populated and canceled_at is still null?
Or i misunderstand?
lethal glade
I think my read is correct and you misunderstand. Easiest is to test it in Test mode quickly to confirm
ah we're both right/wrong "cancel_at": 1648796400, "cancel_at_period_end": true, "canceled_at": 1648773474,
basically we do set cancel_at to current_period_end. Didn't know that
so basically if you take your subscription and you explicitly set cancel_at: X at timestamp Y you get "cancel_at": X, "cancel_at_period_end": false, "canceled_at": Y,
If instead you say "hey please cancel at the end of the period" and that timestamp is Z and now is T you get "cancel_at": Z, "cancel_at_period_end": true, "canceled_at": T,
I'm surprised though, I was sure we kept cancel_at: null in that case but I hadn't looked at this specifically before
tranquil path
So the cancled_at is when you pushed the button for it to cancel when time() == cancel_at?
lethal glade
yup
tranquil path
Hmm, cause in the test i did before asking, was a manual cancel now from dashboard, which populated canceled_at and left cancel_at null.
lethal glade
Ah that one is when you cancel immediately
and I guess that one doesn't need cancel_at since it's not in the future, so there's no reason to track it
yeah I just tried, even if you mark it to cancel at the end of the period and then you change your mind and cancel immediately we unset cancel_at so you get cancel_at: null
tranquil path
End goal, trying to decide what values to listen for and act upon for all situations for either customer.subscription.updated or customer.subscription.deleted
because surprise to me, the update doesn't trigger when you cancel now.
lethal glade
correct
xxx.updated events are usually sent when "something change on the resource and no other event is sent"
it's a bit of a strange pattern and it's more a catch all otherwise almost every change other than xxx.created would trigger a duplicate xxx.updated event
tranquil path
What im trying to figure out, is it safe to only pay attention to canceled_at? will that always be set to the date the service ends whether set to be cancelled at future date or canceled now?
lethal glade
I'm not sure if it's set after we exhaust all the retries
let me see if I have a recent one on my account
tranquil path
Of if its set for automatic cancel at future date, will it still fire off an update event with cancled_at populated
which brings me to the confusion of the wording above. canceled_at will reflect the time of the most recent update request
lethal glade
If you call https://stripe.com/docs/api/subscriptions/update and set cancel_at_period_end: true then canceled_at is set to the current timestamp, and you get customer.subscription.updated
tranquil path
So if a user inside their portal cancels their sub at end of billing cycle, and im listening to canceled_at then that would be wrong, id end up killing their service now when they are expecting to get another week out of it.
lethal glade
and then, every time you call https://stripe.com/docs/api/subscriptions/update on that Subscription then canceled_at will be updated
correct
canceled_at just means when the plan to cancel was done
in your example you want to basically track that they plan to stop at the end of the period and once you later get customer.subscription.deleted that's when you purge them from your database or mark them as canceled
tranquil path
Okay, square one. What should i be looking at to know when a need to cut a sub expiration early, whether they set to cancel at end of cycle or they were cancelled immediately?
tranquil path
Will the cust.sub.deleted fire off as a result of an automatic cancel such as time based?
lethal glade
yes
tranquil path
Oh, that helps, i assumed just update would happen on auto time based expires
lethal glade
If you cancel immediately => customer.subscription.deleted immediately
If you mark to cancel at the end of the period => customer.subscription.updated immediately and then customer.subscription.deleted at the end of the period when really canceled.
If customer fails all payments and you have the default settings to cancel after 3 retries => customer.subscription.deleted when Stripe automatically cancels the Subscription for you
tranquil path
So during the customer.subscription.deleted do i still have to juggle between cancel_at and canceled_at? Or will one of those always be the right one?
In the scenario you said, sub is marked for cancel at date, when date comes it auto fires off sub.del event, which property is going to hold the cancel time? cancel_at or canceled_at in the customer.subscription.deleted event?
lethal glade
canceled_at would hold "when was that subscription marked to cancel"
but you likely don't need that information at the time the subscription is canceled, you just know it's now canceled/fully ended
tranquil path
so programming wise, safe to just ignore the dates, just the fact event triggered then just set expTime=now();
tranquil path
And if i use the sub obj API to cancel a customers sub now, it will still fire off the cust.sub.del event in the background?
wanton thorn
Hi @tranquil path I'll take over this thread, give me a min to catch up
tranquil path
It's all good, i was pretty much done, that last question i will run some test and it will either or it wont.
wanton thorn
Just want to be clear, are you talking about this cancel API? https://stripe.com/docs/api/subscriptions/cancel
wanton thorn
Got it, it's the same API. Yup you will receive the customer.subscription.delete event.