I need a "subscription billing" engine that handles usage-based pricing models.

If you’re building the engine rather than just buying one, I’d structure it as a separate metering → rating → invoicing system, not as logic embedded in your payment provider.

Current usage-billing systems commonly follow this pattern: ingest immutable usage events, aggregate them into billable metrics, apply versioned pricing, then generate invoices.

Recommended architecture

Product / APIs
     │
     ▼
Usage Events ──► Event Store
     │               │
     ▼               │
Metering/Aggregation │
     │               │
     ▼               ▼
Billable Metrics ◄── Replay/Corrections
     │
     ▼
Pricing / Rating Engine
     │
     ├── flat subscription
     ├── per-unit
     ├── graduated tiers
     ├── volume pricing
     ├── package/block pricing
     ├── minimum commitments
     ├── credits / prepaid
     ├── overages
     └── hybrid base + usage
     │
     ▼
Invoice Engine
     │
     ├── taxes
     ├── discounts
     ├── credits
     ├── proration
     └── currency
     │
     ▼
Payment Provider

1. Usage events

Make usage append-only and idempotent.

{
  "event_id": "evt_123",
  "customer_id": "cus_42",
  "meter": "api_calls",
  "timestamp": "2026-09-17T08:30:00Z",
  "quantity": 17,
  "dimensions": {
    "region": "us-west",
    "model": "pro"
  }
}

Give every event a unique transaction/event ID so retries cannot double-bill. Idempotent ingestion is a particularly important production characteristic in existing billing engines.

2. Metering layer

Don't put pricing directly into the event collector.

Instead, define meters such as:

api_calls       = COUNT(events)
tokens          = SUM(tokens)
storage_gb      = MAX(storage_gb)
active_users    = COUNT_UNIQUE(user_id)
compute_seconds = SUM(duration)

Also allow filtered metrics:

pro_tokens =
    SUM(tokens)
    WHERE model = "pro"

This separation makes pricing changes much safer.

3. Pricing engine

Represent pricing as data, not application code.

For example:

{
  "metric": "api_calls",
  "model": "graduated",
  "currency": "USD",
  "tiers": [
    { "up_to": 10000, "unit_price": 0.01 },
    { "up_to": 100000, "unit_price": 0.008 },
    { "above": 100000, "unit_price": 0.005 }
  ]
}

Your pricing engine should support at least:

• Flat recurring fee
• Per-unit usage
• Graduated tiers
• Volume tiers
• Package/block pricing
• Minimum charges
• Included usage + overage
• Prepaid credits
• Percentage-of-revenue
• Seats + usage
• Multiple meters on one subscription
• Customer-specific negotiated prices

Modern usage-billing platforms expose many of these models, including tiered, package, volume, prepaid, minimum-commitment, and hybrid pricing.

The really important part: version everything

Never mutate a price that has already been used to produce an invoice.

Instead:

pricing_plan_v1
pricing_plan_v2
pricing_plan_v3

with effective dates:

v1: Jan 1 → Jun 30
v2: Jul 1 → Sep 30
v3: Oct 1 → ...

That lets you answer:

"Why was this customer charged $742.18?" with a deterministic chain:

Invoice
  → invoice line
    → rating calculation
      → pricing version
        → meter
          → usage events

This auditability becomes especially important when usage is corrected or prices change retroactively; raw usage retention makes backfills and billing corrections much more manageable.

Billing-period model

I'd explicitly model:

Customer
  └── Subscription
        ├── Plan
        ├── Billing period
        ├── Price versions
        ├── Entitlements
        └── Meters

Then have a billing-period state machine:

OPEN
  ↓
CALCULATING
  ↓
DRAFT_INVOICE
  ↓
FINALIZED
  ↓
PAYMENT_PENDING
  ↓
PAID

Never recalculate a finalized invoice in place.

Corrections should create credit notes, adjustments, or replacement invoices.

Database

A relational database such as PostgreSQL is a good system of record:

customers
subscriptions
subscription_items
plans
prices
price_versions
meters
usage_events
metered_usage
billing_periods
invoices
invoice_lines
credits
credit_notes
payments
entitlements

