Set Up Metered Billing for Your AI Product 2026

The practical, first-principles guide to charging for AI products by what people actually use, from your first meter to scaled, defensible revenue.

Every request your AI product serves costs you real money, and a flat monthly price cannot see that. That single fact is the reason metered billing went from a niche practice used by cloud infrastructure companies to the default business model for AI software in 2026. When a heavy user of a $20 subscription quietly consumes $60 of model inference, a per-seat price does not just leave money on the table, it burns your margin. GitHub Copilot reportedly lost an average of more than $20 per user per month, and as much as $80 on its heaviest users, while charging a flat $10 - Thurrott. Even Anthropic retrofitted weekly usage caps onto its top Claude plans in 2025 because a small slice of subscribers ran workloads that were uneconomic to serve at a fixed price - Anthropic.

But here is the problem: metered billing is genuinely hard to build correctly, and the market you buy it from just got reshaped. In a single twelve-month stretch the three independent usage-billing specialists were all acquired: Stripe bought Metronome for a reported $1 billion, Adyen bought Orb for $335 million, and Salesforce bought m3ter. The pricing models multiplied too, from pure pay-as-you-go tokens to prepaid credit wallets to per-resolution outcome pricing, and the tax and compliance obligations that ride along with charging customers in dozens of countries did not get any simpler.

This guide breaks down exactly what metered billing is, the specific platforms that implement it (with real pricing), the five-stage pipeline you have to instrument to do it right, the failure modes that cause double-billing and bill shock, and the agent-native frontier where AI agents themselves become the buyers. It is written for founders shipping an AI product, not for finance PhDs, so it starts high level and then goes deep into the nitty-gritty. If you are still deciding how to price the thing before you decide how to bill for it, start with our companion guide on how to price your AI product to beat token costs, then come back here to wire it up.

Contents

1. Why Metered Billing Became the Default for AI Products
2. The Five Pricing Models, Decoded
3. The 2026 Market Map and the Great Billing Consolidation
4. The Platform Scorecard, in Depth: Stripe, Metronome, and Orb
5. The Open-Source Stack: Lago, OpenMeter, and Kill Bill
6. The Rest of the Field and the Entitlements Layer
7. Merchant of Record and the Tax Trap
8. How to Instrument Metering: The Five-Stage Pipeline
9. Credits, Wallets, and the Economics of Breakage
10. Outcome and Agent-Native Billing: The Frontier
11. How Metered Billing Fails, and How to Prevent It
12. A Founder's Rollout and Decision Framework
13. The Future Outlook

Before the deep profiles, here is the master scorecard. It ranks the platforms a founder building an AI product would realistically choose among, scored on the five things that actually matter when you are the one wiring it up. Each cell carries the score and the real data point behind it, and the table is sorted by final score, highest first.

The five criteria reflect the founder's actual decision, not a generic feature checklist. Ease to live (25%) asks how fast a small team gets a correct invoice out the door. Metering power (25%) measures real-time event ingestion, aggregation flexibility, and credit handling at volume. Billing-layer cost (20%) is the take rate or ops cost of the billing layer specifically, separate from the roughly 2.9% payment processing everyone pays. Tax and compliance (15%) captures whether the platform absorbs global tax remittance (a merchant of record) or leaves it on you. Scale and durability (15%) weighs proven throughput and, after the 2026 consolidation, whether the platform will still be independent and stable a year from now. Read the table as a map, not a verdict: Stripe Billing wins for the median founder because you are probably already on it, while Metronome and Orb win on raw metering for teams billing on token and GPU volume at scale.

1. Why Metered Billing Became the Default for AI Products

To understand why metered billing is now the default, ignore the marketing and start with the structural question: what actually changed about the cost of delivering software? For twenty years, the defining feature of software-as-a-service was that the marginal cost of one more user was close to zero. Serving a thousandth customer cost almost the same as serving the tenth, so a flat per-seat subscription was not just simple, it was economically honest. The price bore almost no relationship to the cost, and that was fine, because the cost rounded to nothing. Intelligence changed that overnight. Every time an AI product answers a question, writes code, or resolves a ticket, it burns tokens on a model that a lab charges you for by the million. The marginal cost stopped being zero and became a real, variable, per-request expense.

Once you see that, the seat model breaks in a specific and measurable way. Under a flat price, your revenue per customer is a flat line while your cost per customer is a function of how hard they use the product, and those two lines diverge at exactly the users you most want to keep. The concrete arithmetic is unforgiving: a product earning $100 of revenue against $20 of traditional cost runs an 80% gross margin, but adding an AI feature that costs $15 of inference pushes cost to $35 and margin to 65%, a fifteen-point drop, and that is the average before a single power user is accounted for - The SaaS CFO. The average always looks survivable. The distribution is what kills you, because a small tail of heavy users consumes a wildly disproportionate share of compute while paying the same flat price as everyone else.

This is not a theoretical worry, it is the most repeated pattern in the industry. ICONIQ's 2026 State of AI report projects average gross margins for AI-native companies at just 52%, up from 41% in 2024 but still far below the 70% to 85% that classic SaaS enjoyed, with pure application-layer AI companies averaging only 45% - SaaStr. Model inference is climbing toward a quarter of total company spend. When your single largest variable cost scales with usage, your price has to scale with usage too, or you are running a business that gets less profitable every time a customer loves your product more. Metered billing is simply the mechanism that reconnects price to cost.

The market data on adoption confirms the shift is already well underway rather than speculative. Metronome and Greyhound Capital's survey of 100 software companies found that 77% of the largest software firms and 85% of all respondents had adopted usage-based pricing, with nearly half of them making the move in just the previous two years - Metronome. Kyle Poyar's separate survey of 240 software and AI companies shows the mix shifting fast: hybrid pricing rose from 27% to 41% year over year, while flat-fee subscriptions fell from 29% to 22% and pure seat-based pricing fell from 21% to 15% - Growth Unhinged. Three in four software companies changed their pricing in a single year. That churn is not indecision, it is an industry re-pricing around a new cost structure in real time.

