#MikeD-sub-proration-calculation
cinder abyss
shadow zealot
Do you have an example?
Because they are looking to Change the Quantities.
But don't want to bill them. Then once they say. Yeah looks good. Then go ahead and invoice them
shell zealot
Hi 👋
The process of previewing prorations by retrieving an upcoming invoice is discussed here in more detail:
https://stripe.com/docs/billing/subscriptions/prorations#preview-proration
But the way you can leverage that endpoint is to tell it to retrieve an upcoming invoice, while also passing parameters that are used in the calculation so you can simulate the changes you're considering making without actually making them.
For example, if you're retrieving the invoice for a specific subscription, then you can use the subscription_items hash to pass in adjusted parameters (like quantity) to changed the data used for calculating the preview:
https://stripe.com/docs/api/invoices/upcoming#upcoming_invoice-subscription_items
shadow zealot
Yeah I have done something like this already.
Will be testing today
I really think this should be built into the libraries. Or Stripe should publish their prorate algo
Because it would be much better to pass to the front end the sub and the sub items) and let a front end component do the calc never having to bother your servers or the backend
shell zealot
Hm, that's an interesting idea, but I'm not sure it'd be able to do that without reaching out to our servers. It seems to me like the current subscription details would at least need to be retrieved.
shadow zealot
Right. But the calc portion wouldn't
Also, almost every single System that integrates with stripe collects the sub and sub items locally too.
Laravel Cashier , Python Stripe etc. ,
Even if they don't they can make a call for the sub and the items -> send that to the front end. Then the front end knows the items and the sub. Then can use the algo provided by stripe to calculate the prorate.
Obviously there would have to be a disclaimer about (Seconds of the time of purchase)
For example. At the time of calc it might be 12.74 delta. Then by the time they click Submit it might be 13.12 because they waited another 3 or 4 minutes
shell zealot
Ah, interesting, thank you for that clarification. I'm going to capture that feedback to relay to our teams.
shadow zealot
Yeah, I mean the protation algo shouldn't be a secret. I mean it is what it is you know?
Also, I don't understand something here
each additional is 4.50 actually.
Clicking off prorate. Yields correct result.
So what happens with the remaining for the billing cycle ? Is it invoiced immediately? Or ?
Who came up wtih this logic?
a proration is a proration. Not a proration ADD
shell zealot
Sorry, I'm having a bit of trouble following what you're doing as we're not very familiar with the Dashboard flows here.
shadow zealot
Ok.
So there are 2 product prices in the subscription
Core and Storage
Both which have graduated pricing
Core - 1st Tier - Up to 49 = $5 / mo - 2nd Tier - $4.50 a month
Storage 1st Tier - up to 15 = $0/mo - 2nd Tier - $0.20 a month
Now, let's say customer Decides to add an additional unit to the Core Product/Price
1/2 way through the billing cycle.
a Prorate should be $2.25 (charged immediately). and the following bill should be + $4.50
With the logic that stripe is implementing.
It is saying. We'll take the Prorate + The Standard Charge and simply add it to the next months invoice.
How is this a problem in SaaS world?
Let's imagine the scale was different or it wasn't graduated pricing.
Let's imagine it was standard pricing. - Price is 5 a user per month
Customer Signs up with 1 User.
Then immediately goes into his account and CRANKS it to 1,000 users
Then end of month comes and customer decides to cancel his account before month end
Well, Guess what that next invoice never got paid. So the user technically got 999 users for 1 month for free.
shell zealot
That is a valid concern, which is why we have multiple proration behaviors available, including one that forces an invoice to be generated immediately rather than adding the prorations onto the next invoice:
https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior
https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
If this is a scenario that you're worried about, I would recommend that you test the always_invoice proration behavior to see if that is a better fit for what you're trying to accomplish.
shadow zealot
Possible to update this from the dashboard for testing?
shell zealot
Not terribly certain how to mirror that via the Dashboard, but I think you can do so by selecting the "Reset the billing cycle" checkbox during the update process.
shadow zealot
It's alright I am testing it right now.
Interesting I set it programmatically. But the returned object is missing this field?
shell zealot
That's expected, proration_behavior is not a field on the Subscription object, but is rather an input parameter specific to updating a subscription (or creating a backdated subscription).
shadow zealot
Yeah it's just interesting. Because that is as you see a pretty standard concern.
As we all know since we're all programmers. If you have this vulnerability and your site or whatever gains traction. People can exploit this vulnerability through bots etc.
Potentially losing thousands of dollars.
I would figure it would almost be a default behavior. but I will continue to test.