7 Best Usage-Based Billing Platforms for SaaS in 2026: Deep Comparison

What Is Usage-Based Billing Software?

Usage-based billing software is infrastructure that tracks how much of a product each customer consumes, applies pricing logic — linear, tiered, volume, matrix, or committed-spend — and generates invoices based on actual consumption rather than a fixed fee. It sits between your event sources (APIs, infrastructure metrics, application telemetry) and your payment processor, handling the metering, aggregation, pricing calculation, and invoice generation in between.

Key Takeaways

• Data ownership splits the market in two. ABAXUS and Lago (self-hosted) keep usage data inside your infrastructure. Every other platform on this list stores it on their servers.
• Percentage-of-revenue pricing compounds. A platform charging 0.5% of revenue costs $50,000/year at $10M ARR and $150,000/year at $30M ARR — independent of what it actually costs the vendor to process your events.
• API rate limits are architectural, not configurable. Cloud billing platforms process events on shared infrastructure. Their rate limits cannot be raised by customer request; they can only be worked around with batching and compression that introduce aggregation lag.
• Stripe Billing is not a usage-based billing platform. It is a payment processor with metering add-ons. Evaluating it alongside purpose-built metering platforms sets the wrong benchmark.
• The right choice changes as you scale. A platform that works well at $1M ARR may cost too much, process too slowly, or hold data in the wrong place at $20M ARR. Evaluate against your 3-year trajectory, not today’s volume.

The Case for Getting This Decision Right

Usage-based pricing has become the dominant revenue model for B2B SaaS. According to OpenView Partners, 61% of SaaS companies now offer some form of usage-based pricing component, up from 45% in 2021. Bessemer Venture Partners reports that best-in-class net revenue retention from usage-based cohorts reaches 120%+ — meaningfully above the 109% median for pure subscription models.

The billing infrastructure underneath that model is not a commodity decision. A misconfigured metering pipeline produces invoices customers can’t verify, support teams can’t explain, and finance can’t audit. A real incident: a Vercel customer received a $96,000 bill in a single month from a misconfigured deployment. Stripe’s Events API rate-limits at 100 requests per second — a ceiling that becomes visible at approximately 10 million metered API calls per month.

The platform you choose determines whether you can explain every charge, whether your usage data stays in your infrastructure, and whether your billing fees stay flat as revenue grows. These are architectural decisions with a 5-year cost that is invisible at selection time.

How to Choose a Usage-Based Billing Platform

Usage-based billing platforms are not interchangeable. The right choice depends on where your usage data needs to live, how complex your pricing logic is, how much engineering you want to own, and what event volume you’re planning for. Before evaluating any platform, answer seven questions:

1. Data residency — does your usage data need to stay in your own infrastructure, or is cloud-hosted acceptable? For healthtech SaaS, any usage event that carries patient context triggers HIPAA obligations the moment it crosses a third-party API.
2. Pricing model complexity — do you need linear rates only, or tiered, volume, committed-spend, ramp schedules, and custom enterprise structures?
3. Event volume — how many usage events per month today, and at 3× growth? Cloud platforms have shared-infrastructure rate limits that cannot be raised on request.
4. Engineering capacity — how much does your team want to own, configure, and maintain? Self-hosted platforms shift operational overhead to your team.
5. Transaction volume economics — at what revenue level does percentage-of-revenue pricing become a significant line item? Run the math at your 3-year ARR projection.
6. Integration requirements — what does the platform need to connect to? CRM, ERP, Stripe, accounting — the integration ecosystem varies significantly.
7. Migration path — how easily can you export your data if you need to switch? Your data portability risk is proportional to the maturity and data policies of the vendor.

At a Glance

1. ABAXUS

Self-hosted billing infrastructure for engineering teams that have outgrown cloud billing platform constraints.

Most SaaS billing platforms share a structural constraint: your usage data must cross a network boundary to reach their API. That boundary is invisible when event volumes are modest. It becomes the throughput ceiling, the compliance risk, and the audit trail gap as you scale.

ABAXUS eliminates that boundary. It is a production-grade billing engine that deploys inside your own Kubernetes cluster, co-located with your event sources. Every usage event, every aggregated meter, every invoice lives in your database — in your infrastructure — with no external API in the billing critical path.

