Prepaid Credits for AI Products: How They Work

You sell a customer 100,000 credits and move on. A month later, support asks which credits expired, finance wants to know what can be refunded, and two agents have been spending from the same balance in parallel.

That is usually when prepaid credits get interesting. The balance itself is only the surface. Underneath it are rules for grants, burn order, expiry, adjustments, refunds, and who gets to spend what.

What are prepaid credits?

Prepaid credits are a stored balance of future usage that the customer pays for upfront.

The payment creates the commercial value, and usage later consumes it.

The flow is straightforward on paper:

Payment → credit grant → metered usage → burn rule → remaining balance

Behind that flow, the product still has to translate real activity into credits. A request might consume tokens, call several models, invoke tools, or generate media. The customer does not need to see each infrastructure cost separately if those events can be mapped into a consistent credit unit.

An example: A customer pays $200 for 20,000 credits.

The product might assign:

• Standard model request = 1 credit
• Premium reasoning request = 5 credits
• Image generation = 8 credits
• Agent workflow = 15 credits

A premium reasoning request therefore deducts five credits from the same balance that a standard request deducts one from.

The credit becomes the pricing abstraction, while metering underneath determines how much each action burns.

Why AI products use prepaid credits

Prepaid credits work well for AI products because usage can vary quite a bit between workloads while customers still want predictable spend.

A single subscription allowance can struggle when one action costs a fraction of another, but credits give you an abstraction layer between customer pricing and underlying consumption.

They can help with:

• Spend predictability because customers commit money before usage
• Multiple AI workloads under one customer-facing balance
• Different model costs through configurable burn rates
• Usage allowances bundled into subscriptions
• Top-ups when customers need more capacity
• Enterprise commitments represented as a credit balance
• Promotional usage without changing the core price

The hard part is defining what one credit means.

If the conversion between workload and credits changes constantly or feels arbitrary, customers lose the predictability that credits were meant to provide.

How the prepaid credit lifecycle works

Prepaid credits usually move through five stages from payment to final settlement.

1. The customer buys credits

The customer purchases a defined amount of future usage.

For example:

$500 → 50,000 credits

You now have two related records:

• A financial transaction for $500
• A product balance containing 50,000 credits

Those records need to stay connected even though they may live in different systems.

2. Credits are granted to the account

The purchased amount becomes available to the correct customer, workspace, department, user, or other entity.

This is where basic implementations can get messy. A single company may have several balances with different owners and rules.

3. Workloads consume credits

Each billable action deducts credits according to its burn rate.

A product might charge:

The customer sees a single balance, while the product accounts for differences across workloads.

4. The balance changes over time

Purchases are only one way a balance can change. Credits may also be:

• Granted
• Consumed
• Expired
• Refunded
• Adjusted
• Rolled over
• Added through a top-up
• Issued as a promotion

That is why a production credit balance is better represented as a history of transactions than a single mutable number.

5. The balance reaches its next state

Once available credits run low or reach zero, your commercial rules determine what follows.

The customer might purchase more credits, move onto postpaid usage, draw from another balance, or lose access to a particular workload.

That final behavior is a product decision as much as a billing decision.

You can see this model in Anthropic’s API billing. Developers purchase usage credits before calling the API, usage draws down that balance, and an optional auto-reload replenishes credits once the balance falls below a chosen threshold.

Prepaid credits vs. included credits

The main difference between prepaid credits and included credits is how the customer acquires them.

• Prepaid credits are purchased directly before use.
• Included credits come with another commercial commitment, such as a monthly subscription.

For example:

Pro plan: $99/month with 10,000 included credits

versus:

Credit pack: $100 for 10,000 prepaid credits

Both may eventually feed the same usage balance, but their commercial rules can differ.

Included credits may reset each month. Purchased credits might last longer. Promotional credits could expire first.

That means your system needs to know which credits are being consumed, not only the total remaining balance.

How credit burn rates work

A burn rate defines how many credits a particular action consumes.

This is one of the most important pricing decisions in a prepaid credit model.

Imagine three workloads:

• Small model request = 1 credit
• Reasoning request = 6 credits
• Video generation = 25 credits

The customer still buys one type of credit, but each workload draws from the balance differently.

This gives you room to account for meaningful cost differences without publishing every underlying token, inference, storage, and compute price.

Burn rates can change

Burn rates rarely remain fixed because the cost and structure of the underlying workload can change. A model provider might cut inference prices, you may move a workflow to a cheaper model, or an agent that once needed five model calls may later complete the same task in two.

Your credit system should let you update those burn rules centrally, without having to change pricing logic across the application each time the underlying workload changes.

The customer impact matters too. If a workflow moves from 5 credits to 8, its effective price increases, even if the customer still holds the same number of credits.

That makes burn-rate changes as much a pricing decision as a technical one, especially when existing balances were purchased under earlier assumptions.

Credit expiration and rollover rules

Prepaid credits need an explicit rule for how long the purchased value remains available.

Common structures include:

• No expiry
• Fixed expiration date
• Expiration after a defined number of months
• Contract-period expiry
• Partial rollover
• Full rollover

Expiry becomes more complicated when an account holds several credit types.

Suppose a customer has:

• 2,000 promotional credits expiring Friday
• 6,000 included monthly credits
• 15,000 paid credits valid for a year

Which balance should the next request consume?

That is a burn-order rule, and it directly affects how much value the customer retains.

Many products consume credits on a first-expiry basis, but the correct rule depends on the commercial agreement.

Prepaid credit top-ups

Top-ups let customers add more prepaid usage before their current balance runs out.

You can offer them manually:

Buy another 25,000 credits for $250.

Or trigger a purchase once the balance reaches a defined threshold.

For example:

When the balance falls below 5,000 credits, purchase another 20,000.

