I need a billing engine that handles usage-based pricing with complex tiers.

A usage-based billing engine with complex tiers is best designed as a pricing/rating platform, not as invoice code. Separate the system into metering, aggregation, rating, and invoicing so pricing changes do not require application rewrites.

A reference architecture:

                ┌─────────────────┐
Product Events ─► Usage Ingestion  │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Meter Store      │
                │ (raw events)     │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Aggregator       │
                │ usage/month/etc  │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Rating Engine    │
                │ tiers, credits,  │
                │ discounts        │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Invoice Engine   │
                │ line items/tax   │
                └─────────────────┘

Core components

1. Usage ingestion

Capture immutable usage events:

{
  "event_id": "evt_123",
  "customer_id": "cust_456",
  "metric": "api_calls",
  "quantity": 1,
  "timestamp": "2026-09-19T04:00:00Z",
  "dimensions": {
    "region": "us-east",
    "model": "premium"
  }
}

Requirements:

• Idempotency keys to prevent duplicate billing
• Late event handling
• Full audit trail
• Replay capability

A billing system should treat usage events as financial records, not disposable analytics data.

---

2. Pricing model schema

Do not hardcode tiers. Store pricing as configuration.

Example:

{
  "plan": "enterprise",
  "metric": "api_calls",
  "billing_period": "monthly",
  "tiers": [
    {
      "from": 0,
      "to": 10000,
      "price_per_unit": 0.01
    },
    {
      "from": 10001,
      "to": 1000000,
      "price_per_unit": 0.005
    },
    {
      "from": 1000001,
      "to": null,
      "price_per_unit": 0.002
    }
  ]
}

This lets pricing teams modify rates without deployments.

---

3. Rating engine

The rating engine converts usage into money.

Support multiple strategies:

Graduated tiers

Example:

• First 10,000 calls × $0.01
• Next 990,000 calls × $0.005
• Remaining calls × $0.002

Calculation:

def graduated_price(quantity, tiers):
    remaining = quantity
    total = 0

    for tier in tiers:
        available = tier.limit - tier.start if tier.limit else remaining
        used = min(remaining, available)

        total += used * tier.price
        remaining -= used

        if remaining <= 0:
            break

    return total

Volume tiers

Different from graduated tiers:

• Customer uses 900,000 units
• Entire volume gets the tier-3 price

Included usage + overage

Example:

Plan:
$500/month
Includes 100,000 API calls

Usage:
150,000 calls

Bill:
$500 base
50,000 overage × $0.004

Commitments

Example:

Annual commitment:
10M API calls

Actual usage:
12M API calls

Charge:
Committed block + 2M overage

---

4. Data model

A minimal relational design:

Customers

customers
----------
id
account_id
currency

Meters

meters
----------
id
name
aggregation_type

Examples:
COUNT
SUM
MAX
UNIQUE_COUNT

Pricing plans

plans
----------
id
version
effective_from
effective_to

Pricing rules

price_rules
----------
plan_id
metric_id
tier_start
tier_end
unit_price
pricing_strategy

Usage events

usage_events
----------
id
customer_id
metric_id
quantity
occurred_at
idempotency_key

Rated charges

charges
----------
customer_id
billing_period
metric
quantity
amount
pricing_rule_version

Keeping the pricing version attached to charges prevents historical invoices from changing when prices change.

---

5. Invoice generation

Generate invoices from rated line items:

Invoice #10001

Base subscription:
Enterprise plan        $500.00

API usage:
0-10k calls             $100.00
10k-1M calls            $450.00
1M+ calls               $80.00

Credits:
Annual commitment      -$200.00

Total:
$930.00

Never calculate invoices directly from raw events during checkout/billing close. Use a reproducible rating step.

---

6. Operational features you will eventually need

• Usage previews: "Your projected bill this month is $842"
• Invoice simulation: test a pricing change before release
• Pricing versioning: future prices only
• Manual adjustments: credits, discounts, contract overrides
• Audit logs: explain every cent
• Customer usage APIs
• Alerting: notify customers near thresholds

Usage visibility and alerts are especially important because unexpected consumption charges can create customer disputes.

---

Build vs. buy decision

Build your own if you need:

