#bzlatz_unexpected
1 messages ยท Page 1 of 1 (latest)
๐ 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/1368878509660835850
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
๐
Can you share a request Id and what are you expecting exactly ?
I think this is the one : req_AEKM4kz1ZiNPu3
Full context is :
- We had two running subscriptions that we wanted to merge into one.
- Subscription A was kept ongoing (billed every 6 months)
- Subscription B was cancelled at the billing end date of Subscription A with a prorata of unused time
Every single result from this use case never actually applied the prorata on the next invoice of Subscription A. It was always applied on the 2nd invoice.
This is the request for creating a Subscription Scheduler from a Subscription
And not the update request
Is it this one ? req_apM961OhiCi39d
No
You can check each request via your dashboard first:
http://dashboard.stripe.com/logs/req_apM961OhiCi39d
Between, that's a live mode request. you should do tests in test mode instead.
Yep, that's where I am in the Dashboard. Still getting familiar with Stripe. Not sure exactly what request you need. I only have Schedules or that last request I shared.
I'm inspecting a past live mode request.
I'm basically unclear as to why our past API calls and schedules have always added the prorata on the 2nd invoice, instead of the 1st invoice.
But when I just did it yesterday, directly from the Dashboard, the prorata applied to the first invoice.
Are you making an update or what exactly? What APi call you are doing? because the request Id you've shared it's just for Scheduler creation..;
There's no action needed. I'm just investigating the variables and expected behaviour so we can avoid it in the future
Would an event_ID help you instead ?
or could I give you the customer_ID ?
Hi. I'm taking over from my colleague. Please, give me a moment to catch up.
You mention "next Invoice" and "2nd Invoice", could you please share the Invoice IDs? in_xxx
Hello. Thanks, let me get them for you.
Here is the 1st invoice : in_1R2bGbAn2h8cdWu9gOq2Uk2w
There was no prorata attached to it
So I refunded the equivalent prorata and deleted the pending invoice line item
- What we expected : 1st invoice would include prorata
- What happened : 1st invoice billed full price without prorata, and pending invoice item was applied to 2nd invoice (the upcoming one)
Still looking...
Where is the second Invoice with the proration?
Or, do you expect that an update to a Subscription will update an already existing Invoice?
I actually don't have the second invoice since I removed the pending prorata and refunded the customer at their request.
The Invoice still must exist
Ok let me give you everything
Can you please answer this specific question? It's important for my understanding of the problem.
No, we don't want to update an existing invoice.
Let me give you the full detail of invoices
Schedule behaviour
- Cancel subscription A at the current_period_end of subscription B and attach prorated amount of unused time to the next invoice of subscription B
Subscription A
- Invoice 0 : in_1QRbWrAn2h8cdWu9m7vreesp
Subscription B
- Invoice 0 : in_1Pyz1WAn2h8cdWu9cMODDWrV
- Invoice 1 after schedule_update : in_1R2bGbAn2h8cdWu9gOq2Uk2w
- Invoice 2 not created because I ended up refunding the prorata and deleting the pending invoice item. Then the subscription got cancelled. But this was the invoice that had the pending invoice line item (the prorata)
You want to move the unused time from one Invoice to another?
Yes and it moved successfully. It just didn't catch the finalisation of Invoice 1. It was "too late" to be attached
We don't know which parameters we should be using to avoid this.
Yes and it moved successfully.
How did this happen exactly?
Prorated amount of unused time from subscription A was created as a pending invoice line item.
It then was attached to the upcoming invoice of subscription B
But then the next invoice of subscription B didn't include the prorata.
in_1R2bGbAn2h8cdWu9gOq2Uk2w
Does this help ?
Did you create the pending item yourself?
Nope. Stripe did it automatically
"proration_behavior": "create_prorations"
It was honestly hard for all of us to identify the problem
I started updating the end date to - 1 DAY to avoid the prorata being applied on the wrong invoice
Ok, it's much easier to add a custom Invoice Item on any Invoice you want with the calculated amount. You need to listen to invoice.created webhook event and update the Invoice before it's automatically finalized.
So in the future, your recommendation would be to "force" the immediate application of the prorata , is that what you're saying ?
Not sure what you mean by ""force" the immediate application" exactly
Ok, maybe I can re-phrase my question
What would you recommend from a technical standpoint :
- to attach the prorata to an invoice before it's finalised
As in, what variables / parameters are the most important.
"create_prorations" or "always_invoice"
collection_method: "charge_automatically"
payment_behavior = default_incomplete
In the future, we want to avoid lingering pending invoice items and account balances. So we're trying to align a on a new process moving forward
This varies widely from one use case to another, but yeah creating a proration should work here I think.
In general I recommend doing couple of tests using test clocks in order to validate that this aligns with your needs
https://docs.stripe.com/billing/testing/test-clocks