#nita1234_api
lament owlBOT
đź‘‹ 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/1420407766174142586
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
tight ember
Hi there! Can you provide a little more context as to what is the unexpected behavior here? What is the desired behavior you are expecting in this case? Can you share the request ID for the subscription you're describing in your example?
visual olive
When a renewal invoice goes past_due, and the customer later pays it, the customer is charged the full subscription amount as if the cycle had started on the original billing date (e.g. 1 October).
Then, when I update the subscription with billing_cycle_anchor = now (e.g. 7 October), Stripe resets the billing cycle — but this creates another full charge for the new cycle, starting from 7 October.
The result is that the customer effectively pays twice for the same period (once for the past_due invoice and again for the new anchor), even though my intention is simply to shift the cycle forward so that the next invoice will be due one month later (7 November).
What I want to achieve is:
When the customer pays a late invoice, that payment should cover the subscription until the new anchor date.
From there, invoices should only continue on the new schedule (e.g. 7 November, 7 December, etc.), without double billing the customer for overlapping periods.
tight ember
Got it. One approach is to use a free trial in combination with billing cycle to avoid the double charging that you're describing
https://docs.stripe.com/billing/subscriptions/billing-cycle#configure-proration-behavior
lament owlBOT
visual olive
I understand how this could prevent the double-charging issue, but in our case it creates problems with our reporting and analytics:
We would be recording these customers as “trialing” when in reality they are fully paid users.
It also introduces inconsistencies in our entitlement logic, since “trial” is treated differently from “active paid” in our system.
@somber lion @tight ember
somber lion
Why do you need to reset billing cycle anchor like this? Does access to your product reset at the end of the month and you don't provision access again until the customer pays?
Because there's not a way to not generate a new invoice when resetting the billing cycle anchor
Even if you did it via a trial, an invoice would be generated at trial end
So you'd have to hack around this via a discount or negative invoice item or something
But curious why this is a use-case. It's not something I've heard before
visual olive
When invoice is in status "retrying" we revoke the customer access. So user is paying full price even though the access is removed during retrying period. I know this kinda looks like edge case but thats how our requirements are
somber lion
Got it. So yeah in stripe we always generate an invoice when resetting billing cycle anchor
So you're going to need to create a negative amount invoice item for the total to credit the user for the amount of the invoice to bring invoice total to 0
You call this right before resetting the anchor: https://docs.stripe.com/api/invoiceitems/create#create_invoiceitem-amount
And can pass the subscription id to apply it to: https://docs.stripe.com/api/invoiceitems/create#create_invoiceitem-subscription
And it'll get pulled in automatically to that next invoice (created from resetting the billing cycle anchor)
visual olive
what about scheduling subscription does this provide me an alternative solution ?