logo

What Is Pay Per Call?

Pay per call is a pricing model where a client pays for each individual request rather than subscribing to a plan or prepaying for a quota. For machine clients it removes signup and account provisioning, because payment is settled during the request itself, which requires settlement cheap and fast enough to add to every call.

How it differs from the alternatives

Against subscriptions. A subscription sells access for a period. The buyer commits before knowing their usage, and the provider gets predictable revenue and a relationship. Pay per call inverts both: no commitment, no relationship, and revenue that tracks usage exactly.

Against prepaid credits. Credits are closer, and still require an account, a top-up flow, and a balance the buyer manages. Pay per call removes the account entirely when settlement happens in the request.

Against post-paid metering. Traditional metered billing measures usage and invoices later, which requires a billing relationship, credit risk, and collections. Paying during the request removes all three, which is the property that matters most for serving clients you have no relationship with.

The reason this became practical is machine clients. A human will not approve a payment for every request, so per-call pricing for people has always needed an account wrapped around it. A program holding funds can settle mid-request without anyone being asked, so the account stops being necessary. That is the actual shift, and it is why per-call pricing is discussed now rather than a decade ago.

When settlement cost decides everything

Per-call pricing only works when the cost of settling is small relative to the amount being settled. If moving the money costs a meaningful fraction of the price, the model collapses, which is why cheap fast settlement is a precondition rather than an optimisation. It also sets a practical floor on what you can charge for: a call worth a hundredth of a cent cannot carry a settlement cost larger than that, no matter how the flow is designed.

What it asks of a provider

Metering you trust. You are billing per request, so the count has to be right, and both sides need to agree on what counts. A failed request, a cached response, a partial result, a retried call: each needs a stated rule, and disputes come from the cases nobody decided in advance.

Idempotency. A client that pays, times out, and retries must not be charged twice for one delivery. This means requests carry an identifier and the server recognises repeats, which is the same discipline any payment system needs and is easy to omit when the amounts are small.

A pricing decision per endpoint. Uniform per-call pricing is simple and wrong whenever endpoints differ in cost. Charging the same for a trivial lookup and an expensive computation either overprices the cheap path or subsidises the expensive one, and machine clients will find that asymmetry quickly.

Refunds and failures. When the service fails after payment, something has to happen: a refund, a credit, or a documented policy that there is none. For autonomous buyers this needs to be machine-readable, because there is nobody to read a support page.

Abuse and cost control. Removing signup removes your main lever against abuse. Paid requests are self-limiting to a degree, since the caller bears the cost, but a caller willing to pay can still saturate a capacity you provisioned for less.

Revenue that varies. Usage-tracking revenue is honest and less predictable than subscriptions. That is a business consideration rather than a technical one, and it is the most common reason providers offer both.

What it asks of a buyer

The buyer side is lighter but not free. An agent paying per call needs a funded account, a balance in the fee asset of whatever network settles the payment, and logic that decides whether a quoted price is acceptable before paying it. That last piece is the one most often missing: without an expected price range per service, an agent will pay whatever it is asked, and a spending cap only tells it whether the amount is affordable rather than whether it is reasonable. Buyers also need to track what they spent and on what, because per-call spending across many services produces a cost profile that is invisible unless someone records it at the point of payment. None of this is difficult, and all of it is easier to build before volume exists than after a surprising bill.

Frequently asked questions

What does pay per call mean?
A pricing model where each individual request is charged rather than access being sold as a subscription or prepaid quota. For machine clients, payment can be settled during the request itself, which removes the need for an account, a plan, or a signup step beforehand.
Why is pay per call suited to AI agents?
Because a program holding funds can settle a payment mid-request without asking anyone. A human would not approve a payment for every call, so per-call pricing for people has always needed an account around it. Autonomous clients remove that constraint, which is what made the model practical.
What is the difference between pay per call and metered billing?
Metered billing measures usage and invoices afterwards, which needs a billing relationship, credit risk, and collections. Pay per call settles during the request, so none of those are required. That is the property that matters when serving clients you have no prior relationship with.
What should a provider decide before charging per call?
What counts as a billable request, including failures, cached responses, partial results, and retries. Then per-endpoint pricing where costs differ, an idempotency scheme so a retry is not charged twice, and a machine-readable policy for what happens when the service fails after payment.
Does pay per call prevent abuse?
Partially. Paid requests are self-limiting because the caller bears the cost, which removes the cheapest kinds of abuse. A caller willing to pay can still saturate capacity you provisioned for lower volume, so rate limits and capacity planning remain necessary alongside pricing.