• Highly custom pricing formulas
• Proprietary rating logic
• Tight integration with internal product events
• Full control over invoice calculations

Consider an existing billing platform if you need:

• Tax handling
• Accounting integrations
• Subscription lifecycle management
• Multiple payment providers
• Global invoicing

A common hybrid approach is:

• Build your own metering + rating engine
• Use a payment provider for collections

---

A production-grade implementation would typically start with:

• PostgreSQL for pricing/configuration
• Kafka/SQS/PubSub for usage events
• A columnar store (ClickHouse/BigQuery) for aggregation
• A stateless rating service
• Stripe or another provider for payment collection

The most important design choice is making the rating engine declarative and versioned rather than embedding pricing rules in application code.

When dealing with usage-based pricing and complex tiers (tiered pricing, volume pricing, graduated tiers, or prepaid credit drawdowns), traditional payment gateways like standard Stripe Billing often require building brittle custom workarounds.

To handle high-throughput metering and complex, multi-dimensional rating logic out of the box, specialized billing engines fall into three primary categories:

• Developer-First & API-Driven (Headless) : Built for high-volume engineering teams needing clean APIs for complex usage calculations and real-time event aggregation.
• Open-Source Alternatives : Fully owned and self-hostable engines that prevent vendor lock-in on core revenue logic.
• Enterprise Subscription Suites : Heavyweight monetization engines designed for complex contractual commitments, multi-region setups, and advanced finance reporting.

Top Billing Engines for Complex Tiers

1. Orb — Best for complex developer-led and AI workloads
   • Why it fits : Built specifically for high-throughput multi-dimensional usage (API calls, tokens, compute, storage). It features hosted rollups that aggregate millions of events per second during ingestion before running calculations.
   • Pricing model : Custom-quoted (tiered base fee + volume % + ingestion fees).
   • Check out : Review developer documentation and capabilities on Orb.
2. Lago — Best open-source / self-hosted choice
   • Why it fits : An open-source, usage-first billing platform that natively supports pay-as-you-go, graduated pricing tiers, prepaid credit bundles, and drawdown rules. You can self-host it for free or use their managed cloud tier.
   • Pricing model : Free to self-hosted (AGPLv3) or custom-priced managed cloud.
   • Check out : Explore the repository and architecture on Lago.
3. Metronome — Best for enterprise-scale volume & credit systems
   • Why it fits : Excels at complex contractual minimum commitments, multi-product packaging, and sophisticated credit-ledger mechanics for large B2B SaaS.
   • Pricing model : Percentage of billing volume + ingestion fees.
   • Check out : Learn about enterprise metering on Metronome.
4. Zuora — Best for heavy enterprise & multi-model billing
   • Why it fits : The traditional heavyweight for enterprise subscription and usage billing. It handles sophisticated structures like high-water mark pricing, volume tiers, and prepaid drawdowns, though implementation is long and complex.
   • Check out : View enterprise offerings on Zuora.

To help narrow down the right engine for your architecture, could you share:

• What is your estimated event volume (e.g., events per second or month)?
• Do you prefer a managed cloud service or an open-source / self-hosted solution?
• What does your pricing structure look like (e.g., flat tiers, volume-based, or prepaid credits with drawdown)?

Yes. For usage-based pricing with complex tiers, I’d build the billing engine around an immutable usage ledger plus a versioned pricing engine—not around invoices themselves.

A useful architecture is:

                    ┌──────────────────┐
Usage events ──────►│  Usage ingestion │
                    └────────┬─────────┘
                             │
                       dedupe/idempotency
                             │
                             ▼
                    ┌──────────────────┐
                    │  Usage ledger    │
                    │  immutable       │
                    └────────┬─────────┘
                             │
                    aggregation/windowing
                             │
                             ▼
                    ┌──────────────────┐
                    │ Pricing engine   │
                    │ versioned rules  │
                    └────────┬─────────┘
                             │
                    priced line items
                             │
                             ▼
                    ┌──────────────────┐
                    │ Invoice engine   │
                    └────────┬─────────┘
                             │
                             ▼
                    Payments / GL / ERP

1. Make usage events immutable

Every event should have something like:

event_id
customer_id
metric
quantity
timestamp
dimensions
source

