vfatia_api

[wide pivot]

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1257562049568047154

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

[azure raft]

Hi there, you can set proration_behavior to none to disable prorations. https://docs.stripe.com/billing/subscriptions/prorations#disable-prorations

[rotund zephyr]

Hi! Yes I'm already using that as part of the mix. The key problem is that I'm not able to update the quantities before the invoice is created/finalized

[azure raft]

Hi! Can you share the request ID (req_xxx)? Here's how you can find it: https://support.stripe.com/questions/finding-the-id-for-an-api-request

[rotund zephyr]

Sure. 1s

For example req_p1u2spJ2AuCeBb

Or req_desVfI13pCV5gC (where I tried using invoiceItems instead)

[azure raft]

Hmm, why do you want to change the quality on the invoice line items? I believe you should update the subscription directly https://docs.stripe.com/billing/subscriptions/upgrade-downgrade

[rotund zephyr]

Right the problem is when do I update that quantity. The root of the problem is us trying to use proration when adding seats and not refunding when removing seats mid-cycle.

When removing a seat mid-cycle we actually don't want to update the quantity because that seat is already paid for the remainder of the cycle, hence the need to update the seats when a new cycle starts

Granted we could store the purchased seats on our side, but looking to avoid that

[azure raft]

If you set set proration_behavior to none, the updated number of seats will only be reflected in the next invoice.

So I still don't understand why you want to modify the quantity of the invoice line item directly

[rotund zephyr]

What we saw when testing was that if we set the proration_behaviour to none and updated the quantity as soon as a new user was added the billing would trigger for it.

For example

• The month starts with 10 users
• 2 users are added mid month –> a prorated invoice is generated
• 1 user is removed –> proration_behaviour was set to none, no refund or invoice is issued
• 1 user is added back –> a prorated invoice is generated

This last user is already paid for for the month, but in our testing an invoice was still generated for them.

I will double check but this was the behaviour we saw

And confirmed. Removing and adding a user mid-cycle triggers an invoice for the new user

[azure raft]

What's the subscription ID?

[rotund zephyr]

sub_1PXeyHBwkHHkhPHy74LpSYdb

[azure raft]

https://dashboard.stripe.com/test/logs/req_pyye9eX32Q7aKh the proration_behavior that you set is always_invoice

[rotund zephyr]

So is that the source of the problem when we add users?

Ok let me change that

Sorry but I'm seeing the same behaviour after switching to create_prorations

• 1st screenshot is after creating a new invoice showing 4 users
• 2nd screenshot is after removing and adding a user (total should have remained $26)

[azure raft]

Why do you want to switch to create_proraitons? I thought you want to disable prorations?

[rotund zephyr]

We want prorations when adding seats mid-cycle because we offer yearly billing as well which is an awful long time to not be paid

[azure raft]

Share with me ID of the invoice in the 2nd screenshot

[rotund zephyr]

in_1PXzS4BwkHHkhPHyIn5AylBh

[azure raft]

https://dashboard.stripe.com/test/logs/req_icob2NkijJ9JiU i still see proration_behavior:"create_prorations", in the request

[rotund zephyr]

How should we do it otherwise if we want to bill/prorate when new users are added?

[azure raft]

So this is what happend

In req_C3m1iNHPGn7aSy, you set the quantity to 1 and disabled proration
In req_icob2NkijJ9JiU, you set the quantity to 2 and enabled proration

Since the latest request enabled proration, the resulting invoice in_1PXzS4BwkHHkhPHyIn5AylBh is prorated

[rotund zephyr]

Correct, which is why I was looking to not update the quantities when a user is removed so that the subscription always represents the paid seats and update the values when the new subscription cycle is started through invoice.created

[azure raft]

I don't see a easy way to achieve it. You might want to edit the draft invoice when it's generated and add in the appropriate line item to offset the proration credit generated from quantity decrease.

[rotund zephyr]

Yeah that would be an option. I think I will be tracking the purchased quantities on our DB and use that to decide when to bill for new seats