Usage-based pricing for SaaS: how it works, real examples and when it fits

Usage-based pricing charges customers for what they consume, measured over a billing period. It’s also called consumption-based or pay-as-you-go pricing. API calls, messages sent, gigabytes stored and tokens processed are the usual units.

I implement usage-based pricing for many clients and steer just as many away from it. It’s useful because a usage metric can often get you quite close to the outcome your customer is paying for, and the closer your price sits to that outcome, the more money you make over time. But whether it fits depends more on your customer than on you. The question is whether they’ll accept a variable bill and whether they’re already used to paying this way.

Most guides to usage-based pricing in SaaS are written by companies that sell usage billing software, so they read as if the model fixes growth. This one covers how the model is structured, which companies use it today, what it does to your revenue and how to tell whether it fits you.

What is usage-based pricing?

Usage-based pricing is a pricing model where the bill is a price per unit multiplied by the units a customer consumed. Twilio charges $0.0083 per SMS segment in the US. AWS Lambda charges $0.20 per million requests plus a rate for compute time. A customer who sends 40,000 messages in March and 90,000 in April gets two very different invoices for the same product.

“Consumption-based”, “pay-as-you-go”, “metered” and “pay-per-use” pricing all describe the same idea. Where people do draw a line, “pay-as-you-go” usually means no commitment at all, and “consumption” is the word infrastructure and data companies use, often for deals where the customer commits to a spend and draws it down.

Two things get called usage-based pricing that aren’t:

• Tiers sized by contacts or records. An email tool that charges by the size of your contact list is charging for capacity. The bill doesn’t move with what you send.
• Seats with a usage limit attached. The seat is the unit you pay for. The limit only fences off the plan.

The unit you meter is a value metric like any other. You have to be able to measure it, customers have to think it’s fair to pay for, and it has to grow as they get more out of the product. A usage metric that fails those tests is no better than a bad seat price.

How a usage-based pricing model is structured

Pay-as-you-go is only one of five ways to build a usage-based pricing model. The other four exist because pure pay-as-you-go leaves both sides guessing at the bill.

Outside infrastructure, pure pay-as-you-go is generally rare. Most SaaS companies described as usage-based run one of the other four, because each one puts back some of the predictability that pay-as-you-go takes away.

Usage combines with tiers too

Usage also works alongside the rest of your pricing, including packaging. One client of mine, a North American automotive software company, sells a parts ordering tool priced per order. In the repricing I ran for them, we built a higher tier where each order comes back with richer data that’s hard to source and that their heaviest users wanted. The price per order on that tier is 50% higher. Over 30% of new customers chose it.

The meter didn’t change. Customers still pay per order. The tier changed what each order is worth, so customers who get more out of every order pay more for it.

Usage-based pricing examples

These twelve companies all have usage in their pricing.

Two things stand out. Pure pay-as-you-go sits in infrastructure, payments and APIs. Every product sold to a business buyer outside that group has a floor of some kind, whether that’s a base fee, a plan or a seat. And most of them now ship a way for the customer to limit the bill.

Why usage-based pricing works: it gets you closer to the outcome

Usage-based pricing works when the metered unit sits closer to your customer’s outcome than the alternative does. Map their value chain from the moment they sign up to the result they came for, and look at where your price attaches. Attach it early, at setup, and you’re a cost they work to control. Attach it near the outcome and you’re sharing in what they made.

A seat usually sits at the start of that chain. Someone gets access and nothing has happened yet. A usage unit often sits further along: a message delivered, an order placed, a document processed. If usage gets you closer to the outcome than a seat does, it’s the better metric. I cover how to map the chain and test each candidate in my guide to finding your SaaS value metric.

In practice that gets you:

• A cheap first purchase. There’s no commitment, so a customer can start small and see whether the product works for them.
• Expansion without a renegotiation. The bill grows as the customer grows, and nobody has to book a call to make it happen.
• A price that moves with your cost to serve. This matters most in AI products, where one heavy user can cost many times more to serve than the next.

There’s a limit. Plenty of usage metrics sit nowhere near the outcome. They’re cost-plus meters at the inputs end of the chain. A cloud provider sells compute without caring whether your business is profitable. It supplies the fuel whether you drive a Beetle or a Ferrari. That’s fine for infrastructure, where buyers expect to pay for the capacity they use. For an application, a meter that only tracks your own costs gives the customer a reason to use you less.

When does usage-based pricing fit? Start with your customer

Whether usage-based pricing fits depends more on your customer than on your product. Two questions decide it:

1. Will your customers accept a variable bill?
2. Are they already used to paying this way?

If you sell infrastructure, both answers are yes. Buyers have paid by the unit for cloud and telecoms for years, and they can see why your cost moves with their usage.

Usage generally works better in B2B than in B2C, because consumers generally want predictability. There are exceptions. Take a laundromat. You accept paying per wash, both because that’s how you expect to pay and because you understand there’s a cost to running the machine: the electricity, the water, the detergent, and the time in which someone else could have used it.

For everyone else it depends on who is buying. I’ve watched usage models break in four situations.

