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

Yes. For complex usage-based pricing, I’d build the billing engine as a deterministic pipeline rather than putting pricing logic directly into your application.

A good architecture is:

Usage Events
    │
    ▼
┌──────────────┐
│ Ingestion    │  validate, authenticate, deduplicate
└──────┬───────┘
       ▼
┌──────────────┐
│ Metering     │  sum/count/max/last, dimensions
└──────┬───────┘
       ▼
┌──────────────┐
│ Aggregation  │  customer + metric + billing period
└──────┬───────┘
       ▼
┌──────────────┐
│ Rating Engine│  tiers, volume, discounts, minimums,
│              │  commitments, credits, overages
└──────┬───────┘
       ▼
┌──────────────┐
│ Invoice      │  immutable line-item calculation
└──────┬───────┘
       ▼
 Payments / ERP / Revenue Recognition

This separation is important: modern usage-billing systems similarly distinguish metering/aggregation from the pricing configuration and invoice calculation.

The pricing model

Make pricing data-driven, not hardcoded:

type PricingPlan = {
  id: string;
  currency: string;
  billingPeriod: "monthly" | "annual";

  components: PricingComponent[];
};

type PricingComponent = {
  metric: string;

  baseFee?: Money;

  includedUnits?: number;

  tiers?: Tier[];

  mode: "graduated" | "volume" | "flat";
};

type Tier = {
  upTo: bigint | null;
  unitPrice: Money;
  flatFee?: Money;
};

For example:

{
  "metric": "api_requests",
  "baseFee": 4900,
  "includedUnits": 10000,
  "mode": "graduated",
  "tiers": [
    { "upTo": 10000, "unitPrice": 0 },
    { "upTo": 100000, "unitPrice": 2 },
    { "upTo": 1000000, "unitPrice": 1 },
    { "upTo": null, "unitPrice": 0.5 }
  ]
}

The engine should distinguish graduated tiers from volume tiers. With graduated pricing, each portion of usage gets its tier's price; with volume pricing, the achieved tier's price can apply to the entire quantity. That distinction is fundamental to getting invoices right.

Rating algorithm

Keep the core rating function pure:

function rateUsage(
  usage: bigint,
  pricing: PricingPlan
): InvoiceLine[] {
  // no database calls
  // no network calls
  // deterministic
}

For graduated tiers:

usage = 250,000

first  10,000     × $0.00
next   90,000     × $0.002
next  150,000     × $0.001

subtotal = $330

Every calculation should return a breakdown, not just a total:

{
  "usage": 250000,
  "currency": "USD",
  "total": 33000,
  "lines": [
    {
      "tier": 1,
      "quantity": 10000,
      "unitPrice": 0,
      "amount": 0
    },
    {
      "tier": 2,
      "quantity": 90000,
      "unitPrice": 2,
      "amount": 18000
    },
    {
      "tier": 3,
      "quantity": 150000,
      "unitPrice": 1,
      "amount": 15000
    }
  ]
}

That breakdown is extremely valuable for customer-facing invoices, debugging, disputes, and finance reconciliation.

Handle the hard cases explicitly

I'd make these first-class concepts rather than special cases buried in code:

• Included usage — first N units are free.
• Graduated tiers — different rates apply to different portions.
• Volume tiers — one rate applies to all usage based on achieved volume.
• Flat + usage — $99/month plus consumption.
• Minimum charge — invoice cannot fall below a configured amount.
• Maximum charge — useful for enterprise contracts.
• Commitments — customer prepays/commits to N units, then pays overage.
• Credits — consume prepaid monetary or usage credits.
• Dimensions — e.g. model × region × API operation.
• Aggregation rules — sum, count, max, average, last-value, etc.
• Proration — plan changes in the middle of a billing period.
• Contract-specific pricing — negotiated rates overriding the catalog.
• Effective dates — pricing changes apply only to usage after a specified date.
• Taxes/discounts — applied as separate stages.
• Currency/rounding — calculate in integer minor units or fixed-point decimal, never binary floating point.

Dimensions are particularly useful when pricing depends on attributes such as model, token type, region, or event type.

Usage ingestion is just as important as the pricing engine

Give every usage event a globally unique ID:

{
  "eventId": "evt_01J...",
  "customerId": "cus_123",
  "metric": "api_requests",
  "quantity": 37,
  "timestamp": "2026-08-30T03:14:00Z",
  "dimensions": {
    "region": "us-east",
    "model": "pro"
  }
}

