TL;DR (May 2026): Stripe launched AI token billing on March 2, 2026, in preview, behind a waitlist. Most teams aren't getting access fast. The good news: you don't need it. You can build the same thing today with Stripe Meter Events (generally available since the 2025-03-31 API rev) plus a thin tracking layer. Working code below.
Stripe's March 2026 announcement was a big deal in concept and a small deal in practice. The concept: bill customers for AI token usage with a 30% markup applied automatically, across multiple LLM providers, with the meter event flow handled by Stripe. The practice: it's preview, it's gated, the waitlist isn't moving fast, and you can't ship a real product on something you can't access.
Here's the thing the announcement coverage mostly missed: the preview is mostly a convenience wrapper. The underlying primitive (Stripe Meter Events) has been generally available since 2025-03-31. If you want to bill for tokens this month, you wire it yourself in about a day.
What the preview actually gives you
The preview adds two convenience layers on top of Meter Events:
- Auto-detection of model pricing. Stripe tracks the published per-token cost of major LLM providers (OpenAI, Anthropic, Google) and updates the rates as the providers change them. You don't have to maintain a price table yourself.
- Markup-as-a-config. You tell Stripe "charge a 30% margin above raw model usage" and it applies the math without you computing it. Useful if you resell raw model access and your margin is the entire product.
Both are nice. Neither is blocking. You can build the same thing with a per-provider price table you update quarterly and a multiply-by-1.3 in your billing service.
The do-it-yourself version, today
The flow:
- You call the LLM (OpenAI / Anthropic / Gemini / whoever).
- The response comes back with usage data (input tokens, output tokens, model name).
- You convert tokens to dollars using your per-model price table, apply your markup, and emit a Stripe Meter Event with the customer ID and the amount.
- Stripe accumulates the meter events and bills the customer at the end of the period.
Here's the Python version:
import stripe
import openai
# Your per-model rates (update quarterly)
RATES = {
"gpt-5": {"input": 0.003, "output": 0.015}, # per 1K tokens
"claude-opus-4-7": {"input": 0.005, "output": 0.025},
"gemini-3-1-pro": {"input": 0.002, "output": 0.010},
}
MARKUP = 1.30 # 30% margin
def call_llm_and_meter(customer_id, model, prompt):
# 1) make the LLM call
response = openai.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}]
)
# 2) extract usage
usage = response.usage
rate = RATES[model]
raw_cost = (usage.prompt_tokens * rate["input"] +
usage.completion_tokens * rate["output"]) / 1000
billable = raw_cost * MARKUP
# 3) emit Stripe Meter Event
stripe.billing.meter_events.create(
event_name="llm_usage",
payload={
"stripe_customer_id": customer_id,
"value": str(billable),
},
)
return responseThat's it. Twenty-something lines for the core. Add error handling, retries, and a circuit breaker for the Stripe call (you don't want a Stripe outage to break your LLM endpoint), and you're at maybe sixty lines total.
The Stripe meter, set up once
On the Stripe side, you create the meter once via the dashboard or the API:
stripe.billing.meters.create(
display_name="LLM Usage",
event_name="llm_usage",
default_aggregation={"formula": "sum"},
customer_mapping={
"type": "by_id",
"event_payload_key": "stripe_customer_id"
},
value_settings={"event_payload_key": "value"},
)Then you attach it to a Price (probably $1 per unit so your meter value is already in dollars), and put that Price on the customer's subscription. From that point on, every meter event accumulates and shows up on their invoice at period end.
The gotchas
A few things that will bite you the first time:
Meter events are write-only. Once you send an event to Stripe, you can't query it back. You need your own log of every event you sent if you want to reconcile, audit, or refund. Don't skip this.
Cancellations have a 24-hour window. If you over-billed, you have 24 hours to send a cancellation. After that, you're issuing credit notes via the regular Stripe Invoice flow, which is messier.
Meters only support sum, count, last. No max, no average, no min. If your pricing model needs "peak concurrent tokens per hour" or "average daily spend per agent", you compute it yourself and emit the result as a meter event.
Aggregation is at period level, not per-event. A customer who runs 10,000 calls in a billing period gets one line item on the invoice (total dollars), not 10,000 line items. If you want per-call detail on the customer-facing invoice, you have to use multiple meters with different aggregation rules and that gets complicated fast.
When the preview is actually worth waiting for
The preview is worth waiting for if your business model is "I'm an AI gateway and my product is purely reselling raw model access with markup." In that case, the price-table maintenance and markup math are roughly 80% of what you're building, and letting Stripe do them is a meaningful simplification.
The preview is not worth waiting for if your business model is "I'm a vertical SaaS that uses LLMs and I want to bill customers based on their usage." In that case, you're going to have your own product pricing layered on top of raw model cost anyway, your markup isn't a simple percentage, and you're going to want full control of the price table to make per-customer deals. The do-it-yourself version above is the right shape.
What UsageBox handles for you
If you'd rather not maintain your own per-model price table, your own customer mapping, your own audit log, your own retry-on-Stripe-error logic, and your own per-customer dashboard, that's the layer UsageBox provides. The wire-up is roughly the same as the Python above, except the price table is updated automatically, the event log is queryable, and the customer dashboard is included.
If you'd rather wire it yourself, the code above is genuinely all you need. Either way, you don't need to wait for the Stripe preview.