Five failure modes that surface at scale in cloud billing platforms — events double-counted on retries, aggregates that lag real usage, invoices support cannot explain, meter definitions that break historical data when pricing changes, and data residency requirements that cloud APIs cannot satisfy — are each addressed by design in ABAXUS, not patched after the first incident.

Strengths

No API rate limit ceiling. Cloud billing platforms process your events on shared infrastructure. Their rate limits are not bugs — they are architectural constraints of the shared-infrastructure model. When your event volume outgrows the vendor’s limit, no configuration fixes it. ABAXUS ingests events from within your own infrastructure — from Prometheus, OpenTelemetry, Kafka, change-data-capture, webhooks, or direct API — without a network boundary to saturate.

Complete data sovereignty. Every usage event, aggregated meter value, and invoice lives in your database. There is no vendor dependency for access to your billing history. For healthtech SaaS, usage events containing patient context stay inside the HIPAA-compliant perimeter — no Business Associate Agreement required for the billing layer, because billing data never crosses a third-party API.

Meter versioning. When a cloud billing platform’s meter definition changes, historical data is typically frozen at the old definition or requires a manual migration. ABAXUS meters are versioned with time-bounded applicability: pricing changes apply to events from their effective date forward. Events already ingested are repriced at the rate active when they occurred. Historical invoices remain accurate; no backfill migration required.

No per-transaction fees — and the math compounds. A platform charging 0.5% of revenue costs $50,000/year at $10M ARR. At $30M ARR, that fee is $150,000/year — a cost that scales with your revenue independent of what it costs the vendor to run. ABAXUS operates on a self-hosted license model. The cost is fixed regardless of the revenue you process through it.

Idempotent event ingestion at any volume. Duplicate event submissions — from retries, from regional multi-delivery, from batch pipeline replays — are deduplicated against a globally unique idempotency key per event. Double-counting on retry is a structural property of systems that do not enforce this guarantee end-to-end; ABAXUS enforces it at the ingestion layer.

Full audit trail, in your infrastructure. Every invoice line is traceable to its raw usage events through a queryable, immutable audit log stored in your own database. Finance and support run their own queries without opening a vendor support ticket. This is the operational difference between a billing system that can explain every charge and one that cannot.

Built for AI and LLM products. Token billing, agent action metering, and per-model-call pricing are first-class dimensions in ABAXUS. For AI products generating billions of token events per month, the rate limit ceiling and per-transaction fee structure of cloud billing platforms are business problems before they become infrastructure problems. ABAXUS processes at your infrastructure’s capacity, with costs fixed at the license rate.

Weaknesses

Requires infrastructure ownership. If you want zero operational overhead — no Kubernetes deployment, no database management, no upgrade cycles — ABAXUS is not the right choice. The self-hosted model shifts infrastructure responsibility to your team. For companies below a certain engineering maturity threshold, this overhead is not worth the control.

Smaller integration ecosystem than established vendors. Chargebee and Metronome have years of pre-built integrations with CRMs, ERPs, and accounting software. ABAXUS integrates via API, covering standard connection patterns but requiring more initial setup than clicking a pre-built connector.

Newer market entrant. ABAXUS is newer to the market than the established platforms. The API surface and documentation are production-grade, but the ecosystem of third-party tooling, community knowledge, and published case studies is still building.

Pricing

Self-hosted annual license. No per-transaction fees. Cost does not scale with your revenue.

Early adopter program active: 65% lifetime discount for qualified teams. See full pricing →

Who ABAXUS is for

Engineering-led SaaS companies billing on API calls, compute time, tokens, agent actions, or other high-volume metered dimensions — and have either hit the throughput ceiling, the compliance wall, or the fee inflection point with their current cloud billing platform. Particularly strong fit for: healthtech SaaS with PHI in usage events, AI and dev tools companies processing billions of events per month, and any team whose billing transaction fees have become a material line item.

Who should look elsewhere

Teams that want a fully managed billing service with zero infrastructure ownership. Companies below $2M ARR where the absolute fee savings do not justify the migration overhead. Products with purely flat-rate pricing that generate no meaningful event volume.

2. Lago

Open source usage-based billing — self-hosted or cloud.

Lago is MIT-licensed open source software for usage-based billing. It provides a full billing API with metering, pricing logic, invoice generation, and a customer portal. The self-hosted version is free; a cloud-hosted version is available for teams that want the open source foundation without the operational overhead.

Strengths

