jscheel

[gilded coyote]

Hi there

[waxen jackal]

hi @gilded coyote !

[gilded coyote]

So all you really need to focus on here is the end_behavior of your Sub Schedule: https://stripe.com/docs/api/subscription_schedules/object?lang=node#subscription_schedule_object-end_behavior

[waxen jackal]

right, with release, correct?

[gilded coyote]

As long as you set that to release then the Sub Schedule will end but the underlying Sub will continue

So you can just do one iteration of the phase and then let the schedule release

[waxen jackal]

so, in that case, I am essentially using schedules as staging for changes?

[gilded coyote]

Yep that's what you are looking to do, correct?

[waxen jackal]

yes, I think that is totally fine for me to do it that way. I was just confused about if I should be maintaining an indefinite subscription with schedules or if I should just be treating schedules as staged changes. One other question about this: We have a situation where our automated spam detection will close suspect spam accounts and set the cancel_at_period_end on the subscription. 99% of the time, it's right, but every once it a while it catches a legitimate account. We have a manual review process that activates, then we unset cancel_at_period_end if the account is legit. By introducing scheduled changes, we run the risk of closing an account that had changes scheduled in the future. The process I am considering is to release the schedule immediately, set the cancel_at_period_end, then if we deem the account to be legit, look at the released schedule and rebuild a new one from it. Is that the appropriate approach there?

I'm assuming there's no way to maintain future phases but inject a cancellation in the middle of them that I might later rescind 🤔

[gilded coyote]

Yeah the way you described is what I'd recommend.

Anything else would just be more complicated imo

[waxen jackal]

awesome, thank you so much!