event_id needs to be idempotent so retries don't double-bill customers. Keep the raw event permanently; derive aggregates from it rather than modifying the original record.

This mirrors the basic metering lifecycle used by modern billing systems: ingest usage, aggregate it over a billing period, apply pricing, then invoice.

2. Treat pricing as a rules engine

Don't encode pricing logic directly into subscription/invoice code.

For example:

{
  "metric": "api_requests",
  "model": "graduated",
  "tiers": [
    { "up_to": 10000, "unit_price": 0.002 },
    { "up_to": 100000, "unit_price": 0.001 },
    { "up_to": null, "unit_price": 0.0005 }
  ]
}

Then support multiple pricing models:

• Flat — $100/month
• Per-unit — $0.01/request
• Graduated tiers — first 10k at one price, next 90k at another
• Volume tiers — determine the customer's tier, then apply that price to all usage
• Package pricing — $50 per 10,000 units
• Minimum charges
• Maximum/capped charges
• Included usage + overage
• Commitments
• Credits
• Discounts
• Multiple metrics
• Dimensional pricing — e.g. region × model × storage class
• Proration
• Taxes

The distinction between graduated and volume pricing is particularly important: graduated pricing applies each tier's price only to the usage falling within that tier, whereas volume pricing applies the selected tier's price to the entire quantity.

3. Version every price

This is critical.

Never mutate:

Plan A = $0.001/request

into:

Plan A = $0.002/request

Instead:

pricing_version 17
effective_from: 2026-01-01
effective_to:   2026-06-30

pricing_version 23
effective_from: 2026-07-01

An invoice should always reference the exact pricing version used to calculate it.

That gives you reproducibility: six months later, you can explain exactly why an invoice was $13,842.17.

4. Make the pricing engine produce a breakdown

Don't have:

calculatePrice(usage) => 1384217

Return something auditable:

{
  total: 1384217,
  currency: "USD",
  lines: [
    {
      metric: "api_requests",
      tier: 1,
      quantity: 10000,
      unitPrice: 0.002,
      subtotal: 2000
    },
    {
      metric: "api_requests",
      tier: 2,
      quantity: 90000,
      unitPrice: 0.001,
      subtotal: 9000
    },
    {
      metric: "api_requests",
      tier: 3,
      quantity: 684217,
      unitPrice: 0.0005,
      subtotal: 342.1085
    }
  ]
}

Then round according to an explicit currency/rounding policy.

This makes customer support, invoice reconciliation, and financial audits dramatically easier.

5. Separate metering from pricing

This is probably the most important architectural decision.

Metering answers:

How much did the customer consume? Pricing answers:

What should that consumption cost? For example:

Customer A
  ├── API requests: 1,250,000
  ├── GPU seconds: 83,400
  └── Storage GB-hours: 42,812

The pricing engine can then apply completely different rules to each metric.

That also means you can change pricing without changing your product's telemetry pipeline.

6. Use an intermediate "rated usage" layer

I'd make the lifecycle:

Raw usage
   ↓
Normalized usage
   ↓
Aggregated usage
   ↓
Rated usage
   ↓
Invoice lines
   ↓
Invoice

For example:

1,250,000 API requests
        ↓
pricing version 42
        ↓
10,000 × $0.002
90,000 × $0.001
1,150,000 × $0.0005
        ↓
$685.00

The rated usage record becomes the bridge between your pricing engine and accounting system.

7. Design for corrections

Usage systems inevitably receive:

• duplicate events
• late events
• corrected events
• refunds
• cancellations
• backdated subscriptions
• pricing changes
• invoice recalculations

Don't overwrite historical records.

Use compensating entries:

+1000 API calls
-1000 API calls
+1200 corrected API calls

Then rerate the affected billing period.

8. A good core domain model

I'd start with these entities:

Customer
Subscription
SubscriptionItem
Metric
UsageEvent
UsageAggregate
PricingPlan
PricingVersion
PricingRule
RatingResult
Invoice
InvoiceLine
Credit
Adjustment

And keep the boundaries clean:

UsageEvent
    ↓
Meter
    ↓
UsageAggregate
    ↓
PricingVersion + PricingRules
    ↓
RatingResult
    ↓
InvoiceLine
    ↓
Invoice

9. Don't use floating point for money

