Seven platforms handle token billing today: Solvimon, Orb, Metronome, Amberflo, Lago, Chargebee, and Stripe Billing. They differ most on how events get into the system, how precisely usage gets rated, whether credits are a real ledger or a balance field, and, as of this year, who owns them. The comparison is below, and the AI token pricing glossary covers how per-token rates work underneath.

An AI company shared a billing problem recently that most multi-model products will recognize. They support 4-5 LLMs across different tasks, each with input tokens, output tokens, cached tokens, and ephemeral cache tiers. They wanted to bill per token through their payment processor's metering system and hit a wall, because their billing platform capped subscriptions at 20 line items. Multiply 5 models by 4-5 token types and you're already over. Adding one more model breaks checkout entirely.

Their workaround was custom code that collapses every token type into a single abstract "billing unit," does the pricing math internally, and reports one aggregate number to the billing platform. It works. The billing dashboard now shows unit counts nobody can interpret, and the company runs separate telemetry for actual usage analytics. The billing system's only remaining job is multiplication and invoicing.

That's what happens when token billing runs on infrastructure designed for something else. The workarounds remain but you have multiple "billing brains" so every new model, every pricing change, every enterprise negotiation touches internal code.

In 2026, AI Token billing shouldn’t require this.

What is token-based subscription billing?

Token-based subscription billing is a recurring subscription that also meters token consumption, with both charges landing on the same invoice for the same billing period. The subscription covers the platform fee and any included allowance. The metered portion covers whatever the customer burned past it.

Most AI products end up here. Pure per-token billing makes revenue unforecastable and makes customers nervous about opening the app. Pure subscription leaves you absorbing inference cost on your heaviest users. The hybrid is where the market settled, which means "token billing," "token-based subscription billing," and "usage-based billing for AI" describe the same invoice most of the time.

How does recurring billing work when usage is metered per token?

The subscription and the meter run on different clocks, and reconciling them is most of the work.

Subscriptions bill in advance. Usage bills in arrears. A customer on a monthly plan pays July's platform fee on 1 July and July's tokens on 1 August, so one invoice carries two periods. Mid-cycle changes compound it: if someone upgrades on the 12th, you prorate the subscription and then decide whether their included token allowance prorates too, resets, or carries.

Questions to put to a vendor:

• Can one invoice carry a subscription line and metered lines from different periods?

• On a mid-cycle upgrade, does the included allowance prorate, reset, or roll over, and is that configurable per plan?

• Are usage charges billed in arrears next cycle, or trued up against a prepaid balance in real time?

• How many line items can a single subscription hold? Ask this one specifically. It's the ceiling that really hurts when you go multi-model products and it's rarely in the docs.

What can be automated in token billing, and what can't?

Automated in any platform worth buying: event ingestion, deduplication, aggregation, rating against a card, invoice generation, payment collection, dunning, credit burn-down, allowance resets.

Still manual nearly everywhere: rate card design, mapping a new provider's token taxonomy to your internal units, deciding what happens to unused credits, and revenue recognition treatment for prepaid balances. Vendors will tell you rate card updates are automated. What they mean is that changing a price doesn't require a code deploy, which is real and useful... it isn't the same as the system knowing what the price should be.

What token billing actually requires

Token billing isn’t usage billing with a different label. It has specific requirements that most billing platforms weren’t designed for.

High-frequency event ingestion. One customer session generates thousands of metering events. A busy AI product processes millions per day. The billing system has to ingest, deduplicate, and aggregate without dropping data or falling behind.

Multi-dimensional metering. Tokens aren't one thing. Input, output, cached, sometimes reasoning, each at a different cost and each model at a different rate. The metering layer tracks all of those dimensions at once and prices them separately.

Sub-cent precision. A single token costs a fraction of a cent. At billions of tokens monthly, the difference between truncating and rounding to 8 decimal places shows up on the P&L.

Model-aware pricing. A customer using Claude Opus for one task and Haiku for another burns different value per call. Usage maps to the correct rate automatically, and those rates update when providers change pricing, which happens often.

Credit-to-token exchange rates. Most AI companies sell credits, and each credit maps to a variable number of tokens depending on the model. The rate card converts credits to tokens to cost, in real time, across every model supported.

What to ask about the metering API before you integrate

The demo is the pricing configuration UI. The thing you'll live inside is the ingestion endpoint. Six questions, in the order they'll bite.

How does the platform ingest usage events?