Buyers on a fixed budget

Some buyers can’t take a variable bill however good the product is. I advised a company building marketing software for shopping malls that wanted to charge on footfall. The mall’s marketing department turned it down immediately. Their budget was a fixed percentage of the rent the stores paid. Even if the software doubled footfall, it would take three to five years to renegotiate rents and grow that budget. The software’s success would have bankrupted the department paying for it.

Government tenders and oil and gas projects work the same way. They need a predictable total cost for the length of the project and will decline a usage model outright.

Buyers who don’t control the usage

In larger companies the person who pays is rarely the person who uses the product. Procurement buys a tool and hands it to the developers, the developers start hammering the API and the bill spikes. Sometimes the usage isn’t even human, because third-party software is triggering the calls.

Figma shows the same flaw in a seat model. Until March 2025, seat upgrades in Figma were “driven by user actions”, with admins reviewing them afterwards, before the next bill. Anyone could hand out edit access and the company paid for it. Figma changed the model so that any upgrade that costs money needs an admin’s approval first.

Seasonal demand

Usage revenue follows your customers’ calendar. If their business peaks around Black Friday and Christmas and goes quiet over the summer, your revenue does the same. That’s survivable if you have the balance sheet to get through the quiet months. If you don’t, a pure usage model is dangerous.

Units that are sometimes valuable and sometimes not

Usage breaks when one unit is worth a lot to a customer on Monday and almost nothing on Tuesday. Take a legal app that uses AI to scan contracts and charges per scan. On a $1M deal, a few dollars a scan is fine and nobody minds. On a routine NDA the same few dollars feels like a tax, so the customer stops scanning the small stuff.

Once that starts, customers cut back, then bundle or filter what they send you to dodge the fee. They use the product less and ask for a discount anyway. The fix is a consistent value metric, one where each unit is worth roughly the same to the customer as the last. This is also called pricing density. If your unit fails that test, you have the wrong value metric to begin with, and a lower unit price won’t fix it.

A quick test

As with every pricing model, choose the one that fits. Never go usage because you want usage. A trend only helps in one way: customers who already pay this way elsewhere find it easier to accept from you. That’s worthless if the model doesn’t fit your product.

How will usage-based pricing impact your revenue predictability?

Usage-based pricing makes your revenue variable. Under a license, a customer who buys ten seats pays for ten whether they use eight or none. Under usage, revenue follows what customers did that month, and it moves in both directions.

Snowflake is the clearest public example. In May 2023 it cut its product revenue growth guidance for the year from 40% to 34% after customer consumption slowed in April. The stock fell 16% the next day, and its CFO told investors he couldn’t point to a single cause.

The upside comes from the same mechanism. OpenView’s benchmarks put median net revenue retention at 125% for usage-based companies against 115% for subscription peers. That sample leans on venture-backed infrastructure companies during good years, so read it as what’s possible when customers are growing. The expansion that happens automatically also reverses automatically.

Vendors buy predictability back in three ways:

• A base fee or minimum. It sets a floor under every account.
• Committed spend with drawdown. The customer commits to an annual number that finance can forecast.
• Prepaid credits. The cash arrives before the usage does.

Each one gives up some of the pure usage upside in exchange for a steadier number.

Licenses even out revenue. But the closer your price sits to the value customers get, the more money you make over the long run, and usage is often how you get closer. That’s why I still recommend usage where the customer test passes.

Fundraising is where the variability costs you most. In my experience, selling the promise of future usage works at pre-seed and Series A. By Series B, investors look at revenue, growth and net retention, and they don’t much care which pricing model produced them. If you haven’t built a reliable history by the time you reach $5M to $10M ARR, raising later rounds gets hard.

Where usage-based pricing goes wrong

Most public usage pricing failures come from how the model was run. Three patterns come up again and again.

Bill shock

In February 2024 a developer with a free static site on Netlify got a bill for about $104,500. A DDoS attack on a single audio file had generated roughly 190 TB of data transfer. Netlify offered to cut the bill to 20%, then to 5%, and the CEO eventually waived it.

Hosting companies have since built the controls that story was missing. Vercel gives new Pro teams a default $200 budget, sends alerts at 50%, 75% and 100% of it, and can pause every project when the budget is reached. Supabase switches its spend cap on by default. PostHog lets you set a billing limit per product.

A rollout that changes the deal

In June 2025 Cursor replaced the 500 fast requests a month on its Pro plan with $20 of usage at API rates. Users ran through the $20 far faster than they expected and found charges they hadn’t seen coming. The CEO apologized for mishandling the rollout and the company said it would refund affected users.

Usage may well have been the right model for Cursor’s costs. The damage came from customers finding out what the change meant from their invoice.

A metric the customer can’t control

In September 2023 Unity announced a runtime fee of $0.01 to $0.20 per game install, applied to titles that had already shipped. Developers can’t control installs, and Unity was estimating the numbers from its own telemetry. After a developer backlash, Unity cancelled the fee on 12 September 2024 and raised seat prices instead, by 8% on Pro and 25% on Enterprise.

Guardrails to ship before the meter

