#ceducharme_best-practices

1 messages · Page 1 of 1 (latest)

red palmBOT
#

👋 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/1418568014156271739

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

viscid token
#

👋 happy to help

#

And what would be the best practice to have included allowance that can be changed? I thought of creating multiple tiered prices but it doesn't seem that flexible.
how so?

#

for your use case I find it very easy

#

first tier would have up_to 1073741824 and a flat_amount

#

so basically the unit cost of the first tier is 0

#

but the flat rate is x

#

and then flat rate is 0 but unit_amount is y

dapper ingot
#

Saw the transform quantity and tried to create a price following the docs, but in Stripe dashboard it was translating it weardly my price was for 1073741824 units and not 1 GB

viscid token
viscid token
dapper ingot
#

I have a number input in my dashboard that let my staff change the amount of included gb to any value needed but that wouldn't be possible with tiered pricing without creating new prices for each values. I have an other component that let's them change price used for an item of a customer subscription that could work for tiered prices but seems counterintuitive.

#

Yes I'll share it, give me a minute

viscid token
#

I have a number input in my dashboard that let my staff change the amount of included gb to any value needed but that wouldn't be possible with tiered pricing without creating new prices for each values.
yes you can map these out in your DB

dapper ingot
#

I created the price with the following params {
"currency": "cad",
"nickname": "Standard - Monthly",
"product": "prod_QxqfKTDkAPKkZ6",
"recurring": {
"interval": "month",
"meter": "mtr_test_61RFIrLIVb52oS8Jl41FOEj3lF4AU0j2",
"usage_type": "metered"
},
"transform_quantity": {
"divide_by": "1073741824",
"round": "up"
},
"unit_amount": "9"
}

viscid token
#

you didn't create tiers

dapper ingot
#

No that one was to try sending byte values in my event and have my unit being 1 GB

#

But in Stripe dashboard it was translating it weardly my price was for 1073741824 units and not 1 GB

viscid token
#

where? in the invoice you mean?

dapper ingot
#

In the price page of dashboard under the price's nickname there's the product and then Unit price, it was showing $0.09 per 1073741824 Gb / month (gb is there because my unit label is gb on my product)

viscid token
dapper ingot
#

I just recreated the price since I deleted the first one seeing it didn't seem to work

Screenshot_from_2025-09-19_08-45-06.png
viscid token
#

yes this is normal. but on the invoice it won't show like this

dapper ingot
#

Perfect so I'll try that for the bytes to gb thing, I'm still wondering what to do for the included threshold though, I want the customer to see the full usage so I can't start counting just after threshold, but I also don't like tiers since it could potentially mean having many many different prices with the same cost but different tiers, that gets bad when I want to change the cost and have to duplicate all of them.

viscid token
#

unfortunately for the time being tiers are the only way to go for your use-case

dapper ingot
#

I just saw billing credits in public preview, could that be a potential solution? Having the credit amount changed per customer and a simple per_unit metered price like the one I created.

viscid token
#

but it won't change the need for multiple prices

red palmBOT
dapper ingot
#

Really? If it's like a recurring credit for my price and it's resetted each billing period, let's say 9$ to get 100gb of included bandwidth, unused credit is lost after each billing period and a new one applies for the next period, if I want my customer to have 200gb included I set the credit to 18$. I still only have one price, the credit pays for the included amount and the customer the remaining amount.

twin canyon
#

Howdy, stepping in for tarzan who needed to step away

#

You could go down that path but i would not recommend it, its overly complex

#

At the core of the model you describe is a tiered price system, flat fee + overage

#

You'll need to either set up combined prices for each possible tier/allowance split, or use separate price for the base rate and overage rate, then you just control which meter you send usage to on your end

#

With a given price, tier breakpoints are fixed and inflexible on a per-customer/sub basis

#

IMO the simplest solution is two fixed prices: flat rate, overage rate

#

the flat rate has a fixed fee, say $100 for 100GB, and $0/unit usage and you can report usage up to whatever your per-customer limit it

#

overage rate has 0 fixed rate, and only a per unit rate of say 9c/GB, and you only send usage to that meter when the customer exceeds their allowance

#

You can certainly explore other options, but i'm reasonably confident every other way to get the result you want is going to be more complicated to implement & manage

#

With what I've sketched out, you use the same prices for all subs/customers of this shape, regardless of allowance. If you set up multiple prices or credits etc you need to then manage switching prices when allowances change.

dapper ingot
#

That's the kind of answer I was looking for, but it brings in another factor, switching my metered events from one meter to another, how should I go about this? Bandwidth calculation is lots and lots of data to process (if 1 million loaded files accross multiple customer websites, it means I have 1 million events to process and assign the right customer to each), I then export that as bulk csv in an S3 to have my metered usage transfered in stripe, adding a mechanism to also assign the rigth meter to use for each event would be pretty intense.

twin canyon
#

Yea, you'd need to manage that part

#

If that layer is burdensome, you can go the other route of setting up multiple tiered prices for each possible allowance amount

#

It's really up to you to determine which painful part you want to manage: swapping prices for difference allowances, or tracking allowance and swapping meters to report to

#

Personally I'd lean toward tracking the usage and overage, then reporting to the overage meter when needed, but i don't know your systems or needs

dapper ingot
#

Yeah, if I let go of being able to modify per customer included bandwidth and just have multiple tiers for 25, 50, 100, 150, 200 included gb, I would just have 5 prices, I already have the system to let my staff change individual items prices, so that would be done. I use Tinybird to merge customer data and bandwidth and then export to my s3, tracking the usage and overage could be done, but will be complex and might be error prone. If I let go of being able to modify per customer included bandwidth which one should I pick and what could be the downside of multiple tiered prices, does switching prices mid period be a problem or proration would work perfectly?

