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:

1. Block: reject further requests until the next period or until the customer upgrades.
2. Allow and bill: keep serving, and charge for the pages above the allowance as overage.
3. Allow and prompt: keep serving for now, tell the customer they are over, and ask them to upgrade.
4. 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.

1. 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.
2. 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.
3. 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.

Their terms are rarely in one place. The price lives in the payment provider's subscription. The plan name sits in a column in your own database. The limits are checked somewhere in your code. A handful of customers have a discount or a special arrangement that someone agreed to over email. Changing the plan means deciding what happens to all of that for every existing subscriber.

This post walks through what the payment side does and does not do for you, the common ways teams handle existing customers, and the state that tends to get lost when they are moved.

What the payment side does when a price changes

Using Stripe as the example, since its behavior is documented in detail, a few facts from its documentation shape every option below.

A price cannot be edited. Once a price object exists, its amount is fixed; only fields such as its metadata, nickname and active flag can change. Changing what a customer pays means creating a new price and moving the subscription to it (Manage products and prices).

Retiring a price does not move anyone. Archiving a price stops new purchases of it. Existing subscriptions on that price stay active until they are cancelled. Taking an old plan off sale leaves every current subscriber exactly where they were.

Moving a subscription is an explicit step, with two details to get right. To switch a subscription to a new price you name the subscription item being replaced; otherwise the new price is added alongside the old one and both are billed. The quantity also resets to one unless you pass it again (Change the price of existing subscriptions).

Proration covers money paid in advance, not usage. A mid-cycle change is prorated by default: the rest of the period is charged at the new price. You can preview this or turn it off, and a negative proration is not refunded automatically. Stripe's documentation states that usage-based billing is not subject to proration (Prorations). If you want the switch to happen at the end of the period instead, the documentation points to subscription schedules.

That last point matters most for this post. The payment side settles the money for the part of the period already paid for. What happens to the customer's usage counts, remaining allowance and limits when the plan changes is not decided there. Wherever those numbers live, deciding what happens to them is your call.

Ways to handle existing customers

None of these is the right answer in general. Each has people who argue for it in public, and each has a cost.

Keep them on the old plan

The old plan stops being sold, and everyone already on it keeps their price and limits for as long as they stay. One software company wrote publicly, when it retired a product, that it would take no new users but would look after the existing ones forever.

This is the simplest thing to tell customers, and the payment side already behaves this way when you archive a price. The cost builds up on your side. Each plan you keep is another set of limits your code has to recognize, another row in every report, and another case to test when you change anything nearby. Customers on the same features end up paying different amounts. One founder has written that, two years after keeping existing customers on their old pricing, a noticeable part of their revenue came from plans they no longer sold, and that the extra plans added operational complexity.

Move them at their next renewal, with a window to lock in

The new price applies from each customer's next renewal after a set date. Some teams also offer a window before that date: renew early, or switch to annual billing, and keep the old price for one more term. A team chat product took this approach for its first price increase in 2022, according to reporting at the time.

This spreads the change across a full billing cycle, and nobody is moved in the middle of a period they have already paid for. It also means that for months you are running both the old and the new terms at once, and each customer's switch date depends on when they last renewed.

Move them to the new price with an explicit discount

Instead of keeping the old plan, you move everyone to the new one and give existing customers a discount on it, stated as a loyalty discount. One pricing-analytics founder has argued for this in a talk, as later summarized by an investor: since price increases are inevitable, avoid leaving customers on legacy pricing, and give existing customers a loyalty discount on the current plan instead.

You end up with one plan to maintain and one set of limits. The discount, though, becomes a long-lived piece of state of its own, which leads to the next section.

Move them now

The change applies to everyone at once. Mid-cycle, the payment side prorates the money by default. Everything that is not money (usage so far this period, what is left of an allowance, any customer-specific limits) has to be carried across by you.

This gets everyone onto the same terms fastest. It also puts the most state in motion at a single moment, and the customer notices the change in the middle of a period.

