#steve_17024
stable geyser
warm willow
Hello! Yeah, what's up?
mighty sonnet
hey Rubeus
here's the subscription: https://dashboard.stripe.com/subscriptions/sub_1Nvo3fKwepuboAKVgj27wh9T
here's the subscription schedule change: https://dashboard.stripe.com/logs/req_9UaMKkruM0lGmp
The scheduled change should reflect a different usage price, but on the subscription this is what we're seeing
wanted to confirm with the subscription scheduled change whether we've set it up correctly.
namely the payload in each of the phases.
warm willow
The second phase is only one second long. Is that intentional?
mighty sonnet
context here is that we're trying to tie the subscription change to the billing cycle anchor and time it to the next invoice.
so in order for us to do that, we made the start_date of the next phase on the targetted billing cycle anchor and end_date immediate after so that it would change immediately
e.g. if today is Sept 29, and billing cycle ends on the end of each month, we want to schedule the subscription change so that the next phase kicks off right on Oct 1
warm willow
Right, that explains the start date, but why is the end date one second later? You're specifying that that entire phase has a total duration of a single second.
mighty sonnet
what would we do to specify that the end phase should be indefinite?
it looks like this atm. which appears to be correct?
but not sure
warm willow
The end_behavior of a Subscription Schedule defaults to release, which means the Subscription controlled by the Subscription Schedule will continue to use the last phase's behavior after the Subscription Schedule ends. Typically the last phase represents the last scheduled period change, so i in this case (with a monthly Price) I would expect the last phase to last a month.
Really though, what I would probably do in this case, is omit end_date from the last phase and instead set iterations to 1: https://stripe.com/docs/api/subscription_schedules/update#update_subscription_schedule-phases-iterations
Can you give that a try and see if it does what you expect?
mighty sonnet
before i try that, what would happen if the last phase only lasts 1 second?
warm willow
I honestly don't know. I assume the Subscription Schedule would release the Subscription after that and the billing cycle anchor would be offset slightly. I've never tried a single second phase before; it just doesn't make sense to do something like that, and I'm worried you'll run into unexpected behavior if you do it like this.
Why do you want it to be a single second instead of one iteration?
mighty sonnet
if it's one iteration, then what happens after that itertions is over?
the documentation seems to suggest that it only lasts for the specified number of iterations
warm willow
The Subscription Schedule only lasts that long. After that iteration the Subscription Schedule will release the Subscription according to the end_behavior I mentioned above.
I recommend you try this in test mode and see how it works in practice. You can use a Test Clock to advance time several months to see how things play out: https://stripe.com/docs/billing/testing/test-clocks
mighty sonnet
so in our payload, we dont specify end_behavior which if the default is release as per your comment above, it sounds like the current subscription keeps going?
Behavior of the subscription schedule and underlying subscription when it ends. Possible values are release or cancel with the default being release. release will end the subscription schedule and keep the underlying subscription running
i'll verify with the test clock in the meantime
warm willow
Yes, that's correct.
mighty sonnet
so if the subscription keeps going, im assumimg that also means any price items/products with that subscription keep going?
warm willow
Yes.
mighty sonnet
then in theory we should be ok. but like you recommended, will confirm on sandbox