Usage-based pricing has become the most common approach for businesses that deliver software via public or private cloud or embedded deployments. As of 2026, 74% of suppliers had adopted usage-based models, and 56% expected usage-based revenue to grow by 2027.

A usage-based pricing strategy might sound simple, but the execution involves a chain of compounding decisions. The value metric you pick shapes your packaging. Your packaging shapes your pricing page. Your pricing page shapes how customers interpret their bills. And how customers interpret their bills determines whether your migration goes smoothly or generates a wave of cancellations and support tickets.

Below, we’ll cover how to choose a value metric, how to design a pricing page that explains the model, and execution mistakes that can sink otherwise solid usage-based pricing launches.

Highlights

• Choosing the right value metric is key. A metric customers can’t predict or control can undermine the model regardless of how well you execute everything else.

• Sequencing your migration matters: new customers first, opt-in migration next, segment-by-segment rollout after that.

• Bill shock is a product problem. Spend caps, in-product usage visibility, and proactive notifications should ship with your pricing.

What is usage-based pricing for SaaS?

Usage-based pricing for software-as-a-service (SaaS) (i.e., subscription-accessed software) means customers pay based on what they consume rather than a flat fee for access. Usage-based SaaS pricing is the model behind Twilio, which charges per message sent; Snowflake, which charges per credit; and many artificial intelligence (AI) application programming interfaces (APIs), which charge per token.

What value metric should you choose for usage-based pricing in your SaaS product?

Your value metric for usage-based pricing is the unit of measurement that determines how a customer pays. Everything else in your pricing flows from this choice.

A good metric has three properties:

• Scales with value: The amount increases as a customer uses your product more. For example, a customer processing 500,000 records pays more than one processing 5,000.

• Legible before signup: Customers can estimate their bill using information they already have without having to seek other input.

• Clearly measurable: You can show customers how you calculated the cost of your service.

Strong metrics in SaaS usage-based pricing and AI products tend to be API calls, active users, records processed, gigabytes (GB) stored or transferred, agent actions completed, and tokens consumed.

Metrics that tend to fail include:

• Internal compute units: If you’re billing per “processing unit” that customers can’t observe or control, you might encounter customer confusion and pushback at renewal.

• Metrics that grow without corresponding value: Billing per database row seems easy until customers realize row counts inflate from routine background operations they don’t consider product usage.

• Metrics customers can’t control: If the number increases based on your system’s behavior rather than customers’ deliberate actions, you can erode confidence fast.

If a customer can’t estimate their monthly bill quickly using only information they already have, reconsider the metric.

How does usage-based pricing work once you’ve chosen your metric?

SaaS usage-based pricing requires three factors to function: metering (e.g., accurately counting usage at the event level), rating (e.g., converting raw usage into a dollar amount), and invoicing (e.g., presenting the bill and collecting the payment).

Once you’ve chosen your metric and metered its usage, rating can take three forms:

• Per-unit flat: Each unit costs the same regardless of volume. This is simple to explain and works well when your customers’ usage stays steady.

• Volume-tiered: The price per unit drops as consumption crosses thresholds. For example, the first 10,000 calls are priced at $0.002 per call and the next 90,000 at $0.0015. Your biggest customers are rewarded with lower per-unit costs, which is standard in infrastructure-style products.

• Graduated: Each tier’s rate applies only to the units n that tier. Customers always pay the marginal rate for each block of usage rather than a single blended rate.

Stripe’s billing infrastructure can handle all three models, which frees up finance and engineering teams that would otherwise build rated invoices from scratch. Pick the model that matches how value scales in your product: flat for simplicity versus tiered or graduated when you want volume discounts to potentially drive expansion.

How should you package usage-based pricing offers?

Pay-as-you-go (PAYG) can mean unpredictable revenue for you and unpredictable bills for your customers. Many products that mature beyond the developer-tool phase use a hybrid model, which means a base subscription covering some included usage and overage charges when customers exceed that usage. The base provides predictable, recurring revenue, while the overage captures expansion as customers grow.

Regardless of which model you choose, these four predictability tools are worth including from the start:

• Free tier or trial credits: A fixed amount of usage before usage-based billing starts. This is common in AI APIs, where something like $5–$10 in credits lets developers test.

• Spending caps: A hard ceiling set by customers on their monthly bill. Below the cap, the product works normally, but at the cap, you pause usage or prompt a notification to upgrade. This is common for developer tools, where a runaway script can generate a $4,000 bill when the customer expected $40.

• Committed use discounts: Customers commit to a usage floor in exchange for a lower per-unit rate. This is good for enterprise customers who are willing to pay for budget certainty.

• Bundles: Prepackaged usage volumes sold at a discount versus PAYG. This might look like “10,000 calls for $15” versus $0.002 per call. These work well for customers who can forecast usage and want predictability without a formal commitment.

How should you sequence your usage-based pricing migration without churning your existing base?

If you’re moving an existing product to usage-based pricing rather than launching a new product entirely, the migration can be a challenge. Note these options:

