If you sell plans with a monthly allowance, sooner or later a customer uses all of it before the month is over. What your product does at that moment is a pricing decision, even if nobody made it on purpose. Often it was made by whichever piece of code happens to check the counter first.
There are four common answers. None of them is free: each one moves a cost onto someone. This post walks through who pays in each case, what you need to know to choose, and one constraint that applies to all four.
A worked example
Take a document-processing API. Its middle plan includes 10,000 pages a month, and every page costs you something, because you pay a third-party service for each call. On the 20th of the month, one customer's integration sends its 10,000th page.
At that point your product can:
- Block: reject further requests until the next period or until the customer upgrades.
- Allow and bill: keep serving, and charge for the pages above the allowance as overage.
- Allow and prompt: keep serving for now, tell the customer they are over, and ask them to upgrade.
- Cut off at a ceiling: keep serving past the allowance, but stop at a spending ceiling that you or the customer set in advance.
One billing guide calls the first a hard cap, where usage stops at the line, and the second a soft cap, where usage continues and the customer pays for crossing the line through overage charges, slower service or fewer features. The third and fourth are soft caps with different rules for when to stop.
Block: reliable, and it lands on your heaviest users
Of the four, a hard cap comes closest to stopping your cost at a known point; the usage that gets through before the block takes effect is covered below. It is also the option that hurts the customer who uses you the most, and that customer may be using you heavily because their own business is growing on top of yours.
The cost of blocking is easier to see when an infrastructure provider offers it to its own customers. One hosting platform lets a team set a spend amount, and its documentation says plainly that the amount does not stop usage on its own. To actually stop, you turn on an option that pauses production deployments. When that happens, the sites, APIs and functions in those projects stop serving visitors and return an error, and each project has to be resumed by hand. Raising the spend amount afterwards does not bring them back.
That is what a hard cap looks like from the receiving end: everything behind the limit goes down at once, including whatever your customer's own users were in the middle of. If you block at the plan allowance, work out what a blocked request looks like to your customer's end users, and whether the customer had any warning before it happened.
Allow and bill: the risk moves to collection
If you keep serving and bill for the overage, nobody is locked out. The cost moves to you instead. You have delivered the usage and paid your own suppliers for it, and the money arrives only when the invoice is paid.
Some payment providers offer tools for this. One provider's billing thresholds issue an invoice early, as soon as a customer's accumulated usage in the period reaches an amount you set, to limit how much a customer can owe between invoices. Thresholds do not stop usage, and a threshold invoice only includes the usage the provider had received when it was created.
An early invoice shortens the time you are exposed, but the customer still has to be able and willing to pay it. If a large overage came from a runaway script rather than real demand, you may be asked to forgive usage that you have already paid your suppliers for.
Allow and prompt: only as good as the timing
The third option keeps the customer working and turns the moment into an upgrade conversation. Whether that works depends on when the customer sees the prompt.
A prompt is an event your system has to produce and deliver. The same payment provider can send you a webhook when a customer's usage crosses a value you set, including a kind of alert that fires only once per customer. The alert tells you; it does not block anything, and what happens next is code you write. The billing guide mentioned above suggests warning at several points, such as 50%, 80% and 100% of the allowance, so that the last warning is not the first.
If the first message a customer sees is "you are over your limit", the prompt has already turned into a surprise on the invoice.
Cut off at a ceiling: depends on how recent the numbers are
The fourth option combines the others: let usage run past the allowance, bill for it, and stop at a ceiling. Some infrastructure tools let you connect an alert to an automatic action. One major cloud provider's budget notifications can trigger your own code, and its documentation gives disabling billing for a project as an example. Another major cloud provider lets a budget threshold run actions, either automatically or after someone approves them, such as attaching a policy that prevents new resources from being created, or acting on specific compute or database instances.
A cutoff can only act on the usage it can read, and the documentation of each of these providers describes a delay before usage shows up in its numbers.
Every option leaves a gap
Read together, the documentation of the services above makes two points.
An alert is not a limit. One major cloud provider states that a budget that only sends alerts does not cap usage or spending. The hosting platform says the same about its spend amount. The payment provider's usage alerts notify you, and its thresholds invoice early. Stopping is a separate decision, and someone has to make it.
Usage data arrives late. The first cloud provider notes a delay between when a resource is used and when its cost shows up in billing. The second updates budget information up to three times a day, usually 8 to 12 hours apart, so spending can already be past a threshold when the notification arrives and can keep changing after it. The hosting platform checks spend every few minutes, so a pause can come several minutes after the line is crossed, and it suggests setting the amount below what you can actually afford. The payment provider processes usage events asynchronously, so usage totals and upcoming invoices may not yet include events it has just received.
So whichever option you choose, some usage will happen between crossing the line and anything happening in response. The design question is who absorbs that usage:
- If you block, decide how far past the allowance you accept before the block takes effect, and whether you bill or forgive that part.
- If you cut off at a ceiling, set the ceiling below the number you truly cannot exceed, leaving room for the usage that can build up during the delay.
- If you prompt or bill, check that the warnings come early enough for the customer to act before the gap matters.
How to choose
Three questions settle most of the decision.
- Who pays for each unit of usage? If every unit costs you money at a supplier, such as an inference call, a third-party API or compute time, open-ended overage puts your margin at risk, and a ceiling matters more. If the cost of one more unit is close to zero, blocking mostly costs you goodwill.
- Can the customer see their usage before the limit? If customers can check their usage and get warnings ahead of time, a block or an overage charge is something they saw coming. If they cannot, any of the four will feel like a surprise.
- Can you collect the overage? Billing for overage assumes the customer will pay the larger invoice. For customers on monthly card payments with no contract, that assumption is weaker than for customers with a signed agreement.
When a customer is upset about a large bill, the conversation often turns to price. Usage the customer can see, warnings before the limit and a ceiling they agreed to all speak to the surprise itself, which a lower rate does not. These are worth deciding before you tune the numbers on the pricing page.
When you are the one being metered
The same choices apply in reverse when your product depends on a service that charges per call. One payment provider's tax calculation API, for example, includes a set number of calculation calls with each transaction and charges for each call above that. An integration that calls it more often than it needs to, on every change to a cart or inside a retry loop, can make far more calls than you planned for, and the bill follows the calls rather than your revenue.
Before you add a per-call dependency:
- Read the supplier's pricing for what is included and what is charged per call.
- Put your own counter and limit in front of the calls, so a bug stops at your limit rather than at the end of the billing period.
- Turn on the supplier's alerts where they exist, and treat them as a notice that may arrive late, not as a stop.
This post was written by the team building ShipRev, which has not been released. It describes common approaches to usage limits, not a feature of ShipRev.