Push or pull, streaming or batch, and what the payload allows. A token event needs a customer identifier, a timestamp, a model, a token type, a count, and an idempotency key at minimum. If the event schema forces you into a single numeric quantity field, you'll be collapsing input, output, and cached tokens into one abstract unit before writing a line of pricing logic.

Ask what happens at 10x current volume. Published throughput varies by an order of magnitude across this market (Orb publishes 250K events/sec, Lago publishes 15K events/sec), and the number that matters is sustained ingest with rating keeping up, not a burst benchmark.

What happens to duplicate and late-arriving events?

Your gateway retries. Your queue redelivers. A batch job replays a window. Each one produces a duplicate token event, and if billing counts it, you overbill.

• Is deduplication keyed on an idempotency value you supply, and how long is the dedup window?

• If an event arrives 40 minutes after the period closed, does it land in the closed period or the next one?

• Can you see rejected and deduplicated events, or do they disappear?

That last one matters more than it sounds. Silent rejection is how you discover at month-close that 3% of usage never made it in.

Can you correct history?

Someone will misconfigure a meter. A model will map to the wrong rate. You'll find out three weeks later.

Backfill support is the difference between reprocessing the affected period and issuing manual credit notes to every affected customer. Some platforms here have no historical backfilling at all, which makes pricing errors permanent and pushes the fix downstream into accounting. Ask directly: can we replay a corrected event stream for a closed period, and does that regenerate the invoice or create an adjustment?

Where does metering stop and rating begin?

This determines what you can change without touching code.

Platforms that keep metering and rating in separate layers let you change pricing without changing measurement. Platforms that fuse them turn a pricing experiment into a data migration. Metronome separates them explicitly. Amberflo decouples the metering cloud from the billing cloud so each scales independently, which matters when you ingest billions of events to produce a few thousand invoices.

An AI gateway (LiteLLM, Portkey, OpenRouter, Kong AI Gateway) sits upstream of both. A gateway is a good metering chokepoint because every model call passes through it and it already counts tokens. It is not a billing system: no ledger, no invoice, no credit expiry, no revenue recognition. Metering at the gateway and rating in a billing platform is a reasonable architecture, and it means your billing vendor has to accept events from a source it doesn't control.

What does integration actually cost in engineering time?

Ask for a number from a real customer, not a docs page. The spread runs from an afternoon to a full quarter with dedicated data engineering. Weeks of configuration plus SQL plus pipeline setup is normal at the enterprise end, and it's fine if you're staffed for it. It's not fine if you find out in month two.

How do you bill for AI usage across multiple LLM providers on one invoice?

You normalize each provider's token taxonomy into your own internal units, then rate against a single card. The hard part is that the taxonomies don't line up.

OpenAI reports cached input tokens. Anthropic separates cache writes from cache reads and prices them differently (a cache read runs at roughly 10% of the normal input rate, a cache write costs more than uncached input). Google reports context caching with its own storage-duration component. Reasoning tokens are billed as output by some providers and broken out by others. None of these are the same field, and a customer session touching three providers produces three incompatible usage shapes.

So the pipeline runs: capture the provider-native event, map it to an internal token type you define, apply your own rate, then let the invoice see it. Your internal taxonomy is a product decision, not a technical one. Most teams land on four or five buckets (input, output, cached-read, cached-write, reasoning) and accept that the mapping is lossy at the edges.

Auto-sync of provider list prices is convenient right up until you want to charge something other than a markup on list. Lago ships pre-built OpenAI and Mistral templates. Stripe auto-syncs OpenAI, Anthropic, and Google. Others expect you to maintain the card yourself, which is more work and more control.

How do you reconcile token cost against what you charge?

Two invoices exist for every customer: the one you send them, and the share of your provider bills they caused. Most billing systems only know about the first.

Cost-to-charge reconciliation means attributing provider spend down to the customer, ideally to the model and token type, then setting it against revenue from that customer in the same period. It's the number that says which accounts are underwater, and it usually arrives late because the provider invoice lands after month-close.

The pattern that catches companies: the heaviest 5% of users drive most of the inference spend and pay the same flat fee as everyone else. On a subscription with an included allowance, that's a margin problem hiding inside a growth number.

Doing this means pricing the same event stream twice. Once at your provider's rate to produce cost, once at your customer's rate to produce revenue. Platforms that treat metering as a billing-only function can't run the first pass, which is why most teams build cost attribution in the data warehouse and never quite reconcile it against the invoice.

