#stiggz_api
ornate timberBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1352376715565076601
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- stiggz_api, 20 hours ago, 38 messages
candid forge
Hello, always_invoice shouldn't change the cycle when switching between monthly prices as far as I am aware, though I will double check. Do you have the ID of an invoice that was created that way?
proud mesa
Yeah give me a moment, I'm mostly testing with previewUpcoming
Oh retrieveUpcoming doesn't give you an id
I'll see if I can dig one up from the stripe dashboard
candid forge
Gotcha, can you send me your snippet of code for making that call and the the full response that you get from that call here? I can take a look and try to figure out what is happening from that
proud mesa
Hmm, now that I've just tried this again, it looks like the billing period did not adjust.
Maybe it adjusts only if you change from monthly -> annual?
Ahhh yeah that looks like the issue. If our new price is an annual price, the billing anchor date changes to now()
candid forge
Yep exactly, changing between prices with the same cycle length should keep things the same. Different cycle lengths are expected to start a new cycle
proud mesa
Is there a way to keep the cycle anchored to the same datetime as the original subscription after the update?
The reason this would be convenient for my use case is that we "issue" credits for each subscription. Our calculation of a user's usage is "how many credits have they used since the start of their billing cycle" / "how many credits are associated with their subscription". So you could imagine:
- A user signs up for product A and uses up all their credits.
- They then upgrade to product B on an annual subscription, paying the difference in price.
- Since their billing cycle restarted, they effectively got all the credits associated with product A for free
So in the above scenario I think there are 2 solutions.
- Keep the billing cycle start date fixed.
- Calculate the user's usage since their start date and manipulate the proration discount in some way.
Of the 2, the former sounds a lot more palatable :p
candid forge
Just double checking: this is specifically for the scenario where you are changing cycle lengths?
proud mesa
Yes it appears so. Because as you pointed out, if the cycle length does not change, neither does the billing cycle start date for the subscription in question. So no problems for me there.
ornate timberBOT
candid forge
There isn't a way to keep the cycle the same when switching cycle lengths. I think your two main options would be to calculate a prorated amount of credits given how much less they are paying. If partial credits would be an issue in that case, a way to fix that would be to pass us a proration_date for a time that would charge a whole credit amount (I have no idea if that makes any sense given how you work with credits)
https://docs.stripe.com/api/subscriptions/update#update_subscription-proration_date
And a workaround could be using a subscription schedule so that the yearly price starts when the current monthly cycle ends, so at least you are working with full cycles.