There is a deeper reason to embrace this rather than resent it, and it is worth reasoning through from first principles because it changes how you feel about the whole exercise. When intelligence gets cheaper every year, a metered price you set today gets more profitable over time on its own. Andreessen Horowitz calls this LLMflation, estimating that the cost of equivalent-quality inference falls roughly tenfold per year, so a model task that cost thirty dollars per million tokens in early 2023 costs a small fraction of that now - a16z. A founder who charges a stable credit price and buys inference at a falling cost is riding a widening margin. The metered model is not a defensive tax on your customers, it is the only structure that lets you participate in the cost curve instead of being crushed by it. This is the lens Yuma Heymans (@yumahey), the founder behind Founden and co-founder of the AI recruiter HeroHunt.ai, has argued from repeatedly: when software becomes labor, you have to price the work, not the login, and the pricing has to track a cost base that moves every quarter.

2. The Five Pricing Models, Decoded

Before you pick a platform, you have to pick a shape for your price, because the platform decision follows from the model decision, not the other way around. There are five models in wide use for AI products in 2026, and they sit on a spectrum from purest metering to purest outcome. Understanding where each one aligns price with value, and where it does not, is the single most important design choice you will make, because the model determines your margin ceiling, your revenue predictability, and how your customers feel about their bill. Get this right and the billing plumbing is a solved problem. Get it wrong and no billing platform will save you.

The first and most transparent model is pure pay-as-you-go, where the customer is charged for exactly what they consume, metered in the units that drive your cost. This is how the model labs themselves sell: as of August 2026, Anthropic charges $5 and $25 per million input and output tokens for Claude Opus 5, and $2 and $10 for Sonnet 5, while OpenAI's flagship GPT-5.6 Sol tier runs $5 and $30 and its budget Luna tier just $0.20 and $1.20 - Finout. Pure PAYG is the most honest model and the easiest to reason about, but it has two weaknesses: revenue is unpredictable because it swings with usage, and customers experience anxiety because they cannot forecast their own bill. It works best when your buyer is technical and already thinks in units of consumption.

The second model, and probably the most popular for consumer-facing and prosumer AI products, is the prepaid credit wallet. The customer buys a balance of credits up front, and each action draws it down at a rate you control. This is how ElevenLabs sells, where one credit equals one character of generated speech and cheaper models cost half a credit per character, and how Vercel's v0 works, where monthly credits are consumed by tokens per generation and, crucially, do not roll over - Vercel. The credit wallet is powerful for three reasons: it collects cash up front, it lets you obscure the raw token cost behind a friendly unit, and expiring credits create breakage revenue. It also lets you tune margin per action independent of what the underlying model costs. The risk is that customers resent credits that expire, and mispriced credits can either bleed margin or feel stingy.

The third model is the hybrid, a platform fee plus metered overage, which has become the single most common primary model at 41% of companies. The customer pays a predictable base that includes a usage allowance, then pays for consumption above it. Cursor moved to this in June 2025, replacing 500 fixed requests with a $20 monthly plan that includes roughly $20 of frontier-model usage (about 225 Claude Sonnet 4 requests at API rates) plus optional overage - Cursor. The hybrid is the best of both worlds on paper: predictable base revenue for you, a predictable floor for the customer, and metered upside on heavy users. But the Cursor migration is a cautionary tale, because CEO Michael Truell had to publicly apologize on July 4, 2025 and offer refunds after users experienced the change as a stealth price increase. Changing an existing base's pricing model is a communication problem as much as a billing one.

The fourth model is per-seat, which is not dead but is now a component rather than the whole price. A seat still makes sense for the human-facing surface of a product (dashboards, admin, collaboration), and many AI products keep a seat charge and bolt metered AI usage on top. The mistake is using a seat to price the AI work itself, because the seat is a proxy for a human, and AI work is decoupled from headcount. The fifth and most advanced model is outcome-based pricing, where you charge per unit of value delivered rather than per unit of resource consumed. Intercom's Fin agent charges $0.99 per resolution, and Sierra charges roughly $1.50 per autonomously resolved interaction, meaning the vendor carries the performance risk and the customer pays only for work that lands - a16z. Outcome pricing is where the frontier is heading, and section 10 goes deep on it, but it demands that you can define and measure the outcome cleanly, which most products cannot yet do.

The practical takeaway is that these models are not mutually exclusive and the strongest AI products layer them, stacking a fixed component, a metered component, and sometimes an outcome component into one bill.

A common winning structure is a small platform fee for access and support, a prepaid credit wallet for the AI consumption, and a per-seat charge only for the human collaboration layer. What matters is that the piece of your price that scales with cost is metered, so your margin cannot invert on your best customers. Whichever shape you choose, the deeper you go the more you will care about the mechanics of how usage becomes an invoice, which is why the platform you build on matters. If you have not locked your numbers yet, the sister guide on how to price your AI product to beat token costs walks through the markup math in detail, and the guides on cutting AI agent costs with model routing and setting the effort dial cover the cost side of the same equation.

3. The 2026 Market Map and the Great Billing Consolidation

The most important thing to understand about the metered-billing market in 2026 is that it just went through a violent consolidation, and if you read a guide written eighteen months ago it will point you at companies that no longer exist independently. In a single twelve-month window, the three leading standalone usage-billing specialists were all acquired by payment and CRM giants. This is not a footnote, it is the central fact that shapes every platform decision, because it tells you which tools are now tied to a processor's roadmap, which remain independent, and where the strategic risk sits.

