Usage-based pricing for SaaS: how to implement with Chargebee, Stripe, or Paddle

Usage-based pricing has moved from niche to mainstream. According to OpenView's SaaS benchmarks, over 60% of SaaS companies now have some form of usage-based component in their pricing, and that number continues to climb. The reason is straightforward: usage-based pricing aligns what the customer pays with the value they receive. When done right, it reduces barrier to entry, drives natural expansion revenue, and makes your product inherently product-led.

But implementation is where most teams get stuck. Metering, aggregation, billing, and invoicing are complex infrastructure problems. This guide covers the architecture, the trade-offs, and a practical comparison of the three leading platforms for building usage-based billing in 2026.

Why usage-based pricing is winning

Lower barrier to entry

Flat-rate pricing forces customers to commit to a price before they know the value. Usage-based pricing lets customers start small and pay as they grow. This is the natural pricing model for PLG because it eliminates the "is this worth $X/month?" question during signup.

Natural expansion revenue

When pricing is tied to usage, revenue grows automatically as customers get more value. No upsell required. No sales call needed. The customer's success is directly reflected in your revenue.

Better alignment with value

A customer using 100 API calls per month and a customer using 100,000 API calls per month are getting radically different amounts of value. Charging them the same flat rate leaves money on the table with the heavy user and overcharges the light user.

Reduced churn

Customers who pay less during slow periods are less likely to cancel entirely. Instead of a binary stay/leave decision, they naturally scale down and scale back up when their usage increases.

Types of usage-based pricing

Not all usage-based pricing works the same way. Choose the model that fits your product and market.

Pure usage-based

What it is: No base fee. Customers pay only for what they use.

Best for: Infrastructure products, API-first products, and tools where usage varies dramatically between customers (AWS Lambda, Twilio, Snowflake).

Pros: Lowest barrier to entry. Perfect alignment with value. Zero cost to start.

Cons: Unpredictable revenue for the vendor. Can create "bill shock" for customers. Hard to forecast.

Hybrid (base + usage)

What it is: A fixed monthly base fee that includes a usage allowance, plus per-unit charges for usage above the allowance.

Best for: Most B2B SaaS products. Provides predictable revenue for the vendor and predictable costs for the customer, while still allowing expansion.

Example: $49/month includes 10,000 events. $0.005 per event above 10,000.

Pros: Predictable base revenue. Customers have a cost floor they can budget for. Expansion is automatic.

Cons: More complex billing. Need to clearly communicate what happens when usage exceeds the allowance.

Tiered usage

What it is: Usage is grouped into tiers with different per-unit rates. Higher tiers have lower per-unit costs.

Best for: Products where volume discounts make sense and where customers want cost predictability at scale.

Example: 0-10,000 events: $0.01 each. 10,001-100,000: $0.007 each. 100,001+: $0.004 each.

Pros: Rewards and incentivizes higher usage. Customers can predict costs at different scales.

Cons: Most complex to implement and communicate. Can create confusion at tier boundaries.

How to choose your usage metric

The usage metric is the most important decision in your pricing model. Get it wrong and everything downstream breaks.

Characteristics of a good usage metric

• Correlated with value: The more the customer uses, the more value they receive. If a customer can use a lot without getting value, you have the wrong metric.
• Measurable and auditable: Both you and the customer should be able to verify the count. If the customer cannot see how their usage translates to charges, trust erodes.
• Predictable by the customer: The customer should be able to roughly estimate their usage before they start. "API calls" is predictable. "Compute units" is not, unless you provide very clear documentation.
• Grows with the customer: The metric should naturally increase as the customer gets more value and grows their business.

Common usage metrics

The test

Ask yourself: "If a customer doubles their usage of this metric, are they getting roughly double the value?" If the answer is yes, it is a good metric. If the answer is "it depends," you need a different metric or a composite approach.

Platform comparison: Chargebee vs Stripe vs Paddle

Chargebee

Best for: Complex metering scenarios, mid-market and enterprise B2B SaaS.

Strengths:

• Advanced metering: Native support for multi-dimensional usage metering. You can meter on multiple axes (API calls + storage + seats) and combine them into a single invoice.
• Quote-to-cash workflow: Built-in CPQ (configure, price, quote) for sales-assisted deals alongside self-serve.
• Revenue recognition: Built-in ASC 606 compliance and revenue recognition reporting.
• Entitlements engine: Manage feature access and usage limits without custom code.

Weaknesses:

• More complex setup than Stripe. Expect 2-4 weeks for a production implementation.
• Pricing is opaque and can get expensive at scale.
• UI is functional but not elegant.

Pricing: Starts at $249/month for the Growth plan. Custom pricing for enterprise.

Stripe Billing

Best for: Developer-first teams, startups, and companies already using Stripe for payments.

Strengths:

• Developer experience: The best API documentation in the billing space. If your team is engineering-led, Stripe is the most natural fit.
• Metered billing API: Native support for reporting usage and generating invoices. Simple webhook-based architecture.
• Flexibility: You can build almost any billing model with Stripe's primitives (subscriptions, usage records, invoice items, tiered pricing).
• Ecosystem: Tight integration with Stripe Payments, Stripe Tax, and Stripe Connect.

Weaknesses:

• No built-in CPQ or quoting workflow. If you need sales-assisted billing, you will need to build or integrate separately.
• Revenue recognition requires Stripe Revenue Recognition (additional product, additional cost).
• Complex metering scenarios require more custom code than Chargebee.

Pricing: 0.5% of billing volume (Stripe Billing fee, on top of payment processing fees).

Paddle

Best for: Companies selling globally that want to minimize tax and compliance overhead.

Strengths:

• Merchant of record: Paddle handles global sales tax, VAT, and compliance. You do not need to register for tax in every jurisdiction.
• Checkout and billing combined: Payment processing and billing in one platform. No separate Stripe integration needed.
• Usage-based billing support: Paddle Billing supports metered billing with usage reporting APIs.
• Localized pricing: Automatic currency conversion and localized checkout experiences.

Weaknesses:

• Less flexible than Stripe for complex billing scenarios.
• Higher effective fees (5% + $0.50 per transaction, but this includes tax handling that would otherwise cost you separately).
• Smaller ecosystem and fewer integrations than Stripe or Chargebee.
• Less control over the billing experience since Paddle owns the merchant relationship.

Pricing: 5% + $0.50 per transaction (includes payment processing, tax handling, and billing).

Decision matrix

Architecture: metering to invoicing

Regardless of which platform you choose, the architecture follows the same four stages.

Stage 1: Metering

Capture every billable event in real time. This is the foundation. Get it wrong and everything else is inaccurate.

Implementation:

• Instrument your application to emit usage events (API calls, messages sent, records processed)
• Send events to a durable queue (Kafka, SQS, or a simple database table) before processing
• Never meter synchronously in the request path. If your metering service is down, customer requests should not fail.

Stage 2: Aggregation

Roll up raw events into billable units on a schedule (hourly, daily, or at invoice time).

Implementation:

• Aggregate by customer, by billing period, by usage metric
• Store aggregated totals with enough granularity for the customer to audit (daily breakdowns, per-feature breakdowns)
• Run aggregation on a schedule (cron job) or on-demand (at invoice generation time)
• Reconcile aggregated totals against raw events periodically to catch drift

Stage 3: Billing

Apply pricing rules to aggregated usage and generate charges.

Implementation:

• Report usage to your billing platform (Stripe, Chargebee, or Paddle) via their API
• The platform applies pricing tiers, discounts, and credits
• Generate draft invoices for review (optional but recommended for large accounts)
• Finalize and send invoices on the billing cycle

Stage 4: Invoicing and collection

Send invoices and collect payment.

Implementation:

• Automated invoice delivery via email
• Payment collection via stored payment method (card, ACH, wire)
• Dunning workflows for failed payments (retry schedule, customer notifications)
• Usage alerts: notify customers when they approach tier boundaries or budget limits

Common pitfalls

Usage shock

Customers get a bill much larger than expected because usage spiked. This destroys trust.

Solution: Send proactive usage alerts at 50%, 80%, and 100% of their typical usage or budget. Let customers set spending caps. Offer committed-use discounts for predictable workloads.

Metering gaps

Events get lost between your application and your billing system. Customers are undercharged or overcharged.

Solution: Use durable message queues. Implement idempotency keys to prevent double-counting. Run daily reconciliation between your event store and your billing platform. Alert on discrepancies above a threshold.

Unpredictable revenue

Pure usage-based pricing makes revenue forecasting difficult, especially for early-stage companies that need predictable numbers for fundraising or budgeting.

Solution: Use hybrid pricing (base + usage) to create a predictable revenue floor. Track committed usage contracts. Build forecasting models based on usage trends by cohort.

Over-engineering early

Teams spend months building a custom metering and billing system when they have 50 customers. This is premature optimization.

Solution: Start with your billing platform's native metering. Report usage via API, let the platform handle aggregation and invoicing. Build custom infrastructure only when you outgrow the platform's capabilities (typically above 10,000 customers or when metering latency becomes critical).

How usage-based pricing enables PLG expansion

Usage-based pricing is the natural revenue model for product-led growth because it removes the need for a sales conversation at expansion time. When pricing is tied to usage:

• Users start free or cheap and expand naturally as they get value
• No upgrade decision is required until the user exceeds their current tier
• Expansion revenue is a lagging indicator of product value, not a result of sales pressure
• Land-and-expand happens automatically: a single team starts using the product, usage grows as more teams adopt it, and the bill scales with organizational value

If your product is PLG and you are still on flat-rate pricing, usage-based pricing is one of the highest-leverage changes you can make to accelerate expansion revenue.