How prepaid credits work
The customer pays up front for a block of credits, either in money, as account credit in dollars or euros, or in a unit you define, such as API credits or tokens. Each time they use the product, or each time an invoice comes due, the balance goes down.
When the balance runs low the customer tops up by hand, or an automatic top up buys more when it drops below a threshold. Some businesses let unused credits roll over; others set an expiry date, which belongs on the checkout page at the time of purchase.
The balance is best kept as a ledger: every purchase, grant, debit, refund and expiry is a line, and the balance is their running total. Nothing is overwritten, so any balance can be explained.
Worked example
A customer buys 10,000 API credits for $100. Each API call costs 1 credit, and you set a low balance alert at 1,000 credits.
- Top up: 10,000 credits for $100
- +10,000
- May usage: 4,200 calls
- −4,200
- June usage: 5,100 calls
- −5,100
- Balance after June
- 700 credits
At 700 credits the balance is under the 1,000 credit alert, so the customer is warned before they run out. With automatic top up switched on, another 10,000 credits would be bought and charged to their saved card.
Why prepaid credits matter
You are paid before you deliver, which removes collection risk and helps cash flow, especially for products with a real cost per request.
Customers get a spending limit they chose themselves. A team with a fixed budget can buy $500 of credits and know the bill will not go past it.
Common mistakes
- Letting the balance go negative If usage carries on past zero, you are back to billing in arrears, often without the payment method that needs. Decide what happens at zero.
- Unclear expiry Credits that expire without warning feel like a trick. Put the rule on the checkout page and the receipt, and check the rules where you sell.
- Editing balances by hand Overwriting a balance loses its history. Add a correction line instead.