Stripe acquired Metronome for a reported $1 billion, with the agreement announced in December 2025 and the deal closing in January 2026, folding the metering engine behind OpenAI, Anthropic, and NVIDIA directly into Stripe Billing - Stripe. Stripe CEO Patrick Collison framed the rationale bluntly: metered pricing is the native business model for the AI era, the way subscriptions were the native model for the last software generation. Weeks later, Adyen agreed to acquire Orb for $335 million, absorbing the billing platform used by Vercel, Replit, and Supabase into its acquiring stack - Fintech Global. And Salesforce agreed to acquire m3ter, folding its high-volume metering into Agentforce Revenue Management - CIO. One point of confusion worth clearing up: the Stripe deal was Metronome, not m3ter, which are different companies acquired by different buyers in the same season.

Why did three payment and CRM giants pay billions for billing software in a single year? Reason from what they were buying. They were not buying invoicing, which is cheap and commoditized. They were buying the metering engine, the hard, high-throughput system that ingests billions of usage events, deduplicates them, aggregates them, and rates them into money without losing or double-counting a single one. That engine is the chokepoint of AI monetization, and Lago's own commentary captured the irony well: billing is hard enough that even Stripe chose to buy the capability rather than build it - Lago. For a founder, the lesson is that the metering layer is genuinely difficult, which is exactly why you should think hard about whether to buy it, rent it, or own it.

The consolidation splits the field into four camps, and knowing which camp a tool sits in tells you more than any feature list. Processor-owned platforms (Stripe Billing with Metronome inside it, Orb inside Adyen) give you metering tied to a payment stack, which is convenient but couples you to that processor's priorities. Open-source independents (Lago, OpenMeter, Kill Bill) give you full control and no take rate at the cost of running the infrastructure yourself. Merchant-of-record platforms (Paddle, Polar, Lemon Squeezy) bundle tax and compliance into a higher fee. Enterprise suites (Zuora, Chargebee) offer breadth and heavy implementation for larger organizations. A fifth, thinner layer, entitlements platforms like Stigg and Schematic, sits alongside all of them to enforce what a plan is allowed to do.

The strategic reading for a founder is that the independent, processor-neutral options got scarcer and more valuable overnight. If you want a metering layer that is not owned by the company that also processes your payments, your realistic independent choices narrowed to open-source Lago and OpenMeter, plus the surviving suites. That is not necessarily bad, since Stripe owning Metronome makes the mainstream path simpler, but it does mean your billing infrastructure is increasingly a bet on a specific processor's ecosystem. Weigh that when you choose, because switching billing systems after you have thousands of customers on live meters is one of the most painful migrations in software. Founders thinking about the whole stack, not just billing, will find our guide to the AI-native company tech stack a useful companion.

4. The Platform Scorecard, in Depth: Stripe, Metronome, and Orb

The three platforms at the top of the usage-native tier deserve individual treatment, because they represent three genuinely different answers to the same problem, and the right one depends entirely on your stage and scale. This section goes deep on Stripe Billing, Metronome, and Orb. The pattern to hold in mind is that they are ordered by how much metering horsepower you need versus how much you value simplicity and being on a stack you already run.

Stripe Billing is the pragmatic default, and for most founders it is the correct starting point precisely because it is not a separate system to adopt. If you are already taking payments with Stripe, usage-based billing is a capability inside the same dashboard rather than a new vendor. The core primitive is the Billing Meters API, where you create a meter that defines how to aggregate events (sum, count, or last), attach it to a price, and then report usage as meter events. Usage-based billing is included with Stripe Billing up to 100 million meter events per month - Stripe. Stripe layered prepaid support on top with Credit Grants, an append-only ledger that tracks a customer's prepaid or promotional balance and draws it down against metered usage, which is exactly the mechanism you need for a credit wallet. The pricing is a flat 0.7% of billing volume on top of standard payment processing, after Stripe merged its old tiered plans in mid-2024 - Flexprice.

Stripe's honest limitation is that the Billing Meters API reconciles usage at invoice time rather than giving you real-time spend visibility, and its aggregation options are simpler than what a purpose-built engine offers. Stripe itself now acknowledges this by steering new, high-volume, or credit-heavy integrations toward Metronome, which it owns - Stripe Docs. That guidance is the single clearest signal of where each tool fits. Use Stripe Billing directly when your event volume is moderate, your pricing is not exotic, and you value staying on one stack. Reach for Metronome when metering itself is the hard part of your business.

Metronome is that purpose-built engine, and it earns the top metering score because it is the system the most demanding AI companies in the world actually run on. It ingests, rates, and aggregates consumption events in real time, and its customers are a who's-who of the AI frontier: Collison named OpenAI, Anthropic, and NVIDIA explicitly in the acquisition announcement, and Metronome's own materials add Databricks, Confluent, Hugging Face, and Together - Stripe. OpenAI's own product leader is on record that Metronome lets them monitor credit usage and customer health in real time to drive upsells at the right moment. The product models usage, subscriptions, and prepaid or postpaid commits with balances that update continuously against draft invoices, which is what real-time metering actually means in practice.

Metronome's tradeoff is the mirror image of Stripe's strength: it does not publish pricing and requires an enterprise sales conversation, charging an annual platform fee plus consumption-based fees (a percentage of billings, per-event ingestion, and data export) whose exact rates are not public - Metronome Docs. It is not built for two engineers who want to be live by Friday. It is built for the company whose entire business model is metered and whose event volume is enormous. Now that it sits inside Stripe, the likely path is that its capabilities become the high end of a single Stripe continuum, from a garage startup on Billing to a hyperscaler on Metronome, which is exactly how CEO Scott Woody framed the combination.

Orb, now part of Adyen, is the developer-first alternative that sits between the two on ease and rivals Metronome on power. Its distinguishing feature is that metrics are defined with SQL-style rollups over raw events, which gives pricing and finance teams enormous flexibility to model complex or changing pricing without an engineering ticket for every change. It serves Vercel, Replit, and Supabase, developer-heavy companies with sophisticated consumption models, and it raised roughly $44 million before the $335 million Adyen deal - Fintech Global. Orb's answer to the hardest metering bug (correcting usage after a billing period closes) is unusually strong, with dedicated backfill and single-event amendment endpoints. Orb's founder-facing pitch is best seen in a demo of its pricing simulation tooling, which lets you model inference and agent costs against candidate price structures before you commit.