Ask whether a platform can hold a cost rate and a charge rate against the same event, and report margin per customer per model without an export. Most can't, currently, which is odd given it's the first number any AI CFO asks for. Not my favourite state of the market, but here we are.

Should you build token metering on Stripe, or buy dedicated billing infrastructure?

Build on your existing payment platform while all of these hold:

• You support one or two models

• You bill one token type, or you're happy charging a blended per-token rate

• You don't sell prepaid credits, or you sell them as a simple balance that only decrements

• You have no enterprise contracts with custom rates, commits, or minimums

• Nobody has asked you for a per-customer margin number

Buy when two or more stop being true. The failure isn't dramatic. You write a small piece of code to collapse token types into one abstract unit, because the subscription hit a line item ceiling. It works. Then the pricing math lives in your application, the billing dashboard shows numbers nobody can interpret, and you stand up separate telemetry for the analytics billing can no longer give you.

That's the real cost, and it isn't the platform fee. It's that every new model, every provider price change, and every negotiated enterprise rate now needs an engineer, a deploy, and a regression test.

What to look for in a token billing platform

What changed in 2026: billing platforms got acquired by payment companies

Two acquisitions reshaped this list inside six months.

Stripe acquired Metronome in January 2026, for roughly $1B. Metronome was the metering layer behind OpenAI, Anthropic, Databricks, and NVIDIA, processing billions of usage events daily. The roadmap is merging into Stripe Billing.

Adyen acquired Orb for $335 million in cash, closing 1 July 2026 alongside Adyen's acquisition of Talon.One. Orb's founders reinvested part of the proceeds into Adyen shares. Adyen's stated aim is bringing billing and payments into single infrastructure for merchants.

Both deals make sense on their own terms. What they change for a buyer is the shape of what's on offer.

Merging a usage-based billing engine into a payments platform is a multi-year piece of work, and roadmap velocity on the standalone product during that period is a fair thing to ask about. Two questions worth putting to either team, in writing, before signing:

• What ships in the next 18 months, and what's paused until integration completes?

• If we're not a merchant on your parent's platform, what does support and roadmap priority look like for us in 2027?

The second-order effect is on PSP choice because a billing vendor owned by a processor has a commercial reason to route you toward that processor, and its billing roadmap now answers to a payments strategy.

If your payments stack is settled and matches, that's a fine place to be, possibly better than before. If you run multiple processors, expect to switch, or sell into regions where one processor's coverage is thin, the calculus moved and independence at the billing layer is worth pricing in.

Platform deep dives

Solvimon

Solvimon treats tokens and credits as financial primitives rather than metadata attached to subscription records. Multi-dimensional rate cards map token types (input, output, cached, reasoning) across models to different prices inside one billing configuration. Adding a model or changing a provider's rate is a rate card change, not a deploy.

For token billing specifically: Solvimon supports multi-dimensional rate cards that map different token types (input, output, cached) across different models to different prices, all within a single billing configuration. When a provider updates pricing or you add a new model, rate card changes don’t require code deploys.

Credit wallets carry full ledger logic with model-specific exchange rates. When one credit buys 100K tokens on a small model or 10K on a frontier model, the conversion and the real-time burn-down happen in the ledger rather than in your application code.

The same event stream can be priced twice, once at provider cost and once at customer rate, which produces margin per customer per model without an export to a warehouse.

On payments, Solvimon is PSP-agnostic by design. It runs on Stripe, Adyen, Checkout.com, or several at once, and isn't owned by any of them. As of mid-2026 that's a shrinking category. Hybrid billing runs subscriptions, token metering, credit wallets, and enterprise custom contracts in one system. Built and operated by a team that ran billing infrastructure at payments-network scale before starting the company.

Best for: AI-native companies where token and credit complexity is the core problem, and teams who want their billing roadmap decoupled from a payments company's strategy.

Orb (now part of Adyen)

Orb is a usage-based billing engine built for high-volume metering. Ingestion handles 250K+ events per second with deduplication, and billable metrics are defined via SQL or a visual interface, giving engineering teams precise control over how token usage maps to charges.

The credit system uses a block-based architecture: multiple credit blocks per customer, each with its own expiry and amount. More flexible than a single balance field, and it needs careful configuration for pooled team credits with tiered exchange rates.

