AI products call many providers in many price units: per second of video, per image, per thousand characters of speech, per million pricing">tokens of text. A token wallet hides this behind one unit the person can reason about, and gives the business one place to set margin. The design has four parts, plus a ledger underneath them that makes the whole thing auditable.

1. One price per operation

Every operation (a ten-second clip on a given tier, one image, one lip sync, one screenplay) has a token price derived from its real cost by a fixed formula. Publish the table; read it live in the app and on the pricing page so they never disagree. The person should be able to see the price of an operation before starting it and the total charged for a film after it.

Derive, do not hand-tune. When a provider changes a rate, the formula reprices the operation and nothing else moves. Hand-tuned prices drift, and within a year some operations are sold at a loss without anyone noticing.

2. Plans with multipliers

A plan grants a monthly allowance and a cost multiplier: a free plan pays 1.3×, a middle plan 1.0×, a top plan 0.8×. The multiplier is how the same price table serves three audiences without three tables. Anchor the operation price to the lowest multiplier so that the margin is positive for everyone; every other plan simply earns more. Unused allowance should roll over for a limited time or not at all; state which.

3. Packs with bonuses

One-time packs for extra volume, cheaper per token with a plan, with bonus percentages at larger sizes. Packs never expire while the account is active. Spend order matters: spend the monthly allowance first, then the oldest pack, so that a person who bought a pack is not surprised to see their subscription tokens untouched while the pack drains. Show the order in the wallet.

4. Refunds

A failed operation is refunded automatically to the same source it was charged from. Refunds must be idempotent (a retried refund never pays twice) and must reference the original charge. Partial failures, such as a film where one scene failed, refund only the failed operations. A person should never have to write to support to get back tokens for something that did not happen.

The ledger

Underneath the wallet is an append-only ledger: one row per charge, refund, grant or purchase, with the operation, the job, the source (allowance or pack), the amount and a timestamp. The balance is the sum of the ledger, not a column that gets updated. This makes the wallet auditable, makes double-charging detectable, and makes "why did this film cost 27,000 tokens" answerable with a query. Show the ledger to the person as their history.

Solvency checks

  • If a plan's whole allowance is spent on the most expensive operation, it must still cost the provider less than the plan price. Run this for every plan, every month, and whenever a provider rate changes.
  • A pack's price per token must exceed the real cost per token at the lowest multiplier. Bonuses must be included in the calculation.
  • The free plan's allowance times its heaviest operation must be an acceptable acquisition cost per free user.
  • Refund volume as a share of charges should be monitored; a rising share means a provider is failing, not that people are gaming refunds.

What to show the person

The balance, split by source. The price of the operation they are about to run. The total for a film before it starts, as an estimate, and after it ends, as a ledger. The renewal date and what happens to unused allowance. The pack order. Nothing about provider prices, model names or multipliers; those are the business's concern, and exposing them turns every rate change into a support ticket.

Why not credits or dollars?

Dollars expose provider prices and turn every price change into an argument about which provider got more expensive. Credits are tokens by another name, but the word carries the connotation of arbitrary units with no formula behind them. The point is one stable unit and an honest formula behind it; what the unit is called matters less than that the formula exists and is applied everywhere.

Frequently asked

Should tokens be purchasable in any amount? Packs at a few fixed sizes are simpler to price, to bonus and to explain. Arbitrary amounts invite rounding arguments.

What about enterprise customers? The same table with a negotiated multiplier and invoiced monthly usage. The wallet model does not change; only the payment timing does.

How are tokens shown across currencies? The token is the same everywhere; only the pack and plan prices are localised. A person in Türkiye and one in Germany pay different amounts for the same pack and get the same tokens.