Use integer minor units or a decimal type:

$12.34 → 1234 cents

For very small usage prices, you may also need decimal quantities/prices with substantially more precision before the final currency rounding.

10. The pricing DSL is worth building

If your tiers are genuinely complex, I'd give pricing its own declarative representation:

metric: inference_tokens
billing_period: monthly

pricing:
  - when:
      model: standard
    tiers:
      - up_to: 1000000
        price: 0.000002
      - up_to: 10000000
        price: 0.0000015
      - up_to: null
        price: 0.000001

  - when:
      model: premium
    tiers:
      - up_to: 1000000
        price: 0.000008
      - up_to: null
        price: 0.000006

Then your engine becomes a deterministic interpreter for this pricing configuration.

That's much easier to test than hundreds of nested if statements.

What I'd build

For a production system, I'd aim for:

Event ingestion → immutable usage ledger → aggregation → versioned pricing DSL → deterministic rating engine → invoice lines → payment provider/accounting

And I'd make the rating engine a pure function wherever possible:

rating(
    usage,
    pricing_version,
    customer_context,
    billing_period
) → rating_result

That gives you an especially valuable property: the exact same inputs always produce the exact same bill.

Stripe's own usage-based model similarly separates meters/usage events from prices and billing, and supports both graduated and volume tiering.

If you're building this yourself, I can next lay out a production-ready database schema + TypeScript pricing engine, including graduated/volume tiers, credits, minimums, commitments, proration, idempotency, and invoice generation.

9. Don't use floating point for money

Use integer minor units or a decimal type:

$12.34 → 1234 cents

For very small usage prices, you may also need decimal quantities/prices with substantially more precision before the final currency rounding.

10. The pricing DSL is worth building

If your tiers are genuinely complex, I'd give pricing its own declarative representation:

When your pricing model moves beyond simple flat fees into complex, multi-tiered, or high-throughput usage data (like AI tokens, API calls, or compute hours), standard payment processor billing modules (like basic Stripe Billing) often hit walls.

The top-tier specialized usage-based billing engines available depend on whether you prefer a developer-first API, an open-source self-hosted stack, or enterprise-grade contract flexibility:

1. Orb

• Best for: AI, API-first, and high-volume developer tools with formula-driven or multi-dimensional pricing.
• How it handles tiers: Ingests massive event streams and processes complex rating logic in real time. It treats pricing like a formula rather than a static list, supporting sophisticated volume tiers, matrix pricing, and hybrid subscriptions.
• Trade-offs: API-first by design—requires engineering muscle to configure and maintain; it does not process payments natively, instead syncing cleanly with payment gateways like Stripe.

2. Lago

• Best for: Teams that want an open-source, self-hosted option with absolute data ownership.
• How it handles tiers: Built to scale past high event throughput per second. It natively supports multiple advanced charge models, including graduated, volume-based, percentage, and dynamic tiered pricing.
• Trade-offs: While the core open-source self-hosted version gives you total control, production-ready analytics and enterprise features require leaning into their managed cloud tier.

3. Metronome

• Best for: B2B SaaS and enterprise companies handling complex multi-year commitments, draw-down credit balances, and custom ramp schedules.
• How it handles tiers: Excellent at marrying granular consumption metering with intricate enterprise contract structures (minimum commitments, prepaid credits, and overage tiers).
• Trade-offs: Geared heavily toward complex contract management rather than just raw high-frequency API metering.

4. Solvimon

• Best for: High-volume transaction processing (scaling up to millions of events per second) unified on a single ledger with automated revenue recognition.
• How it handles tiers: Handles heavy hybrid billing models and transforms raw event streams into precise tiered line items while feeding directly into your finance and accounting stack.
• Trade-offs: Best suited for scaling/enterprise operations moving toward strict audit and IPO readiness.

To help narrow down the best fit, tell me:

• What is your estimated event volume per month (e.g., thousands, millions, or billions of events)?
• Do you need an open-source/self-hosted solution or a managed cloud service?
• Are you dealing with enterprise contracts (prepaid credits/drawdowns) or purely self-serve credit card billing?

When your pricing moves past flat-rate tiers into metered, multi-attribute, or volume-tiered consumption (e.g., sliding-scale API calls, sliding compute units, or tiered overages), standard checkout tools like basic Stripe Billing can become brittle and require heavy custom engineering.

