#arghh-schedules

1 messages · Page 1 of 1 (latest)

tender magnet
#

generally you'd update the existing Schedule with new details. So for example if it was (jan->feb 1x Gold plan ; Feb->Mar Platinum plan) and they choose to update to 2 quantity , then you update the schedule with two phases again, (jan->feb 2x Gold plan ; Feb->Mar Platinum plan)

#

you have to re-declare all the phases when updating the Schedule(phases "sets" the variable, so anything you don't specify is dropped)

junior phoenix
#

That was unexpected, good to know.

tender magnet
#

I believe updating the current subscription directly with the UpdateSubscription API also writes the change back to the current phase of the schedule. So that can simplify things a lot

#

there's not really a substitute here for testing the exact scenarios, Schedules are an extremely complicated API that it's hard to describe without just using it

junior phoenix
#

From my developer perspective it seemed "simpler" to just cancel the old subscription and start a new one, then I don't need to get confused with the Schedules API or write different flow & logic to consider the possibly existing (or not) schedule when making any changes to the subscription. This also simplifies keeping our local DB in sync with the Stripe's subscription (sub items, their id's etc).

Are there any reasons why we should not do this?

#

In a nutshell, making it work with Schedules API seems like 3x the code, and the only benefit being that we don't throw away the existing subscription object.

tender magnet
#

yeah that's all quite accurate

#

creating multiple subscriptions maybe skews the data in the graphs in the dashboard for retention and new signups and stuff, I would imagine(I don't know anything about how that data really works). That's the only other point I can think of

junior phoenix
#

Thank you, that's good to be aware of. I need to check on that.