Stripe Billing v2 vs Orb vs Metronome: Usage-Based Billing 2026

Flat-rate SaaS subscriptions made sense when software was a static tool you logged into. But the product landscape has shifted hard toward consumption models. AI inference, API calls, tokens processed, compute minutes, data egress. These are the units of value that modern companies sell, and none of them map cleanly to a $49/month plan.

OpenAI charges per token. Twilio charges per message and per minute. Snowflake charges per compute credit. AWS charges per everything. The pattern is clear: the companies defining the next era of software infrastructure all bill based on what customers actually use. And the SaaS companies building on top of those platforms are following suit, because their own costs scale with consumption and their pricing needs to reflect that reality.

The problem is that traditional billing platforms were built for seat-based subscriptions. Charging $20/user/month is straightforward. Charging $0.003 per API call across 47 different endpoints with tiered volume discounts, prepaid credit drawdown, and minimum monthly commits is a completely different engineering challenge. You need event ingestion pipelines, real-time metering, flexible rating engines, and invoice generation that can handle millions of line items without breaking.

Three platforms have emerged as the serious contenders for usage-based billing in 2026: Stripe Billing v2 with its new Meters API, Orb with its event-driven billing engine, and Metronome with its enterprise-grade consumption platform. We have helped dozens of AI and API startups implement usage-based pricing, and each of these platforms excels in different scenarios. Let us break them down honestly.

Stripe launched its revamped Billing v2 with the Meters API in late 2025, and it represents a significant leap from the old usage records approach. If you are already running Stripe for payment processing, the pitch is compelling: keep everything in one ecosystem and bolt on metering without adding another vendor.

How Stripe Meters Work

The Meters API lets you define a meter (for example, "api_calls" or "tokens_processed"), then send usage events to Stripe in real time. Each event includes a customer identifier, a numeric value, and a timestamp. Stripe aggregates these events per billing period and applies your pricing model at invoice time. You can send events individually or in batches of up to 1,000, and Stripe handles deduplication via an idempotency key on each event.

Pricing models available on Stripe Billing v2 include tiered pricing (different per-unit rates at different volume tiers), graduated pricing (each tier's rate applies only to units within that tier), volume pricing (the total volume determines the per-unit rate for all units), and package pricing (charge per block of units). You can also combine usage-based charges with flat subscription fees on a single invoice, which is the most common pattern we see: a $99/month base plan plus $0.01 per API call over 10,000.

The Stripe Ecosystem Advantage

Stripe's real strength here is not the metering engine itself. It is everything around it. Payment processing, tax calculation, revenue recognition (Stripe Revenue Recognition), fraud detection (Radar), customer portal, invoicing, dunning, and a financial reporting suite are all native integrations. If your finance team already uses Stripe for reconciliation and your support team uses the Stripe Dashboard for refunds, adding usage-based billing does not introduce a new vendor relationship, a new dashboard, or a new set of webhooks to manage.

Stripe also supports 135+ currencies and all major payment methods globally. For companies selling API access to customers worldwide, this matters. Orb and Metronome handle billing and metering but rely on Stripe (or another processor) for actual payment collection, adding a layer of integration complexity.

Pricing and Limitations

Stripe Billing v2 charges 0.7% of the billed amount for metered usage, on top of standard Stripe processing fees (2.9% + $0.30 per charge in the US). So on a $1,000 usage invoice, you pay $7 for the billing engine plus roughly $29.30 for payment processing. Total cost: about 3.6%.

The limitations are real, though. Stripe's metering pipeline has a slight delay (events are not reflected in real-time dashboards instantly, typically a few minutes of lag). The pricing model configuration, while improved, still lacks the expressiveness of purpose-built billing engines. You cannot define arbitrary SQL-based rating rules or build complex pricing waterfalls without writing custom application logic. And if you need features like prepaid credit balances, minimum commit tracking, or contract-based billing, you will be building those yourself on top of Stripe's primitives.

Orb has quietly become the billing platform of choice for developer-facing AI companies. Perplexity, Vercel, Replit, and a growing roster of high-profile startups run their billing through Orb, and for good reason. Orb was built from day one for the specific problems that usage-based billing creates.

Event-Driven Architecture

Orb's core abstraction is the billable event. You send structured JSON events to Orb's ingestion API, and Orb stores, deduplicates, aggregates, and rates them according to your pricing configuration. The ingestion pipeline is designed for high throughput. Orb handles millions of events per customer per billing period without breaking a sweat, and events are reflected in customer balances within seconds, not minutes.

What sets Orb apart is its pricing rule engine. You define pricing using a SQL-like syntax that supports arbitrary transformations on your event data. Want to charge differently based on the model used in an AI inference call? Filter events by a metadata field. Want to apply a multiplier for priority-queue requests? Write a pricing rule. Want to aggregate by unique users rather than raw event count? Orb supports distinct count aggregations natively. This flexibility is why AI companies love Orb. Their pricing models are genuinely complex, and Orb does not force them into rigid templates.

Prepaid Credits and Drawdown

Orb has first-class support for prepaid credit models, which are the dominant monetization pattern for AI companies in 2026. A customer buys $500 in credits, and usage draws down from that balance in real time. Orb tracks credit balances, sends alerts at configurable thresholds (50% remaining, 25% remaining, depleted), handles auto-top-up, and prevents usage beyond the credit balance if you configure hard limits.

This is not a trivial feature to build yourself. Credit drawdown requires real-time event processing, atomic balance updates, race condition handling for concurrent API calls, and graceful degradation when balances hit zero. We have seen teams spend 6 to 8 weeks building credit systems from scratch, only to discover edge cases around refunds, expirations, and partial credits that add another month of work. Orb handles all of this out of the box.

Pricing and Considerations

Orb's pricing is not publicly listed, which is typical for billing infrastructure at this level. Based on our experience with client implementations, expect to pay a platform fee that scales with your billing volume, typically in the range of 1% to 2% of billed revenue, with minimums starting around $1,000/month. There are setup and onboarding fees for enterprise contracts. Orb does offer a self-serve tier for earlier-stage companies, but the full feature set requires a sales conversation.

The main consideration with Orb is that it is a billing and metering engine, not a payment processor. You still need Stripe, Adyen, or another processor for actual payment collection. This means managing two vendor relationships, two sets of webhooks, and potential sync issues between Orb's invoice state and Stripe's payment state. Orb provides a native Stripe integration that handles most of this, but it is another moving part in your billing stack.

Metronome targets a different segment of the market than Stripe or Orb. While Orb has captured the developer-tools and AI startup crowd, Metronome focuses on enterprise software companies with complex, contract-driven billing needs. Think companies selling to large organizations with negotiated pricing, volume commits, custom rate cards, and multi-year contracts.

Contract and Commit Management

Metronome's standout feature is its contract management system. You can model enterprise sales agreements directly in Metronome: a 12-month contract with a $50,000 annual commit, custom per-unit rates negotiated for this specific customer, quarterly true-ups, and automatic overage billing at a different rate. This is the billing reality for enterprise software companies, and Metronome handles it natively while Stripe and Orb require you to build significant custom logic.

The commit tracking alone is worth attention. When a customer has a $50,000 annual minimum, Metronome tracks their consumption against that commit in real time, shows the burn rate, projects whether they will hit the minimum, and generates the right invoice at period end. If the customer consumed $40,000 in usage, the invoice shows the $10,000 shortfall. If they consumed $60,000, the invoice shows the $10,000 overage at the contracted overage rate. This is painful to build from scratch and error-prone to maintain.

Revenue Recognition and Finance Features

Metronome integrates deeply with revenue recognition workflows. For companies that need ASC 606 compliance (any company with significant revenue or planning to go public), Metronome provides the data structure and event trail that finance teams and auditors require. Usage events are immutable, pricing calculations are auditable, and revenue can be allocated across performance obligations in a way that satisfies accounting standards.

This is not a feature that early-stage startups care about. But for Series B and beyond, or for companies selling to enterprises that require detailed invoicing and audit trails, it is a genuine differentiator. We have seen companies outgrow their billing system specifically because their finance team could not get the revenue recognition data they needed for audits.

Pricing and Positioning

Metronome is priced for enterprise buyers. Contracts start in the tens of thousands per year, with pricing based on billing volume and feature requirements. There is no self-serve tier. Implementation involves a dedicated onboarding process with Metronome's team, which typically takes 4 to 8 weeks for a full production deployment.

Metronome's sweet spot is companies with $5M+ ARR, enterprise sales motions, and billing complexity that has outgrown what Stripe can handle without significant custom engineering. If you are pre-revenue or at $500K ARR, Metronome is almost certainly overkill and overpriced for your current needs.

Feature matrices are useful, but they hide the nuances that actually determine which platform works for your specific situation. Here is how these three platforms compare on the dimensions that matter most for usage-based billing implementations.

Event Ingestion and Throughput

Stripe Billing v2 handles event ingestion well for most use cases but is designed as a general-purpose billing layer, not a high-throughput event pipeline. Expect batching limits of 1,000 events per API call and occasional latency spikes during high-volume periods. For most SaaS companies processing thousands to low millions of events per month, this is perfectly adequate.

Orb is built for high-volume event ingestion. Their pipeline handles billions of events per month for customers like Vercel, and the ingestion API is designed for low-latency, high-throughput workloads. If your product generates millions of billable events per day (common for AI inference, CDN, or data pipeline products), Orb is engineered for that scale.

Metronome also handles high-volume ingestion well, with a focus on data integrity and auditability over raw throughput. Every event is immutable and traceable, which matters for enterprise customers that require billing audit trails.

Pricing Model Flexibility

Stripe offers tiered, graduated, volume, and package pricing. These cover 80% of use cases. But if you need per-customer rate cards, SQL-based event transformations, or pricing that varies based on event metadata, you will be writing custom code.

Orb wins on flexibility. The SQL-based pricing engine lets you define almost any rating logic you can imagine. Charge per unique user per day. Apply different rates based on the API endpoint called. Calculate pricing based on the 95th percentile of hourly usage rather than total consumption. If your pricing model is genuinely novel, Orb can probably express it.

Metronome sits in between but adds contract-level customization. Each customer can have a unique rate card, and contract terms can override default pricing. For enterprise sales where every deal has negotiated rates, this per-customer pricing flexibility is essential.

Real-Time Dashboards and Customer-Facing Usage

All three platforms provide some form of usage dashboard, but the quality varies. Orb offers the best real-time customer-facing usage views, with embeddable components that let your customers see their consumption and projected costs. Stripe provides usage data via API but does not offer a polished customer-facing dashboard out of the box. Metronome provides detailed usage reporting oriented toward finance teams and account managers rather than end-user self-service.

API Design and Developer Experience

Stripe's API follows their well-established patterns: RESTful, well-documented, with SDKs in every language. If your team knows Stripe, the learning curve for Billing v2 is minimal. Orb's API is modern, strongly typed, and optimized for the billing domain. Their TypeScript and Python SDKs are excellent, and the API design feels like it was built by engineers who actually implement billing systems. Metronome's API is functional but more enterprise-oriented, with a steeper learning curve and less community content available.

Integration Effort

Stripe Billing v2 is the fastest to integrate if you are already on Stripe. Adding metered billing to an existing Stripe setup takes 2 to 5 days for a senior developer. Orb integration takes 1 to 3 weeks, including the Stripe connector setup, event pipeline configuration, and pricing model definition. Metronome integration takes 4 to 8 weeks, reflecting both the platform's complexity and the typically more complex billing requirements of companies that choose Metronome.

The straightforward case (send events, calculate usage, generate invoice) is easy on all three platforms. The hard parts of usage-based billing are the edge cases that every production system eventually encounters. Here is how each platform handles them.

Prepaid Credits and Drawdown

Orb has the most mature credit system. Prepaid credits, auto-top-up, expiration policies, credit grants from sales deals, and real-time balance tracking are all native features. Metronome supports prepaid commits as part of its contract management, with drawdown tracked against contract terms. Stripe has no native prepaid credit system. You will need to build credit balances, drawdown logic, and threshold notifications in your own application layer. This is one of the biggest gaps in Stripe's usage-based billing offering and the number one reason we see companies add Orb on top of Stripe.

Minimum Commits and Shortfall Billing

Minimum commits are standard in enterprise deals: the customer agrees to consume at least $10,000/month, and if they fall short, they still pay the minimum. Metronome handles this natively as a core part of its contract system. Orb supports minimum charges on subscriptions. Stripe requires custom logic to compare actual usage against the committed amount and generate the correct invoice. It is doable but manual.

Overage Billing

Overages come in two forms: exceeding a plan's included usage (like going over the 10,000 free API calls in your base plan) and exceeding a prepaid credit balance. Stripe handles the first case well with graduated pricing. Orb handles both cases natively, with configurable behavior for what happens at credit exhaustion (block access, allow overage at a specified rate, or notify and let the customer decide). Metronome handles overages as part of its contract terms, with different rates configurable for in-contract versus overage consumption.

Proration and Mid-Cycle Changes

What happens when a customer upgrades mid-cycle, switches pricing plans, or cancels with outstanding usage? Stripe has the most battle-tested proration engine, handling upgrades, downgrades, and cancellations with configurable proration behavior. Orb supports mid-cycle plan changes with usage-proportional adjustments. Metronome handles plan changes at the contract level, which typically aligns with enterprise amendment workflows rather than self-service plan switching.

Our recommendation for teams building subscription billing systems: map out your edge cases before choosing a platform. Write down exactly what should happen when a customer upgrades mid-month with $200 in unused prepaid credits and a $500 minimum commit. If you cannot express that scenario in your chosen platform without custom code, you may be picking the wrong tool.

After implementing usage-based billing across dozens of projects, from pre-launch MVPs to post-Series C infrastructure companies, here is our honest recommendation for which platform fits each stage.

Early-Stage Startups (Pre-Revenue to $500K ARR)

Start with Stripe Billing v2. The 0.7% billing fee is the lowest cost option when you are not processing high volumes. The integration is the fastest, especially if you are already on Stripe (and you probably are). You do not need a separate vendor for metering, billing, and payments. Yes, you will hit limitations. Prepaid credits will require custom code. Complex pricing models will require workarounds. But at this stage, your pricing model is going to change three times in the next 12 months anyway, and the speed of iteration matters more than billing engine sophistication.

The exception: if your product is credit-based from day one (like an AI product selling inference credits), consider starting with Orb's self-serve tier. The credit drawdown system alone will save you 4 to 6 weeks of engineering time compared to building it on Stripe.

Growth Stage ($500K to $5M ARR)

This is where Orb shines. You have enough volume to justify the cost, your pricing model has stabilized enough to invest in a proper billing engine, and you are likely hitting Stripe's limitations on pricing flexibility and real-time usage visibility. Orb sitting on top of Stripe for payment processing is the most common architecture we recommend at this stage.

The key signals that you have outgrown Stripe alone: you are spending more than 20% of an engineer's time maintaining billing code, your finance team is doing manual calculations to reconcile usage with invoices, or you need customer-facing usage dashboards that Stripe does not provide. If any of these ring true, the ROI on Orb pays for itself within 2 to 3 months. We covered more about choosing the right billing platform in our broader SaaS billing comparison.

Enterprise ($5M+ ARR, Contract-Driven Sales)

If your sales team is closing six and seven-figure annual contracts with custom rate cards, volume commits, and quarterly true-ups, Metronome is the right tool. The contract management and revenue recognition features justify the higher cost and longer integration timeline. At this scale, billing errors or audit failures cost more than the platform fee.

One pattern we see frequently: companies start on Stripe, migrate to Orb at growth stage, and then evaluate Metronome only if they move upmarket to enterprise sales. Most companies never need Metronome. But for those that do, nothing else handles contract-based consumption billing as completely.

The Bottom Line

Usage-based billing is not a solved problem, but these three platforms cover the full spectrum of needs. Stripe Billing v2 is the safe, fast, affordable starting point. Orb is the developer-loved engine for companies with complex, high-volume metering needs. Metronome is the enterprise powerhouse for contract-driven billing at scale. Pick based on where you are today, not where you hope to be in two years, because migrating billing platforms, while painful, is far less painful than fighting the wrong tool for 18 months.

If you are building a usage-based product and need help choosing the right billing architecture, or if you have already chosen and need a team to implement it properly, book a free strategy call with our engineering team. We have built these integrations across all three platforms and can help you avoid the expensive mistakes we have seen others make.