A purpose-built usage-based billing engine handles event ingestion, aggregation, complex pricing calculations (graduated or volume tiers), and invoicing, then syncs with a payment processor to charge the card.

The leading usage-based billing engines optimized for complex tiers are categorized below by their strengths:

1. Orb — Best for developer and product teams needing a clean API to handle complex, highly custom calculations (like multi-dimensional usage or complex credit systems). Check out Orb for deep documentation on custom pricing logic.
2. Metronome — Best for enterprise-scale event volumes (millions/billions of high-frequency events) with sophisticated contract structures, minimum commitments, and credit drawdowns. Learn more at Metronome.
3. Lago — Best if you want an open-source, self-hostable option or need full architectural control over your billing and metering data rather than being locked into a closed SaaS ecosystem. Explore the codebase and setup via Lago.
4. m3ter — Best for complex industrial, B2B, or data-heavy products with multi-layered metering requirements and heavy analytics. See details on m3ter.
5. BillingPlatform — Best for large enterprises requiring a monolithic financial suite that handles usage tiers alongside complex revenue recognition (ASC 606) and ERP integration. Visit BillingPlatform.

To help narrow down which engine fits your architecture best, let me know:

• What is your estimated event volume per month (e.g., thousands vs. millions of usage events)?
• Do you prefer a fully managed cloud SaaS or an open-source/self-hosted solution?
• Are you dealing with pure consumption or a hybrid model (base subscription + tiered usage)?

Yes. For complex usage-based pricing, I’d avoid putting pricing logic directly into application code. Treat billing as a small domain-specific engine with immutable pricing versions, metering, rating, and invoicing as separate stages.

A good architecture looks like:

Usage Events
    │
    ▼
┌─────────────┐
│   Metering  │  aggregate usage by customer / feature / period
└──────┬──────┘
       ▼
┌────────────────┐
│ Pricing Catalog │  versioned plans, tiers, discounts, commitments
└───────┬────────┘
        ▼
┌──────────────┐
│ Rating Engine │  convert usage → monetary charges
└──────┬───────┘
       ▼
┌────────────┐
│ Invoice Run │  consolidate charges, tax, credits
└──────┬─────┘
       ▼
   Invoice / Ledger

The key design

Represent a price as data, not code.

For example:

{
  "price_id": "api_requests_v4",
  "currency": "USD",
  "billing_period": "month",
  "model": "graduated",
  "tiers": [
    { "up_to": 10000, "unit_price": 0.01 },
    { "up_to": 100000, "unit_price": 0.008 },
    { "up_to": null, "unit_price": 0.005 }
  ]
}

Then your rating engine can support multiple models:

• Flat: $99/month
• Per-unit: $0.01 × usage
• Graduated tiers: each slice of usage gets its own price
• Volume tiers: all usage gets the price of the highest tier reached
• Package pricing: 1,000 units for $20, rounded up
• Included usage: first 10,000 units free, then overage
• Minimum/maximum charges
• Percentage and fixed discounts
• Customer-specific negotiated rates
• Time-based phases: trial → ramp-up → normal pricing
• Multi-dimensional pricing: e.g. API calls × region × model
• Credits / prepaid balances
• Commitments and minimum spends

Graduated and volume pricing are importantly different: with 6,000 units and tiers of $0.30, $0.20, $0.10, graduated pricing charges each tier separately, while volume pricing charges all 6,000 at the highest achieved tier.

Make pricing immutable

This is probably the most important architectural decision.

Don't do:

customer → "Pro plan"

Do:

customer
   ↓
subscription
   ↓
plan_version_7
   ↓
price_version_12

When you change a price, create a new version. Existing subscriptions continue using the old version unless explicitly migrated. This also makes historical invoices reproducible. Versioned plans and subscriptions bound to specific versions are a pattern used by OpenMeter.

Separate usage from billing

Store immutable usage events such as:

{
  "event_id": "evt_123",
  "customer_id": "cus_42",
  "meter": "ai_tokens",
  "timestamp": "2026-09-10T18:22:31Z",
  "quantity": 1842,
  "dimensions": {
    "model": "gpt-x",
    "region": "us-east"
  }
}

