#mick23_code
vapid gladeBOT
👋 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/1347208281822593074
📝 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.
- mick23_proration-logic-for-upcoming-invoice, 9 hours ago, 146 messages
long karma
Just following on from this conversation from yesterday - https://discord.com/channels/841573134531821608/1346969219010658335 (read top to bottom, probably only need to read the last + first comments, ignore the rest.
"Looks like you made lots of changes to the subscription on 5 Mar
https://dashboard.stripe.com/test/logs/req_3G8bQBFfqu736s and you also disabled proration in this particular request
https://docs.stripe.com/billing/subscriptions/prorations#disable-prorations When prorations are disabled, customers are billed the full amount at the new price when the next invoice is generated. Is this the behaviour you want to achieve?"
Did I want to disable prorations? No.
That may explain why I'm seeing figures I'm not expecting.
Here is the code;
Subscription resource = Subscription.retrieve("sub_xxx");
SubscriptionUpdateParams params
= SubscriptionUpdateParams.builder()
.addItem(
SubscriptionUpdateParams.Item.builder()
.setId("si_xxx")
.setQuantity(newQuantity)
.build()
)
.build();
Subscription subscription = resource.update(params);
So the code hasn't explicitly disabled prorations, so why would that have turned it off?
stable falcon
Can you share a new test request you made with this code, and explain the result you're trying to achieve?
long karma
Let me create a new request now, one minute
stable falcon
From the other thread, i understand you're seeing a prorated invoice amount you consider unexpectedly high
So i'd like to see a fresh example of that, and have you explain what you expected to happen instead of what you actually see
long karma
Done
sub_1QxV8jE9qTMxDj1EixKxaTpq
si_RrDZgO2rveFHNd
Quantity has increased +1 as expected
And the amount due has increased by ~£1000
To £3111 ex tax
So even without all the adding/removing of users by changing the quantity while testing, the maximum I'd expect to see on the next invoice would be 3x £500 (for next months pre-payment) = £1500 + maybe 1-5 days of activity while these users have been getting added/deleted over the last couple of days, so say a £2-300 maybe at most.
One thing I've been wondering around the calculations, is the new user getting charged from 28th Feb - 5/6th March in total, even though they were only added/removed within a day period?
That is something that may be explaining the higher figure. i.e. they aren't just being charged for the 1 or 2 days they have been active, but the 6-7 days each time they get added/removed? Which would certainly explain the higher figure.
stable falcon
Where are you seeing an unexpected higher amount?
There are a ton of updates on this subscription, so i can try to explain but you'll likely get a clearer picture with a new test subscription with a cleaner history
I think you're looking at an upcoming invoice preview, which then i think boils down to a misundertanding of prorations and pending items
long karma
Yes that's right, it's the upcoming invoice here --> https://dashboard.stripe.com/test/subscriptions/sub_1QxV8jE9qTMxDj1EixKxaTpq
stable falcon
Unless the prorations are immediately invoiced (optional under normal conditions, required when changing billing interval or changing from free<>paid), the default behaviour is to accrue pending items
so for example, if you had a price that was 100/mo/seat
and you had a sub subscribed to a single seat, so 100/mo
if you update them to 3 seats (two more) in the middle of the billing period, what happens by default is:
1/ they get a credit for the half unused month of 1 seat (-50)
2/ they get a debit for the half remaining month of 3 seats ( +150)
3/ none of this is invoiced right away but is pending the next renewal
then on the next renewal you'd expect:
1/ normal recurring 3 seats (300)
2/ additional sum of pending items (+100)
and the invoice would be for 400
does that help explain what youre seeing?
the next month, assuming no further changes, would be the base 300, with no additions from pending items
if you want to charge your customer the prorated amount for the new seats for the current month when you make the update, you can use proration_behavior=always_invoice and they will be charge immediately for the prorated extra seats for a half month (100), then the renewal at the end of the period would just be for the 300.
long karma
That's well explained. Yes that is what I would expect to see.
Given that, I think you're right here, it's going to be best to test this end to end process on a brand new subscription as this existing one has got a little messy to say the least.
Then hopefully I can see what this practically looks like
stable falcon
Yea, i would recommend that
i think you've got some cruft of a bunch of changes built up on that customer/sub
i suggest creating a new customer + sub for a clean test
every quantity update was accruing additional pending items to be invoiced on the renewal
long karma
The existing subscription is probably right, it's just very confusing to look at, and given there have been so many changes, it's difficult to calculate easily. I'm just seeing in my head in simple terms of 1 user originally, about 5 attempts at adding/removing users while testing, which only existed for a day or two, currently at 3 users, so bill should be around £2k maybe. But that's probably too much of a simple calculation to use.
stable falcon
long karma
I'll have a fresh end to end test of this today and try to trace each step through one by one to check the amounts.
stable falcon
this update in particular decreased quantity from 3 to 1 with prorations disabled, which is likely where the bulk of the extra billing comes from
because you removed two seats for the rest of the month without creditting
long karma
ah that's where it's happening
stable falcon
and then increasing quantity again leaving prorations enabled would effectively double bill that usage
long karma
So when I did that bit via the Stripe Dashboard (because I haven't built the API versino of Remove User) then that has turned the prorations off, hence the larger billing.
stable falcon
yep
long karma
That's making sense now.
That was the needle in the hay stack that we were struggling to find yesterday.
long karma
Probably best I build the API version of Remove User then so I can test 100% of the add/remove via the API for consistency.
That gives me something to be having a play with today anyhow. I'll give this another end to end run through once I've got that implemented and will pop back if anything looks odd.
stable falcon
Yep, and you can also leverage our Test CLocks API to test how prorations look at various points in the billing cycle etc
long karma
That's good to know, I've not come across that yet so I'll add that to the reading list.
stable falcon
There's also support for that in the Dashboard, but i'd recommend using the API/SDKs for reproducible test sequences
long karma
Great, thanks. Right, leave it with me, I'll have another play. 👍
Thanks for the help, as always!
stable falcon
NP!