Genuinely open source. The core billing engine is available under the MIT license — inspect the code, fork it, customize it, run it without any vendor dependency. For teams evaluating billing infrastructure as a long-term architectural decision, open source provides assurances that proprietary software cannot.

Strong developer experience. The API is well-documented, actively maintained, and designed to be integrated by engineers. The community is active; the changelog is transparent about what is and is not supported.

Self-hosted data control. Like ABAXUS, the self-hosted deployment keeps all usage data in your own infrastructure. For teams where data residency matters but open source is preferred over a commercial license, Lago is the primary option.

Progressive complexity. Lago handles most common billing models — per-unit, tiered, volume, graduated, package — and the configuration is accessible without requiring custom code for standard use cases.

Weaknesses

Community support on the open source tier. The self-hosted version is community-supported. If you need guaranteed SLAs, priority incident response, or dedicated support, you are on the cloud plan — which changes the cost comparison.

Cloud pricing narrows the advantage. The managed cloud version starts around $600–800/month. At that price point, it competes with the lower tiers of Chargebee and Orb, and the cost advantage over proprietary platforms narrows.

Enterprise readiness. Lago’s strengths are on the developer and startup end of the market. Complex enterprise contract structures, committed-spend agreements with custom exceptions, and deep ERP integrations are less mature than in enterprise-focused platforms.

Pricing

Self-hosted: free (MIT license). Cloud: paid plans starting around $600–800/month. Custom enterprise pricing available.

Who Lago is for

Development teams that want an open source billing foundation they can inspect, modify, and run themselves. Early and growth-stage companies that want to avoid proprietary vendor lock-in from the start. Teams where the engineering capacity exists to own and maintain the billing infrastructure.

Who should look elsewhere

Companies that need enterprise-grade SLAs, deep pre-built ERP integrations, or complex committed-spend contract structures. Companies where the engineering team cannot own the billing infrastructure deployment.

3. Orb

Cloud-native, API-first billing built for developer tools and API companies.

Orb is a managed cloud billing platform with strong support for complex usage-based pricing. It is designed with engineering teams in mind — the API is well-documented, the pricing engine handles sophisticated models, and developer experience is a primary focus. Orb positions itself as the billing layer for developer tools, AI products, and API businesses.

Strengths

Sophisticated pricing engine. Orb supports a wide range of pricing structures: tiered, volume, bulk, matrix pricing (billing on multiple dimensions simultaneously), and committed-spend with overage. Pricing configuration is accessible through code or API rather than a complex UI workflow.

Real-time metering. Event ingestion is designed for high-throughput API products. Usage data is available near real-time, and the platform handles aggregation and state management for real-time billing dashboards.

Strong developer documentation. The API reference, SDKs, and integration guides are among the strongest in the category. Engineering teams evaluating Orb typically find that integration friction is low.

Pricing simulations. Orb allows teams to model the revenue impact of pricing changes against historical usage data before rolling them out — a capability that reduces the risk of pricing model changes.

Managed infrastructure. No deployment, no database management, no upgrade cycles. The full billing pipeline is managed by Orb.

Weaknesses

Data lives in Orb’s infrastructure. For companies with data residency requirements or strong data sovereignty preferences, this is a fundamental constraint. Your usage events, customer data, and billing history are stored on Orb’s systems.

Percentage-of-revenue pricing at lower tiers. The pricing model includes a percentage of revenue component, which becomes materially expensive as revenue scales.

Cloud-only deployment. No self-hosted option. If your security requirements or regulatory environment require data to remain in your own infrastructure, Orb is not available.

API rate limits cap event throughput. As a shared-infrastructure platform, Orb’s ingestion API has rate limits. For products generating event volumes in the billions per month, these limits require batching or compression strategies that introduce processing lag and aggregate staleness.

Pricing

Percentage of revenue at lower tiers; flat-rate enterprise pricing at higher volumes. Pricing is not publicly listed for all tiers — contact for current rates.

Who Orb is for

API companies, developer tool businesses, and AI products that want a sophisticated billing engine without infrastructure ownership. Teams where data residency is not a constraint and the cost of percentage-of-revenue pricing is acceptable relative to the engineering time saved.

Who should look elsewhere

Companies with data residency requirements. Companies at revenue scale where percentage-of-revenue billing fees are a significant line item. Teams generating very high event volumes that stress shared API ingestion limits. Products that need their billing data in their own infrastructure for analytics, compliance, or operational reasons.

