Key Takeaways

• Burn-down is the deduction mechanism. The balance is the number it produces. Deduction order is what makes them disagree.

• Across three grants of 500, 2,000, and 1,000 credits, a 2,200-credit month forfeits nothing under expiry-first ordering and 1,300 credits under purchased-first.

• Burn-down has to resolve at request time, not at invoice time, or a customer with a zero balance keeps consuming.

• Every deduction needs to trace back to the usage event that caused it, otherwise a disputed balance is unprovable.

• A burn rate customers can't see becomes a support ticket. Exposing remaining days at current pace prevents most of them.

How does a credit burn-down work?

A burn-down converts each unit of usage into a credit deduction at a conversion rate, then decrements the wallet. It runs continuously rather than at invoice time, because a prepaid balance only works as a control if it's current.

The path from one API call to a decremented balance:

1. The product emits a usage event for the call.

2. Real-time metering resolves the event against the customer's meter and quantity.

3. Rating converts that rated usage to credits at the plan's conversion rate, say 1 credit per 1,000 tokens.

4. The wallet deducts the credits from the eligible grant, following the deduction order.

5. The balance updates, and any threshold alert or auto top-up fires.

6. The ledger records the deduction against the originating event ID.

Step 6 is the one teams skip and regret. A wallet storing only a running total can't answer "why is my balance 40,000 lower than last week", and every enterprise customer asks. Store the deductions, not just the balance.

What order do stacked credit grants burn down in?

Deduction order should burn the credits that expire soonest first, because that's the only ordering that minimizes what the customer forfeits. Naive implementations burn the largest or newest balance first, quietly destroying credits the customer paid for.

A customer holding three simultaneous grants, consuming 2,200 credits in one month:

The same consumption under two orderings:

Same usage, same grants, 1,300 credits of difference. Purchased-first burns the long-dated credits the customer paid for, then forfeits the promotional grant on day 7 and 800 recurring credits at period close.

Feature scope complicates the ordering. A grant restricted to one product can't cover another, so the rule is: filter to eligible grants, sort by expiry, then deduct. Reversing the two deducts from a grant that never applied. Credit based pricing vs usage based pricing covers when a credit model is the right call at all.

How do you expose burn-down to customers?

Show balance, burn rate, and projected exhaustion together, because a balance without a trajectory doesn't tell a customer whether to act.

What belongs in a customer-facing view:

• Balance per grant, with each expiry date visible.

• Burn rate over a trailing window, in credits per day.

• Days remaining at the current rate, which is the number customers actually read.

• Deduction history tied to dates and features, so the drop explains itself.

• Threshold alerts before exhaustion, since one at zero arrives too late.

What does burn-down need from a billing system?

It needs real-time deduction, per-grant expiry, configurable ordering, and an auditable ledger. Deferring deduction to invoice time turns a prepaid model into an unenforceable one, because the balance only works as a control if it's accurate at request time.

The capabilities that have to exist:

• Deduction at request time, fast enough for the critical path.

• Expiry dates per grant, not one policy per wallet.

• Deduction priority as configuration, so changing the order doesn't need a deploy.

• Overage behavior on exhaustion: either charge the payment method or block further usage.

• A deduction ledger keyed to usage events, which makes a disputed balance provable.

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Credits and Wallets stacks multiple credit types with custom priority and deduction order, sets expiration per grant or per wallet, fires auto top-ups at a threshold, and handles exhaustion by either charging the payment method or blocking usage. Segwise had spent three weeks building credit-based pricing internally before switching, and the Flexprice implementation took three days. If you're specifying deduction order and expiry rules right now, the Flexprice docs cover the wallet and credit grant APIs.

Related terms

Burn-down sits between the usage that causes a deduction and the policy that decides what survives the period.

• Credit rollover decides what happens to the balance burn-down leaves at period end.

• Real-time metering is what makes request-time deduction possible.

• Rated usage is the priced quantity a burn-down converts into credits.

• Consumption-based pricing sits underneath every prepaid credit design.

• Spending cap is the alternative control for customers who aren't on a prepaid balance.

FAQ

Is credit burn-down the same as a credit balance?

No. The balance is a number, and burn-down is the process that changes it. Two systems can report the same balance and disagree about which grant gets consumed next, which changes what the customer forfeits at expiry.

What happens when a customer's credits run out?

Whichever of two behaviors the plan specifies: block further usage, or let it continue and charge the payment method for the overage. Blocking risks an outage, charging risks a dispute, and auto top-ups at a threshold avoid choosing.

How do you calculate a credit burn rate?

Divide credits consumed by the days in the window, using a trailing window rather than the full period. A seven-day rate reacts fast enough to catch a spike, and the remaining balance divided by that rate gives the days-remaining figure customers act on.

Can a credit balance go negative?

It can, and whether it should is a policy decision. A small negative balance absorbs the race between serving a request and landing its deduction, which beats rejecting valid requests. An unbounded one turns a prepaid model into an uncollected receivable.