#rp
1 messages · Page 1 of 1 (latest)
*Specifically I'm passing in unix timestamps set to the start of each date in UTC
hey @maiden bramble -- proration uses time (days, if i recall correctly) to calculate amounts
Looking at that subscription
thanks!
Looking at your creation request, the backdate is to jan 25 at 8am (UTC) while the billing cycle anchor is to June 25 at 7am, so the days/months aren't aligned there. Is that 2c delta possible 1hrs worth of difference over a month?
Looks like it might be. 15.72/720hrs is ~0.02
This worked, thanks a lot 🙂
Huzzah!
had one more question if that's ok - it seems like once a subscription becomes past_due, if the customer pays the latest invoice, the subscription becomes active again even if the previous invoices remain past_due. Is there a way to change that behaviour?
E.g. sub_1NLtJXCwsLkfK67Bjep3YDh6
Thanks for the ID. Catching up and checking in to it
Unfortunately there isn't a way to change that behavior at the moment. I am trying to remember if there is a workaround that we typically suggest
I think it may just be custom logic on your end that checks for previous invoices being unpaid (or maybe something in your DB that indicates if there are any) and not provisioning the service if so
Hmm gotcha, I guess in that case I should just ignore the stripe subscription status?
Yes, it looks like that would be the way to achieve this behavior. You can add other things to make the logic easier but you will need to consider more than just the subscription status
Got it, ok thanks for your help! Will work around that
Could a feature request be put in to support that? It would be nice to have that as a built-in option
Sure, I can definitely write one in for that. I definitely get the want to charge retroactively for those invoices. I think the assumption for the current behavior is that access was cut off anyway so there wasn't something to charge for