Usage-Based (Metered) Licensing for Software

A founder I advised built an AI document-processing tool and priced it the obvious way: $99 per seat per month. Then their customers split into two camps. A law firm ran 40,000 documents a month through three seats and thought the tool was the bargain of the century. A consultancy bought ten seats, ran 200 documents, and churned because “we’re barely using it.” The price had nothing to do with the value delivered, so it was simultaneously too cheap for the heavy user and too expensive for the light one. The fix wasn’t a new price — it was a new pricing model: charge for documents processed, not seats owned.

That’s usage-based licensing. This post covers how it actually works: credits versus metered billing, how to meter a unit correctly, prepaid credit blocks, overage policy, and — the part most guides skip — reconciling usage on clients that aren’t always online.

Key takeaway: Usage-based licensing charges for consumption of a well-defined unit instead of a flat fee. It aligns cost with value, but it lives or dies on three details: choosing an unambiguous unit, counting it idempotently, and enforcing the balance by failing closed. Prepaid credits give you cash up front and the customer a hard ceiling; signed credit blocks let even offline machines take part.

Where metering fits among licensing models

Usage-based pricing isn’t a replacement for the licensing machinery you already know — it’s a dimension you add on top of it. You still issue a signed license, you still gate features with entitlements and tiers (as in how to license your software), and you still node-lock and count seats where that matters. Metering adds a fourth thing the license carries: a consumable balance.

Think of entitlements as three flavours the license expresses together:

• Feature flags — is export on? (IsEnabled("export"))
• Numeric limits — how many projects? (GetLimit("max-projects"))
• Metered credits — how many units remain, and what happens at zero?

The first two are static for the life of the license; the third counts down as the customer works. Getting that countdown right is the whole game.

Choosing the unit — the decision everything hangs on

Before a line of code, decide what you’re metering. A good billable unit is:

• Unambiguous — everyone agrees what “one” is. “One processed document” is clean; “one API call” needs a definition (does a failed call count? a retry?).
• Correlated with your cost and the customer’s value — you want the meter to tick roughly when the customer gets value and when you incur cost, so pricing stays healthy at both extremes.
• Countable at a single choke point — one place in your code where the unit is unmistakably consumed, so you meter it once and only once.

Common units: API calls, processed items (documents, images, transactions), rendered/compute minutes, or even active seats metered by the day. Pick one primary unit. Metering three things at once is a billing-support nightmare and a customer-trust problem.

Metering a unit correctly

Once you’ve chosen the unit, the mechanic is: count it at the choke point, decrement the allowance, and enforce zero.

// At the single point where a billable unit is consumed.
var draw = await license.MeterAsync(unit: "document", amount: 1, idempotencyKey: docId);

if (!draw.Allowed)
{
    // Balance exhausted — fail closed. Don't process, don't silently allow.
    ShowMessage(draw.Message); // e.g. "Credit balance exhausted. Top up to continue."
    return;
}

ProcessDocument(doc); // only runs when a unit was successfully metered

Three things make this correct rather than merely working:

1. Idempotency. Pass a stable key (here, the document id) so a network retry doesn’t charge the same unit twice. Double-billing is the fastest way to lose a customer’s trust, and retries are inevitable.
2. Fail closed. When the balance is empty or the server is unreachable and no allowance is cached, the safe outcome — don’t consume — is the default. A meter that fails open is a meter an attacker (or a bug) turns into free usage by breaking the call. This is the same discipline that governs every license check; see offline license validation explained.
3. Meter after enforce, before deliver. Decrement the allowance before you hand over the value, not after, so a crash mid-operation can’t deliver a unit you never charged for.

Prepaid credits vs metered billing

Two ways to turn metered units into money, with genuinely different economics:

Prepaid credit blocks. The customer buys a block of units up front — say 10,000 documents. Consumption draws the balance down; at zero, access stops or overage begins. This is my default recommendation for most vendors, because:

• You get cash up front instead of chasing invoices.
• The customer has a hard, predictable ceiling — no nightmare bill at month end.
• Enforcement is simple: a balance you decrement and refuse at zero.

Metered (postpaid) billing. Usage accrues over a period and you invoice for the total at the end. Lower friction to start — no purchase decision before first use — but it carries bill-shock risk: a customer who accidentally 10בs their usage gets a 10× invoice and disputes it. If you go postpaid, add spending caps and usage alerts as a matter of course, not as a feature request.

Many products combine them: a monthly quota of included units (metered, reset each period) plus prepaid credit blocks for anything above it. That gives predictable base revenue and a clean upsell path.

Overage: decide before you ship

The moment a customer hits their limit, your code has to do something, and “we hadn’t decided” is not an option — it’ll surface at the worst time. The standard policies:

• Hard stop. At zero, refuse further units. Cleanest and safest; the risk is interrupting a customer mid-task, so pair it with low-balance warnings well before empty.
• Overage billing. Let usage continue past the limit and bill the excess at a defined rate. Customer-friendly, but this is exactly where bill-shock lives — cap it.
• Grace buffer. Allow a small overage (say 10%) before enforcing, so a customer isn’t stopped dead by crossing the line by one unit, then prompt them to top up.

Whatever you choose, warn early (“you’ve used 80% of your credits”) — a surprise is a support ticket and a surprise bill is a chargeback.

Reconciling usage — including offline

Metering seems to demand a live connection: how do you decrement a central balance from a machine that’s offline? The answer is signed credit blocks.

The server issues a cryptographically signed allowance — “this license holds 5,000 document credits” — that the client verifies against its embedded public key, exactly like a signed license, then draws down locally with no network call. The client keeps a tamper-resistant running tally, and when it next reconnects it reconciles: reports what it consumed, the server trues up the balance, and issues a fresh signed block. An air-gapped or intermittently connected deployment can fully participate in usage-based pricing this way.

It isn’t real-time — an offline machine can, in principle, overrun a stale block before it reconciles — so size blocks to your risk tolerance and reconcile as often as connectivity allows. But it means “usage-based” and “offline” aren’t mutually exclusive, which for enterprise and on-prem customers is often the difference between a deal and no deal.

An honest limit

Metering runs, in part, on the customer’s machine, so — like any client-side check — a determined attacker with a decompiler can try to patch the meter or forge a tally. You reduce this the same way you protect every licensing check: keep the authoritative balance on a server the attacker doesn’t control, reconcile signed blocks against it, and make the client hard to patch with obfuscation (more on that here). Offline metering is a controlled trust extension, not a guarantee — treat it accordingly, especially for high-value units.

Doing this with Keyright

Keyright treats metering as a first-class entitlement alongside seats and feature flags. You define a unit and a price, sell prepaid credit blocks or monthly quotas with an overage policy, and the SDK (.NET, Node, Python, Java) meters and enforces the balance — failing closed at zero. For disconnected deployments it issues signed credit blocks that meter fully offline and reconcile when the machine reconnects, so air-gapped and on-prem customers aren’t shut out of usage-based pricing. It’s the same system that also handles your trials, seats and revocation, so metering isn’t a bolt-on billing hack — it’s part of the license.

The free plan lets you model a metered product and wire it end to end before you pay a cent — start free, or read the Keyright docs for the exact metering surface. If usage-based pricing is central to your product, the feature overview walks through credits, quotas and overage in depth.