New customers first

Consider launching usage-based pricing for all new signups while existing customers stay on their current plans. Use that strategy for at least 60–90 days before affecting your existing base. You need real data on conversion rates, average spending, and bill-shock complaints before you commit to a broader rollout.

Opt-in migration next

Invite existing customers to switch voluntarily, perhaps with an incentive such as a temporary rate discount or bonus credits. Frame it as early access. The customers who opt in first are often your most engaged users, and they’ll tell you what’s confusing before you change the process on everyone else.

Segment-by-segment rollout

When you move to mandatory migration, start with your smallest or lowest-risk cohort, such as monthly subscribers on your lowest tier who have less to lose and much to gain from PAYG flexibility. Don’t start with your largest accounts.

Carefully transition your highest-risk accounts

For annual subscribers in the middle of their contracts, honor existing pricing through their renewal date. For customers whose bills would increase significantly, offer credits that ease the transition over one or two billing cycles. Check your contract terms because B2B SaaS agreements might require notice periods for substantial pricing changes.

Set a hard cutoff

If your migration will take six months, announce early and send reminders at 90, 60, and 30 days out. Make the end date nonnegotiable. Open-ended migrations can drag on indefinitely and create a two-tier pricing mess that’s difficult to resolve.

What customer communication assets should you develop during a usage-based pricing launch?

The quality of your communication helps determine how much support volume you need to handle. You should have these three assets ready before you announce the changes:

The announcement email

Tell customers exactly what’s changing. Name the metric, the per-unit rate, and a date for the change. Include an example of the change in their terms, such as providing an estimate of what their bill would be at the new rate, and a link to a usage estimator. Even a simple slider can substantially reduce support tickets. If you’re using Stripe, you might already have customers’ historical metering data, so the estimate would be accurate.

The ‘what’s changing’ page

You need a pricing page that explains how billing will change from the previous pricing model. This can live in your help center and cover the metric definition, your pricing table, and example bills at three usage levels.

At a minimum, the FAQ section should answer these questions:

• “What if I exceed my included usage?”: Spell out exactly what happens, including overage rate, a notification, or a cap.

• “Can I set a spending limit?”: If you’ve integrated spending caps, let customers know. If you haven’t, expect this question in support.

• “Will I be notified before my bill increases?”: Describe the exact prompt (e.g., 80% of cap, $X threshold, or end-of-cycle summary).

• “What happens to my current contract?”: Detail terms during the transition, renewal dates, and any bridging credits explicitly.

Your CSM and sales script

A dedicated customer success manager (CSM) can handle objections to a higher, variable bill, which many customers find difficult to budget for. To counter these issues, the CSM can show customers their usage trend and what that growth would cost under the new model. Clarify that bills go up when usage goes up, which means they’re getting more value. Discuss committed use agreements or bundles, both of which give customers the predictability they’re asking for without locking you into flat-rate economics.

What mistakes should you avoid when launching usage-based pricing?

Usage-based pricing launches can fail because of avoidable execution gaps.

Look out for:

• Choosing an unpredictable metric: Customers might churn if they can’t estimate their bill before signing up. Select the right metric before building other parts of the pricing model.

• Launching without spending caps: Spending caps are a basic trust mechanism. Without them, you risk public complaints and lost accounts.

• Migrating all customers at once: You don’t want to discover a problem only after it’s affecting your entire base. Sequencing the migration prevents that.

• Underinvesting in the pricing page: A usage-based pricing page must explain the metric, show example bills, and address predictability concerns before the customer has to ask.

• Treating bill shock as a support problem: Treating unexpectedly large bills on a case-by-case support basis masks a product problem, such as missing notifications, no spending visibility in the product, and no caps. Fix the product first.

• Skipping post-launch improvements: Some metrics that tell you the launch is working include conversion rate on usage-based pricing plans versus your prior flat rate, expansion revenue from overage, churn rate in the 90 days post-migration, and billing-related support ticket volume. If ticket volume increases significantly after launch, your communication or pricing page isn’t working.

How Stripe Billing can help

Stripe Billing lets you bill and manage customers however you want—from simple recurring billing to usage-based billing and sales-negotiated contracts. Start accepting recurring payments globally in minutes—no code required—or build a custom integration using the API.

Stripe Billing can help you:

• Offer flexible pricing: Respond to user demand faster with flexible pricing models, including usage-based, tiered, flat-fee plus overage, and more. Support for coupons, free trials, prorations, and add-ons is built in.

• Expand globally: Increase conversion by offering customers’ preferred payment methods. Stripe supports 100+ local payment methods and 130+ currencies.

• Increase revenue and reduce churn: Improve revenue capture and reduce involuntary churn with Smart Retries and recovery workflow automations. Stripe recovery tools helped users recover over $6.5 billion in revenue in 2024.

• Boost efficiency: Use Stripe’s modular tax, revenue reporting, and data tools to consolidate multiple revenue systems into one. Easily integrate with third-party software.

Learn more about Stripe Billing, or get started today.