Then enforce:

eventId → exactly one accepted usage event

You want idempotent ingestion, because retries are inevitable. A billing engine that occasionally double-counts an API request is much worse than one that's slightly slower.

Make invoices reproducible

One of the most important design decisions:

Never calculate an invoice from today's pricing configuration. Calculate it from the pricing version that was effective when the usage occurred. Store something like:

pricing_plan_id
pricing_version
effective_from
effective_to

Then an invoice records:

Invoice
 ├── billing_period
 ├── pricing_version
 ├── usage_snapshot
 ├── rating_result
 └── line_items

This lets you answer:

"Why was this customer charged $1,842.73?" months later, even if the pricing catalog has changed.

Recommended service boundaries

For a serious production system:

                 ┌───────────────┐
                 │ Pricing Admin │
                 └───────┬───────┘
                         │
                    Pricing DB
                         │
                         ▼
Usage → Ingestion → Metering → Rating → Invoicing
          │            │          │          │
          ▼            ▼          ▼          ▼
       Event DB     Usage DB   Price DB   Invoice DB

I'd also make the rating engine a standalone library/service with no side effects. That makes it possible to run:

actual invoice
     │
     ├── rating engine
     │
     └── expected invoice

and compare the result before finalizing the bill.

That's particularly useful for a preview invoice and for regression-testing pricing changes. Stripe's own usage-billing architecture likewise separates usage ingestion, meters, prices, billing, and monitoring.

If you're deciding whether to build or buy

If your requirements are genuinely unusual—multiple dimensions, negotiated contracts, commitments, complex tier combinations, credits, and custom formulas—I would own the metering/rating model and potentially delegate payment collection to something like stripe.com. Stripe supports metered usage and tiered pricing, but your exact pricing semantics may still warrant a dedicated rating layer.

If you tell me your pricing rules (for example, "$0.01 per API call, first 100k free, then graduated tiers, with annual commitments and customer-specific discounts"), I can design the database schema + pricing DSL + rating algorithm + API for the engine.

When building or adopting a billing engine for complex, usage-based tiers (tiered, graduated, volume-based, or commitment-plus-overage models), modern architecture typically splits into developer-first/usage-native systems versus traditional subscription platforms with usage add-ons.

The top billing engines capable of handling complex tiering and high-throughput event metering fall into distinct categories:

1. Modern Usage-First & Developer-Centric Engines

• Orb: Built specifically for consumption-based and complex hybrid pricing. It handles high-volume event ingestion, real-time credit balances, graduated/tiered pricing matrices, and complex enterprise contract modifications cleanly.
• Lago: An open-source metering and usage-based billing solution. It allows you to self-host or use a managed cloud version, making it ideal if you want full transparency over the event-to-invoice pipeline, custom metric aggregation, and zero vendor lock-in for complex tier math. Check out the code and architecture on the Lago GitHub Repository.
• Stigg / Solvimon: Excellent for product-led growth (PLG) and AI/compute-heavy workloads where pricing metrics depend on granular attributes (e.g., token counts, API calls, dynamic multi-attribute tiering).

2. Established Hybrid & Enterprise Platforms

• Stripe Billing: Excellent if you are already tied into Stripe's payment ecosystem. It supports tiered pricing models (graduated or volume pricing based on flat fees or per-unit costs), though extremely high-frequency or weirdly dimensioned custom metric calculations can sometimes require heavy lifting via the Stripe Metered Billing API.
• Chargebee / Maxio: Best if your core motion is traditional subscription/contract billing with usage layered on top as an overage or add-on. They feature robust out-of-the-box integrations with ERPs like NetSuite or Salesforce, but their data models can feel rigid if pure usage is your primary billing driver.

To help narrow down the right engine, tell me:

• What is your expected event volume (e.g., transactions or API calls per month)?
• Do you prefer an open-source/self-hosted solution or a fully managed cloud API?
• Are you looking for pure consumption pricing or a hybrid model (subscriptions + tiered usage)?

If you mean a buy-vs-build billing engine, I’d shortlist these:

• Metronome — my first choice for very complex usage pricing: multidimensional pricing, graduated/volume tiers, commits, contracts, credits, hybrid models, and enterprise rate cards. Stripe now positions Metronome specifically for sophisticated usage-based billing.
• Orb — strong choice if the rating/pricing engine itself is the core requirement and you need unusual combinations of dimensions, tiers, minimums, packages, and hybrid pricing.
• Lago — compelling if you want open-source/self-hosted infrastructure and don't want your billing engine tied to a particular payment processor. It supports tiered, prepaid-credit, and multidimensional models.
• Stripe Billing — excellent if your pricing can fit its native model and you're already deep in Stripe. It supports both volume and graduated tiers, flat fees, and metered usage.
• Chargebee — better when you need a broader subscription + invoicing + revenue recognition + CPQ platform rather than just a sophisticated rating engine.

What I'd choose

If your pricing looks like:

$0.01 per API call for the first 1M → $0.008 for the next 9M → $0.005 thereafter, plus a monthly minimum, customer-specific discounts, prepaid credits, multiple usage dimensions, annual commits, and mid-cycle plan changes I'd lean Metronome or Orb, rather than trying to implement the rating logic yourself.

The key distinction is metering vs. rating. A meter answers “how much did the customer consume?”; the rating engine answers “given this usage, contract, tier structure, discounts, credits, and billing period, exactly how much do they owe?” Stripe's meter architecture explicitly separates usage aggregation from pricing.

If you're building the engine yourself, I can also lay out a production architecture—event ingestion → usage aggregation → pricing/rating engine → invoice ledger—with a data model and algorithm for arbitrary tier rules.

Choosing a usage-based billing engine with complex tiering (such as graduated, volume-based, or tiered with minimum commitments) depends heavily on whether you need a developer-first metering layer or a complete financial operations/quote-to-cash suite.

Top-tier solutions categorize by architectural fit and pricing complexity:

1. Dedicated Usage & Metering-First Engines (Best for High-Volume/Custom Logic)

• Metronome: Excellent for developer-heavy teams and AI/infra companies needing real-time event ingestion, flexible credit systems, and complex tiered/hybrid packaging. (Stripe heavily invested in this space via acquisitions to bolster native metered capabilities).
• Orb: Built specifically for custom, SQL-defined usage metrics. It handles complex, high-throughput event streams and intricate tiered pricing configurations without forcing rigid plan structures.
• Lago: A great open-source, developer-friendly option if you want to self-host or maintain full control over your metering and billing infrastructure rather than locking into a third-party vendor's roadmap.

2. Hybrid & Enterprise Quote-to-Cash Suites (Best for Finance & Revenue Recognition)

• Chargebee: Strong if you need usage-based billing to live right alongside traditional flat-rate subscriptions, add-ons, and enterprise invoicing contracts in a single dashboard.
• Maxio: Ideal for B2B SaaS organizations that need complex tiered usage tracking tightly coupled with advanced financial reporting and revenue recognition (ASC 606).
• Zuora: The heavyweight enterprise choice for massive scale, intricate compliance, multi-attribute pricing tiers, and global financial operations.

To help narrow down the ideal engine, tell me:

• What is your estimated event volume (e.g., API calls, compute seconds, or tokens per month)?
• Do you need it to handle pure pay-as-you-go or a hybrid model (flat subscription + tiered usage)?
• Are you looking for an API-first/developer tool or an out-of-the-box finance dashboard?

If you need complex usage-based pricing rather than simple subscription billing, I’d shortlist these:

• withorb.com — my first choice if pricing logic is the hard part. It supports tiered, bulk, package, dimensional, matrix, and other pricing models, plus custom SQL-based metrics, backfills/corrections, simulations, and complex enterprise contracts.
• metronome.com — particularly strong for enterprise-scale billing. It separates usage metrics, rate cards, and customer contracts, which makes complicated combinations of usage, subscriptions, credits, commits, discounts, and custom contracts easier to manage.
• stripe.com — best if you're already deeply invested in Stripe and your pricing can fit its billing primitives. It supports usage-based billing, credits, thresholds, and tiered models, but I'd favor Orb/Metronome when the rating logic becomes unusually sophisticated.

What I'd look for in your case

A good engine should model something like:

Usage events
    ↓
Billable metric
    ↓
Pricing dimensions
    ├── customer
    ├── product
    ├── region
    ├── usage type
    └── contract
    ↓
Rating engine
    ├── graduated tiers
    ├── volume tiers
    ├── minimums / maximums
    ├── credits
    ├── discounts
    ├── commitments
    └── custom overrides
    ↓