Top-ups make prepaid pricing more flexible, but they introduce another set of rules around price, expiry, balance priority, and purchase authorization. Enterprise customers may also negotiate different top-up rates than those in the standard self-serve package.

How refunds and adjustments affect prepaid credits

A prepaid balance gets messy the moment money and manual changes start touching the same pool.

Say a customer buys 50,000 credits for $500, uses 18,000, and then asks for a refund. The balance may say 32,000 credits remain, but that number alone does not tell you how much is refundable or where those credits came from.

Your refund policy needs to define whether you return:

• All unused paid credits
• A prorated cash amount
• Credits tied to a specific purchase
• Nothing once any usage has occurred

Support grants add another complication. If someone receives 5,000 goodwill credits after an outage, those should not be treated as purchased credits when issuing a later refund.

A ledger solves this by keeping every change separate. Paid grants, promotional grants, usage deductions, expirations, refunds, and manual adjustments all remain traceable, making reconciliation much easier as the balance changes over time.

Prepaid credits vs. postpaid usage

The main difference between prepaid credits and postpaid usage is when the customer pays for consumption.

Neither model is inherently better, and some AI products combine them.

For example, an enterprise customer could commit to 1 million prepaid credits, then move on to a contracted postpaid rate once those credits are consumed.

This creates a hybrid model with a predictable commitment and room for additional usage.

Where prepaid credit systems get complicated

The first version can look almost too easy. You create a balance, subtract credits when usage happens, and show the customer what remains.

The complications tend to show up afterward, once you introduce different credit types, shared wallets, custom burn rates, refunds, and contract-specific rules.

One balance suddenly has several meanings depending on who is spending it and where the credits came from.

Common pressure points include:

• Several credit types with different expiration dates
• Different burn rates across models and workloads
• Shared balances across users, teams, or agents
• Account-specific pricing and negotiated terms
• Promotional and paid credits are living in the same wallet
• Mid-cycle grants and manual adjustments
• Refunds after partial consumption
• Enterprise commitments with custom rules
• Prepaid-to-postpaid fallback
• Concurrent consumption against the same balance

The part I’d pay closest attention to is provenance. If two balances both say “10,000 credits,” but one came from a paid purchase and the other from a promotion that expires tomorrow, they are not interchangeable.

At that point, a credit balance ceases to be a counter and becomes a commercial state. Product access, pricing, refunds, renewals, and usage decisions can all depend on the history behind that number.

What to define before launching prepaid credits

A prepaid credit model works much better when these rules are explicit before engineering starts wiring them into the product. Define:

Definition

• What does one credit represent?
• How does each workload consume credits?

Ownership & sharing

• Who owns the balance?
• Can balances be shared?

Lifecycle & exceptions

• Do paid credits expire?
• Do included credits roll over?
• Which credit type gets consumed first?
• Can customers top up automatically?
• What happens to unused credits after cancellation?
• How are refunds calculated?
• Can usage continue after the balance reaches zero?
• Can enterprise contracts override standard credit rules?

If one of those answers is "we'll figure it out later," it will probably become a special case in application code.

Building prepaid credit infrastructure for AI products

Prepaid credits become an infrastructure problem when balances must remain accurate while multiple workloads consume and modify them.

Stigg is the usage runtime for AI products. Entitlements, credits, usage limits, and spend governance are enforced synchronously in the request path.

For prepaid credit systems, the relevant pieces include:

• Prepaid credit balances for purchased, included, promotional, and contract-based credits
• Ledger-backed credit history for every grant, deduction, expiry, refund, and manual adjustment
• Configurable burn rates that map different workloads to different credit costs
• Burn-order rules for deciding which credit pool gets consumed first
• Usage metering for the events that draw down a prepaid balance, including tokens, agent actions, API calls, and custom units
• Shared credit pools across accounts, departments, teams, users, products, and agents
• Real-time balance and entitlement checks before a workload consumes more credits
• Stigg Sidecar for low-latency BYOC balance checks. Cache hits resolve instantly from local Redis, and cache misses fall back to Stigg's Edge API at around 100ms with a configurable timeout so upstream latency doesn't cascade into the application.
• Billing integrations that keep payment collection and invoicing in your existing billing stack while Stigg manages credit state
• Modular adoption if you only need prepaid credits, metering, or entitlements to start

Prepaid credits tend to get interesting once one balance starts carrying several rules. If you’re working through purchase grants, burn order, expiry, top-ups, and refunds, the Stigg docs show how to model these pieces together.

FAQs

1. What are prepaid credits?

Prepaid credits are a stored balance of future usage that a customer pays for upfront. Payment creates the credit balance, and usage later draws it down through a burn rate that maps each action to a set number of credits.

2. How does a credit burn rate work?

A credit burn rate assigns a fixed number of credits to each billable action, so a standard request might cost 1 credit while an image generation call costs 8. Burn rates can change as the underlying model cost changes, and updating them centrally avoids rewriting pricing logic across the application.

3. Do prepaid credits expire?

Yes, prepaid credits can expire, though the exact rule depends on how the plan is structured, with common options including no expiry, a fixed date, or expiry tied to a contract period. When an account holds several credit types, a burn-order rule decides which balance gets consumed first, often the one expiring soonest.

4. What's the difference between prepaid credits and postpaid usage?

The main difference between prepaid credits and postpaid usage is timing: prepaid credits are paid for before usage, while postpaid usage is billed after consumption. Some AI products combine both, letting a customer draw down a prepaid commitment before moving to a contracted postpaid rate.

5. Can unused prepaid credits be refunded?

Yes, unused prepaid credits can often be refunded, but the policy has to define exactly what comes back: the full unused paid balance, a prorated cash amount, or credits tied to a specific purchase. Promotional or goodwill credits are typically excluded from that calculation.