#

Also I just tried creating a tiered price with transform_quantity and thats not possible, so what can be done in that case for the bytes to GB transformation?

twin canyon
#

ie, an example request etc

dapper ingot
#

if I just send usage in GB with a decimal value (bytes consumed divided by 1073741824 bytes), is their any limitation in regards of how many decimal precision the value can have?

twin canyon
dapper ingot
#

Here's the body: {
"active": "true",
"billing_scheme": "tiered",
"currency": "cad",
"nickname": "50 GB included - Monthly",
"product": "prod_QxqfKTDkAPKkZ6",
"recurring": {
"interval": "month",
"interval_count": "1",
"meter": "mtr_test_61RFIrLIVb52oS8Jl41FOEj3lF4AU0j2",
"usage_type": "metered"
},
"tax_behavior": "exclusive",
"tiers": {
"0": {
"unit_amount": "0",
"up_to": "50"
},
"1": {
"unit_amount": "9",
"up_to": "inf"
}
},
"tiers_mode": "graduated",
"transform_quantity": {
"divide_by": "1073741824",
"round": "up"
}
}

#

And the response I got: {
"error": {
"message": "You may only specify one of these parameters: tiers, transform_quantity.",
"message_code": "multi_exclusive_parameters",
"param": "tiers",
"request_log_url": "https://dashboard.stripe.com/test/logs/req_KEElJDqkY4krSF?t=1758287915",
"type": "invalid_request_error"
}
}

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

twin canyon
#

This is why i think the simple approach is best: flat price, overage price, just report overage according to your customer allowance.

dapper ingot
#

request id: req_KEElJDqkY4krSF

twin canyon
#

This is another reason to use the simple model then, since it would work with transforms

#

Otherwise, you need to transform units on your end and send usage in the billing unit

dapper ingot
#

I don't mind converting values on my side, I just want to be sure I will get the precision I need knowing bytes to gb gives pretty big decimal values

twin canyon
dapper ingot
#

All my bandwidth prices have the same meter yes, so I guess when updating the subscription line item with a different price that uses the same meter has the price that was setted previouly the usage would just transfer and new tier would be applied in a prorated manner

twin canyon
#

You'll need to test that "hot swap" price on the same meter, I haven't actually tried that flow myself before

#

But if so, then great!

#

You can set up these quantized tiers, with whatever granularity you want to offer your team

red palmBOT
dapper ingot
#

If the usage of a meter is linked to the customer and no subscription items to bill this usage has to be setted to start recording usage, does that mean I could even just try adding a line item once the customer recorded usage hits a certain threshold, then remove it on next billing period until he hits threshold again?

twin canyon
#

I don't understand the sequence you're suggesting. It would help if you could illustrate by trying the flow and sharing some examples of what did/did not work like you expected.

dapper ingot
#

It's just an idea, I can't find docs to confirm that, but it seems like it's possible to record customer usage with a meter even if it's not used by a price. If that's the case it means I could potentially set an alert threshold (https://docs.stripe.com/billing/subscriptions/usage-based/thresholds) to received a webhook when the threshold is hit by individual customers and then add the subscription item to start charging for usage for the remaining time of the billing period (only new usage would be accounted for). Is that a bit more clear?

Set up thresholds

Set up usage thresholds to trigger alerts or invoices.

sweet crest
#

Hi there, taking over for @twin canyon as they had to step away

#

I'll need a moment to understand the context from this discussion, thanks!

dapper ingot
#

No problem, let me know if you have any questions

sweet crest
#

For the specific question of recording customer usage with a meter even if it's not used by a price, according to my understanding of the documentation this should be possible, as meters are created independently from prices. This means your approach should work in theory. However, as you note it's a non-standard use case, so I would definitely recommend thorough testing to make sure there isn't some complication that arises because the meter isn't used with a price

dapper ingot
#

Looking futher in the docs I think it wouldn't be optimal, the title in the last page of doc I sent (https://docs.stripe.com/billing/subscriptions/usage-based/thresholds) seems to say setting a threshold can trigger alerts or invoices but reading further down it seems to always invoice and that's not what i'm looking for... It's kind of a bummer, I know I don't have the most simple case but it still seems pretty basic, most Saas like mine have this kind of billing model nowadays (usage-based and included usage that may vary according to plans), Stripe should try to impliment simpler ways of doing that or at least offer better guides on how to do it. From what I learned now I know it's possible to do it but it's always based on somewhat hacky solutions that feel like they will be technical debt down the line. In my mind it should just be a field we can set on individual subscription items like included_quantity and it just substract that from the quantity when drafting the invoice. I'll try figuring out something from what you all gave me, I still appreciate the help and support, it's awsome. I don't know if you have any way of sending that to someone that can change things but I think many devs would appreciate having the included_quantity thing I just mentionned.

Set up thresholds

Set up usage thresholds to trigger alerts or invoices.

sweet crest
#

Got it, I can definitely make the product team aware of that feature request. Thanks!

dapper ingot
#

Thanks a lot for your time, can I give you an email address or something to get a follow up on that feature request?

sweet crest
#

I can attach the feature request with your account ID which has the necessary contact info. Is acct_1G8sYMFOEj3lF4AU the best account ID to use in this case?

dapper ingot
#

Yes that's perfect, thank you!