Lago Alternatives for Usage-Based SaaS: 3 Steps to Pick 2027

The short answer: pick a billing engine by category

Usage-based billing engines fall into three categories, and that choice matters more than any single feature. The first is billing attached to a payments company, which covers Stripe Billing and Metronome, the usage engine Stripe now owns. The second is metering-first billing built for complex AI or API pricing, where Orb and m3ter compete, along with subscription suites that add usage, such as Chargebee. The third is open source that you run yourself, where Lago and the open-source OpenMeter project are the main choices. Lago sits in the third group, so the right alternative depends on whether you want to keep that control or trade it for a managed vendor.

Usage-based billing means charging each customer for measured consumption, such as events, API calls, seat-hours, tokens or credits, instead of only a flat monthly fee.

TL;DR: Choose open source if you must keep usage data on your own systems, Stripe Billing if payments already run on Stripe, and a sales-led metering vendor if your pricing has many meters and credits. Before you sign, check who owns the vendor, because three of the names on this list changed owners in 2026.

Key Takeaways

• Stripe's pay-as-you-go billing rate is 0.7% of billing volume, and Stripe's own docs now point new usage-based integrations toward Metronome.

• Metronome now belongs to Stripe, Orb now belongs to Adyen, and m3ter is moving into Salesforce, so ownership is the first contract risk to check.

• Four of the seven alternatives publish no price beyond a sales contact, so you will need a quote before you can compare total cost.

• Lago's self-hosted route is genuinely open source, but its own guide lists storage, Redis, TLS and upgrades as work your team takes on.

• Any switch needs a usage-to-invoice reconciliation, because the new engine has to match what your product recorded.

Who this is for

This guide is for an owner or operations lead at a small SaaS company who is close to choosing a usage-based billing engine and needs to know which Lago alternative fits. You likely have at least one usage meter, an engineer who can send events from your product, and a finance owner who approves invoices.

Red flags: you bill only a flat monthly subscription, so metering adds cost without a pricing need; your product cannot send usage events, so none of these engines can bill anything; or you need self-hosting but no one on the team will run the database, Redis and upgrades.

How we evaluated these tools

We reviewed each vendor's public pages, primary announcements and independent coverage from a research firm and trade publications, and we checked ownership and pricing wording against those sources. We did not run any of these products, so this guide makes no claim about hands-on results. The weights below are our judgment about what a small buyer needs, and they set the order in which the later sections compare vendors.

Usage modeling and ingestion correctness together carry 45% of the weight, because an engine that cannot represent your meters, or that counts a retried event twice, creates billing work that no discount covers.

Ownership changes that affect a multi-year contract

Three of the seven alternatives changed owners in 2026, which matters more for a multi-year contract than most feature lists. Adyen agreed on June 11, 2026 to buy Orb. Adyen purchase price for Orb: $335 million according to Adyen (2026). Adyen's closing release states that the Orb and Talon.One acquisitions closed on July 1, 2026, according to Adyen (2026), and it says Adyen will begin integrating Orb's flexible billing. Orb's roadmap now follows a payments company's integration plan, which is a question to put to the vendor in writing.

Stripe's newsroom says it completed its acquisition of Metronome on January 14, 2026, according to Stripe (2026). The price is reported, not confirmed by a primary source. Metronome deal value: about $1 billion, reported according to Sacra (2025). Sacra's research note describes Metronome as supporting multi-meter pricing, credits and caps.

Salesforce announced its m3ter acquisition on June 8, 2026 and states on its announcement page that the deal closed on July 1, 2026, according to Salesforce (2026). CIO reports that the aim is to bring m3ter's metering and rating into Agentforce Revenue Management, which CIO describes as the new name for Salesforce's former Revenue Cloud, according to CIO (2026).

The pages reviewed here do not describe post-acquisition pricing, support or data-export terms, so ask each vendor for those in writing before you sign anything.

Published prices and what they leave out

Pricing checked October 21, 2026.

Stripe publishes the most concrete usage rate in this group. Stripe pay-as-you-go: 0.7% of billing volume according to Stripe (2026). The same page lists annual plans paid monthly at $620, $1,500, $2,950 and $5,750 per month on one-year contracts, and it bills card payments separately at 2.9% plus 30¢ per successful charge. The pay-as-you-go rate covers billing transactions processed on and off Stripe and excludes one-off invoices.

Chargebee's Flow plan includes 100M usage events per month, according to Chargebee (2026). The same page shows two fee formulas, $0 + 0.80% and $99 + 0.65%, beside a monthly invoicing volume slider, but it does not say which plan each formula belongs to, so confirm the applicable figure with Chargebee before you model it.

Orb publishes a per-credit price, covered in its profile below. Metronome's price is set through contact, since Stripe's pricing page tells readers to contact Metronome for usage-based billing. m3ter's core fee depends on the size of your needs, and its page gives no figure. Kong's OpenMeter pricing page tells readers to contact sales for pricing. Paid's pricing page lists no public prices. Lago's pricing page lists no dollar amounts and routes its Premium tier through contact buttons.

