#greggles-subscription-cancel
gentle dew
Can you share subscription id's where this happened?
Could be a timezone thing
Nah subscription id's
not customer id's
edgy bronze
sub_1NQZ3jGxG8m2870UiEkS6MXm
We're worried about 2 things. A webhook will be sent on Jan 6th updating the subscription end date so their access will be cut off for the month they've already paid for.
Or good subscription who haven't canceled might be charged twice.
Here's another
sub_1Nxt7jGxG8m2870U2pfYbqqD
gentle dew
Hm neither of those subs cancelled immediately
You said We are seeing some of those monthly subscriptions cancel immediately following the firth charge
edgy bronze
Sorry, when I say immediately, I wasn't speaking literally. I mean it looks like they canceled in response to the charge, from 40 minutes to a few hours after.
My guess is they'd received the invoice showing the resumption of charges then canceled in response.
edgy bronze
gentle dew
Yeah they're active
They're set to cancel on the 6th
You unpaused them after the billing cycle anchor
So that's why there's no next invoice
The subs are technically still active though and will cancel on the 6th
edgy bronze
Our cancelation flow sets the cancel_at_period_end to true. We don't offer immediate cancelation.
gentle dew
You specifically set the end date to the 6th
So it's cancelling on the exact date you requested
lapis pierBOT
greggles-subscription-cancel
edgy bronze
Hmm. I'm setting the cancel date for the end of the subscription schedule's phase end, which should have ended 1/5/2024.
gentle dew
No if you look at those requests the end date is 1/6
Convert the unix timestamp
It's 1/6
edgy bronze
I realize the phase end is set to Jan 6th. I don't know why that is. We restarted the collection like this
['pause_collection' =>
[
'behavior' => 'void',
'resumes_at' => $jan_5_2024
],
]
The php variable is a unix time stamp for 1/5/2024 :00:00:00
So I'm wondering why phase end is set for 1/6
gentle dew
Resuming collection has nothing to do with phase end
The phase end is 1/6 because you explicitly set it as such in the request I linked
Resuming collection just resumes the generation of invoices
the sub will still cancel at the original phase end
edgy bronze
We don't normally use subscription schedules. Only in this case where we paused collection for an indeterminate amount of time, then set a date to resume collection. If a customer decided to cancel before we resumed collection on 1/5, I check for the presence of a subscription schedule and set the cancelation date for the phase end. If a person cancels after 1/5, there should be no subscription schedule so we'd set cancel_at_period_end to true.
So maybe this is just an edge case thing for people whose subscription renews on January 5th