The pricing compiler handles complex logic (tokens + API calls + GPU time + customer-tier multipliers), and Orb Simulations model pricing changes against historical data before pushing them live. That combination is still the strongest pure pricing-logic engine in this comparison.

The open question is timing. Adyen closed the acquisition in July 2026, and the integration ahead of them is substantial. The Stripe-only payment constraint that used to be Orb's clearest limitation will change over that period. What to establish before signing is what the next 18 months of standalone product development look like.

Best for: Engineering-heavy AI startups who want maximum control over pricing logic and can absorb an integration period.

Metronome (now part of Stripe)

Before the acquisition, Metronome was the metering layer behind OpenAI, Anthropic, Databricks, and NVIDIA, processing billions of usage events daily on streaming infrastructure built on Apache Kafka. If you want to know how the frontier labs bill for tokens, this is the public answer.

The architecture separates metering, pricing, and contract management into distinct layers, so pricing logic changes without touching measurement code. That's valuable when AI model economics shift, and it's the pattern worth copying whether or not you buy Metronome.

Implementation is heavy. Expect weeks of configuration, SQL knowledge, data pipeline setup, and ongoing data engineering bandwidth. No historical backfilling means pricing errors can't be retroactively corrected in the billing system.

Best for: Enterprise AI companies with dedicated billing engineering teams, already deep in the Stripe ecosystem, needing proven scale.

Amberflo

Amberflo decouples the metering cloud from the billing cloud. Each scales independently, which matters when metering volume (billions of token events) vastly exceeds billing volume (thousands of invoices).

The platform is built for LLM and AI workloads specifically: multi-model cost attribution, unified pricing tables across 100+ AI models, and an AI gateway with load balancing and fallback routing. If you route requests across OpenAI, Anthropic, and open-source models, Amberflo meters and bills across all of them from one system, which puts it closer than most to the single-invoice problem above.

Credit support is native. Customers buy credits in custom currencies, usage deducts in real time, and rollover and expiry rules enforce automatically. Payment integration is primarily Stripe, and the customer base is smaller than Orb's or Metronome's, so fewer proof points at massive enterprise scale.

Best for: AI startups wanting LLM-specific billing infrastructure without months of integration. Fastest time-to-value for AI-specific metering.

Lago

Lago is the open-source option. The core billing engine is free and self-hostable, with a cloud version for teams that don't want to manage infrastructure.

For token billing, Lago ships pre-built pricing templates for OpenAI and Mistral models, with dimension-based aggregation separating input from output tokens at different rates per model. Mistral AI uses Lago itself, generating 32,000+ invoices monthly with per-token billing.

The wallet system supports up to 5 active wallets per customer, scoped to specific billable metrics, with configurable priority and auto-topup rules. More granular than most commercial alternatives.

Where Lago stands out now: multi-PSP support, with native Stripe, Adyen, GoCardless, and Cashfree integrations plus webhook connectivity to others. It's the only open-source option handling that natively, and after the 2026 acquisitions it's one of a shrinking number of options at any license.

The tradeoff: self-hosted Lago needs Postgres, Redis, and ClickHouse at scale. No built-in dunning or collections. Steep learning curve if your team isn't API-first.

Best for: Technical teams that want full control over their billing infrastructure.

Chargebee

Chargebee is the most mature subscription billing platform here. If your business is primarily subscription-based and you're adding AI features that generate token usage at the margin, its 200+ integrations, mature dunning, and accounting connectivity (Salesforce, NetSuite, QuickBooks) make it the path of least disruption.

The limitation for token billing is that it wasn't designed for real-time, high-frequency event metering. Adding token billing on top typically requires custom engineering to bridge Chargebee's subscription logic and the real-time metering tokens demand. Credit ledger depth is limited compared to purpose-built alternatives.

Best for: Mid-market SaaS with mature subscription billing adding token-based AI features without replacing the stack.

Stripe Billing (LLM Token Billing)

Stripe's LLM token billing feature is in private preview. It auto-syncs token prices for OpenAI, Anthropic, and Google models, lets you set a markup percentage, and meters through the Stripe AI Gateway, integration partners (OpenRouter, Vercel, Cloudflare), or self-reported usage.

This is Stripe's answer to the multi-model metering problem. Instead of creating 20+ meters and hitting the subscription item cap, token billing handles model-by-model metering natively. It supports usage-based, fixed fee with included usage, credit packs, and hybrid models.