4. Chargebee

Subscription billing with usage-based capabilities — best for hybrid models.

Chargebee is one of the most established names in SaaS billing. It started as a subscription billing platform and has added usage-based capabilities over time. The result is a mature, well-integrated platform that works best for companies whose billing model is primarily subscription-based with usage-based components layered on top.

Strengths

Mature ecosystem. Chargebee has pre-built integrations with a large number of CRMs, accounting platforms, payment gateways, and other SaaS tools. For companies that need billing to connect to Salesforce, NetSuite, QuickBooks, and a dozen other systems, Chargebee’s integration library reduces implementation work significantly.

Subscription management depth. Trial management, plan changes, proration, dunning, renewal automation — among the most complete in the market. For companies with complex subscription models, this depth is hard to replicate.

Non-technical accessibility. Chargebee’s UI allows operations, finance, and sales teams to configure pricing plans, create coupons, manage customers, and generate reports without engineering involvement. This is a genuine capability advantage for companies where billing operations are not owned by engineering.

Revenue recognition compliance. Built-in support for ASC 606 and IFRS 15 revenue recognition, plus tax compliance tools, makes Chargebee relevant for companies with audit requirements.

Weaknesses

Subscription-first architecture. Chargebee’s data model and workflow are built around subscriptions. Usage-based billing is an add-on to that model, not the primary design. For companies running pure usage-based models — no subscription base — the fit is less natural.

Per-transaction fees and complex pricing tiers. Chargebee’s pricing includes a percentage of revenue component at lower tiers, transitioning to flat fees at higher volumes. The pricing structure is more complex than it appears at first evaluation.

Less developer-first. The API is functional but less cleanly designed than platforms built specifically for engineering teams. Integration via API requires more workarounds for common patterns than Orb or ABAXUS.

Pricing

Starts around $299/month with revenue caps; flat-rate plans at higher volumes. Current pricing available on Chargebee’s website.

Who Chargebee is for

SaaS companies with primarily subscription-based models that need usage components — seat-based subscriptions with usage overages, for example. Companies that want billing configured and managed by non-engineering teams. Companies that need deep pre-built integrations with accounting, CRM, and ERP systems.

Who should look elsewhere

Companies running pure usage-based models where the subscription-centric architecture creates friction. Companies where billing is owned by engineering and developer experience is the primary evaluation criterion. Companies with full data control requirements or strict data residency constraints.

5. Metronome

Enterprise usage-based billing for large-scale committed-spend contracts.

Metronome is purpose-built for enterprise usage-based billing — specifically for companies handling large committed-spend contracts, complex custom pricing structures, and enterprise-grade billing at significant transaction volume. It is used by infrastructure companies, cloud platforms, and AI businesses with enterprise customer bases.

Strengths

Enterprise contract structures. Metronome’s design is optimized for the complexity of large enterprise deals: committed-spend agreements, prepaid credits, draw-down balances, custom contract terms, ramp schedules, and amendments. Managing this contractual complexity at scale is where Metronome has the most differentiated capability.

Real-time usage at enterprise volume. The platform is designed to handle very high event volumes and produce accurate, real-time usage data for large customer accounts.

Enterprise audit trails. Usage data, contract terms, and billing calculations are maintained with the level of detail that enterprise finance teams and auditors require.

Integrations with enterprise financial systems. Deep integrations with Salesforce CPQ, enterprise ERP systems, and financial reporting tools are more mature than in earlier-stage platforms.

Weaknesses

Designed for large companies. The enterprise focus means the platform is overkill — and priced accordingly — for companies below a certain scale. Early-stage and growth-stage companies evaluating Metronome are typically not the target customer.

Custom pricing and sales process. No self-serve signup or publicly listed pricing. Evaluating Metronome requires a sales engagement, which adds time and friction for teams that want to move quickly.

Cloud-only, data on Metronome’s infrastructure. Like Orb and Chargebee, your usage data lives in Metronome’s systems. Data sovereignty is not an option.

Less flexible for simpler models. The platform’s strengths are in enterprise contract complexity. Simple usage-based models run more efficiently on lighter platforms.

Pricing

Custom enterprise pricing. Not publicly listed. Requires a sales conversation.

Who Metronome is for

Enterprise companies handling committed-spend contracts, ramp structures, and complex custom pricing at significant scale. Infrastructure companies, cloud platforms, and AI businesses with large enterprise customer bases where billing complexity is a primary operational challenge.

