#maxime1992
frigid grove
Hi 👋 I'm not sure usage-based billing will do exactly what you want, because it doesn't prorate the amount charged for the usage based on when the usage was reported.
zenith charm
Ah I see. Indeed. Is there a way to achieve what I want?
lapis vortexBOT
charred galleon
Happy to help figure that out, through after reading your description I am still a bit unclear on the end goal. Can you give me a quick example of how many licenses a user would have to pay for across a couple cycles depending on how many people were using it?
Okay so I think I get it, the IT admin says they want up to 100 licenses and they don't pay anything until their users start using them.
Like toby I think that the lack of proration handling would mean that usage-based billing would not be a good fit. I actually think you could do this well with a standard per-seat subscription and just slowly incrementing the quantity up as users use their licenses.
zenith charm
Hey @charred galleon , thanks.
So let me try to give a more in depth scenario.
Admin 1 from Company XYZ needs to manage up to 1000 users licenses.
The way I see it, Admin 1 should be able to say "I'm ok buying up to 1000 licenses" on our server. When someone with their company email domain signs up (let's call him user A), we'd then check if we're < 1000 and if so grant access, and somehow count that as 1 license used. Therefore the billing would start for this one directly. But I don't want to current user to have to worry about the billing, it'll just be a regular user, allow to use the software in the 1000 licenses the company xyz grants. Now, user B shows up 2 months later. Same thing: Check if < 1000 active licenses, yes so we grant access and start billing for that one. 1 year after their sub, they'll automatically renew and on admin side, they'll pay for a new licence for the new year (unless the admin decides to remove access for that user).
That's the overall idea. It's pretty much to allow a lazy start. Unless maybe if we could use a simple new subscrption per user in that case? But I'm not sure if Stripe allows to start a new paid sub without explicit consent first from the user (but on our side, the admin would allow 1000 licenses for ex).
charred galleon
If I understand your use-case correctly, I think you can do this with just one subscription and incrementing the quantity as more users use your service.
zenith charm
I don't think so but I could be wrong.
The quantity is only attached to 1 sub. Meaning that all the quantities "starts" at the sub starts and ends at the same time right?
charred galleon
Like let's say you have a $100/yr subscription. One user starts using it immediately so the quantity starts at 1, if someone joins halfway through the year you bump up the quantity to 2 with proration which would add $50, then bump up the quantity three quarters of the year to 3 when another user uses it adding $25 to their next bill.
Ah, you also want each license to cycle a year out from when their user starts using the license?
Also to be clear, you can start new subscriptions without explicit user action, I think you would just need to save their cards for off session usage
zenith charm
oh I see. Maybe proration would do 🤔.
Although, let say that I want the cycle a year from when they start using, is that possible?
charred galleon
To do that you would need to make a new subscription for each license, or I guess each set of licenses that cycle at the same time. That would work in that it would cycle properly for everyone but it would generate a lot of individual invoices and could be confusing because none would show the total quantity
That being said, invoices with a lot of prorations can also be fairly unclear because of how Stripe currently generates them. Each proration adds two invoice lines for "unused time" and "remaining time"
zenith charm
To do that you would need to make a new subscription for each license, or I gues...
Yep that was our first thought, create 1 sub for each license but it feels wrong to receive different invoices... And also has a cap of 500. Which I suspect we won't hit at first but hey, who knows 🙂
in our scenario with the quantity and the prorating, what happens when the number of quantities is lowered down? Like from 10 to 5 🤔. Are you paying them back? Is it credit for next year? That shouldn't really be possible. I think this could work if when someone lowers it down, it'd just not reimburse, not prorate, just not renew as much next billing. Is that possible?
charred galleon
Proration is defined per update, so you can pass proration_behavior: create prorations when increasing the quantity and proration_behavior: none when reducing the quantity https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior
zenith charm
brilliant, thanks!