For very high-volume usage, I'd separate the raw event path from the transactional billing database:

Kafka / Kinesis
       ↓
Usage event store
       ↓
Aggregation workers
       ↓
Postgres billing DB

The billing DB remains authoritative for contracts, subscriptions, invoices and financial state, while the event infrastructure handles throughput.

One design choice I'd strongly recommend

Build a deterministic function like:

calculate_charge(
    customer,
    subscription,
    meter,
    period,
    pricing_version
) → Charge

It should be pure and replayable.

Then you can run:

Historical usage
       +
Historical pricing
       ↓
     Rating
       ↓
Expected invoice

That gives you:

• Invoice previews
• Pricing simulations
• Automated regression tests
• Backfills
• Dispute investigation
• Historical invoice reconstruction

Buy vs. build

If this is a product you're developing, I would also seriously consider using an existing billing engine rather than implementing all of the above yourself. Lago, for example, is open-source and specifically provides metering, pricing, subscriptions, invoices and payment-provider integrations.

Other current options include Orb, Chargebee, Stripe Billing/Metronome, Zuora, and others; the right choice depends heavily on whether you need an embeddable engine, self-hosting, complex rating, or primarily subscription/payment management.

If you're building this yourself, I can .

That lets you answer:

"Why was this customer charged $742.18?" with a deterministic chain:

Invoice
  → invoice line
    → rating calculation
      → pricing version
        → meter
          → usage events

This auditability becomes especially important when usage is corrected or prices change retroactively; raw usage retention makes backfills and billing corrections much more manageable.

Billing-period model

I'd explicitly model:

Customer
  └── Subscription
        ├── Plan
        ├── Billing period
        ├── Price versions
        ├── Entitlements
        └── Meters

Then have a billing-period state machine:

OPEN
  ↓
CALCULATING
  ↓
DRAFT_INVOICE
  ↓
FINALIZED
  ↓
PAYMENT_PENDING
  ↓
PAID

Never recalculate a finalized invoice in place.

Corrections should create credit notes, adjustments, or replacement invoices.

Database

A relational database such as PostgreSQL is a good system of record:

customers
subscriptions
subscription_items
plans
prices
price_versions
meters
usage_events
metered_usage
billing_periods
invoices
invoice_lines
credits
credit_notes
payments
entitlements

For very high-volume usage, I'd separate the raw event path from the transactional billing database:

Kafka / Kinesis
       ↓
Usage event store
       ↓
Aggregation workers
       ↓
Postgres billing DB

The billing DB remains authoritative for contracts, subscriptions, invoices and financial state, while the event infrastructure handles throughput.

One design choice I'd strongly recommend

Build a deterministic function like:

calculate_charge(
    customer,
    subscription,
    meter,
    period,
    pricing_version
) → Charge

It should be pure and replayable.

Then you can run:

Historical usage
       +
Historical pricing
       ↓
     Rating
       ↓
Expected invoice

That gives you:

• Invoice previews
• Pricing simulations
• Automated regression tests
• Backfills
• Dispute investigation
• Historical invoice reconstruction

Buy vs. build

If this is a product you're developing, I would also seriously consider using an existing billing engine rather than implementing all of the above yourself. Lago, for example, is open-source and specifically provides metering, pricing, subscriptions, invoices and payment-provider integrations.

Implementing a usage-based or hybrid subscription billing engine requires separating three core functions: metering (ingesting high-volume event data), pricing logic (calculating tiers, overages, and minimum commitments), and payment collection (charging cards via gateways like Stripe or Adyen).

Top-tier engines built explicitly for usage-based and hybrid subscription models fall into developer-focused open-source options and specialized cloud platforms:

1. • Type: Open-source (AGPLv3) & Cloud-managed.
   • Best For: Teams wanting a transparent, self-hostable billing layer that handles pay-as-you-go, hybrid subscriptions, and prepaid credit drawdowns without vendor lock-in.
   • How it works: It acts as the calculation and invoicing engine, then plugs into your payment gateway (Stripe, Adyen, etc.) to collect funds.