Worked example: fees on $20,000 of usage

Take a small SaaS company that bills $20,000 of usage in one month, with 40 card charges as an assumption for this illustration. At the 0.7% pay-as-you-go rate on Stripe's pricing page, the billing fee is $140 (20,000 × 0.007). At the 0.60% that Orb's pricing page gives for one credit, the equivalent is $120 (20,000 × 0.006), a $20 gap before the event ingestion and other metered dimensions that Orb says are charged on top. Card processing on the same charges adds $592 at 2.9% plus 30¢ ((0.029 × 20,000) + (40 × 0.30)), which is more than four times the Stripe billing fee and applies whichever billing engine you choose. On the recording side, a team already on Billing Meters would send usage to /v1/billing/meter_events, while Stripe's recording docs now direct new integrations to Metronome.

Feature matrix: what each page states

This matrix records only what the pages reviewed say. "Not stated" means the page says nothing on that point, not that the feature is absent.

Lago is the baseline. Its GitHub page states that the platform is distributed under AGPLv3, that it deduplicates usage events by transaction ID so a retry does not bill twice, and that it supports prepaid credits with automatic top-ups. Its self-hosted guide covers persistent storage, SMTP, TLS, object storage, Redis, database configuration and upgrades, and that is the operational work an open-source choice carries. The Lago repository is the primary reference for those details.

Vendor profiles: best fit, limits and implementation

Stripe Billing

Best fit: teams already processing payments on Stripe that want usage fees and invoices in the same account. Limitations: Stripe's docs say Billing Meters is for teams already using it, and new integrations should use Metronome, so a fresh build on Billing Meters may need a later move. Payment processing is billed separately from the billing fee. Implementation: Stripe's recording docs describe an API path, a dashboard CSV upload and an Amazon S3 bulk path, so pick the one your event pipeline can support. Evidence: the Stripe recording-usage docs.

Metronome

Best fit: products with multi-meter pricing, credits, caps and high event volumes, such as AI products. Limitations: pricing is set by contact, and Stripe's own docs recommend Metronome for most new integrations, so inside Stripe it is the default choice rather than a separate option. Implementation: Stripe's documentation says Metronome processes usage events in real time and tracks running balances, which means your product sends events to Metronome's ingest API rather than to Stripe directly. Evidence: the Stripe usage-based billing docs and the Sacra research note.

Orb

Best fit: teams with credit-based or hybrid pricing that accept a sales-led contract. Orb per-credit price: $6.00 per credit according to Orb (2026). The same page says one credit works out to 0.60% of billing volume, plus event ingestion and other metered dimensions, so budget for both. Limitations: Orb now belongs to Adyen, and Adyen's closing release says it will begin integrating Orb's flexible billing into its own platform, so the roadmap now follows that plan. Implementation: plan for an event feed from your product and a mapping from your current meters to Orb's billable metrics, and get the ingestion terms in the contract. Evidence: the Adyen announcement and Orb's pricing page.

m3ter

Best fit: mid-size and large B2B SaaS companies with complex usage pricing, which is the segment m3ter's pricing page says it is designed for. Limitations: a small team gets a sales-led process with a core fee based on the size of its needs, and add-ons increase the usage-data and calculation allowances and bring prebuilt CRM and ERP integrations. The product is also being folded into Salesforce's revenue stack, as covered above. Implementation: confirm whether the CRM or ERP connection you need is one of the prebuilt add-ons, since its page describes those as extra. Evidence: the m3ter pricing page.

Chargebee

Best fit: teams that want subscriptions and usage billed in one suite, and that want published fee formulas at smaller volumes. Limitations: Enterprise pricing is quote-based, and ingesting up to 500M usage events per month is a paid add-on with no price shown on the pricing page. Implementation: Chargebee's documentation describes hybrid, purely prepaid and pay-as-you-go models, so map your current pricing to one of those before you configure included usage and overages. Evidence: the Chargebee usage pricing docs.

Kong Konnect Metering & Billing

Best fit: API-first products that already run Kong gateways and want entitlements and invoices close to their traffic. Kong said the product would be available as part of Konnect in Q4 2025, according to Kong (2025), and the release lists real-time metering inside Kong's gateways, rate cards, entitlements and invoice generation at the end of a cycle or on demand. Limitations: OpenMeter Cloud has been renamed Konnect Metering & Billing, and its pricing page directs buyers to sales. Kong's 2025 coverage described a customer migration to Konnect planned for mid-2026, as SiliconANGLE reported. I could not confirm the current migration state from the pages I opened, so ask Kong directly. Implementation: the open-source OpenMeter project remains under an Apache 2.0 license, according to Kong's acquisition post, which matters if you want a self-hosted path.

Paid

