#bzlatz_unexpected

1 messages ยท Page 1 of 1 (latest)

ornate haloBOT
#

๐Ÿ‘‹ 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.

tawny forge
#

๐Ÿ‘‹
Can you share a request Id and what are you expecting exactly ?

ionic zodiac
#

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.

tawny forge
#

This is the request for creating a Subscription Scheduler from a Subscription

#

And not the update request

ionic zodiac
tawny forge
#

No

#

Between, that's a live mode request. you should do tests in test mode instead.

ionic zodiac
#

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.

tawny forge
ionic zodiac
#

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 ?

ornate haloBOT
tepid crater
#

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

ionic zodiac
#

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)
tepid crater
#

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?

ionic zodiac
#

I actually don't have the second invoice since I removed the pending prorata and refunded the customer at their request.

tepid crater
#

The Invoice still must exist

ionic zodiac
#

Ok let me give you everything

tepid crater
ionic zodiac
#

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)
tepid crater
#

You want to move the unused time from one Invoice to another?

ionic zodiac
#

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.

tepid crater
#

Yes and it moved successfully.
How did this happen exactly?

ionic zodiac
#

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 ?

tepid crater
#

Did you create the pending item yourself?

ionic zodiac
#

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

tepid crater
#

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.

ionic zodiac
tepid crater
#

Not sure what you mean by ""force" the immediate application" exactly

ionic zodiac
#

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

tawny forge
#

This varies widely from one use case to another, but yeah creating a proration should work here I think.

ionic zodiac
#

Yeah, we did do some tests, but I don't think we're fully aware / expert enough yet on Stripe

#

Anyway, thanks for all the help !