Some customers barely touch your product. Some rely on it every day.
If you are charging both the same flat fee, one side will feel overcharged, and the other will feel capped.
The solution here is the pay-as-you-go (PAYG) pricing model, as it aligns cost with activity. Customers pay for what they actually use. There are no bundled limits or guesswork about future demand.
For SaaS and AI teams, PAYG offers a direct link between product usage and revenue. Still, the idea is simple, but running it well requires clear metering and strong control over access and billing.
This guide breaks down how PAYG works, where it fits, and what it takes to operate it reliably.
The pay-as-you-go pricing model charges customers based on measured usage, so the invoice equals rate × metered usage during a billing period.
PAYG billing calculates charges with a single meter (usage × rate) or multiple meters where each meter has its own rate, and the invoice totals the line items.
PAYG fits best when you can define a clean unit, meter usage reliably per account, and support hybrid pricing and hybrid selling without forcing plan migrations.
Running PAYG well requires reliable metering, plan, and entitlement control, and runtime enforcement; tools like Schematic help teams keep usage, access, and billing aligned without hard-coding logic.
The on-ramp is the simplest form of usage monetization: pay-as-you-go. A PAYG pricing model charges based on measured consumption instead of a fixed commitment. Users pay only for what they use, rather than a recurring fee tied to a subscription plan.
You pick a unit, set a public rate, and meter what each account consumes during the billing period (typically monthly). The invoice reflects usage multiplied by the rate for that unit. The bill equals rate × metered usage.
The pricing structure stays simple. Each unit has a clear price. The payment model does not require high upfront costs, long contracts, or bundled subscription fees.
A PAYG model can use a single meter or multiple meters. A single meter tracks one unit, such as API calls or compute minutes. Multiple meters track different units and price each one separately, then sum them into one invoice.
PAYG billing is simple because the math is simple. You track usage, apply a rate, and invoice for what the account consumed during the billing period.
With a single meter, the formula is:

You measure one unit, such as API calls or compute minutes. Each usage event increments the total. At the end of the billing period (typically monthly), you multiply total resource usage by the published rate to calculate usage costs.
Multiple meters follow the same logic. The formula becomes:

You might charge separately for compute time, storage, and data transfer. Each meter has its own rate. The invoice adds them together.
Accurate metering supports transparent pricing and reduces unexpected costs. You can define usage thresholds or usage limits to prevent runaway costs. Clear tracking also improves cost management and leads to fewer billing disputes.
Below are everyday PAYG scenarios:
A single meter tracks one measurable unit. The bill equals total usage multiplied by one rate. For example:
Traditional gas pump – The meter measures gallons (or liters). The station posts a price per gallon, and the total equals gallons × price. If you pump 10 gallons at $4 per gallon, you pay $40.
City parking apps – The meter measures time parked. You select how long you want to park, and the app charges the posted rate per hour for that zone. Two hours at $3 per hour results in a $6 charge.
API usage in SaaS products – The meter tracks API calls. You set a rate per 1,000 calls. If a customer makes 200,000 calls in a month, the bill reflects 200 units at the posted rate. Many developer tools and AI platforms use this model.
Cloud storage – Many cloud providers price cloud storage per GB stored. If a customer stores 500 GB and the rate is per GB, the bill reflects that exact amount of usage. Most cloud computing services price individual cloud resources this way.
Multiple meters track more than one unit at the same time. Each unit has its own rate, and the invoice adds them together.
Ride-hailing – Price combines time and distance for the trip:

If the ride lasts 20 minutes and covers 10 miles, both measurements contribute to the final charge, along with required taxes and fees.
Home utilities on one bill – Electricity and gas run on separate meters. Electricity charges per kWh, and gas charges per BTU. Each line item calculates independently, and then the total appears on one invoice.
AI model usage – In many AI products, one meter tracks input tokens while another tracks output tokens, and the invoice equals:

Many AI products price computing power this way because input and output consumption differ.
The structure stays consistent whether you are buying fuel, sending API requests, or consuming cloud infrastructure: measure the unit, apply the rate, and sum the totals.
PAYG matches how modern products are used because activity is uneven, value is variable, and SaaS companies want low-friction adoption that reflects real customer behavior. It stays simple to explain, quick to ship, and it scales naturally with customer demand.
Many teams building software-as-a-service adopt PAYG to support diverse usage patterns without forcing rigid contracts.
You define a unit, set a rate, and connect usage tracking to billing, which lets you go live without building complex hybrid pricing models upfront.
Engineering instruments the meter, product defines the unit, and RevOps connects it to Stripe, so the model supports real business needs without slowing release cycles.
Customers pay only for what they consume, which lowers the commitment barrier compared to flat-rate pricing or long-term contracts.
The structure feels familiar because it mirrors phone plans and other on-demand services, which helps new accounts get started without procurement delays.
When usage increases, invoices grow without plan migrations, so expansion happens naturally instead of relying on plan upgrades. That structure supports higher lifetime value, reinforces customer retention, and creates a direct link between product activity and revenue.
You can later layer in minimum commitments or a credit-based system while preserving the PAYG core, which creates a path toward more predictable recurring revenue.
Because usage is metered directly, you see what customers consume and what they pay, which supports improved cash flow management and cleaner revenue reporting.
You can adjust infrastructure or pricing with exact usage numbers, giving you direct visibility into margin per unit.
Your value maps cleanly to a countable unit or a small set of units, such as API calls, tokens, compute minutes, or GB stored, which keeps metering simple and billing logic clear.
Customers show varying usage patterns, and you want prices to follow actual activity instead of pushing everyone into a fixed subscription model with the same limits.
You want fast price discovery and the ability to adjust rates without migrating customers between complex tiered pricing plans.
Procurement stays lightweight, or customers accept variable invoices while you define usage limits or usage thresholds to control exposure and support predictable costs based on expected usage.
You can instrument a reliable meter, attribute usage to the correct account, and connect that data to billing so invoices reflect real product activity.
PAYG also works well inside hybrid models where you later introduce minimum commitments, prepaid plans, or fixed contracts for customers who need more predictable costs, while keeping usage as the core driver of expansion.
Pay-as-you-go is simple on paper and powerful in practice. You pick a unit, set a rate, and meter usage so revenue follows real product activity. Many SaaS and AI teams start here because it lowers friction for new customers and scales naturally as usage grows.
The challenge is not the formula but everything around it.
Plans change while limits shift and trials expire, sales negotiates custom terms, and when customers hit usage thresholds mid-cycle, engineering often ends up stitching billing logic into the product just to keep access and invoicing aligned.
That is the gap Schematic closes.

Schematic acts as the monetization operating system built on Stripe. It serves as the system of record for your plans and SaaS entitlements while enforcing access in the product at runtime, so engineering does not have to rewrite billing logic every time pricing changes.
Product adjusts limits and packaging, RevOps supports custom deals, and GTM sells flexibly without breaking alignment between billing and access.
The pay-as-you-go cost rate is the price charged per measurable unit of usage. That unit could be API calls, GB of storage, minutes of processing time, or other computing resources. The total charge equals the published rate multiplied by the amount consumed during the billing period.
Pay-as-you-go pricing is based on actual usage inside the product. Customers are charged according to how much they consume rather than paying a fixed subscription fee. This structure supports a flexible pricing model because charges adjust with demand instead of staying locked to a flat monthly fee.
The four common pricing models are:
Flat-rate pricing
Tiered pricing
Pay-as-you-go pricing
Pay-as-you-go supports revenue growth because expansion happens when customer usage increases. It can also drive cost savings by aligning infrastructure spend with real consumption and limiting unnecessary access to premium access services or high-cost features until customers use them.