#noegip-metered-plan
1 messages ยท Page 1 of 1 (latest)
Hello ๐
Give me a moment to catch up and I'll respond as soon as I can ๐ thanks
I'm using action: "set" and setting a different timestamp, but changing it action: "increment" doesn't really effect the outcome
Can you try updating the usage with action: set again and send me the request ID (req_123) for it?
sure, give me a sec
wait, it only response with a mbur_123?
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
or is that what you mean?
You can typically get the latest request from any object https://stripe.com/docs/api/request_ids
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Here, either one totally works
Yeah there we go. And thanks, checking in to that usage record
You are definitely on the right track with set, I am not sure why it would still increment here but am looking in to it.
thanks
My current theory is that aggregate_usage on the price needs to be set to last_during_period for this to behave as you are expecting https://stripe.com/docs/api/prices/object#price_object-recurring-aggregate_usage
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Still checking in to that. Do you know already if that is how you set this up?
just a sec
it's currently setup to sum up the usage of values during the period
hah lol ok
let me check if that works how I expect it, I guess i misinterpreted that
Ah there we go. I haven't had a chance to test this but I do think that last_during_period should help here
that works
and i assume it calculates how much time was used for 3 units and calculates the amount for that?
but if I remove that 1 unit half way into the month it will still bill me โฌ0.50?
(billing period is monthly)
I'm not sure I follow. Are you looking for the metered usage to be prorated in some way?
Actually, taking a step back, can you tell me the end goal here for how you want this to work?
no not prorated, so what we're trying to do is:
- have a flat fee for the first 10 units (as a base fee), which is just โฌ10,-
- every unit above that is calculated based on how much the unit was "enabled"
every unit is basically โฌ1,-
but if I use 11 units for the whole month, you pay โฌ11,-
if I use 10 units for half of the month, and than from the 15th (or so) go to 11 units, you pay just what you have used that period, so this would mean around โฌ10,50 (half of 1 unit price above the flat fee)
the flat fee is always billed upfront, but all that you used extra is paid when you're billing cycle ends
i hope that makes sense ๐
That makes sense though unfortunately I am not sure if we have built-in support for that pricing model. With the latest config we discussed, if you set a qty of 11 midway through the month the user would be billed โฌ11,-
ah yes exactly, that's why I was confused about "sum"
I expected it to sum up the usage
I am thinking on how to do this with built-in Stripe functionality
it's something 1password does for example, bill on how much seats were given out during the billing period ๐
Honestly standard prorations may be the way to go here. The line items on the invoices would look decently different but I think it would calculate this properly
i assume its a pretty common use case ๐
Or at least it would in the 10 to 11 scenario. I am trying to think of what if you went from 10 to 12 to 11 and so on (as I am assuming that that is possible)
it will always go by 1 step, but can go down for sure
same as 1passwords business model basically
Honestly this sounds like our tiered pricing may be a better fit here than the metered usage model but I am unsure how that would work with these updates
I'll try out some other setups
see how it reacts ๐
I don't think it's possible with Stripe
it mentions a similar approach, but it just bills it completely
like its now
prorating doesn't do the trick i think
I think having a standard โฌ1 price and updating the quantity as you go would work here. Can just make sure to never put the quantity below 10.
What issues are you running in to with that model that you just mentioned?
ah I get what you mean
just used the license model and ditch metered all together
set the quantity (default is 10), but if you go above just update it to that number and prorate
right?
Yeah, that would let you charge at the per seat rates prorated to the amount of time that the user actually spent at each rate