#Eben
1 messages · Page 1 of 1 (latest)
Hi there
As you noted, that event will only fire for Subs that have a Schedule attached. There is no similar event for Subs that don't have a schedule.
So you would either need to track this yourself
Or you could create Schedules for these Subs if you so desire even though they don't technically need them
How are schedules created? I'm confused why scheduling cancellation doesn't create one — where in the UI can this be done?
Ah you are only creating through the Dashboard?
We have some that occur through a web form, but yes, many are created in the dashboard directly.
Yeah don't think you can add a schedule via the Dashboard if it isn't strictly necessary. You would have to do it via the API
Mostly I'd recommend just tracking the cancellation date on your end and sending the email 7 days before.
We don't currently have any infrastructure for running scheduled tasks, so that's a big lift just to send a cancellation notice
How are you sending the cancellation notice when the schedule.expiring event fires?
In response to the subscription_schedule.expiring webhook.
Right so you do have some infrastructure then. I do understand this would be a lift.
I was reading the docs for subscription schedules, which seems to indicate that they should be created when a subscription is scheduled to cancel (bullet 2):
The other option is to just send upon the actual cancellation in this case.
We already send one on cancellation, but it's a disruptive event if it happens in error so we need to notify customers in advance.
Hmm actually it is a good point. To be clear, for normal ones you are setting it to cancel after a certain amount of cycles?
Like when you don't backdate
Usually we set them to cancel via the UI later on, when the customer requests cancellation, not after a fixed number of cycles.
Ah I see.
But they are of course still set to cancel at a future date.
Yeah it would create a Schedule on creation
But on an update you can just set a specific time to cancel so it wouldn't use a schedule in this case.
I suppose I just don't understand what a "schedule" is, then. How is it scheduled to cancel without one?
Why is the behavior different depending on whether it is set to cancel at creation time vs. later on?
One sec, let me check something.
Okay so there is a way through the Dashboard if you use cycles instead of a specific date.
So the difference in behavior is that when updating a Sub you can set a specific cancel_at: https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at
That is just an arbitrary timestamp to cancel the Sub at, doesn't require a schedule
However, when you select cycles in the UI (see on the right under Shortcuts) this does use a Schedule. Which does things based on the phases/cycles of the Sub Schedule.
But again that's only available at creation-time, correct?
Nope
You can do that on update
The problem is if you want to cancel mid-cycle
Are you only canceling at the ends of a cycle?
I have tried both "end of current period" and "custom date"
as far as I can tell neither creates a schedule
and, unfortunately, we often need to use "custom date" in practice because we support monthly billing on annual contracts, and so when the customer cancels we can't use "end of current period" as we need to push it out to the future date that marks the end of their contract instead.
Ah instead of clicking on the "Schedule update" button, click on the "Forever" button
Okay I think this will work
Try this:
1/ create a test Sub
2/ update the Sub to cancel in a certain amount of cycles (using the "Forever" button). In reality you would want to select an amount of cycles past the specific date you actually what you actually want to cancel
Step 2 here will create a Sub Schedule
3/ Now update again by going to "Actions" --> "Reschedule cancellation" and select the specific day you want to cancel
This should update the Sub schedule
Now you have a Sub Schedule and a cancellation date
What I'd recommend is using a test clock to do this and push time forward and make sure everything behaves as you want
But I think that should be a sufficient workaround for what you want while just using the Dashboard
Okay, I'll try this when I get a chance. Will that work even if the subscription is set to not cancel in the interim? That is, between creation and the time when the final cancellation date is set, it will have to be set not to cancel (so, back to forever)
Hi there. Bismarck had to step away. Give me a bit to catch up on context here
Not sure I understand. I believe you have to set the subscription to cancel in a certain number of cycles in the interim. It's a bit hacky, but this is how you get the subscription to be attached to a schedule
Okay, yes, it does seem to work. So as long as anything other than "forever" is selected at creation time, I'll get a schedule. I can then set the subscription not to cancel (essentially setting it back to forever), and the schedule remains. Will the schedule remain forever?
That's a good question. I think it might not, but can you share a subscription id where you tried this so I can have a look? I think ideally you'd execute the above flow that bismarck outlined once you know the cancellation date you want to set
I'm still confused then — I don't see how to set the "cycle-based" cancellation (to trigger the creation of the schedule) except at creation time.
I have to step away for a while, but I'll pick this up again this afternoon.
Ok the thread will likely be archived then, but you can message again in the main channel to pick back up again