SaaS Billing Models Explained: Per Seat, Usage, Tiered and Hybrid

SaaS products bill in four ways: flat plans (often tiered as Basic, Pro, Enterprise), per seat, by usage, or a hybrid of a base fee plus usage. Flat and per-seat need the least code, because the price only changes when a customer changes plan or headcount. Usage-based billing costs the most, because you must meter, store and reconcile every billable event. Hybrid combines both costs.

This guide is for founders and engineering leads deciding how to charge, and wanting to know what each choice commits the code to. The pricing strategy side, what to charge, is a business decision. This post is about what each model does to your system, with the mechanics taken from Stripe's pricing model documentation, since Stripe Billing is the tool most early SaaS teams reach for. The implementation walkthrough is in how to add Stripe billing to a SaaS.

What are the main SaaS billing models?

Stripe's documentation groups recurring pricing into four patterns. The fifth row, hybrid, is a combination of them rather than a separate Stripe model.

Model	How the customer pays	Good fit	Engineering cost
Flat rate	One fixed price per plan, such as Basic, Starter or Enterprise	Products where value does not grow much with team size or volume	Low: plan changes and feature gating
Per seat	A price per user, multiplied by the number of users	Collaboration tools, B2B apps where each employee logs in	Low to medium: keep the seat count in sync, handle proration
Tiered	The unit price changes as quantity or usage grows	Volume discounts for larger customers	Low on top of seats or usage; the pricing logic lives in Stripe
Usage-based	Pay for what you consume: API calls, messages, storage, compute	Infrastructure, APIs, AI features with real per-unit costs	High: metering, idempotency, reconciliation, customer-facing usage
Hybrid	A base fee or seats, plus usage or overage above an allowance	Products with a predictable core and a variable, costly extra	High: everything usage needs, plus plan logic

The engineering cost column is RAITHub's engineering judgement, not a Stripe figure. It reflects how much code outside Stripe each model needs.

How does per-seat billing work, and what does it take to build?

Stripe describes per-seat as a linear model "where the number of seats (for example, software licenses) maps to the number of units (for example, users)". In practice it is one price with a quantity on the subscription item: twelve seats at $10 is quantity: 12.

The code you write is the sync between your membership table and that quantity. When an admin invites or removes a user, update the subscription:

// Called after a member is added or removed, inside the same job that changed the membership.
export async function syncSeats(tenant: { stripeSubscriptionItemId: string }, activeMembers: number) {
  await stripe.subscriptionItems.update(tenant.stripeSubscriptionItemId, {
    quantity: Math.max(activeMembers, 1),
    // Default: credit and charge for the partial period on the next invoice.
    proration_behavior: 'create_prorations',
  })
}

The part teams underestimate is proration, meaning charging for part of a billing period. According to Stripe's proration documentation, changing a quantity triggers a proration by default, the default proration_behavior is create_prorations, and "negative prorations aren't automatically refunded and positive prorations aren't immediately billed". Its example: upgrading from a $10 plan to a $20 plan halfway through the month adds $5 to the bill. Decide up front whether seat changes bill immediately (always_invoice), at the next renewal, or not at all, and write it on the pricing page.

Two design questions to settle early: does a pending invitation use a seat, and can an admin buy seats in advance, or does the count always equal active users? Both change the sync logic.

What is the difference between volume and graduated tiered pricing?

Both lower the unit price as the customer buys more, but they apply it differently. Stripe's tiered pricing guide uses three tiers: 1 to 5 units at $7, 6 to 10 at $6.50, 11 and up at $6.

