How to add usage-based pricing to an existing SaaS without rebuilding your whole system

You add usage-based billing to an existing SaaS product by instrumenting your app to send usage events to a separate metering and billing layer, then pricing those events with a hybrid plan. Your current subscriptions keep running. New customers and new features go first. Existing accounts migrate last, in waves.

The rest of this guide covers the architecture, the pricing structure to aim for, and the order of operations that keeps finance, sales and customers on side.

How to implement usage-based billing without rebuilding your billing system

Most teams assume "add usage" means rewriting billing. It rarely does. (If you are weighing whether to build the billing layer yourself, see build or buy usage-based billing.) The pattern that works keeps three jobs apart:

1. Your application does what it already does, plus one thing: when something billable happens, it emits an event.
2. A metering and billing layer receives those events, deduplicates them, aggregates them per customer and turns them into invoice lines using your pricing rules.
3. Your payment provider keeps collecting money. Nothing about your checkout or payment stack has to change.

The application never calculates a price. It reports facts: who did what, when, and with which attributes. Pricing lives in configuration, so changing a rate or adding a tier doesn't need an engineering release.

Here's an illustrative event in Lago's documented format:

{
  "transaction_id": "rpt_20261007_acct418_00027",
  "external_subscription_id": "sub_acct418",
  "code": "report_runs",
  "timestamp": 1791383400,
  "properties": {
    "report_type": "scheduled",
    "workspace_id": "ws_12"
  }
}

The transaction_id makes retries safe: the same event sent twice is billed once. The code maps to a billable metric you define in the billing layer. Properties you don't price on today are ignored, so it pays to include dimensions you might price on later. The event ingestion guide covers design, delivery options and late-arriving events.

This is also why the change stays out of your core code. One instrumentation call per billable action is usually the whole footprint. Your existing billing can keep invoicing flat subscriptions while the new layer handles usage, until you choose to consolidate.

Which billing platform engineers look for when core code can't change

If the requirement is "add usage pricing without touching the core application," the evaluation checklist is short:

• Event ingestion with idempotency. Retries and replays must never double-bill.
• Pricing as configuration. Plans that combine a fixed fee with metered charges, tiers and filters, editable without a deploy.
• Per-customer exceptions without forking plans. Negotiated rates have to live somewhere other than a spreadsheet.
• Prepaid credits and spend controls. Wallets, top-ups and thresholds, so usage can be paid before or after it happens.
• Plan changes with proration. Customers will upgrade and downgrade mid-cycle.
• Your payment provider stays. Native payment provider integrations or a webhook-based custom path, so switching billing logic doesn't force a new processor.
• Inspectable logic. Finance and customers will ask why a number is what it is. The answer has to trace back to events.

Lago covers this list. Plans combine a recurring fee with usage-based charges. Billable metrics define how events aggregate (count, sum, unique count and more). Wallets hold prepaid credits with top-ups. Upgrades and downgrades prorate automatically. Lago connects to existing payment providers, and because it's open source, engineers and finance can read the same logic that produces the invoice. Some capabilities, such as per-customer plan overrides and progressive billing, are premium. The usage-based billing overview shows how the pieces fit.

How to implement usage-based pricing for your software product

Start with the unit, not the meter. The tempting choice is whatever your infrastructure already counts. The right choice is what the customer already sees as valuable: a report run, a workflow completed, a document processed, an agent action executed. Sometimes that really is API calls or events, but only when those calls are the value. Our usage-based pricing examples show how other companies chose their unit.

One test settles it. Can the customer explain, without your help, why this number moves their bill? If they can't, it isn't pricing. It's a tax they will eventually push back on.

How to implement hybrid pricing with both flat fees and usage charges

For a SaaS product with an existing subscription base, the target structure is a hybrid with three parts:

1. A platform fee. Predictable revenue for you, a predictable floor for the buyer.
2. An included allowance. A pool of usage inside the fee, so customers can adopt without watching a meter.
3. One rule past the allowance. Overage, top-ups, prepaid credits or a higher tier. Pick one, not all four.

The allowance is the hardest number. Include too much and you give away margin. Include too little and the plan reads as greedy.

The rule past the allowance depends on what the usage is:

• Operational usage (the customer's production depends on it) should be postpaid and keep running. Most buyers would rather pay an overage than have a critical workload stop.
• Discretionary usage (user-initiated, not critical) fits prepaid credits. When credits run out, the customer tops up or the feature pauses. Letting customers choose between auto top-up and manual purchase removes most of the surprise.

When usage can grow fast, as with AI inference, a large bill at month end is a risk for both sides. Progressive billing addresses it: an invoice is issued as soon as cumulative usage crosses a threshold you set, instead of waiting for the period to close. For the tradeoff between the two approaches, see prepaid credits vs progressive billing.

What changes when switching from flat subscriptions to pay-as-you-go

The pricing decision usually makes itself. The product grew, the plans stopped matching how people use it, and a few accounts get far more value than everyone else on the same fee.

The hard part is that "add a usage component" lands on live contracts, renewal dates, sales comp, the finance close and the support queue. It is an operating model change. Our playbook breaks it into seven steps:

1. Price the value, not the meter. Bill the thing the customer already sees as valuable.
2. Use new customers as a clean room. They carry no legacy discounts or old promises. Run the target hybrid model on them first.
3. Validate pricing like product. Watch three signals in live deals: a rep can explain the model in a minute, a buyer can ballpark their own spend before signing, and the bill rises when the customer gets more value.
4. Build a bridge for existing customers. Put new pricing logic on something they didn't already buy, so nobody's current contract gets reopened.
5. Make one number survive an audit. Product, billing, finance and the customer must all land on the same usage figure.
6. Treat migration as a migration. Map contracts and move in waves, with the most complex agreements last.
7. Sequence the tension. Finance, sales, product, legal and support want different things. You order them, you don't remove them.

Public examples show steps 3 and 4 at work. MongoDB kept its licensed product and built Atlas as a separate consumption product that customers could move to when ready. Atlas made up 75% of total revenue in the third quarter of fiscal 2026 (MongoDB, Q3 FY2026 results). Salesforce priced Agentforce at $2 per conversation, then in May 2025 added Flex Credits at $0.10 per action (Salesforce press release). The first unit is rarely the final one, so test it on live deals before rolling it across the base.

Steps 5 and 6 are where most transitions get expensive: reconciling usage figures across systems and moving each contract type in the right order. The full playbook covers both in detail. Download "How to Add Usage Without Breaking the Business" for the audit standard and the migration waves.

On the systems side, you don't need a big-bang cutover. Existing customers can keep their current plan, effectively grandfathered, while new plans run alongside. When an account is ready to move, Lago lets you start a subscription with a past start date without generating invoices for periods already completed, so a migrated customer isn't billed twice. If you are replacing your whole billing system rather than adding usage to it, our guide to billing system migration covers parallel runs and cutover.

How to add usage-based billing to a SaaS product that just added AI features

New AI features make a natural bridge. Customers didn't buy them under the old contract, so new pricing logic doesn't feel like a change to what they already pay for.

A practical setup:

• Keep the existing seat or tier subscription exactly as it is.
• Meter the AI feature as its own billable metric, using a unit customers recognize (tasks completed, documents processed, credits consumed) rather than raw tokens, unless your buyers think in tokens. If they do, see how to bill for AI API usage.
• Include an allowance in each existing tier so current customers can try it without a new purchase decision.
• Sell additional usage as prepaid credits, which suits discretionary, user-initiated AI usage and keeps cost exposure bounded.

Because each event carries properties, you can record the model or feature variant from day one and decide later whether to price on it. For token-based products, the Lago Agent SDK can extract token usage from supported model clients and send it as billable events.

How to implement usage-based billing for fintech companies with complex pricing models

Fintech pricing usually mixes three things: a platform or account fee, a percentage of transaction value, and per-transaction fixed fees, often with rates that change by volume or by payment method.

The same architecture applies. Each transaction becomes an event carrying its amount and attributes like method, currency or region. The billing layer then applies the pricing:

• A percentage charge takes a rate on summed transaction value, with an optional fixed fee per transaction and free units.
• A graduated percentage charge lowers or raises the rate as volume crosses tiers.
• Filters price the same metric differently by attribute, for example card versus bank transfer.
• A recurring platform fee on the plan provides the hybrid floor.

In Lago, per-transaction minimum and maximum amounts on the percentage model are a premium feature. Fintech teams also tend to need negotiated rates per customer, which is where plan overrides help, and progressive billing when a single customer can generate large volume within a cycle.

Start with the sequence, not the system

The technical half of adding usage is the solvable half. Send events, configure a hybrid plan, keep your payment provider and run old and new plans in parallel. The harder half is deciding who moves first and making sure every number holds up when finance checks it.

Get the playbook: How to Add Usage Without Breaking the Business

Want to see the setup on your own pricing? Book a demo.