Best fit: companies that sell AI agent work, where the billable unit is a task, an outcome or an agent. Paid's pricing page describes metering agent events into billable units, usage and outcome-based invoicing, and a billing stack covering payments, credits, proration, dunning and e-invoicing. Limitations: the pricing page lists no public prices, and its focus on agent work may be more than a SaaS company with seat-plus-usage pricing needs. Implementation: the page says finalized invoices can be pushed into an existing billing or financial stack, which helps if you keep a separate ledger. Evidence: the Paid pricing page, which contains vendor claims that you should verify in a demo or contract review.

Reconciling usage after a switch

This is where a switch usually goes wrong. A proposed design from US Tech Automations would be a configurable workflow, not a live deployment. Its trigger would be a scheduled export of per-customer usage totals from the billing engine, or a webhook if the vendor offers one. Its action would compare those totals with the usage log in your own product database for the same billing period and flag any customer where the two differ by more than a threshold your team sets. Its output would be an exception queue listing the customer, the meter, both counts and the invoice ID. Prerequisites are read access to the billing engine's usage export or API and read access to your event store, and a finance owner would approve any credit or re-bill before it posts.

A second configurable workflow covers the cutover. It would trigger when a new plan version is published in the new engine, run the reconciliation for the last full billing cycle in parallel with the old engine, and output a summary of mismatches by meter. The review point is the operations lead's sign-off before the old engine stops invoicing. Prerequisites are API or export access on the new vendor and a documented mapping from your old meters to the new billable metrics. This check does not replace the vendor's own invoicing; it verifies it. For the reporting side, our how-to guide on automating SaaS usage reporting covers the same data flow from a reporting angle.

The usual alternative is stitching this together in Zapier, Make or n8n, or building it in-house. Those tools can keep run histories, retries, error branches and audit evidence when they are configured that way. The buyer still designs and owns idempotency, escalation paths, access controls and ongoing maintenance, and those are the parts that stop being maintained when the person who built them moves on. A configured US Tech Automations design would differ mainly in packaging those controls into a fixed exception queue and review step, and the buyer would still need to supply the export access that makes it work.

Terms used in this guide

• Metering: recording each usage event from your product with a customer identifier, a meter name and a quantity.

• Rating: turning recorded usage into a charge using a price rule, a tier or a credit balance.

• Included usage: the allowance inside a base fee before overage rates apply.

• Overage: the charge for usage above the included allowance.

• Prepaid credit drawdown: deducting usage from a balance the customer paid in advance.

• Deduplication: making sure a retried usage event is counted once, so the customer is not billed twice.

• Reconciliation: comparing invoice totals with the usage log for the same period.

Three steps to shortlist

1. Map your usage. List every billable event, who sends it, and whether it is sent in real time or in a batch. Anything you cannot list is a question for every vendor.

2. Match the price basis. Translate your current price into each vendor's basis, whether that is a percentage of volume, a per-credit price, a core fee or a quote, and compare on your own volume rather than on plan names.

3. Check owners and exit terms. Confirm who owns the vendor, what happens to pricing and support after an acquisition, and how you export your usage history if you leave.

Choosing by situation

When NOT to use US Tech Automations: if your usage fits one meter and one invoice template, the billing engine's own reports may be enough, and an added workflow layer only adds a system to maintain. If your team cannot grant read access to usage exports, the reconciliation workflow has nothing to read. If you want the billing vendor to own every control, including exception handling, a simpler setup inside that vendor is the better fit. For a broader look at AI tools sold to SaaS teams, our AI writing tools for SaaS roundup covers that category separately.

Frequently asked questions

Is Lago still the right pick if I want open source?

Yes, if keeping usage data on your own systems is a hard requirement, because Lago's core is AGPLv3 and it runs on infrastructure you control. You then take on storage, Redis, TLS and upgrades, and its paid cloud and self-host tiers are quote-based on its pricing page.

Did Stripe buy Metronome?

Yes. Stripe says it completed the acquisition on January 14, 2026, and its usage-based docs now recommend Metronome for most new integrations.

Is Orb still independent?

No. Adyen says the Orb acquisition closed on July 1, 2026, and it plans to integrate Orb's flexible billing into its own platform.

Does m3ter sell to small companies?

Its own pricing page says it is designed for mid-size and large B2B SaaS companies, so a small team should expect a sales-led process with no published figure.

Which alternative has the lowest published price?

No single winner exists because the figures use different bases: Stripe charges 0.7% of billing volume, Orb charges per credit, and Chargebee uses fee formulas, so compare them on your own volume using the worked example above.

Can a non-engineer switch billing engines?

No, not on these products alone, because usage events have to be sent from your product to the new engine, and that needs a developer who can build and maintain the integration.

Narrow the list this week

Start with the category decision: open source if you must keep usage data on your own systems, Stripe Billing if payments already run on Stripe, and a sales-led metering vendor if your pricing needs many meters and credits. Then check ownership, since Metronome, Orb and m3ter all changed hands in 2026, and ask every shortlisted vendor for its price basis and post-acquisition terms in writing. Before any cutover, run the reconciliation so the new engine's invoices match what your product recorded, and see how our team at US Tech Automations configures this for your own export and review steps.