2. Orb / Metronome
   • Type: Enterprise cloud platforms.
   • Best For: High-volume event ingestion and complex, contract-heavy enterprise pricing (common in AI, infrastructure, or data APIs).
   • How it works: Built to scale horizontally for millions of raw metering events per second, translating real-time usage into precise line items.
3. • Type: Open-source cloud metering and billing.
   • Best For: Real-time API usage tracking and event aggregation before pushing final invoice amounts to gateways like Stripe.
4. Stripe Billing / Chargebee
   • Type: Traditional SaaS billing (with added usage features).
   • Best For: Simpler tiered or per-seat models with minor usage-based add-ons.
   • The Catch: As usage granularity and custom contract terms scale up, rigid data structures can require heavy engineering workarounds.

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

• Expected event volume (e.g., thousands vs. millions of usage events per day)?
• Deployment preference (self-hosted open source vs. fully managed cloud service)?
• Pricing structure complexity (simple tiered overages vs. prepaid credit drawdowns or custom enterprise contracts)?

Building or integrating a usage-based subscription engine requires handling high-throughput event metering, complex pricing tiers (e.g., tiered, volume, or overage pricing), and reliable invoice generation.

Top-tier options break down by developer-first/API architectures, open-source flexibility, and enterprise suites:

• Orb - Orb Billing Software excels at high-throughput, multi-dimensional usage data (API calls, AI tokens, compute, bandwidth). It handles flexible hybrid models (flat subscription + usage credits) seamlessly.
• Metronome - Metronome is a developer-first metering and billing engine built specifically to scale complex consumption-based and hybrid enterprise contracts.
• Lago - Lago Open-Source Billing is an open-source, AGPLv3-licensed option ideal if you prefer a self-hosted or cloud-hybrid setup for usage-based, subscription, and prepaid wallet models without vendor lock-in.
• Chargebee - Chargebee is a strong fit if your model is a hybrid of traditional tiered subscriptions with usage-based add-ons, particularly for mid-market to enterprise SaaS.
• Stripe Billing - Stripe works well for usage-based billing via metered billing features if you are already deeply embedded in the Stripe ecosystem and your usage tracking logic isn't hyper-complex.

To help narrow down the right choice, tell me:

• What is your core usage metric (e.g., API requests, active seats, data volume, AI tokens)?
• Do you prefer a hosted cloud API or an open-source/self-hosted solution?
• Are you looking for a pure consumption model or a hybrid (base fee + usage) model?

If you need a subscription billing engine with usage-based pricing, you’re essentially looking for a system that can do four things well:

1. Track usage events (API calls, tokens, storage, seats, transactions, compute hours, etc.)
2. Apply pricing rules (tiers, volume discounts, overages, credits, minimum commitments)
3. Generate invoices and collect payments
4. Provide auditability for finance and customers

A good architecture looks like this:

Core components

1. Usage Metering Service

Receives events from your product:

{
  "customer_id": "cust_123",
  "meter": "api_calls",
  "quantity": 15000,
  "timestamp": "2026-09-13T04:00:00Z"
}

Responsibilities:

• Event ingestion API
• Deduplication/idempotency
• Aggregation by billing period
• Usage dashboards
• Late event handling

---

2. Pricing / Rating Engine

Converts usage into billable charges.

Examples:

Simple per-unit

15,000 API calls × $0.001 = $15

Tiered pricing

0–10,000 calls: $0.002 each
10,001–100,000 calls: $0.001 each
100,001+: $0.0005 each

Hybrid subscription + usage

Pro plan: $99/month
Includes: 50,000 API calls
Overage: $0.001/call

You’ll want configurable pricing rules rather than hard-coded logic.

---

3. Subscription Management

Handles:

• Plans
• Upgrades/downgrades
• Trials
• Proration
• Entitlements/features
• Contract overrides

Example:

Customer A
 └── Enterprise Plan
     ├── Base fee: $5,000/month
     ├── Included tokens: 10M
     ├── Overage: $0.20/M tokens
     └── Custom discount: 15%

