Stripe Billing for AI SaaS — Per-Call Margin, Credits, No Bill Shock

Because the cost basis is per-call, not per-seat. A flat per-seat price is fine when usage is bounded and predictable — it falls apart the moment one customer discovers your product can summarize their entire knowledge base in a loop. Per-call metering keeps the pricing structure honest: heavy users pay for the inference they actually consume, and you stop subsidizing them out of the light users' subscriptions. The Stripe-side change is small once the architecture is right — the work is on your backend, where the metering signal has to be tied to the LLM call that actually completed and got returned to the user.

Both, on the same customer. The pattern BFEAI runs in production is a dual pool — a recurring subscription tier that grants a monthly allowance of credits, plus prepaid credit packs the customer can buy to top up when they run out before the cycle resets. The subscription anchors MRR; the packs absorb usage spikes without pushing customers into a higher tier they do not need year-round. Stripe supports both inside the same customer object using billing credits for the pack side and metered prices for the consumption side. The hard part is the consumption logic that draws down the right pool first and updates Stripe at the right moment.

Your backend tracks remaining balance in your own ledger, not in Stripe — Stripe processes meter events asynchronously and is not a real-time source of truth for whether a customer can make the next call. When the ledger crosses a configurable threshold (often 10-20% remaining), the backend fires a reload event that either auto-charges the saved payment method for a configured pack size or emails the customer to confirm. On a successful charge, the backend creates a new Stripe credit grant for the purchased amount and updates the ledger atomically. The whole flow is idempotent on a reload_id so a retried webhook does not double-grant credits.

Several things, layered. Hard caps per customer per period that block the next call rather than charging through them. Soft caps that warn at 50% and 80% via email or in-product banner. A live cost view in your dashboard fed from the same ledger that gates calls, so the customer sees what they are about to spend before they spend it. Optional spend approval for calls over a configured per-call cost threshold for enterprise-tier customers. And a transparent refund policy for the unavoidable cases — LLM returned garbage on a 200, provider had an outage that corrupted output, a runaway loop got past your rate limit. Stripe's customer balance and credit-note flows handle the refund side; the prevention side is all your code.

Have a written policy and apply it consistently. The honest stance for most AI products is that a 200 from the provider is not a guarantee of useful output, and customers know that — but a clear refund posture for repeat-failure cases (same prompt, multiple retries, all garbage) is what keeps trust intact and gets your support team out of one-off judgment calls. Implementation-wise, refunds against meter usage go through credit notes or by issuing fresh billing credits, not by editing the closed invoice. Track refund reason codes in your ledger so you can see whether garbage rates are climbing on a particular model or after a provider weight update — that signal is more valuable than the refund dollars.

Capture the actual provider response usage block on every call — input tokens, cached input tokens, output tokens — and price the call against the live per-model rate card your backend holds, not against an estimate. The ledger writes the priced amount in your own currency-precision integer (cents or sub-cents) before posting the meter event to Stripe. That way, if the provider changes prices, your ledger stays accurate retroactively and the Stripe meter only sees pre-priced consumption units. Skipping this step is the most common reason AI-product billing drifts away from actual cloud cost over a few months.

Persist every processed event.id in a dedup table and check it inside the same database transaction that applies the side effect — granting credits, posting a meter event, charging for a pack, all of it. Stripe retries with exponential backoff for up to three days in live mode, so the dedup record needs a TTL longer than that retry window. Every handler in the AI billing stack is written so that running it twice with the same event.id produces identical state on the second run. This is the discipline that keeps the dual-pool model from quietly hemorrhaging free inference under load.

For an AI SaaS already on Stripe with a working subscription, layering metered per-call billing plus the dual credit-pool model plus reload triggers is typically a few weeks of focused work. Most of the time is spent on the consumption ledger and the per-provider cost mapping, not on Stripe API calls — Stripe's surface area here is small once you know which primitives to use (metered prices, billing credits, customer balance). The variable that moves the timeline is how clean your existing call-completion signal is. If you do not currently capture provider usage blocks on every call, that instrumentation goes in first.