Who should look elsewhere

Early-stage and growth-stage companies — the pricing and sales process are not calibrated for this part of the market. Companies with simple pricing models that do not require enterprise contract management. Companies with data residency requirements.

6. Stigg

Pricing and entitlements platform for product-led growth SaaS.

Stigg approaches billing from a different angle than the other platforms on this list. Where ABAXUS, Lago, Orb, and Metronome focus on the metering-to-invoice pipeline, Stigg focuses on the product-facing layer: feature entitlements, pricing plan configuration, and customer-facing usage portals. It is built for PLG SaaS companies where billing and feature access logic need to be tightly coupled to product behavior.

Stigg integrates with Stripe for payment processing rather than handling payments directly — it sits between your product and Stripe, managing what customers can do on each plan and feeding usage data into Stripe Billing for invoicing.

Strengths

Entitlements as a first-class feature. Stigg’s core differentiation is its entitlements engine: a system for defining what customers on each plan can access, how many of a given resource they can consume, and what happens when they hit a limit. Most billing platforms treat this as a configuration concern — Stigg makes it a product.

Customer portal and in-app upgrade flows. Stigg ships a white-label customer portal widget that surfaces usage, plan details, and upgrade options directly inside your product. For PLG companies where the upgrade path runs through the product rather than a sales conversation, this reduces the custom UI work significantly.

Pricing plan management without engineering. Product and growth teams can modify pricing plans, feature flags, and entitlement rules through Stigg’s UI without engineering deployments. For companies iterating on pricing frequently, this operational flexibility has real value.

Real-time feature access checks. The SDK provides low-latency feature access checks that gate functionality based on current plan entitlements, usage limits, and custom rules — the link between billing and product that most billing platforms require you to build yourself.

Weaknesses

Not a standalone billing engine. Stigg does not process payments directly — it requires Stripe as the payment backend. If your payment infrastructure is not Stripe, or if you need billing logic that exceeds Stripe Billing’s capabilities, Stigg’s architecture becomes a constraint.

Cloud-only, data on Stigg’s infrastructure. Like the other SaaS billing platforms, your usage data, entitlement state, and customer plan information live in Stigg’s systems.

Less suited to high-volume metered billing. Stigg’s metering capabilities are functional but less optimized for products generating very high event volumes. For dev tools or API companies billing on billions of monthly events, Orb or ABAXUS are better architecturally matched.

Stripe dependency limits payment flexibility. Stripe’s own rate limits, API constraints, and pricing apply through the Stigg integration. The ceiling Stigg can reach is ultimately bounded by what Stripe Billing supports.

Narrower pricing model support. Complex enterprise contract structures, multi-region committed-spend, and matrix pricing are outside Stigg’s core focus.

Pricing

Tiered plans based on tracked customers and features. Starter tier available; pricing scales with usage. Current rates on stigg.io.

Who Stigg is for

Product-led growth SaaS companies that need feature entitlements and access control tightly integrated with billing. Teams building freemium-to-paid conversion flows where in-product upgrade prompts are the primary monetization mechanism. Companies already on Stripe that want to add sophisticated plan management and customer portals without building the UI themselves.

Who should look elsewhere

Companies not using Stripe. Teams with data residency requirements. Dev tools and API companies at high event volumes where Stripe Billing’s throughput becomes a bottleneck. Enterprises with complex committed-spend contracts that exceed what Stripe Billing can model.

7. Stripe Billing

Payment infrastructure with metering add-ons — not a purpose-built billing platform.

Stripe Billing is the billing module of the Stripe payments platform. Many SaaS teams start here because Stripe is already in their stack for payment processing. For low event volumes and simple pricing models, Stripe Billing works. At scale, three structural constraints surface: rate limits on the Events API (100 req/s — a ceiling reached at approximately 10 million metered API calls per month), all usage data residing in Stripe’s infrastructure, and a percentage-of-revenue fee (0.5–0.8% depending on tier) that scales independently of your actual event processing costs.

Stripe Billing is listed here not because it competes with purpose-built metering platforms on technical merit, but because it is the most common starting point — and understanding where it falls short clarifies the case for migrating to a platform built for usage-based billing.

Strengths

No additional vendor onboarding. If you already use Stripe for payments, Stripe Billing adds metering to an existing vendor relationship. No new contract, no new integration for payment processing.