---

4. Invoice Engine

Needs to support:

• Billing in advance
• Billing in arrears
• Usage summaries
• Taxes
• Credits
• Adjustments
• Refunds
• Invoice PDFs

---

5. Payment + Accounting Integrations

Common integrations:

• Payment processor
• Tax provider
• ERP/accounting system
• Revenue recognition system

---

Build vs buy options

Buy a billing engine

Good options:

• Stripe + usage-based billing extensions — good if you already use Stripe payments and want a managed stack.
• Chargebee — designed for SaaS subscriptions, usage metering, hybrid pricing, and revenue workflows.
• Metronome — focused on sophisticated usage-based monetization, including AI/API-style pricing models.
• Lago — open-source billing infrastructure with usage metering and hybrid plans.
• Recurly — supports usage-based add-ons and billing based on measured consumption.

---

If you build it yourself, a minimal database model

customers
---------
id
name

subscriptions
-------------
id
customer_id
plan_id
status
start_date
end_date

meters
------
id
name
unit

usage_events
------------
id
customer_id
meter_id
quantity
timestamp

pricing_rules
-------------
id
meter_id
model
rate
threshold

invoices
--------
id
customer_id
period_start
period_end
amount
status

---

Important edge cases to design for

• Duplicate usage events
• Usage arriving after invoice generation
• Contract-specific pricing
• Currency changes
• Mid-cycle upgrades
• Free allowances
• Prepaid credits
• Usage caps
• Customer spending alerts
• Invoice disputes
• Audit trails

---

For a new SaaS product, I’d usually avoid building the full billing engine unless billing itself is your product. A common approach is:

• Build your own usage event pipeline + pricing logic
• Use a specialized billing platform for invoicing, payments, and accounting

If you’re building something like an AI API, cloud infrastructure product, developer platform, or enterprise SaaS, the right architecture choices can differ quite a bit.

5. Payment + Accounting Integrations

Common integrations:

• Payment processor
• Tax provider
• ERP/accounting system
• Revenue recognition system

---

Build vs buy options

Buy a billing engine

Good options:

You need a hybrid subscription and consumption-based billing engine that ingests high-volume event data, aggregates it, and applies complex pricing tiers alongside flat recurring fees.

Building this from scratch requires solving real-time event ingestion, idempotency, and ledger accuracy. Alternatively, established platforms provide out-of-the-box infrastructure for hybrid models.

Top Usage-Based Billing Engines

Core Architecture Components Needed

• Metering & Ingestion Layer: An API or Kafka/stream pipeline capable of capturing raw usage events (API calls, gigabytes, compute seconds) without dropping data.
• Aggregation & Mediation Engine: Deduplicates, normalizes, and rolls up raw events into billable metric units hourly or daily.
• Pricing & Rating Engine: Evaluates aggregated usage against the customer's specific contract (e.g., tiered pricing, volume discounting, minimum commitments, or overage rates).
• Invoicing & Revenue Recognition: Generates the final hybrid invoice (base fee + usage) and defers or recognizes revenue accurately.

To help narrow down whether you should build vs. buy or pick a specific vendor, please share:

• Your expected event volume (e.g., number of usage events per month)
• The nature of your metric (e.g., API requests, active seats, data volume, AI tokens)
• Whether you need it to handle pure consumption or a hybrid (base subscription + usage) model

If you’re looking for a subscription billing engine specifically for usage-based pricing, I’d shortlist these architectures/vendors:

• Chargebee Billing — strong fit if you want a fairly complete billing engine rather than building one yourself. It supports pay-as-you-go, fixed fee + overages, and hybrid included-usage models, with usage-event ingestion, metered features, aggregation, pricing, invoicing, and usage reporting.
• Stripe Billing — good if your stack is already heavily Stripe-oriented and you want payments, subscriptions, invoicing, and metering together.
• Orb — worth considering if usage-based pricing is the core of your product, particularly for sophisticated metering and pricing models.
• Lago — attractive if you want an open-source/self-hostable usage-based billing layer.
• Build your own metering + use a payment processor — appropriate when your pricing logic is unusually domain-specific and billing is a strategic part of the product.