The way to choose among these three is to ask how central metering is to your product. If billing is a supporting function and you value simplicity, Stripe Billing is the answer and you already have it. If billing is the beating heart of a high-volume consumption business, Metronome and Orb are purpose-built for that load, with Orb offering more self-serve flexibility and Metronome the deepest enterprise pedigree. The scorecard puts Stripe first for the median founder and Metronome and Orb close behind on the strength of their metering, and that ordering is deliberate: most readers of this guide are not yet billing OpenAI's volume, and the right tool is the one that gets a correct invoice out this quarter.

5. The Open-Source Stack: Lago, OpenMeter, and Kill Bill

For founders who want to own their billing layer outright, with no take rate and no dependence on a processor's roadmap, the open-source stack is a serious and increasingly popular option. The tradeoff is precise and worth stating plainly at the top: you trade a percentage-of-revenue fee for the responsibility of running and scaling the infrastructure yourself. Whether that trade is smart depends on your engineering capacity and your sensitivity to take rates at scale, because a 0.75% fee that is trivial at $50,000 of monthly billing becomes a real line item at $5 million.

Lago is the leading open-source usage-based billing platform and the clear anchor of this category, holding roughly 10,400 GitHub stars and positioning itself explicitly as the open-source alternative to Stripe Billing - GitHub. Founded in 2021 by two former operators from the French fintech unicorn Qonto and backed through Y Combinator, Lago raised a $15 million Series A led by FirstMark on top of a $7 million seed - TechCrunch. Its angel roster reads like a monetization hall of fame, including people who led billing at MongoDB, Stripe, and Hugging Face, and its named customers include Mistral, Algolia, and GitHub. The engine is genuinely capable, with seven aggregation types and eight charge models, including graduated, volume, package, and dynamic pricing, which covers essentially any AI pricing structure you would want to build. The self-hosted version is free with no usage limits or per-event fees, while Lago Cloud takes 0.75% of billing volume above a generous free tier - Lago.

OpenMeter takes a narrower, metering-first approach and is the most explicitly AI-focused of the three. Built on the cloud-native CloudEvents standard with Kafka and ClickHouse under the hood, it is engineered to ingest millions of usage events per second and is designed specifically to meter LLM token and GPU usage, enforce limits, and drive credits - GitHub. It went through Y Combinator, raised a $3 million seed, and was acquired by the API-gateway company Kong in September 2025, which folded its metering into Kong's API monetization stack - OpenMeter. The important nuance is that OpenMeter is metering-first, not a full billing lifecycle, so you typically pair it with a downstream invoicing tool. That makes it the right choice when your hard problem is high-volume, accurate token metering and you already have a way to turn aggregated usage into an invoice.

Kill Bill is the mature, battle-tested elder of the category, an open-source subscription and payments platform created in 2010 with a plugin architecture that integrates Stripe, Adyen, and PayPal - GitHub. It supports usage-based, tiered, and hybrid pricing and is actively maintained after more than a decade. Its cost is the highest ease penalty in the scorecard, because it is a heavier, more traditional platform to self-host than the modern API-first tools, but for a team that wants a proven, fully-owned billing system with a long track record, it is a credible foundation. The reason it scores below Lago and OpenMeter is not capability but developer experience, since the newer tools were designed API-first for exactly the consumption workloads AI products generate.

The honest guidance on open source is that it is the right call in two situations and the wrong call in most others. It is right when you have genuine engineering capacity and expect enough volume that a percentage take rate would become a meaningful cost, or when data residency and control are non-negotiable (regulated industries, on-premise requirements). It is the wrong call when you are pre-revenue or thinly staffed, because standing up ClickHouse, Kafka, and a rating engine, then keeping them correct through every pricing change, is a real ongoing cost that a managed platform absorbs for its fee. Most early founders should start managed and revisit open source only when the take rate on real revenue justifies the operational burden. For the broader build-versus-buy calculus across your infrastructure, our guide to what it costs to build an app with AI frames the same tradeoff.

6. The Rest of the Field and the Entitlements Layer

Beyond the top usage-native platforms and the open-source stack, there is a broad field of billing tools that a founder should understand, both to make an informed choice and to recognize what a salesperson is actually selling. These break into modern usage-native challengers, established subscription suites that bolt on metering, and a distinct entitlements layer that enforces what a plan permits. The reason to survey them is that the best fit is often stage-dependent: a tool that is perfect at Series B is overkill for a solo founder, and vice versa.

Among the modern usage-native challengers, Amberflo stands out as a metering-first platform with a genuine free-forever tier, processing tens of billions of meter events per day and adding quote-to-cash tooling, with usage pricing that starts at a cent - Amberflo. Hyperline, a Paris-based quote-to-cash platform, prices itself like a payment processor at roughly $299 per month plus 0.7% of billed revenue, and importantly offers a real self-serve free trial with no card required, which is rare in a category dominated by "contact sales" - Hyperline. These challengers matter because they are startup-friendly in a way the enterprise incumbents are not, giving a small team real metering power without an enterprise contract.

The established subscription suites offer breadth and maturity at the cost of being subscription-first rather than usage-native. Chargebee attaches metered add-ons to subscription plans and is free until $250,000 of cumulative billing, then takes 0.75% - Chargebee. Zuora, the enterprise monetization standard, added high-volume metering by acquiring Togai and is now privately held after a $1.7 billion take-private, with quote-based pricing aimed squarely at large organizations - Zuora. Maxio and Recurly round out the mid-market, each supporting usage components on top of a subscription core. The pattern across all of them is that usage is a feature grafted onto a subscription engine, which is fine if your product is mostly subscription with some metering, and a poor fit if metering is your core.

