What's the simplest Stripe shape for billing AI usage?

One subscription per customer with a base recurring price plus a metered price. Your backend reports usage events to the metered price; Stripe rolls them into the next invoice. No Connect, no Merchant of Record, no PayFac.

Meter, usage record, or billing meter — which API?

Stripe's new Billing Meters API (2024+) is the right default in 2026. It deduplicates events by idempotency key, supports multiple aggregations, and decouples meter from price so you can change pricing without losing history.

How do I avoid double-billing on retries?

Every meter event needs an idempotency key derived from your internal event ID, not from a random UUID. Stripe deduplicates by (meter, key, timestamp_bucket), so retries with the same key are safe.

Do I bill in raw tokens or in dollar credits?

Dollar credits. Token prices change; user comprehension doesn't. Convert tokens to credits at meter time using a published rate, surface the credit balance in-product, and let finance change the conversion without re-papering contracts.

Where does the per-user cost cap live?

At your gateway, not at Stripe. Stripe is the system of record for what was billed; the cap is a real-time enforcement that returns a friendly error before the user crosses the limit. Stripe sees the events that actually happened.

Stripe usage-based billing for AI features

The right Stripe shape for AI usage in 2026 is one subscription per customer with a base recurring price plus a metered price using the new Billing Meters API. Your gateway records events with stable idempotency keys, a worker posts them to Stripe (retries are safe), per-user spending caps enforce in real time at the gateway, and the invoice groups AI usage as a single line item with a per-user breakdown in-product.

The shape: subscription + metered price

For 95% of AI-billing use cases the right Stripe shape is one subscription per customer with two prices: a base recurring fee and a metered price that accrues usage in real time and bills on the same invoice. No Stripe Connect, no Merchant of Record, no PayFac entity. You stay the merchant; AI is a line item.

Use the Billing Meters API

Stripe's Billing Meters API (GA 2024) is the right default in 2026. It:

Deduplicates events by idempotency key, so retries are safe.
Decouples meter from price — change pricing without losing event history.
Supports multiple aggregations (sum, count, last).
Backfills cleanly via the events endpoint.

Skip the legacy usage records API for new builds.

A reliable pipeline

Gateway records an internal event with a stable event_id.
A worker reads from a queue (pgmq works) and posts to Stripe meters.
Idempotency key = event_id. Stripe dedupes; retries are safe.
Failed posts go to a DLQ and re-drain on a schedule; alerts fire after N retries.
A reconciliation job nightly: sum your local events vs Stripe meter totals; alert on drift.

Idempotency is the only thing

Every other failure mode is recoverable. Lost idempotency means double-billing a customer — the one outcome that costs you the customer and the support ticket.

Bill in credits, not tokens

Model prices change every six months. User comprehension does not. Convert tokens to credits at meter time using a published rate, store the rate alongside each event for audit, and let finance adjust without re-papering contracts. Display the credit balance live in-product.

Caps live at the gateway

Stripe is the system of record for what was billed. The per-user spending cap is a real-time enforcement at your gateway: check projected cost before each call, return a friendly upgrade prompt when the cap is hit. Stripe only sees events that actually happened.

Plan changes and proration

Upgrades: immediate, prorate the recurring component, keep metered counters running.
Downgrades: end-of-period, surface the effective date in-product.
Plan-change events: emit a webhook to your own audit log; never trust client-side plan state.

Invoice presentation

Buyers tolerate usage-based pricing when the invoice is legible. Group AI usage as one line item, link to an in-product detail page that shows per-user / per-feature breakdown, and surface the per-event audit log on demand. Surprise is the killer; transparency is the antidote.

Command+K's Monetize module ships the gateway, meters, caps, and Stripe pipeline as one product.

FAQ

What's the simplest Stripe shape for billing AI usage?: One subscription per customer with a base recurring price plus a metered price. Your backend reports usage events to the metered price; Stripe rolls them into the next invoice. No Connect, no Merchant of Record, no PayFac.
Meter, usage record, or billing meter — which API?: Stripe's new Billing Meters API (2024+) is the right default in 2026. It deduplicates events by idempotency key, supports multiple aggregations, and decouples meter from price so you can change pricing without losing history.
How do I avoid double-billing on retries?: Every meter event needs an idempotency key derived from your internal event ID, not from a random UUID. Stripe deduplicates by (meter, key, timestamp_bucket), so retries with the same key are safe.
Do I bill in raw tokens or in dollar credits?: Dollar credits. Token prices change; user comprehension doesn't. Convert tokens to credits at meter time using a published rate, surface the credit balance in-product, and let finance change the conversion without re-papering contracts.
Where does the per-user cost cap live?: At your gateway, not at Stripe. Stripe is the system of record for what was billed; the cap is a real-time enforcement that returns a friendly error before the user crosses the limit. Stripe sees the events that actually happened.