What I would require from the engine

Your engine should have these primitives:

Usage Event
    ↓
Meter
    ↓
Aggregation
    ↓
Entitlement / Included Usage
    ↓
Pricing Rule
    ↓
Billing Period
    ↓
Invoice Line Items
    ↓
Payment

For example:

Plan: Pro
Base price: $99/month
Included API calls: 100,000

Usage:
  160,000 API calls

Pricing:
  First 100,000 → included
  Next 60,000  → $0.004/call

Invoice:
  Subscription       $99.00
  API overage        $240.00
  ---------------------------
  Total             $339.00

I'd also make idempotency/deduplication, late-arriving usage, backfills, proration, credits, refunds, tier changes, currency, taxation, and an immutable audit trail first-class features. Chargebee, for example, explicitly uses deduplication IDs for usage events and supports backdated usage ingestion.

If you're building this engine rather than selecting a vendor, I can sketch the actual architecture—database schema, metering API, pricing DSL, invoice calculation algorithm, and event-processing pipeline.

Implementing a usage-based or hybrid (subscription + consumption) billing engine requires a stack that can reliably handle three distinct layers: event metering/ingestion (high-throughput tracking of raw usage), aggregation & calculation (turning raw events into billable metrics based on complex pricing tiers), and invoicing/payment collection.

Depending on whether you want a modern API-first developer tool, an open-source self-hosted setup, or an enterprise quote-to-cash platform, the top options break down into clear categories:

1. Developer-First & Consumption Specialists

• Orb / Metronome: Widely considered the gold standard for high-volume, real-time usage-based pricing. They excel at defining complex, SQL-like billable metrics (e.g., compute seconds, active seats, API calls ) and syncing smoothly with underlying payment processors like Stripe.
• Stigg: Great if your product-led growth model couples usage metrics tightly with real-time feature entitlements and packaging changes.

2. Open-Source & Self-Hosted Control

• Lago: An open-source (AGPLv3) billing platform built explicitly for usage-based, subscription, and hybrid models. It connects to your product data via API/webhooks, aggregates events, generates invoices, and integrates with processors like Stripe or Adyen without locking you into a closed SaaS ecosystem.
• Kill Bill: A mature, heavily production-tested open-source billing and subscription engine well-suited for organizations that want complete ownership of their financial logic and data.

3. All-in-One Subscription & Enterprise Platforms

• Chargebee: A robust platform that bridges traditional flat-rate subscriptions with usage-based overages. Ideal if you need out-of-the-box dunning, tax automation, and customer portals alongside consumption data.
• BillingPlatform: Built for complex, multi-model enterprise environments (handling everything from tiered to formula-based consumption alongside GAAP-compliant revenue recognition).

To help narrow down the right architectural choice for your stack, let me know:

• Are you looking for a managed SaaS cloud or an open-source self-hosted solution?
• What is your primary metered metric (e.g., API requests, data volume, compute time, active users)?
• Do you already use a payment processor like Stripe that you want the engine to plug into?

Yes. If you’re looking to buy/use a subscription billing engine rather than build one from scratch, I’d shortlist these:

• Orb — my first choice for complex usage-based or hybrid billing. It models events → metrics → prices → subscriptions → invoices, supports custom metrics, backfills/corrections, simulations, prepaid credits, and enterprise contracts.
• Stripe Billing + Metronome — strongest choice if you already use Stripe for payments. Stripe supports meters, usage events, recurring subscriptions, usage-based pricing, and alerts; its current Billing offering integrates Metronome for more advanced usage-based billing.
• Lago — particularly interesting if you want an open-source/self-hosted billing engine. It supports subscription, usage-based, and hybrid models, with metering, pricing, invoicing, and payment integrations.

What I'd want the engine to support

For a serious usage-based system, I'd make these requirements non-negotiable:

Usage events
    ↓
Idempotent event ingestion
    ↓
Meters / aggregation
    ↓