Broad global payment support. Stripe’s payment rails cover 135+ currencies, local payment methods, and global tax compliance. No purpose-built billing platform matches this breadth.

Developer-familiar API. The Stripe API is well-documented and widely understood. Integration friction is low for teams with existing Stripe experience.

Dunning and subscription management. Smart Retries, failed payment handling, and subscription lifecycle management are mature features.

Weaknesses

100 req/s rate limit on the Events API. At 10 million metered API calls per month, you’re averaging 3.9 req/s and well under the limit. At 100 million events per month, you’re at 38.6 req/s. The ceiling is reached sooner than most teams expect as products grow.

All usage data in Stripe’s infrastructure. Usage events, customer billing history, and metering data live in Stripe’s systems. For regulated industries, this creates third-party data exposure that HIPAA, SOC 2, and enterprise customer audits may flag.

0.5–0.8% billing fee on top of payment processing fees. Stripe already charges payment processing fees. Stripe Billing adds a billing fee on revenue processed through the metering product. At $10M ARR, that is $50,000–$80,000/year in billing fees alone — on top of payment processing costs.

Limited pricing model sophistication. Complex enterprise contract structures, matrix pricing on multiple dimensions, draw-down credit balances, and committed-spend ramp schedules are outside what Stripe Billing models natively.

No self-hosted option. There is no way to run Stripe’s billing logic inside your own infrastructure.

Pricing

0.5% of revenue on the Starter tier; negotiated flat rates at higher volumes. Payment processing fees apply separately.

Who Stripe Billing is for

Early-stage SaaS companies that already use Stripe for payments and want to add simple usage-based billing without a new vendor. Products with low event volumes (under 10 million events/month) and straightforward pricing models.

Who should look elsewhere

Any company at or approaching meaningful scale. Companies with data residency requirements. Teams building pricing models more complex than simple tiered or per-unit billing. Companies where billing fees are becoming a notable cost line.

Detailed Comparison by Dimension

Event Ingestion and Metering

All seven platforms support usage event ingestion, but the implementation details differ significantly and determine the ceiling you can grow to.

ABAXUS places the entire event pipeline inside your own infrastructure. It ingests from Prometheus, OpenTelemetry spans, Kafka, change-data-capture, webhooks, or direct API — whichever source is most natural for your stack — with no external API in the critical path. There is no rate limit imposed by a shared vendor infrastructure. Late-arriving events, idempotent replay, and backfill operate within your own systems. For IoT and device-based products, ABAXUS handles the specific challenges of offline device reconnection, MQTT QoS 1 deduplication, and clock skew detection.

Lago (self-hosted) similarly keeps the event pipeline in your infrastructure, with the data model and operational overhead that comes with running the deployment yourself.

Orb and Metronome have built sophisticated managed metering infrastructure for high-throughput API workloads. For companies that want this capability without building it, the managed option is faster to production — but the shared-infrastructure rate limit ceiling applies.

Chargebee’s metering layer is functional but less optimized for high-volume event streams — it works well for usage components on top of subscription billing, less well for products generating millions of events per day.

Stigg handles metering for entitlement enforcement and passes usage data to Stripe Billing for invoicing. The metering layer is designed for plan management and feature gating rather than high-volume event ingestion.

Stripe Billing accepts events via its Events API, rate-limited at 100 req/s. For context: a product with 10,000 active customers each generating 30 events/day averages 3.5 events/second — comfortably within limits. A developer tools company with 1,000 customers each generating 10,000 API calls/day is at 115 events/second — over the limit before batching.

Pricing Engine Flexibility

Data Ownership

This is the dimension where the market splits cleanly into two categories:

Full data control: ABAXUS (self-hosted), Lago (self-hosted). Your data, your infrastructure, your retention policy, your security perimeter. For healthtech SaaS, this means usage events never cross into a third-party API, eliminating the HIPAA Business Associate Agreement obligation for the billing layer.

Vendor-hosted: Orb, Chargebee, Metronome, Stigg, Stripe Billing. Usage data is stored and processed in the vendor’s cloud. Data export is available, but the primary copy is outside your control.

For most companies, vendor-hosted is acceptable. For companies in regulated industries, for companies with enterprise customers who audit data handling, and for companies that have made data sovereignty a strategic commitment, the distinction is material.

Pricing Model Economics

ABAXUS: self-hosted usage-based billing with no per-transaction fees