There is a separate layer that founders consistently forget until it bites them, and that is entitlements, the enforcement of what a customer's plan actually allows them to do in real time. Metering tells you what a customer used after the fact; entitlements decide, at the moment of the request, whether they are allowed to use it at all. Stigg is a dedicated pricing, packaging, and entitlements platform with a free-forever tier that lets you define plans, limits, and AI credits visually and enforce them at runtime via a single API call, with a Pro plan at $399 per month - Stigg. Schematic approaches the same problem from the feature-flag side, evaluating entitlements against billing state and emitting the same check as a metering event. You can build entitlement logic yourself, and many do, but at the point where you have multiple plans, usage caps, trials, and credit balances all interacting, a dedicated layer prevents the class of bug where a downgraded customer keeps premium access or a depleted wallet keeps serving requests.

The practical way to navigate this field is to match the tool to your stage rather than chase the longest feature list. If you are early and metering is core, a usage-native challenger like Amberflo or Hyperline, or open-source Lago, gets you power without an enterprise contract. If you are already a subscription business adding some usage, a suite like Chargebee fits your existing shape. If you are enterprise-scale with complex contracts, Zuora and the now-acquired Metronome and Orb are built for that. And regardless of billing platform, plan for entitlements as a first-class concern, because the enforcement layer is where metered plans quietly break. The same stage-matching logic applies to the rest of your infrastructure, which is why our guides to the best databases for your product and the best auth for your app are worth reading alongside this one.

7. Merchant of Record and the Tax Trap

Here is the single most expensive thing founders learn too late about billing: calculating tax and remitting tax are two completely different problems, and most billing platforms only do the first. If you sell a digital AI product to customers in multiple countries, you can trigger a legal obligation to register for, collect, file, and remit sales tax or VAT in each of those jurisdictions, and that obligation lands on you the moment you cross a threshold you probably were not tracking. This is not a corner case for AI products, it is the default, because software sells globally from day one. Getting this wrong is not a rounding error, it is a compliance liability that compounds silently until a tax authority sends a letter.

The crucial distinction is between a tax calculation tool and a merchant of record. Stripe Tax is the former: it calculates and monitors your tax obligations and applies the right rate at checkout, charging 0.5% per transaction where you are registered, but it explicitly does not assume the legal role of seller - Stripe. Stripe's own materials are candid that with Stripe Tax you remain the seller of record, so registration, filing, remittance, and liability stay with you - Stripe. A merchant of record is a company that legally resells your product as the seller of record, which means it takes on the tax registration, collection, filing, remittance, and liability in every jurisdiction, along with chargebacks and fraud. You give up a few points of revenue and gain freedom from an entire category of compliance work.

The merchant-of-record options each charge a bundled fee that folds payment processing, tax compliance, and fraud into one number. Paddle charges 5% plus 50 cents per transaction, all-in, and handles VAT and sales tax across more than 200 jurisdictions, though it supports usage-based billing with weaker primitives than a dedicated meter API - Dodo Payments. Lemon Squeezy, now owned by Stripe since mid-2024, charges the same 5% plus 50 cents and is being folded into Stripe's own MoR offering - Lemon Squeezy. Polar, the developer-first open-source MoR, restructured in 2026 to a 5% plus 50 cent free tier with lower rates on paid plans, and positions usage-based billing for AI products as its clearest differentiation - Fungies. Stripe even launched its own true merchant-of-record product, Stripe Managed Payments, which adds 3.5% on top of standard processing to absorb global tax and disputes - Stripe.

The decision here is a genuine tradeoff with no universally right answer, and it turns on your team and your geography. A merchant of record costs roughly ten times the take rate of a pure billing layer, but it eliminates a category of work and risk that a small team is poorly equipped to handle, especially in the EU where VAT rules are strict and thresholds are low. For a solo founder or a tiny team selling globally, paying 5% to never think about VAT registration in seventeen countries is often the correct trade, and it is why our guide to the best payment platforms for your business leans MoR for early-stage global sellers. For a funded team with finance capacity, or one selling mostly domestically, Stripe Tax plus your own filings preserves margin and control. The mistake is not choosing one over the other, it is choosing neither and discovering the liability during due diligence. If you are selling into Europe specifically, our guide to making your AI app EU-compliant covers the adjacent obligations.

8. How to Instrument Metering: The Five-Stage Pipeline

Now for the nitty-gritty, because whichever platform you choose, metered billing is the same five-stage pipeline underneath, and understanding the stages is what lets you reason about correctness rather than trusting a dashboard. The pipeline is: ingest usage events, deduplicate them, aggregate them over the billing period, rate them against a price, and roll them onto an invoice. A parallel credit ledger and an entitlements check run alongside this spine. Every platform in this guide, from Stripe to Lago to Metronome, implements this exact shape, and they differ mainly in throughput ceilings, correction primitives, and how you define a metric.

The first stage, event ingestion, is where your application tells the billing system that something billable happened. In Stripe, you POST a meter event with an event name, a payload containing the customer identifier and a numeric value, and an idempotency identifier. The actual call is refreshingly simple, and seeing it demystifies the whole thing:

curl https://api.stripe.com/v1/billing/meter_events \
  -u "SECRET_KEY:" \
  -d event_name=ai_tokens \
  -d "payload [value]=1500" \
  -d "payload [stripe_customer_id]=cus_..." \
  -d identifier=req_8f3a1c9e

That single call says a customer used 1,500 units of the thing you named ai_tokens, and the identifier is the key that prevents the same usage from being counted twice. Lago and Metronome use the same shape with slightly different field names: Lago calls the dedup key transaction_id, Metronome accepts an array of up to 100 events each with a transaction_id and a properties map - Metronome Docs. For high volume, Stripe offers a dedicated meter event stream that handles up to 10,000 events per second, and Metronome and Orb ingest at similar or higher rates. The Metronome team's own tutorial series is the clearest hands-on walkthrough of getting ingestion right end to end.