• A budget or cap the customer sets. Let them choose between a hard stop and an alert.
• Alerts before the limit. Send them at 50% and 75%, well before the invoice.
• A live usage dashboard. The customer should see where the units are going.
• A forecast. Show what the bill will be at the current pace.
• Shadow billing before launch. Track the metric in the background and work out what current customers would have paid before you announce anything.

Credits: the middle path if the drawbacks worry you

Credit-based pricing is usage-based pricing paid up front. The customer buys a balance of credits and each action in the product spends some of them. If you like what usage does for value and worry about what it does to predictability, credits are the model to look at.

Implemented well, credits give you more stability and keep the upside of usage. They’re spreading fast. Of the 500 companies in the PricingSaaS 500 Index, 79 now offer a credit model, up from 35 at the end of 2024, according to Growth Unhinged in January 2026.

“Implemented well” covers four things:

1. Simple math. Keep the exchange rate obvious, such as $1 for 1 credit or $1 for 100.
2. Visibility. A dashboard that shows where credits are going and a forecast of when they’ll run out.
3. Expiry that isn’t punishing. Credits should expire, but slowly. My default is a 24-month life.
4. Controls. Admins and finance can cap who spends credits and how many.

Get those wrong and nobody can work out what a credit buys, at which point procurement starts treating credits as a hidden markup. I go through the mechanics in how credit-based pricing works.

Credits are also the model I’d least recommend designing alone. The exchange rate, expiry and renewal terms all affect each other, and mistakes are expensive to undo once customers are holding balances. It’s a large part of what I do at Potio, my pricing consultancy for SaaS and AI companies.

What usage-based pricing software do you need?

Usage-based pricing software does three jobs: metering (recording every billable event accurately), rating (turning those events into amounts using your prices) and billing (invoicing and collecting payment). You have four ways to cover them.

• Your payment or subscription billing platform. Stripe Billing, Chargebee and Maxio all handle usage alongside subscriptions.
• A usage billing specialist. Metronome, Orb and m3ter are built for high event volumes and complicated rate cards.
• Open source. Lago can be self-hosted if you need to keep billing data in your own infrastructure.
• Building it yourself. This costs more than teams expect. Late events, duplicates and corrections are where home-built metering loses money.

The specialist category consolidated fast. Stripe completed its acquisition of Metronome in January 2026. In June 2026 Adyen agreed to buy Orb for $335M and Salesforce signed an agreement to acquire m3ter. Check who owns a vendor, and which payment stack it now favours, before you commit to one.

For a small company, start with the usage features of the platform you already take payments through. Move to a specialist when your rate cards or event volume outgrow it.

Should you use usage-based pricing?

Usage-based pricing is worth it when the metered unit sits close to your customer’s outcome and your customers will accept a variable bill. Start with the two customer questions. If both pass, pick the structure that gives each side enough predictability and ship the guardrails before the meter. If they don’t pass, look at credits, or stay with the model that fits.

Frequently asked questions

Is usage-based pricing the same as consumption-based pricing?

Mostly, yes. Both bill on measured usage, and most companies use the two terms interchangeably. “Consumption-based” is more common in infrastructure and data, often for contracts where the customer commits to a spend and draws it down. “Pay-as-you-go” usually means usage with no commitment at all.

What are some examples of usage-based pricing?

Twilio charges $0.0083 per SMS segment in the US. AWS Lambda charges $0.20 per million requests plus compute time. Stripe takes 2.9% plus 30¢ per successful domestic card charge. Resend charges $20 a month for 50,000 emails and $0.90 per extra 1,000. Zapier sizes its plans by tasks per month and bills per task beyond the limit. All five were checked against the companies’ pricing pages in October 2026.

Can you combine usage-based pricing with a subscription?

Yes, and most SaaS companies with usage in their pricing do. Vercel’s Pro plan is $20 a month and includes $20 of usage credit, with pay-as-you-go beyond it. Intercom charges per seat and adds Fin from $0.99 per outcome. The fixed part gives the vendor a floor and the buyer a predictable minimum, and the usage part grows with the customer.

How does usage-based pricing affect revenue growth?

Revenue grows without a renegotiation as customers use more, which is why usage-based companies often report higher net revenue retention. OpenView’s benchmarks put the median at 125% against 115% for subscription peers. The same mechanism works in reverse when customers cut back. Snowflake lowered its growth guidance from 40% to 34% in May 2023 after consumption slowed.

What is the best usage-based billing software for a small business?

For most small companies it’s the usage features of the platform they already take payments through, such as Stripe Billing or Chargebee. Specialists like Metronome, Orb and m3ter are built for high event volumes and complex enterprise rate cards. Lago is the open source option if you want to host billing yourself.

When should you not use usage-based pricing?

Avoid usage-based pricing when your customers are consumers who want a predictable bill, when they buy on a fixed budget, when the person paying can’t control the usage, when your revenue would swing with the seasons and you can’t carry the quiet months, or when some of a customer’s units are valuable and others are nearly worthless, which means the value metric is wrong. In those cases look at credits, a hybrid with a base fee, or a license.