Production-grade metering, flexible pricing engine, and customer dashboards — running in your own infrastructure. Built for engineering teams that need complete control.

See how it works

Total Cost of Ownership at Scale

The comparison table shows the fee structure. The table below shows what that fee structure costs at different ARR levels — a calculation most teams fail to run before selecting a platform.

Assumptions: Orb/Chargebee at 0.5% of revenue; Stripe Billing at 0.7%; ABAXUS at $12,000/yr (Growth tier).

The crossover for ABAXUS Growth vs. a 0.5% platform is approximately $2.4M ARR. Above that point, the fixed license is cheaper. The crossover for Stripe Billing is approximately $1.7M ARR.

These numbers do not include operational overhead. Self-hosted platforms require an engineer to own the deployment — a real cost. The question is whether the engineering cost of owning the deployment is more or less than the recurring fee gap. For most engineering teams above $3M ARR, it is less.

Recommendation by Use Case

You need full data control, no rate-limit ceiling, and no per-transaction fees at scale → ABAXUS. Self-hosted inside your Kubernetes cluster, idempotent event ingestion from any source, meter versioning, full audit trail in your own database. The right choice for dev tools, AI products, and healthtech SaaS.

You want open source with the option to self-host or go managed → Lago. MIT-licensed, transparent roadmap, community-supported. The right choice for teams that want the inspection and modification rights of open source without a proprietary license.

You want a managed billing service for an API or developer tool company → Orb. Strong developer experience, sophisticated pricing engine including pricing simulations, managed infrastructure. The right choice when data residency is not a constraint and engineering time is the primary cost to optimize.

You have a subscription-first model with usage components and need broad integrations → Chargebee. Mature ecosystem, non-technical configurability, subscription management depth, ASC 606 compliance. The right choice for companies running hybrid subscription plus usage models with non-engineering billing operators.

You’re an enterprise company with complex committed-spend contracts at high volume → Metronome. Built for enterprise contract complexity: ramp schedules, draw-down balances, custom pricing exceptions at large scale. The right choice when the billing problem is contractual complexity, not infrastructure throughput.

You’re building a PLG product and need entitlements, feature flags, and in-app upgrade flows integrated with Stripe → Stigg. Customer portal widget, plan management without engineering deployments, real-time feature access checks. The right choice when the primary need is product-layer entitlement management, not high-volume event metering.

You’re pre-product-market-fit or at very early stage, already on Stripe → Stripe Billing. No additional vendor onboarding, familiar API, works for simple models at low volume. The right choice for before you hit the throughput limit or the fee inflection point — then migrate.

Migrating Between Platforms

Platform migrations have a cost proportional to the data volume and schema complexity you need to move. Before selecting a platform, understand the migration path out:

Self-hosted platforms (ABAXUS, Lago) are the easiest to migrate from — your data is already in your own database, in schemas you control. Export and transform as needed.

Cloud platforms (Orb, Chargebee, Metronome, Stigg, Stripe Billing) provide data export APIs, but the primary copy lives on their systems. The migration path involves: exporting historical billing data, mapping to the new schema, running parallel systems for a billing period to validate accuracy, and cutting over invoicing.

The parallel-run period is non-negotiable. Any billing platform migration that skips a parallel run where both systems process the same events and outputs are compared will discover discrepancies after the cutover — in customer invoices. Budget 4–8 weeks for a parallel run before full cutover.

Related Reading

• Engineering Metered Billing for IoT: From Device Event to Customer Invoice — full pipeline walkthrough: MQTT ingestion, clock skew handling, fleet aggregation, multi-region residency
• Billing Event Schema Design: The Engineering Decision That Determines Your Compliance Posture — idempotency keys, DECIMAL vs float, schema versioning, PHI-safe event design
• 10 Use Cases of Usage-Based Billing for IoT SaaS — fleet management, industrial sensors, connected medical devices, smart energy, agricultural IoT, telematics
• Usage-Based Pricing for IoT SaaS: The Model That Matches Your Product — device state cost tables, billing archetypes, hybrid pricing formula, billable metric selection
• 5 Key Features of Usage-Based Billing Software — what to evaluate in any billing platform

ABAXUS is a self-hosted usage-based billing engine for engineering teams. It handles idempotent event ingestion, flexible pricing logic, automated invoicing, and real-time usage dashboards — running in your own infrastructure with no per-transaction fees. See pricing →