Units	Volume pricing (whole quantity at one tier's price)	Graduated pricing (each tier priced separately)
5	$35	$35
6	$39 (6 × $6.50)	$41.50 ($35 + $6.50)
20	$120	$127.50
25	$150	$157.50

Volume pricing has a quirk Stripe points out: because the tier price applies to the entire quantity, "the total might decrease" when a customer crosses a threshold. Five units cost $35, six cost $39, but under a steeper discount the sixth unit could make the bill smaller. Graduated pricing never does this, which is why it is easier to explain on an invoice.

Tiers can also carry a flat fee per tier. A zero-usage trap is documented too: Stripe "always bills the first flat rate tier when quantity=0", so if you want an idle customer to pay nothing, model the first tier as a unit price instead.

What does usage-based billing require from your code?

A reliable pipeline from "something billable happened" to "the invoice is right". This is where most of the engineering in SaaS billing goes.

First, know which Stripe product you are building on. As of September 2026, Stripe's usage-based billing documentation says Metronome, now part of Stripe, is "Stripe's primary usage-based billing platform, recommended for all new integrations", while basic usage-based billing on the Billing Meters API "remains fully supported for existing integrations". Stripe recommends Metronome for prepaid credits, enterprise commits and real-time usage visibility, and notes that Billing Meters "only reconciles usage at invoice time".

With Billing Meters, you send a meter event for each unit or batch of usage. Stripe's recording usage guide sets the rules your code must respect:

• Timestamps must be "within the past 35 calendar days" and no more than 5 minutes in the future. A batch job that falls a month behind loses billable usage.
• Rate limit: 1,000 meter event calls per second per account in live mode, and one concurrent call per customer per meter. Pre-aggregate rather than sending one call per click.
• Processing is asynchronous. Upcoming-invoice totals may lag recent events, so do not show customers Stripe's number as a live meter.
• Errors arrive later, as v1.billing.meter.error_report_triggered events. You need a handler for them, or bad events fail silently.

The core rule is to record usage in your own database first, then send it, with an identifier that makes a retry harmless:

// 1. In the same transaction as the billable action, write a usage row you own.
await db.query(
  'INSERT INTO usage_events (id, tenant_id, metric, quantity, occurred_at) VALUES ($1, $2, $3, $4, now())',
  [eventId, tenantId, 'api_requests', 1],
)

// 2. A worker sends hourly totals to Stripe. The identifier deduplicates retries.
await stripe.billing.meterEvents.create({
  event_name: 'api_requests',
  identifier: tenantId + ':api_requests:' + hourBucket,
  timestamp: Math.floor(hourStart.getTime() / 1000),
  payload: { stripe_customer_id: stripeCustomerId, value: String(hourlyTotal) },
})

Your own table is the source of truth. It lets you show customers live usage, answer "why is my bill higher?" with rows, and re-send anything Stripe rejected. Stripe's docs recommend idempotency so usage is not reported "more than one time because of latency or other issues".

When does a hybrid model make sense?

When part of your cost is fixed per customer and part grows with use. A common shape for B2B products with AI features: a per-seat plan that includes an allowance of AI actions, then overage per action. Stripe lists "fixed fee and overage, pay as you go, and credit burndown" as its usage-based patterns.

Hybrid is the most flexible and the most work. You need the seat sync, the metering pipeline, allowance tracking per billing period, usage alerts before customers hit overage, and an invoice a finance team can read. Start with it only if a variable cost, such as LLM tokens or SMS, would otherwise make heavy users unprofitable. The token side of that is covered in how to reduce OpenAI API cost.

What does Stripe Billing itself cost?

On top of payment processing fees, Stripe Billing's pricing page lists pay-as-you-go pricing of "0.7% of Billing volume" with no recurring fee, and annual plans for higher volumes that charge "0.67% for additional Billing volume" beyond the plan's threshold. At $20,000 a month of subscription revenue, pay-as-you-go Billing is about $140 a month.

Monthly billing volume	Stripe Billing fee at 0.7%
$5,000	$35
$20,000	$140
$100,000	$700

That fee is usually small next to the engineering cost of the model you pick. Sales tax and VAT on subscriptions depend on where you and your customers are; this is general information, so confirm your obligations with your tax adviser.

What goes wrong in SaaS billing, whatever the model?

• Webhooks. Your app learns about payments, failures and cancellations from Stripe webhooks. If they do not arrive or are not processed, access and billing drift apart. See Stripe webhook not firing and webhook returns 200 but the subscription is not updated.
• Entitlements scattered in code. Keep one function that answers "can this tenant use this feature?" from their current plan, rather than plan-name checks everywhere.
• Grandfathered prices. Stripe's pricing guides note that you "can only edit the product and price until you create a subscription with them", so a price change means a new price and a plan for existing customers.
• Untested time-based events. Renewals, trials ending and failed payments happen weeks apart. Test them with simulated time in a sandbox, not by waiting a month.

Why RAITHub for SaaS billing?

Because billing bugs cost real money on both sides, and RAITHub builds payment flows with tests around them.

• Stripe in production. PropDesk, a property management platform RAITHub built, collects rent through Stripe, with 1,024 automated tests.
• Multiple payment rails. TheSkinProof, the founder's own marketplace venture rather than a client project, integrates bKash, Nagad, SSLCommerz and cash on delivery.
• Fixed scope. A billing integration is well suited to a fixed written quote after the free 15-minute technical audit. See the SaaS development service and the multi-tenant SaaS guide.

When to use a tool instead

• Flat plans, early stage. Stripe Checkout and the customer portal cover plan selection and card updates with very little code.
• Complex usage and enterprise contracts. Stripe points new usage-based integrations at Metronome, so use it rather than building your own rating engine.
• You need pricing strategy. What to charge is a commercial question; RAITHub builds the system that charges it.

Choosing a billing model, or untangling one that has drifted? Tell RAITHub how you charge today and what you want to charge, and book the free audit.

Last reviewed: 29 September 2026. Stripe behaviour and prices from Stripe's documentation and pricing page on that date.

Frequently asked questions

What is the most common SaaS billing model?

Flat-rate plans and per-seat pricing, often combined as tiered plans priced per user. They are also the simplest to build, because the bill only changes when a customer changes plan or headcount.

Is usage-based billing harder to build than per-seat?

Yes. Per-seat needs a seat count kept in sync with your users. Usage-based needs metering, a usage table you own, idempotent reporting to the billing system, error handling and a way for customers to see their usage.

What is the difference between volume and graduated pricing?

Volume pricing charges the whole quantity at the price of the tier it lands in. Graduated pricing charges each tier's units at that tier's price and adds them up. In Stripe's example, 6 units cost $39 with volume pricing and $41.50 with graduated.

How much does Stripe Billing cost?

Stripe's pricing page lists pay-as-you-go Billing at 0.7% of billing volume with no recurring fee, on top of payment processing fees. Annual plans for higher volumes charge 0.67% on volume above the plan's threshold.

Does Stripe prorate seat changes automatically?

By default, yes. Changing a subscription item's quantity creates proration items, but they are added to the next invoice rather than charged immediately. Use always_invoice to bill at once, or none to skip proration.

Should I use Stripe Billing Meters or Metronome for usage billing?

For a new integration, Stripe's documentation recommends Metronome, now part of Stripe. Billing Meters remains fully supported, and Stripe suggests staying on it mainly if you already bill customers through it.