The second stage, idempotency, is the most important and most commonly botched part of the entire pipeline, and it deserves its own emphasis. Networks retry. A completion finishes, your server tries to report it, the request times out, and your retry logic fires the same event again. Without a unique identifier per event, you just double-billed a customer, which is the fastest way to lose trust. Every platform enforces uniqueness within a window: Stripe deduplicates on the identifier within at least 24 hours and requires the event timestamp to be within the past 35 days, Metronome dedups on transaction_id within 34 days, and Orb offers a configurable grace period plus explicit backfill and amendment endpoints for corrections - Orb Docs. The discipline is simple to state and easy to forget: generate the idempotency key on your server, deterministically, from the thing that happened (the completion ID, not a random value regenerated on retry).

The third and fourth stages, aggregation and rating, are where usage becomes money. Aggregation collapses the period's events into a number using a formula (sum for tokens, count for messages, max for peak concurrency), and rating applies your price to that number. This is where the pricing model you chose in section 2 becomes concrete. To bill per million tokens in Stripe, you create a meter that sums a tokens property, then a price with transform_quantity set to divide by 1,000,000 and round up, so a cycle's summed tokens become a per-million rate - Stripe Docs. Tiered pricing has two distinct modes that produce very different bills: graduated applies each bracket's rate only to units inside that bracket, while volume applies one rate to all units based on the total reached - Stripe Docs. Confusing the two is a classic mispricing bug, because a customer who crosses a tier boundary pays a wildly different amount under each.

The fifth stage, invoicing, finalizes everything: it takes the rated usage, applies any credit balance, calculates tax, and collects payment, with dunning logic to retry failures. Stripe applies credits after discounts but before taxes, and its Smart Retries use a model trained on billions of transactions to recover roughly 10% to 15% more failed payments than a fixed retry schedule - Stripe Docs. The operational insight that ties the whole pipeline together is that metering is asynchronous, so aggregated usage on an upcoming invoice may not immediately reflect the latest events, and platforms emit error events (Stripe fires v1.billing.meter.error_report_triggered for invalid events) that you must handle to catch silently lost usage before it under-bills you. A metered system is not fire-and-forget, it is a data pipeline you monitor, and the teams that treat it that way are the ones whose revenue matches their reports. Our guide to why AI apps corrupt data and the fix covers the same class of idempotency and reconciliation discipline in a broader context.

9. Credits, Wallets, and the Economics of Breakage

The prepaid credit wallet deserves its own deep section because it is the most popular model for AI products and because its economics are subtler than they look. A credit system separates the money a customer pays from the units they consume, and that separation is a powerful margin lever, but it also introduces accounting obligations and design decisions that quietly determine whether the model helps or hurts you. Reasoning about credits from first principles means treating them as a ledger, not a counter, because that is exactly how the platforms implement them and it is the mental model that keeps you out of trouble.

Mechanically, a credit is an entry on an append-only ledger. In Stripe, a Credit Grant allocates a prepaid or promotional balance to a customer, backed by an immutable ledger, and it can only be applied to metered prices that have a meter attached - Stripe Docs. When an invoice finalizes, the platform draws down the balance against rated usage, following an explicit priority order when multiple grants exist (higher priority first, then earlier expiry, then promotional before paid). Metronome draws a sharp and useful distinction between a commit (a minimum spend obligation over a term) and a credit (a prepaid consumable balance), because they behave differently at renewal and true-up - Metronome. Getting the drawdown order right matters: apply promotional credits before paid ones, and expiring credits before non-expiring ones, or you will strand a customer's paid balance while their free credits sit unused.

