#jarcher

1 messages · Page 1 of 1 (latest)

iron locustBOT
crystal sable
#

Hmmm, I'm not sure why this is happening. Let me dig a bit more and get back to you

limpid bolt
#

Thank you @crystal sable

#

maybe api version? using
2020-08-27

crystal sable
#

I don't think it's that, because we had support for proration_behavior on Subscriptions forever

#

Hmmm, it looks like from our docs:

cancel_at
A timestamp at which the subscription should cancel. If set to a date before the current period ends, this will cause a proration if prorations have been enabled using proration_behavior. If set during a future period, this will always cause a proration for that period.

#

I think that indicates prorations were expected in this case, even though proration_behavior was set to none

limpid bolt
#

is there a way around this? Like do I need to turn proration off with one api call and then second network request to update the cancel_at

balmy imp
#

You would set cancel_at to match the end of the billing cycle

limpid bolt
#

is there a way to set cancel_at to be at the end of the NEXT billing period?

#

or do you have to calculate that? if you have to calculate, then we could potentially be off by minutes,

balmy imp
#

Sure, just as long as your timestamp has the correct value

limpid bolt
#

and if we're off by minutes, then it gets prorated

balmy imp
#

Yes that is true

limpid bolt
#

okay got it. is there a way to modify an existing subscription (without a subscription schedule) to give it a subscription schedule?

balmy imp
limpid bolt
#

okay great. Thanks for your help here!