Optimize SaaS Revenue: Usage-Based vs Subscription Billing

A SaaS business can live quite comfortably with three subscription plans for a long time.

You launch your product from the US, sell directly through your own website, and ask customers to choose Basic, Pro or Business. The model is easy to explain. Customers know roughly what they will spend, while your team can connect each plan to a recurring payment and forecast revenue with reasonable confidence.

Then usage starts to diverge.

One customer logs in occasionally. Another adds a large team. A third connects your API to its own product and begins consuming far more data or computing resources than you expected when the original plans were designed. Meanwhile, customers start arriving from markets outside the US, including Asia, and the payment setup that worked well at launch does not always map neatly to how those customers prefer to pay.

At first, this may still look like a pricing question: should you keep charging a subscription or move toward usage-based billing?

Once you follow the problem through the business, however, the decision becomes broader. A pricing model determines not only what appears on your pricing page, but also what your systems need to measure, how customers understand their bills, when you can recognize revenue, how renewals work and how reliably that money can ultimately be collected.

That is where a general question about usage-based billing vs subscription starts turning into a billing and payment infrastructure decision.

Table of contents

1. SaaS revenue changes as the customer relationship grows
2. Fixed subscriptions improve predictability but can drift from usage
3. Usage-based billing brings price closer to consumption
4. Hybrid models emerge when the business needs both
5. Billing complexity eventually becomes payment complexity
6. Building a payment setup around the model you choose

SaaS revenue changes as the customer relationship grows

An ecommerce merchant can sell a product, receive a successful payment and complete that particular commercial transaction. SaaS works differently because the first payment often begins rather than ends the revenue relationship.

A customer may start on a trial, become a monthly subscriber, add users, upgrade, reduce its plan, consume additional services and continue paying for years. The commercial value therefore depends not only on the first checkout but on everything that happens afterwards.

This changes how payment problems affect the business. If a customer still wants your software but a renewal fails, the lost payment can interrupt an otherwise healthy customer relationship. If a plan upgrade is not reflected correctly in billing, revenue and product access can move out of sync. As the customer base grows, refunds, invoices, payment status and subscription records also have to remain understandable to finance and customer-support teams.

For merchants that want to understand this recurring-payment layer in more depth, our guide to subscription payments follows the journey from first authorization through renewal, failed-payment handling and reconciliation.

SaaS also introduces a second tension that becomes more visible as the product scales: two customers paying the same price may create very different economics.

A collaboration tool may not care whether one customer opens its dashboard more often than another. The value being sold is primarily continued access. An API, cloud or data product can behave differently because usage may directly affect infrastructure consumption. One customer making occasional requests and another processing continuous workloads can sit on the same subscription while consuming very different levels of service.

For AI products, the gap can become wider because the same business may need to monetise different customer groups in different ways. An individual user might pay a monthly subscription, a team might be charged per seat, while an enterprise or developer customer could be billed by API calls, tokens, generated content or prepaid credits. As a result, pricing can evolve from a small set of fixed plans into a combination of recurring, seat-based and consumption-based charges.

Once that happens, the challenge is no longer simply whether a customer should pay $29 or $99 a month. Your billing setup has to keep different pricing rules, usage records and customer relationships aligned, while still producing a bill that the customer can understand and your finance team can reconcile.

Fixed subscriptions trade precision for predictability

That does not make subscription pricing a bad model. In many SaaS businesses, its apparent simplicity is precisely the advantage.

A fixed monthly or annual fee gives customers a clear commitment. It also gives the merchant a clearer recurring revenue base. When the product delivers value through ongoing access—project management, workflow software, collaboration tools or many forms of business software—trying to meter every action can make pricing less intuitive rather than more accurate.

The trade-off appears gradually.

A small customer may feel that it is paying for capacity it rarely uses, while a heavy customer can continue consuming more resources without generating more revenue. A merchant can respond by adding seats, higher plans or usage allowances, but every additional pricing rule moves the business away from a simple "one plan, one recurring charge" model.

Subscription businesses also depend on the payment relationship continuing after the initial authorization. A customer can intend to stay subscribed while a payment fails for a temporary reason. That is why recurring-payment performance, credential management and appropriate retry logic eventually become part of retention rather than a purely technical checkout issue. Our broader payment optimisation guide explains why failed stored or recurring payments need to be diagnosed according to the underlying cause instead of simply retried without context.

The important point is that subscription pricing solves one business problem very well: it creates predictability. It becomes less comfortable when actual consumption starts to matter enough that the business needs greater precision.

Usage-based billing brings price closer to consumption

Usage-based billing begins from a different unit of value.

Instead of charging primarily for time or access, you measure something the customer actually consumes. An API provider might charge by requests. A data platform might measure records or processing volume. A cloud product might use storage or compute. An AI business may go further, combining monthly subscriptions or seat-based plans with consumption metrics such as tokens, API calls, generations or credits for different products and customer groups.

The appeal is straightforward. A customer can start small, then spend more as its own usage grows. The merchant does not need to force a light user and a heavy user into the same economic relationship.

