Usage-based pricing: models, public examples and how to choose a value metric

Usage-based pricing charges customers for how much of a product they use, such as messages sent, requests processed or payments handled, instead of a flat fee per seat or per month. It works best when the unit you charge for, often called the value metric, rises and falls with the value the customer gets. Choosing that unit is a research question: you need to learn how customers measure their own results, how they budget, and how much a surprise bill would hurt.

Common usage-based models, with public examples

We read these pricing pages on September 30, 2026. Prices change, so check the live pages.

Pay per unit. Every unit has a price. Twilio's US SMS pricing lists $0.0083 per outbound or inbound SMS segment on long codes, toll-free numbers and short codes, and notes that carrier fees are added on top, depending on the destination network. The customer's bill follows the number of messages.

Several meters plus a free allowance. AWS Lambda charges for requests and for compute time measured in GB-seconds (memory multiplied by run time). Its page lists $0.20 per million requests and a monthly free tier of one million requests and 400,000 GB-seconds. The free allowance lets people build and test before they pay anything.

A percentage of the transaction. Stripe's pricing page lists 2.9% + 30¢ per successful transaction for domestic cards, with no setup or monthly fees. Stripe earns more when its customer sells more, which ties the price closely to the customer's own results.

A subscription with usage on top. Many seat-based products add a metered part. Notion's pricing page sells plans per member and prices its Custom Agents separately at $10 per 1,000 monthly Notion credits after a free trial. GitHub's plans include a monthly allowance of CI/CD minutes that grows with the tier, and its Codespaces compute starts at $0.18 an hour.

Billing software supports these models directly. Stripe's usage-based billing documentation calls usage-based billing a common pricing model for SaaS businesses and lists features such as prepaid credits, usage alerts and tiered pricing.

What makes a good value metric

A good unit passes four tests:

1. It rises when the customer gets more value. Stripe's percentage grows with the customer's sales. A per-seat price for a tool one person runs for the whole company does not.
2. The customer can predict it. Finance teams need to budget. A unit they already track, such as orders or invoices, is easier to forecast than one they have never measured, like API calls.
3. The customer can control it. People accept a bigger bill when it follows something they chose to do. A bill that jumps because of a background process feels unfair.
4. You can measure it accurately. If you cannot count the unit reliably and show customers the count, disputes follow.

These tests often conflict. The unit that tracks value most closely, such as money saved, may be the hardest to measure and predict. Most companies settle on a close stand-in that customers already count.

A worked example: an invoice-processing API

Suppose you sell an API that reads supplier invoices and extracts the line items for accounting teams. You are choosing between per-seat pricing, per-invoice pricing and a monthly plan with an invoice allowance. This example is hypothetical, and so are its numbers.

At $0.40 per invoice, a customer processing 2,000 invoices a month pays 2,000 x $0.40 = $800. If the same customer processes 6,000 invoices at year-end, that month costs 6,000 x $0.40 = $2,400, three times the usual bill. Whether that is acceptable depends on how the customer budgets, which only they can tell you.

Questions to ask accounting leads and the people who approve software spending:

• "How do you count invoices today, and do you know last year's monthly numbers?" This checks whether they can predict the unit.
• "What happens in your busiest month?" This shows how much the bill would swing.
• "How did you budget for the last tool you paid for by usage?" A real past purchase is better evidence than a hypothetical reaction.
• "If your bill doubled in one month, who would notice and what would they do?" This shows whether you need caps, alerts or prepaid bundles.
• "Would you rather pay a fixed amount that covers most months, with a charge for extra invoices?" This tests a hybrid plan.

Suppose the interviews show that finance teams know their invoice volumes, dislike surprises and approve annual budgets. That points toward a monthly plan with an included allowance, for example 2,500 invoices for $900, and a per-invoice rate above that, plus an alert when a customer nears the limit. Test the numbers themselves with real quotes; how to research willingness to pay covers that step.

When usage-based pricing fits and when it does not

It fits when usage varies a lot between customers, when small customers need a cheap way to start, and when your costs rise with usage, as with messaging, compute or payments.

It fits less well when customers cannot predict usage and hate variable bills, when usage and value are only loosely linked, or when heavy use would make customers avoid the product. If a team starts rationing a collaboration tool to save money, the price is working against adoption.

Hybrid plans exist for these reasons: a subscription gives predictability, and the metered part captures the value from heavy users.

Your next step

List three candidate units for your product and score each against the four tests. Then pull usage data for your current customers and see how much the bill would vary by customer and by month under each unit.

If you need to check your unit with people who budget for this kind of software, Instant Expert can find people who match a description you write, such as "accounts payable managers at mid-size companies." You review who it finds, it sends your invitations, and you pay only for calls that get booked. The directory pages for finance professionals in enterprise SaaS and product professionals in financial technology are one place to start.