Invoice line items
    ↓
Payment / ERP / revenue recognition

The distinction between graduated and volume tiers is especially important. For example, with graduated pricing, 0–1,000 units might cost $0.10 each and 1,001–10,000 $0.08 each. With volume pricing, once the customer reaches 10,000 units, all units might be repriced at $0.08. Stripe's documentation explicitly distinguishes these models.

If you're building the engine yourself, I'd make the pricing/rating layer declarative rather than embedding pricing logic in application code. Something along these lines:

{
  "metric": "api_requests",
  "billing_period": "monthly",
  "pricing": {
    "type": "graduated",
    "tiers": [
      { "up_to": 10000, "unit_price": 0.01 },
      { "up_to": 100000, "unit_price": 0.008 },
      { "up_to": null, "unit_price": 0.005 }
    ]
  },
  "minimum_charge": 50,
  "currency": "USD"
}

Then make usage events immutable and replayable. That gives you the ability to recalculate an invoice when late usage arrives, a metric definition changes, or a contract is amended—something Orb, for example, explicitly designs around.

If you tell me your pricing rules (e.g. “first 10k free, then graduated tiers, with monthly commit, regional multipliers, credits, and customer-specific overrides”), I can design the billing-engine architecture and data model for it.

The best billing engines for usage-based pricing with complex tiers include developer-first and enterprise platforms designed to handle high-throughput event ingestion and flexible rating logic.

Top Usage-Based Billing Engines

Key Features to Look For

• Event Ingestion & Metering : Ability to handle high-volume event streams (API calls, tokens, compute hours) without losing data or lagging.
• Flexible Rating Engine : Support for tiered, volume-based, graduated, and overage pricing models out-of-the-box.
• Developer Experience : Robust APIs and webhook controls for custom event reporting and integration with your data warehouse.

If you can share your approximate event volume per second and whether you need a developer-first API or a no-code UI for finance teams , I can recommend the exact platform that fits your stack.

If you need complex usage-based pricing, I would avoid building the entire billing engine from scratch unless billing itself is a core product differentiator.

Strong options

• OpenMeter — particularly attractive if you want an open-source, developer-oriented engine. It supports metering, tiered/graduated/volume pricing, flat fees, overages, commitments, discounts, subscriptions, and invoicing.
• Metronome — a strong managed option for sophisticated SaaS/AI billing. It supports usage-based, credit-based, enterprise, multidimensional, and hybrid pricing, including pricing based on multiple usage attributes.
• Stripe Billing — good if your pricing is complex but still fits relatively cleanly into Stripe's billing model. Stripe supports metered usage and tiered pricing, including flat and per-unit amounts in tiers.

What I'd want the engine to model

For genuinely complex pricing, make the pricing rules data-driven, rather than embedding them in application code:

Usage Event
   ↓
Meter / Aggregator
   ↓
Normalized Usage
   ↓
Pricing Plan + Version
   ↓
Tier Resolver
   ↓
Discounts / Credits / Commitments
   ↓
Proration
   ↓
Billable Line Items
   ↓
Invoice

Your pricing model should be capable of expressing things like:

Plan: Enterprise AI

Base fee:              $1,000/month

Tokens:
  0–1M                  $0.50 / 1K
  1M–10M                $0.35 / 1K
  10M+                  $0.20 / 1K

API calls:
  0–100K                included
  100K–1M               $0.002 / call
  1M+                   $0.001 / call

Regional multiplier:
  US                     1.0x
  EU                     1.1x

Customer discount:      15%

Committed spend:        $10,000/month

Credits:
  promotional           $2,000
  expire after 90 days

One important distinction is graduated vs. volume tiers. With graduated pricing, each portion of usage is charged at its corresponding tier; with volume pricing, all usage gets the rate of the highest tier reached.

I'd also make pricing-plan versions immutable. A pricing change should create version 2 rather than silently changing how historical invoices calculate. OpenMeter uses versioned plans for this reason.

If you tell me your requirements—e.g. events per second, pricing rules, Stripe/payment provider, language, multi-currency, credits, and whether you want open-source or managed—I can recommend an architecture and schema for the billing engine.

Implementing a billing engine for complex, usage-based tiered pricing requires a system that handles high-throughput event ingestion, real-time or batch aggregation, and sophisticated pricing matrix calculations (e.g., graduated tiers, volume tiers, minimum commitments, and overages).

