Credit-Based Pricing: Prepaid Wallets vs. Postpaid Invoicing
Every usage-based product eventually has to answer the same question: does a customer pay for consumption before it happens, or after? The answer is credit-based pricing versus postpaid invoicing — two different collection models sitting underneath the same metering, and the choice shapes everything from cash flow to how a product feels the moment a balance runs low.
Prepaid wallets vs. postpaid invoicing
Credit-based pricing means a customer buys a credit wallet upfront — a prepaid balance, usually denominated in dollars or a product-specific unit like tokens — and every unit of usage deducts from that balance in real time. There’s no invoice at the end of the month waiting to be paid; the money already changed hands, and the only remaining question is how fast the balance burns and when it needs refilling.
Postpaid invoicing runs the same metering in the opposite direction. Usage accumulates against a plan, a commitment, or a simple per-unit rate throughout the billing period, and the customer sees the bill — and pays it — only after the period closes. The seller extends credit for the length of one billing cycle; the buyer gets a single, predictable collection event instead of managing a balance.
Neither model is more “usage-based” than the other — both can meter the exact same events with the exact same pricing logic. The difference is entirely about the timing of cash and risk: who is financing whom between the moment usage happens and the moment it’s paid for, and how visible that balance is to the customer while it’s being consumed.
| Prepaid credit wallet | Postpaid invoicing | |
|---|---|---|
| Who fronts the money | Customer, before usage | Seller, until the invoice is paid |
| Payment risk | Near zero — balance can't go far negative | Real — dunning and collections exist for a reason |
| Best fit | Self-serve, trials, unpredictable per-unit cost | Contracted accounts, predictable volume, enterprise terms |
| Customer mental model | A balance that counts down | A bill that arrives once a month |
| Cash flow for the seller | Immediate, ahead of cost | Delayed by the billing cycle plus collection time |
When credit-based pricing fits
Credit-based pricing isn’t the right default for every usage-based product, but it’s the right default for a specific, increasingly common shape of business: one where the cost of serving a customer is itself variable, near-real-time, and hard to predict a month in advance.
AI and API products
A product billing on tokens, inference calls, or compute-seconds is passing through a cost that moves with model choice, prompt length, and third-party API pricing — often in ways the seller doesn’t fully control. A prepaid wallet caps exposure on both sides: the customer knows exactly what they’ve committed to spend, and the seller isn’t extending 30 days of credit against a cost structure that can shift underneath them. It’s also simply the pattern users already expect — most developers have bought API credits before, and a countdown balance requires no explanation.
Marketplaces and platforms
A marketplace charging usage-based fees to a large base of self-serve sellers or buyers rarely has a billing relationship worth invoicing individually — the per-account revenue is too small and the account count too large for postpaid collections to be economical. Prepaid credits move the collection cost to the moment of purchase, when the payment method is already in hand, instead of generating thousands of small invoices that each need to be chased if a card fails.
Free trials and self-serve motion
There’s no invoice to send a trial account — there’s no purchasing relationship yet to invoice. A grant of free credits gives a prospective customer a real, metered taste of the product with a hard ceiling on cost exposure, and converting from trial to paid is just adding a paid balance behind the same wallet, not a new billing setup.
Where postpaid still wins
None of this makes prepaid universally better. A contracted enterprise account with a negotiated commit, a finance team that wants one predictable monthly bill, and a payment relationship built on net-30 terms is usually better served by postpaid invoicing against that commitment, with overage billed the same way. Most companies that scale past their earliest self-serve stage end up running both models side by side — prepaid wallets for self-serve, postpaid invoicing for contracted accounts — priced off the same underlying usage ledger.
Burn-down mechanics
Burn-down is the rate at which usage depletes a wallet, and getting the mechanics right is most of what makes credit-based pricing feel trustworthy instead of opaque. Three design decisions do most of the work.
Cost mapping. Every metered event has to translate into a credit cost before it can burn down a balance — a token costs X credits, an API call costs Y, a GPU-second costs Z. That mapping needs to be transparent to the customer (shown in the product, not just implied by a shrinking number) and consistent with however the same usage would be priced on a postpaid plan, so the two collection models never quietly diverge on what the same event actually costs.
Grant ordering. A wallet frequently holds more than one kind of balance at once — paid credits, and free credits from a grant (a trial, a promotion, a make-good after an incident). These should burn in a defined order — grants before paid credits — so a promotional allowance gets used first and a customer’s actual money isn’t silently consumed by usage a free grant was meant to cover.
Real-time deduction, not batch reconciliation.A wallet that only updates on a nightly job creates a window where the displayed balance is wrong — a customer can keep spending against a number that’s already stale, and the seller discovers the overrun after the fact instead of before it. Deducting from the same append-only ledger that records the event, at the moment the event lands, keeps the visible balance and the true balance the same number at all times.
Top-up UX
The top-up moment — the screen a customer sees when a balance is running low — is the single highest-leverage surface in a credit-based product. It happens exactly when someone is about to be blocked from using what they’re already paying for, which makes it either a moment of friction that costs a renewal, or, done well, something the customer barely notices.
Three patterns cover most products, and they aren’t mutually exclusive:
- 1Threshold alerts with a one-click link. Fire before the balance hits zero — at 20% remaining, say — with a direct link to add funds in one click. This is the minimum viable version and should exist even if nothing else does.
- 2Opted-in auto-top-up. A customer authorizes a stored payment method to auto-charge once the balance crosses a threshold, removing the click entirely. The opt-in has to be explicit — silently auto-charging a stored card without prior, affirmative consent erodes more trust than a momentary block ever does, even though the underlying intent is the right one.
- 3A clear, non-punitive zero-balance state. If neither of the above fires in time, what happens has to be legible — a specific error the product surfaces, not a silent failure a customer discovers by noticing nothing works. In-flight requests need a defined behavior too: complete and true up on next top-up, or block cleanly, but pick one on purpose.
The common thread across all three is that top-up UX is a product surface, not a billing afterthought — it deserves the same design attention as checkout, because for a meaningful slice of usage-based revenue, it functionally is checkout.
Common pitfalls
Treating the balance as a mutated counter instead of a ledger
A single number that gets incremented and decremented in place has no memory of how it got there. When a customer disputes a charge or a support ticket asks 'why did my balance drop,' there's no trail to point to. The balance should always be a computed view over an append-only event ledger, not a value that's edited directly.
Burning paid credits before grant credits
Get the order backwards and a customer's real money quietly funds usage that a free trial or promotional grant was supposed to cover. This produces one of the hardest support tickets to explain after the fact — a paid balance that dropped for reasons the customer can't see.
No warning before zero — only a failure after it
The most damaging version of bill shock in a credit model isn't an unexpectedly large invoice — it's a mid-request or mid-batch-job stoppage nobody saw coming. If a wallet only reacts once it's already empty, the product fails at the worst possible moment: mid-use.
Auto-top-up without explicit opt-in
Silently charging a stored card because a threshold was crossed, without the customer having affirmatively agreed to it, reads as unauthorized billing even when the intent was to prevent disruption. Consent has to be captured up front, not inferred from the customer having a card on file.
Ignoring idempotency on the deduction path
A retried request that deducts twice from a wallet is a double charge, not a rounding error — the same idempotency discipline that protects postpaid metering from double-counting has to protect every wallet deduction too.
No path back to postpaid as the account grows
A self-serve account that outgrows prepaid credits and wants a negotiated commit and net-30 terms shouldn't need a new system — it needs the same usage ledger priced a different way. Building the wallet and the invoicing engine as two unrelated systems from day one makes that transition far harder than it needs to be.
How this maps to Kribana’s wallets
Kribana’s credit wallets are built on the same append-only usage ledger as postpaid invoicing, not a separate system bolted on beside it — a wallet deduction and an invoice line item are two views of the same metered event. Grants and paid credits are tracked as separate balances and burn in that order automatically; the agent watches balances continuously and can fire threshold alerts, run opted-in auto-top-ups, or flag an account for a plan conversation before a balance actually hits zero. Accounts that outgrow prepaid credits move to postpaid invoicing and commitments against the same ledger, without a migration.
If your product is deciding between prepaid and postpaid — or, more likely, needs both at once — the underlying question is usually less about pricing philosophy and more about whether the metering layer underneath can support either collection model without being rebuilt. See how Kribana is priced or talk through your specific wallet and invoicing needs directly.
FAQ
Is credit-based pricing the same thing as usage-based pricing?
No. Usage-based pricing describes how a price is calculated — by consumption rather than a flat fee. Credit-based pricing describes when that price is collected — upfront, into a prepaid balance, versus postpaid on an invoice after the fact. A product can be usage-based and still bill postpaid (metered overage on a monthly invoice), or usage-based and prepaid (a credit wallet). Most AI and API products end up using both: a prepaid wallet for self-serve and trial accounts, postpaid invoicing for contracted enterprise accounts.
Why do AI products default to credit wallets instead of postpaid invoices?
Three reasons converge. First, per-unit AI costs (tokens, inference calls, GPU-seconds) are volatile enough that a seller often wants payment before delivering the marginal unit, not thirty days after. Second, self-serve and free-trial users have no purchasing relationship yet — there's no invoice to send. Third, a visible balance that counts down is a clearer mental model for unpredictable, machine-driven consumption than a running total a customer only sees once a month.
What happens when a customer's wallet hits zero mid-request?
That's the failure mode credit-based pricing has to be designed around. The three real options are: block the request and return a clear balance-exhausted error, allow a small negative balance to complete the in-flight request and true it up on the next top-up, or auto-top-up from a stored payment method before the balance reaches zero. Products that don't pick one of these deliberately end up with the worst version by accident — a request that fails midway through a batch job with no clear signal why.
Should trial credits and paid credits share one balance?
They can share one number a customer sees, but they should not share one bucket internally. Wallets that don't separate grant balances (trial or promotional credits, usually with an expiry) from paid balances (money the customer actually handed over) tend to burn paid credits before expiring grants — which means a customer's real money quietly funds usage that was supposed to be covered by a free trial. Burning grants first, then paid credits, avoids that entirely.
Does switching to credit-based pricing require rebuilding our metering?
Not if metering already exists as an append-only event ledger. Credits are a balance computed from that same ledger — usage events are priced and deducted from the wallet the same way they'd be aggregated onto a postpaid invoice line. The work is mostly in the wallet layer (grants, top-ups, low-balance alerts, entitlement checks) and the checkout/top-up UX, not in re-metering usage from scratch.