Pricing rules
    ↓
Subscription + contract
    ↓
Rating engine
    ↓
Invoice
    ↓
Payment provider

And the pricing layer should handle things like:

• Flat subscription + usage overage
• Pure pay-as-you-go
• Graduated tiers — $0.10/unit for first 1,000, $0.07 thereafter
• Volume tiers — all units priced according to the customer's tier
• Minimum commitments
• Included allowances
• Prepaid credits
• Credit burndown
• Per-seat + usage hybrid
• Multi-dimensional pricing — e.g. model × region × tokens
• Proration
• Effective-dated price changes
• Backdated contracts/amendments
• Late/corrected usage
• Usage caps and alerts
• Invoice previews/simulations

The last few are especially important. A billing system that merely increments a counter when an event arrives can become painful when you need to correct historical usage or change pricing. Orb, for example, explicitly uses immutable usage data and recalculates billing from it, while Lago similarly separates usage events, metrics, and pricing.

If you're actually building the engine

I'd recommend not coupling the billing/rating engine to the payment processor.

Make the architecture roughly:

                    ┌─────────────────┐
Product ───────────►│ Usage Event API  │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Immutable Usage │
                    │ Event Store     │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Meter / Metric  │
                    │ Engine          │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Rating Engine   │◄── Price Catalog
                    │                 │◄── Customer Contract
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Invoice Engine  │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Stripe / Adyen  │
                    │ / other PSP     │
                    └─────────────────┘

The key design decision: keep raw usage events immutable and make invoice calculation deterministic and reproducible. That gives you the ability to answer, "Why was this customer charged $18,742.31?" and to recalculate an invoice when a late event, contract amendment, or pricing correction arrives.

If you tell me your intended model (for example AI tokens, API calls, storage, seats + overages, or something more complicated), I can lay out the database schema + pricing DSL + rating algorithm + API design for the engine.

Yes. If by “subscription billing engine” you mean a system that can combine recurring subscriptions with consumption-based charges, I’d avoid building the entire billing stack from scratch.

The current shortlist is roughly:

• Stripe Billing + Metronome — strongest choice if you already use Stripe. Stripe acquired Metronome in January 2026, and the combined offering supports usage events, multidimensional metering, credits, commitments, invoicing, payments, and revenue workflows.
• Orb — particularly good when the core problem is sophisticated usage metering/rating and frequent pricing changes. Orb was acquired by Adyen in July 2026.
• Lago — attractive if you want an open-source/self-hosted billing core and payment-processor independence. It supports usage, hybrid pricing, credits, wallets, and custom aggregation.
• Chargebee — better when traditional subscription management, invoicing, dunning, and SaaS operations are more important than extremely sophisticated metering.
• Zuora — worth considering for very large enterprises with complex contracts, order-to-cash, and revenue-management requirements.

If you're actually building the engine

I'd model it as six separate concerns:

Usage Events
     │
     ▼
┌─────────────┐
│   Metering  │  aggregate requests, tokens, GB, minutes, etc.
└──────┬──────┘
       ▼
┌─────────────┐
│    Rating   │  apply prices, tiers, dimensions, discounts
└──────┬──────┘
       ▼
┌─────────────┐
│ Entitlements│  limits, quotas, included usage, credits
└──────┬──────┘
       ▼
┌─────────────┐
│ Billing Run  │  period boundaries + finalized usage
└──────┬──────┘
       ▼
┌─────────────┐
│   Invoice   │  line items, adjustments, taxes
└──────┬──────┘
       ▼
┌─────────────┐
│   Payment   │  collection, retries, refunds
└─────────────┘

The most important architectural decision is to make usage events immutable and idempotent. Every event should carry something like:

event_id
customer_id
subscription_id
meter
timestamp
quantity
dimensions

Then pricing is applied separately:

Customer:
    Pro subscription       $99/month

Usage:
    API requests            2.4M
    AI tokens               18.2M
    Storage                 420 GB

Pricing:
    1M API requests         $20
    1M AI tokens            $0.80
    1 GB storage            $0.10

