#defekt7x

1 messages · Page 1 of 1 (latest)

stone meadowBOT
upper basalt
#

It sounds like you're trying to change the interval of the subscription (e.g. from 1 month to 6 weeks, for example). Can you change the billing cycle anchor and also add a new trial? I suspect that's what you want to do.

mortal karma
#

How would I do that? The only options for billing_cycle_anchor are now or unchanged, I can't provide a timestamp (the date the trial ends, which would be preferred)

upper basalt
#

What are you trying to do by changing the interval?

mortal karma
#

A december promotion where users can upgrade from a Monthly plan to a Quarterly or Annual plan for some savings

upper basalt
#

Got it. Okay, in that case you would need to:

  • end the current trial
  • reset billing cycle anchor to now
  • update the interval for the subscription to whatever new interval they want
  • create a new trial
mortal karma
#

so I'm really just updating the subscription and setting a new price ID, creating the necessary prorations, applying a coupon, and resetting the billing cycle anchor

#

I can end the current trial and create a new one in the same API call when updating a subscription?

#

If it has to be done in a separate call, then wouldn't the user already be charged from the prior call when ending the trial and resetting the billing cycle anchor to now? at that point, what good is the new trial?

upper basalt
#

Have you tried not doing anything with the trial? I can't remember if you have to update it or not when upgrading and the server is a bit busy right now so I can't repro for you

mortal karma
#

If I don't do anything then it uses the existing trial_end value which is > the billing_cycle_anchor timestamp (now) so it gives the same error message

upper basalt
#

Got it. Is there a reason you don't want to simply create a new subscription entirely? I'm not sure if what you're wanting is possible via just 1 subscription update and it may be simpler to just create a new subscription altogether, then cancel the existing subscription.

mortal karma
#

I think just for simplicity. Canceling a subscription even though the user is upgrading kind of messes with our data and churn numbers, will fire cancellation emails and such that won't be needed. The application wasn't really built around that concept. I figured a subscription update would be the recommended approach for something like this, not an entire new subscription.. but understood if there's a limitation in this case.

upper basalt
#

It's a limitation of making only 1 update to the subscription. You could retain the subscription without creating new ones if you use Subscription Schedules instead. Those allow you to define periods of time (called phases in the API) where specific Subscription behavior is desired. So you could have:

phase[0] as the Subscription's trial period
phase[1] as the paid period going forward from there

I'd definitely give them a look, as they are kind of the catch-all for niche billing scenarios and they open up a lot of extra customization options as a result: https://stripe.com/docs/billing/subscriptions/subscription-schedules

Learn how to use subscription schedules to automate changes to subscriptions over time.

mortal karma
#

Will do - appreciate your help!