Then derive meter totals from those events.

That gives you idempotency and auditability. If the pricing configuration changes or you discover a metering bug, you can recalculate the rating from the underlying events rather than trying to reconstruct what happened from an invoice.

Make the rating engine deterministic

I'd make the core API something like:

rate({
  price,
  usage,
  period,
  customer,
  credits
}) => {
  subtotal,
  discounts,
  commitments,
  taxes,
  total,
  lineItems
}

For example:

const result = rate({
  price: apiPrice,
  usage: 125_000,
  period: {
    start: "2026-09-01",
    end: "2026-10-01"
  }
});

And return detailed lines:

{
  "subtotal": 920.00,
  "line_items": [
    {
      "tier": 1,
      "quantity": 10000,
      "unit_price": 0.01,
      "amount": 100.00
    },
    {
      "tier": 2,
      "quantity": 90000,
      "unit_price": 0.008,
      "amount": 720.00
    },
    {
      "tier": 3,
      "quantity": 25000,
      "unit_price": 0.004,
      "amount": 100.00
    }
  ]
}

Detailed billing lines are valuable both for debugging and for giving customers an understandable invoice.

Don't combine discounts into tier logic

Keep the calculation pipeline explicit:

raw usage
   ↓
included usage / usage credits
   ↓
tier calculation
   ↓
base charge
   ↓
percentage discounts
   ↓
minimum / maximum commitment
   ↓
tax
   ↓
final amount

For example, a usage discount should reduce billable quantity before the tier calculation, while percentage discounts happen afterward. This ordering matters enormously once pricing gets complicated.

Data model I'd start with

Customer
Subscription
Plan
PlanVersion
PlanPhase
Feature
Meter
Price
Tier
Discount
Commitment
UsageEvent
UsageAggregate
RatingRun
Charge
Invoice
InvoiceLine
Credit
Payment

The important relationships are:

PlanVersion
 ├── PlanPhase
 │    └── Price
 │         └── Tier[]
 └── Entitlement[]

Subscription
 └── PlanVersion

UsageEvent
 └── Meter

Meter + Subscription + Price
 └── RatingRun
      └── Charge[]
           └── InvoiceLine

This is close to the conceptual separation used by modern usage-billing systems: features/meters, versioned plans, rate cards/prices, subscriptions, and invoices.

Build vs. buy

If you're building a SaaS product with serious pricing complexity, I'd evaluate an existing metering/billing system before implementing the entire engine yourself.

OpenMeter is particularly relevant because it supports graduated and volume tiers, packages, overages, discounts, commitments, entitlements, plan versioning, and invoicing.

Stripe is another option if you want payments and billing infrastructure tightly integrated; its current Billing offering includes usage-based billing capabilities, with more advanced usage pricing available through Metronome.

If you're building this yourself, I would start with a pure, deterministic RatingEngine plus versioned JSON pricing definitions. That gives you the flexibility to add increasingly exotic pricing rules without turning your application into a giant collection of if/else statements.

You need a specialized metering and billing platform like Orb or Metronome for complex, high-throughput usage-based pricing, or Chargebee if you also require traditional subscription management.

Modern usage-based billing engines handle high-volume event ingestion, complex tier calculations (volume, tiered, stair-step, or graduated pricing), and hybrid models.

Top Usage-Based Billing Engines

Key Capabilities to Evaluate

• Event Ingestion & Mediation: Ability to ingest millions of raw, high-frequency events (API calls, AI tokens, compute seconds) via API or webhooks and deduplicate them reliably.
• Pricing Flexibility: Support for graduated tiers (e.g., $0.10 for first 1,000 units, $0.08 thereafter), minimum commitments, volume discounts, and flat-fee + usage hybrids.
• Auditability & Visibility: Real-time dashboards for customers to track their consumption and clear audit logs for finance teams to trace how an invoice total was calculated from raw events.

To help narrow down the ideal choice, tell me:

• What is your estimated transaction/event volume per month?
• Do you need to combine usage with traditional recurring subscriptions?
• Are you looking for a cloud-hosted SaaS or an open-source/self-hosted tool?

Yes. For usage-based pricing with complex tiers, I’d avoid building the rating logic from scratch unless billing itself is a core product capability.