The billing operation behind that pricing model is less straightforward.

Suppose your API records that a customer has consumed a particular number of requests. Those requests do not become an invoice automatically. Your system still needs to determine which events count, aggregate them correctly, apply the agreed pricing logic, account for any allowance or credit balance and turn the result into an amount the customer can understand.

The business process starts to look like this:

Turning usage into revenue therefore requires more than measuring consumption; the same usage data has to flow reliably into pricing, billing and payment collection.

Our Usage Billing capabilities are designed around this sequence. Usage data can be reported into the system, aggregated and matched with pricing rules before the amount due moves into billing and collection. The current product supports models such as pay-as-you-go, a fixed fee with additional usage, credit-based charging and configurable pricing rules.

That solves part of the merchant problem, but usage billing introduces another tension: a price that is more closely linked to consumption can become less predictable to the buyer.

A customer may understand what each unit costs and still have little idea what the final bill will be after a sudden increase in traffic. When customers only discover high consumption at the end of the billing cycle, a technically accurate bill can still create a poor commercial experience.

For this reason, usage visibility is part of the billing design rather than an optional reporting feature. Our current Usage Billing setup includes usage views, alerts, threshold warnings and abnormal-consumption monitoring so that variable charging can be accompanied by clearer information about how consumption is developing.

The shift therefore does not remove the need for predictability. It changes how you create it.

Hybrid models emerge when the business needs both

As a SaaS product matures, the pricing model often stops fitting neatly at either end.

Consider a developer platform that charges a base subscription which includes an allowance of API usage, then bills additional consumption once that allowance is exceeded.

The base fee preserves part of the predictable recurring relationship. The included usage gives the customer a known starting point. The overage means a customer whose usage expands materially can contribute more revenue without immediately moving into a completely different contract.

A prepaid credit model solves a similar tension from another direction. The customer commits spend first and consumes the balance over time, giving the merchant greater payment certainty while allowing usage itself to remain flexible.

Our Usage Billing product currently supports fixed-fee-plus-overage and credit-based approaches alongside pure pay-as-you-go charging — allowance-plus-overage for SaaS and software scenarios, pay-as-you-go for areas such as API products, and credits for cases including AI and developer services.

This is why "subscription or usage-based?" can become the wrong framing once a SaaS company reaches this stage. The better commercial decision may be to decide which part of the value should remain predictable and which part should follow consumption.

That decision then creates a new operational requirement. Subscription status, usage data, pricing rules and payment collection all have to describe the same customer relationship.

Billing complexity eventually becomes payment complexity

A merchant may begin this journey thinking primarily about pricing.

After the pricing model is chosen, engineering begins thinking about meters and APIs. Finance starts thinking about invoices and revenue records. Customer support needs to understand why one customer was billed differently from another. Eventually, every one of those decisions arrives at the payment layer.

An accurate bill is not the same thing as collected revenue.

With a fixed subscription, later payments need to follow the agreed recurring relationship. With usage-based billing, the amount may only become known once the relevant usage period has been measured. With a hybrid model, the payment may combine a predictable base with a variable component.

This becomes more complicated again when a US or European SaaS company starts selling directly to customers in Asia. The software itself may cross borders almost instantly, while the payment environment does not. Customer payment habits, recurring-payment support and acquiring arrangements can vary by market.

For card payments, the acquiring setup itself can affect the cross-border payment path. Our guide to local acquiring explains why merchants should evaluate local and cross-border acquiring according to their target market and operating setup rather than assume one model is always preferable.

At the technical level, the same principle applies to integration. A team that originally needed a straightforward checkout may later need stored credentials, asynchronous payment status, refunds, reconciliation and more customized transaction logic. Different payment gateway integration approaches create different trade-offs between implementation speed, checkout control and engineering responsibility.

By this stage, the merchant is no longer evaluating a "billing feature." It is evaluating whether the overall setup can carry the revenue model into real operations.

Building a payment setup around the model you choose

There are several reasonable ways to get there.

At Antom, this is where our newer billing capabilities fit into the payment relationship we already support. Our Usage Billing product can take reported usage through aggregation and pricing into billing and collection, while our subscription capabilities cover recurring relationships such as product setup, plan changes, renewals and selected revenue-recovery processes. These capabilities can also work alongside invoicing, payment and tax-management functions in our billing-management setup.

The value of that approach is not that every SaaS company should move all of its billing into one platform. A simple business should not add infrastructure it does not need. The advantage becomes more relevant when your commercial model is already forcing product, finance and payment systems to exchange the same information repeatedly.

A direct-to-consumer SaaS business expanding from the US into Asian markets is one example. The merchant may want the same product and pricing logic globally while adapting the actual collection layer to the markets it enters. Rather than treating international payment as a separate problem after billing has already been designed, the business can evaluate the two together: what amount should be collected, when should it be collected, which payment flow supports that relationship and how will the result return to the merchant's own systems.

With Antom, we can support that evaluation across subscription, usage-based and hybrid revenue models. Contact our team to discuss the setup that fits your business.