#mandeep_api

1 messages · Page 1 of 1 (latest)

torpid jasperBOT
#

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

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

oak yacht
#

Hi there

#

Hmm if you are going to take payments up front here then Usage Based Billing w/ Subscriptions doesn't really apply here.

#

In this case you would mostly just use Stripe Checkout (or Elements) to charge and setup the PaymentMethod for future use and then you can charge it again later as you so desire. But you would track the usage on your side in this case.

pure lintel
#

I see. I was wondering because AFAICS OpenAI use Stripe Billing(?), and when I buy credits they issue invoices that link to https://invoice.stripe.com/i/acct_1HOrSwC6h1nxGoI3/live_.... And it looks like they have usage based billing, although I can't tell if they do all the usage tracking on their end?

oak yacht
#

Yeah they track the usage on their end in this case. They do create Invoices here which leads to that Hosted URL that they use for payment/receipt.

pure lintel
#

ahh I see

oak yacht
#

So if you wanted to use Invoices in place of Stripe Checkout then that works too.

#

Usage Based Billing charges in arrears.

#

So you wouldn't charge up front really unless you wanted to charge a certain amount up front and then start charging after a certain usage via arrears.

pure lintel
#

I see. So I use Checkout/Invoices to charge the user. Then, should I do something like create balance transaction / create credit grant and record usage against this somehow?

Or would I need to store balances in my own DB and update as usage occurs?

oak yacht
#

The two options are either you store the balance and record usage in your own DB or you could create Subscriptions in Stripe with Usage Based Billing and then yeah create Credit Grants.

torpid jasperBOT
pure lintel
#

I see, and the subscriptions method only works with arrears billing right?

modest elk
#

hello! fyi i'm taking over the thread, give me just a bit to catch up

#

if you're using subscriptions + usage based billing then you can use any combination of charging up front + charging in arrears

#

but if you're charging up front you still need to record usage in your own DB so you know when to start calling our meters API for the arrears billing side of things

#

so if you want to rely exclusively on stripe for being the source of truth of usage, charging in arrears is the only option

#

(actually now that i have said that i am doubting myself, give me just a bit to double check some things)

modest elk
#

ok, so if you want to do this with both a "charge in advance" and also have a charge in arrears if they go over the 1000 event limit, you would want to do something like the following:

  1. create a price that represents that flat fee you want to charge, let's say $15. just set this up as a regular recurring $15 subscription
  2. create another price that represents the meter, and set it to Usage-based, Per tier, and Graduated when configuring the meter price. Set this to be $0.00 for the first 0-1000 units and then (however much you want to charge per event after (i just decided $0.05 for the example)
  3. log usage to the meter as people use your product, and as long as they stay under $1000 they will only be charged the $15 subscription, but if they go over they will be charged per event on top in arrears
Screenshot_2025-09-16_at_10.35.47_AM.png
pure lintel
#

Still a bit unsure here. I guess to fully describe the billing model I'm after:

  • Users can sign up on a "Pay as you go" plan. £0 initial commitment, and they pay for usage (upfront by buying credits)
  • There's two different resources that cost money in my platform, say Meter A ($2/1000 usages) and Meter B ($10/1000 usages). All users pay the same rate for now, although I want some flexibility for having different rates for different users
  • Ideally users shouldn't be able to enter arrears, but a small amount of arrears is fine. (e.g. I can check if the user's balance is negative on requests and not serve them)
  • I'll likely issue some free (expiring) credits to some customers, so support for this would be nice

The "no arrears" thing is kinda important (because, esp for smaller customers, non-payment is a concern). OTOH, I'd prefer to not have to build lots of payment infrastructure on top of Checkout (e.g. expiring credits, usage tracking, etc)

Reading your message, would what you describe work just as well if I set the "flat fee" to $0 and "usage-based" prices for the activity? If so, I guess I just need some way to track the user's balance, ideally in my own DB as I understand that metering is asynchronous in Stripe (not sure how long the delay is?)

modest elk
#

fyi a few more questions have come in so my responses may be delayed a bit, but i willl get back to you asap!

#

ok so i think it might be helpful to walk through a simple specific example. with your model you described, let's say i want 1000 usages of meter B and nothing else. i just set up this subscription and don't touch it over the course of several months.

  1. am I expected to just be charged this amount every month? so i pay $10 each month and i get 1000 usages?
  2. if i get to a point where i would reach 1001 usages i am unable to do so?
pure lintel
#

you’d pay $0 initially, then you’d manually deposit some funds to your account.

say you deposit $10, then you’d manually can use the resource that charges meter B until you use 1000 units worth (over any period of time), at which point you’d need to deposit further else your requests get rejected due to insufficient funds

modest elk
#

ok so it's not really a subscription at all, i've got a balance i'm drawing from and i need to deposit more when i run out

pure lintel
#

yeah

modest elk
#

hmmmmmmm

#

i don't think we have a model that really supports that, pretty much all of our usage based billing is based on the idea of some monthly subscription

#

i can dig around in my brain for a bit to see if i can find a creative way to support that, but for now i am leaning towards you needing to basically set up a simple pricing model in stripe where you charge for X units via a price and then track usage entirely on your end

pure lintel
#

ahh I see. was hoping to avoid that as it seems like the work needed to maintain a billing system will just grow

#

was hoping my model was more common (I’ve seen a lot of providers recently start to do it. Namely AI companies that charge by usage rather than by fixed plans with overage charges)

modest elk
#

yeah, it definitely makes sense as a model

#

if you are ok sticking around i will think about ways to handle it, it's possible i'm just missing something

pure lintel
#

yeah no worries!

torpid jasperBOT
proper ocean
pure lintel
#

oh awesome

#

thanks! will try this out

#

is there a recommended way to check if a user's balance is negative before performing a task (or that they have enough credits to perform their request)? without putting a HTTP req to Stripe API on critical path preferably (so probably a webhook sent with usage?), but I could also live with a HTTP request for now

proper ocean
#

Hmm I'm not sure if there's a webhook event 🤔
let me check