The caveats: still private preview, not generally available. The 0.7% billing fee on top of processing fees puts total cost near 1.5%, which compounds at scale. Credit systems are limited, and payments are Stripe-only.

Best for: Early-stage AI companies already on Stripe wanting the fastest path to token billing. Evaluate carefully past $10M in billing volume.

How to choose: decision framework for token billing

The right platform depends on where you are today and where billing complexity is headed in 18 months.

The company that collapses all token types into one abstract billing unit and the company that bills natively across models, token types, and pricing tiers will look identical at $1M ARR. At $10M, one of them is spending two engineering sprints on every pricing change while the other ships a rate card update in an afternoon.

If your billing workaround is currently working, ask yourself: can it handle the next three models you add, the enterprise contract you’re negotiating, and the pricing change your competitor just forced?

Frequently asked questions

Does "token billing" mean payment tokenization? Two different things share the word. Token billing here means metering and charging for LLM tokens, the units of text a model processes. Payment tokenization means replacing a card number with a surrogate value so it can be stored and reused safely. If you're looking for card vaulting, PCI scope reduction, or network tokens, this is the wrong page. They meet in one place: an AI agent that pays for things needs both a metered usage record and a tokenized payment credential.

How do OpenAI and Anthropic bill for tokens, and can I replicate it? The public answer is Metronome, which was the metering layer behind both before Stripe acquired it. The architecture is reproducible without it: a gateway counts tokens on every model call, events stream to a rating layer keyed on customer and model and token type, a prepaid balance draws down in real time, and an invoice generates at period close. What's hard to reproduce isn't the shape, it's the ingestion reliability at billions of events per day and the sub-cent precision across them.

Which platforms support real-time token metering at millions of API calls per day? Metronome and Orb publish the highest throughput figures (billions of events daily, 250K events/sec respectively), and Lago publishes 15K events/sec for the open-source engine. The number to interrogate is sustained ingest with rating keeping pace, not peak burst. Ask about aggregation latency separately, because "real-time dashboard" and "real-time rating" are different claims and vendors use the phrase for both.

Can I integrate token billing with webhooks? Every platform here emits webhooks for invoice and payment lifecycle events. The differences show on the inbound side: whether you can push usage events through a webhook rather than an SDK, whether webhook delivery is idempotent, and whether failed deliveries replay. Lago connects to unsupported PSPs through webhooks specifically. Ask about retry policy and replay windows before designing around them.

What's the best token billing platform for small businesses? For early-stage startups, the priority is getting token billing running without over-investing in infrastructure. Stripe's LLM token billing feature (if you can get into the preview) or Amberflo's free trial offer the lowest barrier. Solvimon's free tier up to $5M billed covers full token and credit billing without platform fees at that stage. Avoid over-engineering early, and choose a system that won't force a migration at $2-5M ARR.

Which token billing services work for UK businesses? PSP coverage is the main consideration. Stripe operates in the UK, so any Stripe-dependent platform works for collection. Lago offers the broadest PSP flexibility with native Adyen and GoCardless integrations, which matters for BACS Direct Debit or enterprise customers requiring specific processors. Solvimon is PSP-agnostic, supporting Stripe, Adyen, and Checkout.com, all with UK presence.

Can I integrate AI billing with my CRM? Chargebee has the deepest native CRM integrations (Salesforce, HubSpot) out of the box. Orb and Solvimon integrate via API. Lago connects through webhooks. If your sales team manages enterprise contracts through Salesforce, Chargebee or Solvimon's CPQ capabilities are most relevant. For self-serve token billing where CRM is secondary, the API-first platforms connect through standard webhook patterns.

How does token billing work for e-commerce platforms adding AI features? If you're adding AI features (recommendations, generated descriptions, chatbots), token billing applies to the compute behind them. The question is whether you pass token costs through to merchants or absorb them into subscription price. Passing through means metering AI usage per merchant and adding it to their existing invoice. Absorbing still requires cost visibility per merchant to protect margins, which is the cost reconciliation problem above.

For a deeper look at credit models, see AI credit pricing models: how tokens, credits, and hybrid billing actually work →

Solvimon runs token billing, credit metering, and hybrid contracts in one system, on whichever PSP you use. Free up to $35M billed.

Related

• AI credit pricing models. The tradeoffs between charging in tokens, credits, and hybrid plans.

• Solvimon for AI. Billing infrastructure built for token, credit, and hybrid pricing.

• AI token pricing. What token pricing is, current provider rates, and where it breaks down.