Strong options

• Metronome — probably the strongest fit if you need sophisticated rate cards, multidimensional pricing, hybrid subscriptions, credits, enterprise contracts, and high-volume usage. It is now a Stripe product.
• Orb — particularly attractive for API/AI infrastructure where pricing logic gets very complicated, including tiered and multidimensional models.
• Lago — best if you want an open-source/self-hosted engine and don't want your billing infrastructure tightly coupled to one payment processor. It supports tiered, credit-based, and multidimensional pricing.
• Stripe Billing — good when your pricing is relatively straightforward and you're already deeply invested in Stripe. For genuinely complex rate-card logic, Stripe itself now positions Metronome for more sophisticated usage billing.

If you're building the engine yourself

I'd structure it as separate layers:

Usage Events
     ↓
Metering / Aggregation
     ↓
Rating Engine
     ↓
Pricing Rules / Tiers
     ↓
Credits / Commitments / Discounts
     ↓
Invoice Lines
     ↓
Invoice + Payment

The rating engine should be deterministic and versioned. For example:

Plan: Pro

0–10,000 units       $0.010 / unit
10,001–100,000       $0.008 / unit
100,001–1,000,000    $0.005 / unit
1,000,001+           $0.003 / unit

Minimum monthly charge: $500
Included allowance: 2,000 units
Overage: graduated
Discount: 15% enterprise

But I'd make the pricing model data-driven rather than encoding those rules in application code:

{
  "model": "graduated",
  "dimension": "api_calls",
  "tiers": [
    { "up_to": 10000, "unit_price": 0.010 },
    { "up_to": 100000, "unit_price": 0.008 },
    { "up_to": 1000000, "unit_price": 0.005 },
    { "up_to": null, "unit_price": 0.003 }
  ]
}

Crucially, support both graduated and volume tiers. A graduated model charges each slice at its tier's rate; a volume model applies the customer's final tier rate to all units. Confusing those two is a classic billing bug.

I'd also make these first-class features:

• Idempotent usage events
• Immutable raw usage records
• Late-event handling and corrections
• Pricing/version effective dates
• Proration
• Minimums and maximums
• Included allowances
• Prepaid credits and rollover
• Commitments and true-ups
• Discounts
• Multi-dimensional pricing
• Tax/invoice integration
• Full invoice calculation audit trail
• Deterministic recalculation of historical invoices

My recommendation: if you tell me your actual pricing rules—e.g. “$X/month includes 100k API calls, then graduated tiers, plus different rates based on region/model, with annual commits and credits”—I can design the billing engine architecture, database schema, pricing DSL, and calculation algorithm around them.

Plan: Pro

0–10,000 units       $0.010 / unit
10,001–100,000       $0.008 / unit
100,001–1,000,000    $0.005 / unit
1,000,001+           $0.003 / unit

Minimum monthly charge: $500
Included allowance: 2,000 units
Overage: graduated
Discount: 15% enterprise

But I'd make the pricing model data-driven rather than encoding those rules in application code:

{
  "model": "graduated",
  "dimension": "api_calls",
  "tiers": [
    { "up_to": 10000, "unit_price": 0.010 },
    { "up_to": 100000, "unit_price": 0.008 },
    { "up_to": 1000000, "unit_price": 0.005 },
    { "up_to": null, "unit_price": 0.003 }
  ]
}

Crucially, support both graduated and volume tiers. A graduated model charges each slice at its tier's rate; a volume model applies the customer's final tier rate to all units. Confusing those two is a classic billing bug.

I'd also make these first-class features:

• Idempotent usage events
• Immutable raw usage records
• Late-event handling and corrections
• Pricing/version effective dates
• Proration
• Minimums and maximums
• Included allowances
• Prepaid credits and rollover
• Commitments and true-ups
• Discounts
• Multi-dimensional pricing
• Tax/invoice integration
• Full invoice calculation audit trail
• Deterministic recalculation of historical invoices

My recommendation: if you tell me your actual pricing rules—e.g. “$X/month includes 100k API calls, then graduated tiers, plus different rates based on region/model, with annual commits and credits”—I can design the billing engine architecture, database schema, pricing DSL, and calculation algorithm around them.