Variations

Teams often mix these. Light users might be moved at once while heavy users get a longer window, or a plan's price might be held while its limits change. Each variation adds a rule that has to be applied correctly to every subscriber, so it helps to write the rules down before deciding which customers fall under which.

Old prices you cannot see

Not every old price shows up as an old plan. Discounts are a common place for one to hide.

In Stripe, a coupon can apply once, for a number of months, or forever. If a coupon is set to apply forever and also has an expiry date, the expiry date only stops new customers from redeeming it; anyone who already has it keeps the discount forever. Deleting a coupon stops it from being applied to new subscriptions and invoices, but it does not remove it from subscriptions and invoices that already have it (Coupons and promotion codes).

So a launch promotion that "ended" years ago can still be lowering what some customers pay today, under a plan whose list price you have since raised. Changing the subscription's discount does not trigger proration either; the new discount applies from the next invoice. Before a price change, it is worth listing every discount still attached to an active subscription, not only the ones you can still issue.

The state that gets lost when you move customers

When a customer moves from one plan to another, four kinds of state need a decision, and they are easy to miss because none of them is the price.

1. Consumed counts. How much the customer has already used this period. Does it carry over against the new limit, or reset?
2. Unused balances. Prepaid amounts or credits the customer has not spent yet. Do they move across at the same value, convert, or expire?
3. Remaining allowance. What is left of a quota under the old plan. If the new plan's limit is lower than what the customer has already used, what happens on the first request after the switch?
4. Per-customer overrides. The higher limit someone was given as a favor, the feature turned on for one account, the arrangement made during a sales call. These are usually the least documented and the most likely to be overwritten by the new plan's defaults.

For each of the four, it is worth deciding in advance what happens to a customer who is moved now, at renewal, or not at all, and checking that every place that stores the number agrees with the decision.

Estimating the impact before you change anything

Before choosing an approach you usually want to know how many customers each option affects and by how much. If that estimate comes from exporting subscriptions into a spreadsheet, keep in mind what the export does not contain. It is a snapshot of the payment side at one moment. It will not show usage, remaining allowances or overrides kept elsewhere, and it is out of date as soon as anyone subscribes, upgrades or cancels. The estimate is only as complete as the sources joined into it.

Telling customers is part of the plan too. Your own terms, and the law where your customers are, may require advance notice of a price change; check with whoever is responsible for your terms before you set dates.

A checklist before you change a plan

• Decide which approach applies to which customers: keep, move at renewal, move with a discount, or move now.
• Create the new price; do not expect retiring the old one to move anybody.
• When switching subscriptions, name the item being replaced and pass the quantity.
• Decide whether a mid-cycle switch is prorated, and remember that proration covers prepaid money, not usage.
• For each of consumed counts, unused balances, remaining allowance and overrides, write down what happens on the switch.
• List every discount still attached to an active subscription, including ones that can no longer be redeemed.
• Check that the plan recorded in your database, the limits in your code and the subscription in the payment provider all agree for a sample of customers after the change.

ShipRev is being built to keep a SaaS product's identity, subscriptions, metering and entitlements on one customer record. It has not been released, and this post describes a situation teams face, not something ShipRev does today.

ShipRev is designed to hold that state on one customer record, in one process and one database, so that a change to one of the four is written in the same transaction as the others. Here is how the four are meant to fit together:

1. Catalog and tiers: products, capabilities and the tiers that bundle them, published as versions.
2. Subscriptions: subscription state, invoices and prepaid balances, connected to your own Stripe account.
3. Metering: usage events recorded against each customer, with reservations that are confirmed or released.
4. Identity: end users, the organizations they belong to, and the boundary between one customer's data and another's.

Changes to configuration, subscriptions and entitlements are designed to be recorded in an append-only change log, so that each change can be traced afterwards.

ShipRev has not been released. This post describes its design, not a product you can use today.