The most economically interesting property of credits is breakage, the revenue from credits customers buy but never use before they expire. Breakage is effectively 100% margin, which is why non-rollover monthly credits (as Vercel's v0 uses) and expiring wallets are deliberate design choices, not oversights - Chargebee. But breakage comes with an accounting rule you cannot ignore: under ASC 606, you must estimate the expiry percentage from historical data and recognize breakage revenue proportionally as active credits are consumed, not book it all up front. This is where founders who treat billing as a pure engineering problem get surprised, because the revenue recognition of a credit system is a finance concern that the metering system has to support with clean data.

The design decisions around credits are where you actually shape the customer experience and your margin simultaneously, and they trade off against each other. Whether credits expire, whether they roll over, whether you offer auto-reload when a balance runs low, and whether you allow a negative balance for trusted customers are all levers. Expiry and non-rollover maximize breakage and cash but can feel punitive, so many products soften them with generous windows or rollover caps (a common enterprise pattern carries forward 10% to 20% on renewal). Auto-reload smooths revenue and prevents service interruption when a customer hits zero mid-task, but surprises people if it is not clearly disclosed, which is exactly the kind of surprise that generated the Cursor backlash. The right settings depend on your buyer, and the discipline is to make each choice deliberately rather than inheriting a platform default.

The tie between credits and entitlements closes the loop and is the part teams most often get wrong. A credit balance is only useful if the system actually stops serving requests when it hits zero, and that enforcement is an entitlements decision made in real time, not at invoice time. If your metering is asynchronous (and it always is), a customer can consume well past their balance before the invoice reflects it, so you need a real-time check that reads the current balance and gates the request. This is precisely why the entitlements layer from section 6 is not optional for a credit product: without it, your wallet is a suggestion, and heavy users will blow through it while your metering catches up hours later. Build the balance check into the request path, not the billing cycle, and your credit model actually enforces the economics you designed.

10. Outcome and Agent-Native Billing: The Frontier

The frontier of metered billing in 2026 is a shift in the unit itself, from resources consumed to outcomes delivered, and beyond that to a world where the buyer is an AI agent rather than a human. This is the most forward-looking section of the guide, and it matters even for founders not yet operating here, because it tells you where pricing gravity is pulling and what your competitors will soon be able to do. The structural argument is simple: if software is becoming labor, then the natural unit of price is the work completed, not the person doing it or the tokens it burned.

Outcome-based pricing operationalizes that argument by charging per resolved result. Intercom's Fin agent charges $0.99 per resolution, billed at most once per conversation regardless of how many actions Fin takes, with a $49 base that includes 50 resolutions - Fin.ai. Zendesk bills automated resolutions at $1.50 committed or $2.00 pay-as-you-go, and Sierra charges roughly $1.50 per autonomously resolved interaction on enterprise contracts - Intercom. The distinction between per-interaction and per-outcome is sharper than it looks: Salesforce Agentforce's original $2 per conversation bills whether or not the issue was resolved, while resolution pricing bills only on success, which shifts the performance risk onto the vendor - Salesforce. Outcome pricing is spreading fast, with ICONIQ finding outcome-based models jumped from 2% to 18% of AI companies in under a year, and a whole billing infrastructure startup, Paid, raising $33 million specifically to give agent builders margin visibility on results-based pricing.

The even newer frontier is agent-native payments, where an AI agent is the entity making the purchase, and this is where the plumbing gets genuinely novel. In September 2025, Stripe and OpenAI released the Agentic Commerce Protocol, an open standard that puts Instant Checkout inside ChatGPT using a single-use, scoped payment token that lets an agent complete a purchase without ever holding raw card data - Stripe. Google answered with the Agent Payments Protocol (AP2), backed by 60-plus partners, which authorizes agent purchases with cryptographically signed mandates carried as verifiable credentials - Google Cloud. And Coinbase's x402 revived the dormant HTTP 402 status code so agents can pay per request in stablecoins with no account or human approval, processing over 119 million transactions on Base by early 2026 - Coinbase. Stripe went further still, taking its Tempo blockchain and Machine Payments Protocol to mainnet in March 2026 so agents can settle sub-cent micropayments that card interchange would make uneconomic - CoinDesk.

Why does this matter for a founder setting up billing today, when most of it is still nascent? Because it changes what "metered" will soon mean. When your customer's AI agent can autonomously call your product's API and pay per call in a scoped token or a stablecoin, the meter is no longer a monthly invoice, it is a real-time settlement on every request. The startups building this layer (Skyfire's agent identity, Nekuda's agent wallets, Catena Labs' agent-native banking) are betting that machine-to-machine commerce needs its own rails, and the card networks agree, with Visa and Mastercard both shipping agent-payment products that bind a credential to a specific agent identity. The practical near-term move is to build your metering pipeline cleanly now, because a clean event stream and a real-time balance are exactly what you will need to expose per-call pricing to agent buyers later. If selling to agents is on your roadmap, our dedicated guides on how to sell to AI agents, sell your product inside ChatGPT, and ship an MCP server for your product go deeper on the interface side of the same shift.

11. How Metered Billing Fails, and How to Prevent It

A guide that only shows the happy path is not an insider's guide, so this section is about how metered billing goes wrong in production, because the failure modes are specific, recurring, and mostly preventable once you know to look for them. Metered billing fails in four characteristic ways, and each one has a root cause and a mitigation. Understanding them before you ship is far cheaper than discovering them in a customer's angry support ticket or a finance team's reconciliation nightmare.

The first and most common failure is double-counting from duplicate events, which we flagged in the pipeline section and which deserves repeating because it is the number-one metering bug. It happens when a network retry, a client-side re-render, or a webhook redelivery causes the same usage to be reported twice, and the customer is billed for consumption that happened once. The root cause is always a missing or non-deterministic idempotency key, and the fix is to generate the key on your server from the unique event itself (the completion ID) so a retry carries the same key and the platform deduplicates it. The corollary failure is the opposite, silent under-billing from lost events, where events fail validation and are dropped, and the fix there is to handle the platform's error events (Stripe's meter error reports) rather than assuming a 200 response means the usage landed.

The second failure is bill shock, where a customer receives an invoice far larger than they expected and churns in anger even though the charge was technically correct. This is a design failure, not a technical one, and it is what happened to Cursor and Replit users whose agentic tasks consumed far more than anticipated - Carly. The root cause is a lack of real-time visibility and guardrails, and the mitigations are concrete: show live usage in the product, send spend alerts at thresholds, offer spend caps that pause service before a customer blows their budget, and default to conservative limits. Bill shock is where usage-based pricing earns its bad reputation, and preventing it is mostly about giving customers control and information, not about the billing engine itself.

The third failure is migration backlash, the specific pain of moving an existing customer base from one pricing model to another, which is far harder than pricing a new product. Cursor's July 2025 apology and refunds are the canonical example, where a change many users experienced as a stealth increase generated a public backlash that a clearer rollout would have avoided - FinTech Weekly. The root cause is treating a pricing migration as a billing config change rather than a customer-communication project. The mitigations are grandfathering existing customers, communicating far in advance, providing calculators that show each customer their new cost, and offering a transition period. You only get to change a customer's fundamental deal a few times before they stop trusting you, so spend the migration budget on communication.

The fourth failure is reconciliation drift, where the usage your billing system reports does not match your accounting ledger, which erodes audit confidence and can misstate revenue. Usage-based revenue must be recognized under ASC 606 as the customer consumes, not when invoiced, and late-arriving events plus the gap between consumption date and processing date create drift that has to be reconciled every period - Lago. The root cause is treating metering and accounting as separate systems that never reconcile, and the fix is a reconciliation process that matches metered usage to the invoice to the ledger every close, with explicit cutoff policies for which period a late event belongs to. This is unglamorous, but it is the difference between a business whose numbers a finance team or an acquirer can trust and one whose revenue is an approximation. The teams that build the reconciliation discipline early are the ones that survive due diligence without a fire drill.

12. A Founder's Rollout and Decision Framework

With the landscape, platforms, mechanics, and failure modes covered, the remaining question is how you actually sequence this for your own product without over-building. The answer depends on your stage, and the biggest mistake founders make is adopting an enterprise-grade metering platform when a simpler setup would serve them for a year. The right rollout starts with the smallest correct thing and adds sophistication only when volume and revenue justify it, because every layer of billing complexity is a layer you have to maintain and reason about.

For the earliest stage, before you have found product-market fit, the correct move is almost always Stripe Billing with meters and credit grants, or a merchant of record if you are selling globally and want to skip tax entirely. The logic from first principles is that at low volume, the platform take rate is immaterial and the value of being live quickly and correctly is everything. You are on Stripe already, meters are built in, credit grants handle a wallet, and you can be billing real usage in days. Do not adopt Metronome or a self-hosted Lago cluster to bill your first hundred customers, because you will spend engineering time on infrastructure that your revenue does not yet warrant. Get a correct invoice out, watch the failure modes, and iterate on the pricing model, which is the part that actually determines whether you make money.

There is also a build-versus-buy question one level up, which is whether you build the product and its billing plumbing yourself at all. For non-technical founders, the emerging option is an autonomous company builder that stands up the whole product, including the billing wiring, from a description of what you want. Founden (founden.ai) sits in this category: you describe the business and the AI builds and runs it, which means the metering, the credit wallet, and the checkout get assembled without you hand-writing meter events, and you still own everything. That is a genuinely different starting point from wiring Stripe yourself, and it belongs on the menu alongside the platforms in this guide, particularly for founders whose edge is a market insight rather than billing engineering. The same "describe it and it runs" logic underlies our broader guide to hiring an AI workforce to run your company and the case for the autonomous business.

As you scale, the decision framework becomes about where your pain concentrates. If your event volume grows past what Stripe Billing handles comfortably, or your pricing gets complex enough that finance needs to change rate cards without an engineering ticket, that is the signal to graduate to Metronome or Orb, or to evaluate open-source Lago if the take rate on real revenue now justifies running the infrastructure. If tax filing across jurisdictions becomes a burden, that is the signal to move to a merchant of record or add Stripe Tax with proper registrations. If customers are churning from bill shock, the fix is not a new platform but real-time visibility and spend controls. And if your product is heading toward outcome pricing or agent buyers, invest early in a clean event stream and real-time balances, because those are the foundation everything else builds on. The framework is not "adopt the most powerful tool," it is "add capability at the exact moment the pain appears, and not before."

The one thing worth doing early regardless of stage is getting the pricing model right, because the model is far harder to change than the platform. You can migrate from Stripe Billing to Metronome with engineering effort, but changing your customers from a flat plan to metered credits is a trust exercise that, done poorly, costs you your base. So spend disproportionate thought on the shape of the price (section 2), instrument it correctly (section 8), prevent the failure modes (section 11), and treat the platform as a swappable implementation detail underneath a pricing decision you have reasoned through from your actual costs. Founders who invert this, obsessing over the platform while under-thinking the model, end up with beautifully engineered billing for a price that does not make money.

13. The Future Outlook

The trajectory of metered billing over the next few years is legible if you extrapolate from the forces already in motion, and the outlook shapes what you should build toward even if you cannot act on all of it today. The first and most certain trend is that metered and outcome-based pricing keep taking share from seats. Gartner projects that at least 40% of enterprise software spend shifts to usage, agent, or outcome-based pricing by 2030, and the ICONIQ data already shows outcome pricing growing an order of magnitude in a single year - a16z. The seat is not disappearing, but it is being demoted from the whole price to the human-collaboration component of a layered price, and any AI product priced purely per seat in 2026 is leaving margin and defensibility on the table.

The second trend is consolidation continuing to reshape who you buy billing from. With Stripe owning Metronome, Adyen owning Orb, and Salesforce owning m3ter, the standalone metering specialist has become an endangered species, and the independent options that remain (open-source Lago and OpenMeter, the surviving suites) will grow more strategically important precisely because they are not tied to a processor. For a founder, this raises the stakes on the coupling question: adopting a processor-owned billing stack is convenient but ties your monetization to that processor's roadmap and take rate, and the value of a processor-neutral option rises as the market concentrates. Expect the independents to lean into that neutrality as their core pitch.

The third and most transformative trend is the arrival of agent-native commerce as a real settlement layer rather than a demo. The protocols shipped in 2025 and 2026 (the Agentic Commerce Protocol, AP2, x402, Tempo's Machine Payments Protocol) are not speculative anymore, they are processing real volume, and the card networks have committed to binding credentials to agent identities - Fortune. The structural implication is that the meter and the payment collapse into the same real-time event: an agent calls your API, and the settlement happens on that call, in a scoped token or a stablecoin, with no monthly invoice in between. Products that have a clean, real-time metering pipeline will be able to expose per-call pricing to agent buyers as a configuration change, while products with batch-oriented, month-end billing will have to re-architect. This is the strongest reason to build the pipeline in section 8 correctly now, even if your buyers are all humans today.

The conclusion for a founder setting up metered billing in 2026 is a clear decision framework. Start with the pricing model, reasoned from your real costs and your buyer, because it is the hardest thing to change. Choose the platform to match your stage, defaulting to Stripe Billing for the median founder, a merchant of record if you are selling globally and want to skip tax, and Metronome, Orb, or open-source Lago only when volume and complexity justify them. Instrument the five-stage pipeline with real idempotency, aggregation, and reconciliation discipline, because correctness is not optional when you are charging people for what they use. Prevent bill shock with real-time visibility and spend controls, and treat any pricing migration as a communication project, not a config change. And whether you wire it yourself, buy a managed platform, or let an autonomous builder like Founden stand up the product and its billing from a description, keep the event stream clean and real-time, because that is the foundation the outcome-priced, agent-native future is built on. Metered billing is not a tax you impose on customers, it is the mechanism that lets a business built on cheap, falling-cost intelligence actually keep the margin it earns. Get it right, and every improvement in your product makes you more profitable, not less, which is the whole point.

This guide reflects the metered billing and AI monetization landscape as of August 2026. Platform ownership, pricing, and model availability change frequently in this space (three of the major platforms changed hands in the twelve months before publication alone), so verify current details on each provider's own pricing and documentation pages before committing.