Handling usage-based pricing with complex tiers (graduated tiers, volume pricing, matrix/multi-dimensional pricing, minimum commitments, or prepaid credits) requires a dedicated usage-first billing engine rather than a traditional flat-rate subscription tool.

The top billing engines that specialize in complex consumption and tiered models break down by use-case and architecture:

• 1. Orb — With Orb is arguably the strongest choice for developer-first and AI/infrastructure companies with deeply complex, non-linear, or matrix pricing (e.g., rates changing based on multiple simultaneous dimensions like region, data volume, and compute type). It features a flexible event-to-invoice data model that handles graduated tiers, minimums, and packaging natively.
• 1. Metronome — Metronome is built for high-throughput, high-event-volume environments. It excels at complex enterprise credit structures, prepaid commits, multi-cloud marketplace integrations (AWS/GCP), and custom contract ramping, making it a favorite for scaling B2B data and AI platforms.
• 1. Lago — Get Lago is an open-source/open-core option ideal for teams that want strict data ownership and self-hosted control over their infrastructure rather than depending entirely on a third-party vendor's roadmap. It natively supports graduated and volume-based pricing models without locking you into a proprietary ecosystem.
• 1. Stripe Billing — Stripe Billing works well if your event volume isn't astronomical and you are already deeply embedded in the Stripe ecosystem. However, be warned: once you move past basic tiers into complex multi-dimensional usage, minimum commits, or custom overages, Stripe requires substantial custom engineering and webhook logic to calculate and push the correct amounts.
• 1. BillingPlatform — BillingPlatform is a heavy-duty enterprise quote-to-cash engine. If your complex tiers need to tie directly into complex ERP environments, automated revenue recognition (ASC 606), and intricate multi-party billing, this is a top-ranked enterprise option.

To help narrow down the ideal engine, tell me:

• What is your estimated event volume (e.g., events per second or month)?
• Do you need prepaid credit/commit contracts alongside the tiered usage?
• Are you looking for a cloud-hosted SaaS or an open-source/self-hosted solution?

Yes. For usage-based pricing with complex tiers, I’d avoid building the entire billing stack from scratch unless billing itself is a core product differentiator.

Strong options

• metronome.com — My first choice for sophisticated enterprise usage billing. It supports graduated/volume pricing, multidimensional usage, credits, commitments, hybrid pricing, and real-time metering. It is now a Stripe product.
• getlago.com — Best if you want an open-source/self-hosted billing engine and payment-provider flexibility. It supports complex pricing logic, multiple aggregation types, hybrid subscription + usage models, and prepaid credits.
• stripe.com — Attractive if you're already deeply invested in Stripe and your pricing isn't exceptionally complicated. For more sophisticated usage models, Stripe positions Metronome as its specialized solution.
• withorb.com — Worth evaluating for an API-first usage-rating architecture, particularly if you want pricing iteration and complex usage models without building the rating engine yourself.

What I would design around

Your billing engine should separate metering, rating, and invoicing:

Usage Events
     │
     ▼
┌──────────────┐
│   Metering   │  aggregate usage
└──────┬───────┘
       ▼
┌──────────────┐
│ Pricing/Rater│  apply tiers, dimensions,
│              │  discounts, credits, etc.
└──────┬───────┘
       ▼
┌──────────────┐
│   Charges    │  immutable rated line items
└──────┬───────┘
       ▼
┌──────────────┐
│   Invoice    │
└──────────────┘

The key is making the pricing model declarative, rather than embedding pricing rules throughout application code.

For example:

metric: api_calls
aggregation: sum

tiers:
  - up_to: 10000
    price: 0.01
  - up_to: 100000
    price: 0.008
  - above: 100000
    price: 0.005

dimensions:
  - region
  - api_type

discounts:
  - customer_segment: enterprise
    percent: 15

I'd also make the engine support graduated tiers vs. volume tiers explicitly, because they produce very different bills. Add versioned price books, effective dates, idempotent usage events, corrections/re-rating, prepaid credits, minimum commitments, caps, and a full audit trail from raw event → meter → rate → invoice.

If you tell me your exact pricing model (e.g. “first 1M API calls at $X, next 9M at $Y, plus a monthly minimum, with different rates by region”), I can design the billing-engine architecture and data model around it.