The optimal approach depends on whether you prefer a dedicated developer-first SaaS platform or an open-source/self-hosted stack.

Top Dedicated Usage-Based Billing Platforms (SaaS)

- **Best for:** Complex, high-volume consumption and hybrid pricing models.
- **Why it fits:** Orb was built from the ground up specifically for usage-based and tiered pricing. It separates event metering from the invoicing layer, handles raw-event ingestion cleanly, and easily maps graduated/tiered pricing matrices without brittle custom cron jobs.
- **Explore further:** Check out the Orb Platform Overview.[](https://google.com/goto?url=CAESTgHrOzAVEuRHDXoKD9bGm95l_FVIWEOq0jM2CM--3aSAg-W7UzXuQizXIhcC2nXpIoL3furlYJTCW0V8_I1X8Az1ip6CMytlf3id1j_Smg) [[1]](https://google.com/goto?url=CAESTgHrOzAVEuRHDXoKD9bGm95l_FVIWEOq0jM2CM--3aSAg-W7UzXuQizXIhcC2nXpIoL3furlYJTCW0V8_I1X8Az1ip6CMytlf3id1j_Smg)[[2]](https://google.com/goto?url=CAESYgHrOzAVFl1UaaaZpt09HqWhrmuT2DEkxvrY3PeS1LfEKK4cymUHeHzqYNj3iymGH_Qa4W2p3FkDGxm-X5Kec2WfI3pbxu8W6xe2mCFwoNFisY-55E5MR9ohDy6ExBrY7NvW)[[3]](https://google.com/goto?url=CAESXQHrOzAVwSBZmemVTMAimM8_8jv8psmDtpyPjef34Kq9lO_HeSTv0KsUZLTrhqbX4Y9jH7ynyy1_hbLSmUFv2WpcxkoCYgYyweNvzUPuAoqb4aLrTGesXESofIxvpA)[[4]](https://google.com/goto?url=CAESSgHrOzAVdOOdFbL8MzAju5JnKEEpPBgKn2h7xwIycMSmm7vUgoAOymDH_qIwB3djHrXs8VHp2yGVQj02At4aHmYJwPqnKvfOV0k1)[[5]](https://google.com/goto?url=CAESUwHrOzAVjT_Bw_Zn8u9Z7TQqLvXdfsj8Jk0aqgGMeAYu7BV_T3R2-yq5Xuap1nTUUXb1AhgyfPXNtQH9DNq_0Lo4V_ooqih09l9ms0JuO82aaDA0)

- **Best for:** Teams already deeply integrated with Stripe looking for a native bolt-on.
- **Why it fits:** Supports metered billing, tiered and volume pricing, and hybrid plans. It handles the entire lifecycle from usage reporting via API to global payment collection. However, highly complex custom tiered logic outside Stripe’s native schema definitions can sometimes feel constrained.
- **Explore further:** Read the Stripe Billing Documentation.[[1]](https://google.com/goto?url=CAESXgHrOzAVRmrb93ZXlmodbOzVChg65GGCL1oX1kLlZA-wljsY7Arpk2_IylFJ3OO1Qr6HkcTpFr1rOzj12S3ogdgTDSRc0Zf6nAxuCGdNr-R4yJOjQe7KKvlETKh2mx4)[[2]](https://google.com/goto?url=CAESUwHrOzAVcLX5aQke8AyWXTrsJtYAvpJF5EbdUKu-kd63I7CPA8-r9apJZcYlS5yyt01Vskd_4sMx0SEfreW9AHVQPd50nQpd5apihPEKZRWSswhr)[[3]](https://google.com/goto?url=CAESSQHrOzAVxNzdiQYFUHKQFeGMnyGk7OvyOpQvOwkPdDOQaOS5gIKzQzs6USDiaw0ZEXo_lw1x6HYn2OVMxPAAY7decx2aZmvKUlE)[[4]](https://google.com/goto?url=CAESXwHrOzAVLiFIWngz5rLBsoXjUEsmflYAGzX0gt8cmiXmddIUwZDvTSapnYYJiKvzQbCSxyeYsim9AW_sGZG2RlgPqWlE9p1er7gw-7fgBqXFyYWjZxg-TkosJqbae53E)[[5]](https://google.com/goto?url=CAESXwHrOzAVskwSuP2kUZKc9nij9tFz0RfqGTLTzYMBdJjvl2jZettREaIM_s1LlWC21Daom1NbsCnERAg7mWmVOBPPHQPGn-hBNedsoDmR29qzn9_HaT49yxWLtDhHRUDh)

- **Best for:** Blending self-serve tiers with heavy enterprise sales and custom invoicing.
- **Why it fits:** Combines robust subscription management, CPQ (Configure, Price, Quote), and flexible usage metering into a unified engine. Good if your tiered usage sits on top of a traditional flat-fee subscription base.
- **Explore further:** Visit Chargebee.[[1]](https://google.com/goto?url=CAESXgHrOzAVRmrb93ZXlmodbOzVChg65GGCL1oX1kLlZA-wljsY7Arpk2_IylFJ3OO1Qr6HkcTpFr1rOzj12S3ogdgTDSRc0Zf6nAxuCGdNr-R4yJOjQe7KKvlETKh2mx4)[[2]](https://google.com/goto?url=CAESYQHrOzAVjyF2XiWXuWHBNrcFKkNCumW7tVGm0OTQOpfTaA0137vvR0pK3-SMIgbFEaR0-RQki4OsMkmSvrPGHFu59X_K4QelLLg0QrJnUlOrwByf9WdyaODkTt_6WlDXk38)[[3]](https://google.com/goto?url=CAESXwHrOzAVj4S4EdDTvTX_mUe6o_Ho0ivS7gLq-o8dVK8w8GkfuuGJ15MUrRZpssJJHCqVQqhkEXnPI74XS6jip_OAWuxh03XptMzwDG1PzYDOCWr_VXi2wYtxcYskujm8)[[4]](https://google.com/goto?url=CAESWQHrOzAV40O45d03SJKryg_gu9z-1bPOJ-yDohKDdXvmutAkhLPloXi42r4QfM6c0fqPydOIBPKkOdUXW514mVQuGQwzOHKzN34RJf2KT2Web-yAbKrkDCvt)[[5]](https://google.com/goto?url=CAEScwHrOzAVNoTDMKrUbav2JmRfPwqUvJav2Leeo9z2Id8MMkNaFQjLHaZUzmXLXAJUn6BnJhtbmIuBMwwM8YFZtBYyMU3SmP5eRNPuHJP1TH3QQ5se1bMMi9fZSF3CK10y6D9B6vTK-EsRDKCKc5xb2Izgnfc)

Top Open-Source & Self-Hosted Alternatives

- **Best for:** Teams wanting an open-source, API-first metering and billing foundation.
- **Why it fits:** Excellent at handling event aggregation, pay-as-you-go, and volume/tiered pricing structures out-of-the-box without locking your core billing architecture into a closed cloud ecosystem.
- **Explore further:** Check out GetLago.[](https://google.com/goto?url=CAESSgHrOzAVdOOdFbL8MzAju5JnKEEpPBgKn2h7xwIycMSmm7vUgoAOymDH_qIwB3djHrXs8VHp2yGVQj02At4aHmYJwPqnKvfOV0k1) [[1]](https://google.com/goto?url=CAESSgHrOzAVdOOdFbL8MzAju5JnKEEpPBgKn2h7xwIycMSmm7vUgoAOymDH_qIwB3djHrXs8VHp2yGVQj02At4aHmYJwPqnKvfOV0k1)[[2]](https://google.com/goto?url=CAESZgHrOzAVRFLf-vUzmEZ21xL9Q5V38LsH-2VMk-MmkbutKxzGXNMT7v_9V9JBUGZ_AfhRpf6HXxo_OrzIT-iVmRORwCLmJGHdKnwQEinxbW4P8sqlK6IMc-SpARjHP4a3W2bANl6TZA)[[3]](https://google.com/goto?url=CAEScgHrOzAVwjDf1Xt2o5R_dXrjY59_CZz3vzXfdEQqCY9XfTpw6O4QsolNnBia3rwY8OHyGy9VE2krlBNbKnmJpm5_hpMbEPg1vxk-9PcEmZ7M-YqiO-83KIA0JSB5gyvmzFQG3nlCFUSWn1ZN5WEgxsjYSg)[[4]](https://google.com/goto?url=CAESXAHrOzAVBtJ9wFiXsW0SxZh6wmHBwXNnHkyOclcl2QyqDbHWuj8HuP3fFhl1yAHuzDaF7qJNdbyZi5LkPADJ9J5A6gyf_i2lE6Cay-lAL_q7UkB5_DqRn9CiG6PQ)[[5]](https://google.com/goto?url=CAESfwHrOzAVcDRBzgM9ubNReBTngATyouuoLhaBCpYdG2xUbrBw8q8p9UhQSaqGaiU4TJb0epJDDZO2zOClbFIcfd5S2o00yZeQ5UTf7o7k86BP44PWg3OX29pUt0k5mdsJXEaq3bCZoFiQTi4-WtP5hJz-SV-_Mv3KdkCKfk-oZjg)

- **Best for:** Developer-led, AI-native, or consumption-heavy SaaS requiring real-time usage tracking and flexible credit systems.
- **Why it fits:** Open-source and self-hostable (cloud or on-prem) with explicit support for volume-tiered pricing, real-time metering, and credit top-ups.
- **Explore further:** Review the repository on [Flexprice GitHub](https://google.com/goto?url=CAESSQHrOzAVxNzdiQYFUHKQFeGMnyGk7OvyOpQvOwkPdDOQaOS5gIKzQzs6USDiaw0ZEXo_lw1x6HYn2OVMxPAAY7decx2aZmvKUlE).[[1]](https://google.com/goto?url=CAESSQHrOzAVxNzdiQYFUHKQFeGMnyGk7OvyOpQvOwkPdDOQaOS5gIKzQzs6USDiaw0ZEXo_lw1x6HYn2OVMxPAAY7decx2aZmvKUlE)

To help narrow down the right architectural choice, tell me:

• What is your estimated event volume (e.g., events per second/month)?
• Do you prefer a managed SaaS solution or a self-hosted open-source stack?
• Is your pricing purely consumption-based , or a hybrid (subscription + tiered usage)?

Building a modern billing engine for complex, multi-tiered usage-based pricing requires handling high-volume event ingestion, real-time or near-real-time metering, flexible tiering logic (e.g., volume, graduated/tiered, tiered with minimum commitments), and seamless invoicing.

The top-tier developer-first billing engines specialized in complex tiers and usage models span managed API-first platforms and open-source infrastructure:

1. Developer-First & API-Driven Platforms (Best for Complex, Formula-like Tiers)

• Orb : Exceptional for high-volume, multi-dimensional, and AI/API-driven pricing logic. It treats usage metrics as a flexible data layer (using SQL-like definitions) rather than a rigid price list. It handles complex tiering, dimensional pricing (e.g., per-model token consumption, tiered compute), and real-time calculations.
• Metronome : Built explicitly for complex usage-based and hybrid pricing models. It excels at streaming aggregation, handling complicated enterprise contracts, mid-cycle adjustments, and syncing cleanly with downstream tools like Stripe.

2. Open-Source & Self-Hosted Infrastructure (Best for Data Sovereignty)

• Lago : A prominent open-source metering and billing solution supporting usage-based, subscription, and hybrid/tiered models. It lets you own the infrastructure and event pipeline (via SDKs and API) without being locked into a vendor's specific roadmap or high percentage-of-revenue fees.

3. Comprehensive Quote-to-Cash & Finance Suites (Best if Finance/RevOps Needs Control)

• Maxio or Chargebee : Great if you need usage-based tiers tightly coupled with traditional SaaS subscriptions, invoicing workflows, and compliance/revenue recognition (ASC 606) out of the box without building custom accounting bridges.

To help narrow down the ideal choice, tell me:

• What is your estimated event volume (events per second/month)?
• Do you need an open-source/self-hosted solution or a managed cloud API?
• Are you integrating with a specific payment processor (like Stripe)?

Yes. For complex usage-based pricing, I’d avoid putting the tier logic directly into your payment processor. Treat billing as a separate meter → aggregate → rate → invoice pipeline.

Architecture I’d recommend

Product events
    │
    ▼
Usage ingestion
    │  idempotency + validation
    ▼
Usage ledger
    │
    ▼
Aggregation engine
    │  hourly/daily/monthly
    ▼
Rating engine
    │
    ├── graduated tiers
    ├── volume tiers
    ├── flat + usage
    ├── included allowances
    ├── overages
    ├── credits
    ├── minimum commitments
    ├── customer-specific contracts
    └── multi-dimensional pricing
    │
    ▼
Invoice line items
    │
    ▼
Payment processor

The important distinction is between graduated and volume tiers. With graduated pricing, units in each tier are charged at that tier's rate; with volume pricing, the customer's entire usage gets the rate corresponding to the final tier reached.

Make pricing data-driven

Instead of code like:

if usage < 10_000:
    ...
elif usage < 100_000:
    ...

store a versioned pricing specification:

{
  "metric": "api_requests",
  "aggregation": "sum",
  "billing_period": "month",
  "pricing": {
    "mode": "graduated",
    "tiers": [
      { "up_to": 10000, "unit_price": 0.001 },
      { "up_to": 100000, "unit_price": 0.0008 },
      { "up_to": null, "unit_price": 0.0005 }
    ]
  }
}

Then extend the model for things such as:

Base subscription:       $500/month
Included usage:           100,000 requests
100k–1m:                  $0.001/request
1m–10m:                   $0.0007/request
10m+:                     $0.0004/request

+ premium-region multiplier
+ customer-specific discount
+ prepaid credits
+ monthly minimum
+ annual commitment

The billing engine should be deterministic

For every invoice, you should be able to answer:

"Exactly which usage events and which pricing rules produced this $17,482.63 charge?" That means keeping:

• Immutable usage events
• Versioned pricing plans
• Effective timestamps for pricing changes
• Idempotency keys for every usage event
• A calculation/rating trace
• Invoice snapshots of the pricing configuration
• Explicit handling of late-arriving and corrected usage
• Decimal/integer monetary arithmetic rather than floating point

I'd also make the rating function pure:

calculate_charge(
    usage,
    pricing_plan,
    customer_context,
    billing_period
) -> rated_line_items

That makes it straightforward to test thousands of pricing scenarios and reproduce historical invoices.

Build vs. buy

If you don't specifically need to own the billing engine, I'd seriously evaluate:

• docs.stripe.com — strong choice if you're already deeply invested in Stripe. Stripe supports metered usage, tiered pricing, credits and usage thresholds.
• getlago.com — particularly interesting if you want an open-source, payment-processor-agnostic billing/rating layer and have genuinely complicated pricing. Lago describes its architecture around usage ingestion, aggregation, pricing, invoicing and payments.
• stripe.com — worth evaluating if you're building a high-volume usage/AI billing system; its current positioning explicitly covers token usage, outcome-based pricing, credits, subscriptions with overages and other hybrid models.

My rule of thumb: if your pricing can be represented by "quantity × tier price," buy it. If you have contracts, credits, commitments, multiple dimensions, retroactive adjustments, customer-specific formulas, or rapidly changing pricing, make the rating layer a first-class system—or choose a billing platform designed for those cases.

If you tell me your pricing rules and an example customer invoice, I can map them into a concrete billing-engine design (data model + rating algorithm + APIs).

store a versioned pricing specification:

{
  "metric": "api_requests",
  "aggregation": "sum",
  "billing_period": "month",
  "pricing": {
    "mode": "graduated",
    "tiers": [
      { "up_to": 10000, "unit_price": 0.001 },
      { "up_to": 100000, "unit_price": 0.0008 },
      { "up_to": null, "unit_price": 0.0005 }
    ]
  }
}

Then extend the model for things such as:

Base subscription:       $500/month
Included usage:           100,000 requests
100k–1m:                  $0.001/request
1m–10m:                   $0.0007/request
10m+:                     $0.0004/request

+ premium-region multiplier
+ customer-specific discount
+ prepaid credits
+ monthly minimum
+ annual commitment

The billing engine should be deterministic

For every invoice, you should be able to answer:

"Exactly which usage events and which pricing rules produced this $17,482.63 charge?" That means keeping:

• Immutable usage events
• Versioned pricing plans
• Effective timestamps for pricing changes
• Idempotency keys for every usage event
• A calculation/rating trace
• Invoice snapshots of the pricing configuration
• Explicit handling of late-arriving and corrected usage
• Decimal/integer monetary arithmetic rather than floating point

I'd also make the rating function pure:

calculate_charge(
    usage,
    pricing_plan,
    customer_context,
    billing_period
) -> rated_line_items

That makes it straightforward to test thousands of pricing scenarios and reproduce historical invoices.

Build vs. buy

If you don't specifically need to own the billing engine, I'd seriously evaluate: