
Pricing & Monetization
Why Stripe paid $1B for Metronome instead of fixing Billing
Anh-Tho Chuong • 7 min read
Aug 5, 2025
/9 min read

Usage-based pricing is now the standard for SaaS and AI monetization, with over 60% of companies adopting it. This shift is driven by AI's variable costs, customer "subscription fatigue", and a focus on margins that make traditional per-seat models obsolete.
For developers, this new paradigm is complex. Implementing usage-based pricing is technically demanding, requiring precise metering, flexible pricing logic, and solid billing automation to prevent revenue leakage and customer frustration. This guide helps engineers design a developer-friendly usage model and build a scalable billing system to support it.
Usage-based pricing (UBP) charges customers based on their consumption of a product or service—such as API calls made, data processed, or gigabytes stored. Unlike flat-rate subscriptions, cost is tied directly to value, and a vendor's revenue scales with customer usage.
UBP works best when usage correlates strongly with customer value and the vendor's costs. It's common for cloud infrastructure, AI, and API-driven software but less so for apps where users don't perceive incremental value from each action. Many companies blend UBP with subscriptions to balance flexibility and predictability.
When it comes to implementation, billing often becomes a nightmare for engineers. Here’s why:
Leap years. Proration. Anniversary versus calendar billing. Trial logic. What begins as a single start_date field quickly sprawls into dozens of logic branches—and just as many support tickets.
You can sketch these scenarios in five minutes. But implementing them? That’s weeks of work—and tests.
Counting API calls or active users sounds easy—until you're processing millions of events a day. Tracking usage accurately, resetting counters monthly, and applying business logic at scale is not just an engineering challenge, it’s a data pipeline.
You have to support retries, replays, and race conditions without double billing—or missing charges. The concept of idempotency is simple. Guaranteeing it across distributed systems, over time, under pressure? Not so much.
Failed payments mean more than missed revenue—they mean workflows: email reminders, access suspension, retries, reconciliations. Every broken payment path is a leak in your funnel and a job for someone to fix. Eventually, someone jokes about hiring a Chief Waiting Funds Officer—and they’re only half joking.
Which rates apply? Where? To what product? For which customer? Are they tax-exempt? What if the rate just changed? What if this feature shouldn’t be taxed? What if you’re in 100 countries? You get the idea.
These examples are just the start. A custom billing system means keeping pace with tax law, time zones, currencies, proration logic, customer complaints, and security reviews. Tools like Lago exist so your team can focus on what makes your product great—not the infrastructure that gets you paid.
Understanding these five common models will help you build the right billing logic and data flows.

In consumption-based pricing, customers pay only for what they consume, with no base fee. Cloud providers like AWS bill for the exact gigabyte of storage or hour of compute used. Twilio charges per SMS sent, and AI APIs charge per token processed.

Customers buy a bundle of credits (often via subscription) that they spend to use the product. If credits run out, they must buy more or wait for the next cycle. This is very popular for generative AI apps.

Pricing is a percentage of a metric, usually revenue—a commission model. Stripe charges ~2.9% of the transaction volume it processes. This model is rare, as it requires access to a clear value metric like revenue or savings.

Outcome-based pricing is a "no cure, no pay" model where customers are charged only when a specific, successful outcome is achieved. For example, Chargeflow charges a percentage of recovered funds only when it successfully reverses a chargeback.

Hybrid pricing models are a common approach blends a subscription base fee (which includes a usage quota) with overage charges for higher consumption. Supabase, for instance, includes storage and bandwidth in its monthly fee, then charges for usage beyond those amounts.
Your billable metric is a foundational decision. It must be:
PostHog, for example, charges for events recorded or sessions replayed—metrics that are intuitive and clearly tied to value.

How you structure charges impacts user acceptance, revenue predictability, and technical implementation.
Pricing is a product feature. Build trust and reduce support load with these components:
Building a billing system is a major engineering effort. Whether you build or buy, address these core components.
Capture every billable action as a usage event with metadata (customer ID, timestamp, quantity). Use a robust events pipeline. Lago’s API can ingest up to 15,000 events per second and ensures idempotency with a unique transaction_id for each event, preventing double billing.
Raw events must be aggregated into the metrics you bill on (e.g., summing API calls per month). Lago supports various aggregation types likeCOUNT, UNIQUE COUNT, SUM, and MAX, and even allows custom SQL for complex metrics.
Apply your pricing rules to the aggregated metrics. This logic can range from a flat rate to complex tiered or volume-based structures. Lago supports all modern pricing models declaratively through its API or UI, including subscriptions, tiered pricing, and prepaid credits. For price estimation, Lago’s API has an endpoint to calculate an upcoming fee for a given usage input.
At the end of a billing period, generate an invoice detailing all charges, credits, and taxes. This process must be automated. Lago’s invoice engine consolidates all data to output a finalized invoice, handling proration and taxes automatically. Then, integrate with a payment processor to collect payment.
Treat your billing system as critical infrastructure. Ensure it can scale, create tests to verify its accuracy, monitor its performance, and keep an audit log of all changes.
Usage-based pricing unlocks growth but is complex to engineer. Building a custom billing system can divert your best engineers for months or years.
This is the problem we built Lago to solve. Lago is an open-source, API-first billing platform that gives you the control of a custom system without the maintenance burden. It supports all the models in this guide, from simple subscriptions to complex hybrid plans. Being open-source, it's flexible and never a black box.
By leveraging a solution like Lago, you can save months of engineering effort and focus on your core product, confident that your billing can handle any pricing strategy you dream up.
We started Lago because we understand the pain of billing. For our co-founder Raffi, building billing was supposed to be a short sprint with a single engineer. It ballooned into an ongoing team of 10 full-time engineers.
If you’ve read this ebook, you now understand the complexity of billing. Each individual part might not be difficult. But if you aggregate all of the parts, the system becomes difficult to maintain.
We built Lago as a plug-and-play billing system that’s as flexible as if you’ve built it yourself, but doesn’t come with the maintenance work of a homegrown system (nor the surprise edge cases).
Lago supports every pricing model and feature in this ebook natively so you can just focus on building.
Under the hood it ingests up to 15,000 billing events per second, lets you mix pay-as-you-go, hybrid or prepaid plans in minutes, and auto-generates tax-ready invoices, credits and one-off charges so revenue keeps flowing while you keep building.
Want to give Lago a try? Schedule a demo with our team today.
Content