Invoice:
    Subscription            $99.00
    API usage               $48.00
    AI usage                $14.56
    Storage                 $42.00
    ------------------------------
    Total                  $203.56

That separation lets you support flat subscriptions, per-unit usage, tiered pricing, volume pricing, graduated pricing, prepaid credits, minimum commitments, overages, discounts, and hybrid plans without rewriting the event pipeline.

For a new product today, my default recommendation would be Stripe + Metronome if you're already in the Stripe ecosystem; Lago if self-hosting/processor independence matters; Orb if sophisticated usage rating is the primary requirement.

If you tell me your usage unit (API calls, tokens, seats, storage, etc.), pricing model, expected event volume, and whether you need to build vs. buy, I can sketch the actual billing-engine architecture and data model.

Building or choosing a subscription billing engine that handles usage-based (metered, consumption, or hybrid) pricing requires separating the architecture into distinct layers: Metering/Ingestion, Aggregation/Rating, Billing/Invoicing , and Payment Collection.

Depending on whether you want a developer-first open-source stack , an API-first cloud service , or an enterprise platform , here are the top choices and architecture patterns.

Phase 1: Core Architectural Components

A robust usage-based engine must support:

1. Event Ingestion: High-throughput APIs or streaming ingestors (Kafka, REST, SDKs) to capture raw telemetry (e.g., API calls, compute seconds, AI token counts).
2. Aggregation & Deduplication: Safely grouping raw events per customer, per billing period, while handling out-of-order or duplicate events.
3. Rating Engine: Translating aggregated units into monetary value using pricing logic (tiered, volume-based, graduated, flat-fee + overage, or prepaid credit drawdowns).
4. Invoicing & Dunning: Generating ledger-accurate PDF/JSON invoices, handling taxes, and managing failed payment retries.

Phase 2: Top Engine Options

1. Open-Source & Self-Hosted (Full Control)

• Lago: An open-source (AGPLv3) metering and usage-based billing platform designed explicitly for hybrid, subscription, and pay-as-you-go pricing. It handles event ingestion, aggregation, prepaid credit wallets, and invoicing, then hooks into gateways like Stripe or Adyen for collection. Check out the Lago GitHub Repository.
• Kill Bill: A mature, highly scalable open-source subscription and billing/payments platform. It handles complex catalog configurations, proration, and metered billing. It's ideal if you have heavy enterprise compliance needs and want to own the entire database.

2. API-First Cloud Services (Developer-Centric)

• Metronome: Widely adopted for complex, high-throughput usage-based and AI/API consumption pricing (acquired/partnered heavily in the modern data stack ecosystem). Excellent at handling massive event volumes and custom enterprise contract drafting.
• Orb: An API-first billing engine built specifically for usage-based and hybrid pricing models. It decouples event ingestion from invoicing and features a flexible calculation engine for tiered/graduated pricing.

3. Traditional / Enterprise Suites

• Stripe Billing: Great for standard tiered or metered pricing if you are already inside the Stripe ecosystem, though highly customized credit-drawdown or multi-dimension hybrid models can stretch its native capabilities.
• Zuora Billing: The heavyweight enterprise choice for complex multi-attribute usage, minimum commitments, and prepaid drawdown models, though it comes with substantial integration and maintenance overhead.

Recommended Implementation Approach

If you are building this out, the modern consensus is not to build the rating and ledger logic from scratch in Postgres/SQL due to edge cases (proration, delayed telemetry, timezone shifts, and invoice amendments).

• Option A (Fastest to Market): Use an API-first usage ledger like Orb or Lago Cloud.
• Option B (Data Privacy / Cost Control): Self-host Lago on your own Kubernetes cluster, pipe high-frequency usage events from your application via SDKs, and sync the finalized invoice totals to Stripe for payment processing.

To help narrow down the best path, tell me:

• What is your estimated event volume (events per month/second)?
• What does your pricing model look like (e.g., flat subscription + API overages, AI token sliding scales, or prepaid credit drawdowns)?
• Do you prefer a managed cloud API or a self-hosted open-source deployment?