Credits replace a long list of technical rates with one product-specific balance. A creative tool may include 1,000 credits per month, an AI operation may consume between 2 and 80, and an API customer may buy another pack when the balance runs low.
This abstraction can make several expensive actions easier to package. It can also hide what anything costs. If customers must perform currency conversion, inspect model documentation and guess output length before every click, the product has moved complexity rather than removed it.
Credit-based pricing works when the balance gives customers a stable planning unit, lets the vendor cover variable cost and supports multiple actions without an unreadable rate card. It fails when credits are designed mainly to obscure price, manufacture breakage or change rates without an explicit pricing decision.
This guide explains how to build a transparent and operationally reliable credit economy.
What a product credit represents
A credit is a commercial entitlement recorded in a wallet or allowance. Product activity consumes that entitlement according to a conversion rule.
The basic calculation is:
credits consumed = action quantity × credit cost per action
The monetary cost depends on how credits were acquired:
effective action price = credits consumed × realized price per credit
The realised price per credit varies because credits arrive by different routes: a recurring package allowance, a one-time pack, an annual commitment, volume discounts, a promotional grant, a refund or service credit, a partner programme, or automatic top-up.
That is why the headline credit price tells you little about revenue. Two accounts consuming identical credits can differ several-fold in what they paid for them.
A credit can abstract one underlying meter or several. For example:
| Product action | Credit cost | Underlying cost drivers |
|---|---|---|
| Remove an image background | 2 | model inference and storage |
| Generate a standard image | 12 | model, resolution and queue |
| Generate a high-resolution image | 35 | larger model and processing time |
| Produce 30 seconds of video | 80 | duration, model and rendering |
The table is useful only if customers can see it before acting and the actions are defined consistently.
Why products use credits
One balance can cover heterogeneous actions
AI and creative products may offer text, image, audio, video and analysis. Directly billing tokens, seconds, pixels, GPU time and provider requests would be precise but difficult to buy. Credits create one commercial layer above those resources.
Packages become easier to construct
A subscription can include a quantity usable across several workflows. The customer receives flexibility without the vendor predicting exactly which feature will be used.
Prepayment limits financial exposure
Purchased credits collect cash before variable cost is incurred and bound usage by the available balance. This is valuable for expensive, instantly provisioned operations.
Promotions are separable from list price
A product can grant trial or recovery credits without changing the permanent action rate. Separate grant balances also make promotional cost measurable.
Cost differences remain expressible
A costly model can consume more credits than an efficient one while the user maintains one wallet.
These benefits require an understandable exchange system. A balance that changes meaning unpredictably is not a stable value metric.
When credits are a good fit
Credit pricing is most useful when:
- the product contains several billable actions;
- actions have materially different variable costs;
- customers want flexibility across those actions;
- direct technical meters would be hard to forecast;
- prepayment or included allowance improves risk management;
- operations can estimate or bound cost before execution.
It is less useful when one natural unit already describes the product. An email validation API with one stable request type may be clearer at €0.004 per validation than at 0.4 credits whose monetary value must be calculated.
It is also weak when credits cannot connect to a meaningful output. “AI energy points” do not improve comprehension if the same prompt consumes an unknowable amount.
Use a fit diagnostic:
| Dimension | Strong credit fit | Warning sign |
|---|---|---|
| Product breadth | Several actions share one wallet | One obvious billable action |
| Cost variance | Action classes have known relative cost | Every run has unbounded unknown cost |
| Customer planning | Workflows can be estimated in credits | Balance depletion feels random |
| Risk | Prepayment protects expensive delivery | Cost is negligible and funding adds friction |
| Packaging | Flexible allowance improves choice | Credits exist only to hide a price increase |
| Operations | Wallet and ledger can be authoritative | Balance is calculated inconsistently across systems |
What one credit means
A credit does not have to map to currency one-to-one. It does need a stable commercial purpose.
There are three common approaches.
Monetary abstraction
One credit corresponds to a fixed monetary value, such as €0.01. Actions consume credits based on their price.
Advantages: easy internal rate calculation, straightforward refunds and accounting and customers can convert to currency.
Disadvantages:
- the extra unit may add little value;
- customers still perform currency arithmetic;
- regional pricing and discounts complicate equivalence.
If the mapping is fixed and visible, consider whether simply displaying currency would be clearer.
Product-action abstraction
One credit approximates a small product action. Larger actions consume multiples.
Advantages:
- product language can be more intuitive;
- package allowances can represent a portfolio of work;
- technical cost details remain internal.
Disadvantages:
- customers need a conversion table;
- changes to actions can alter perceived value;
- fractional or very large costs can become awkward.
Cost-weighted resource abstraction
Credits reflect relative variable resources. Different models, resolutions or priorities consume different quantities.
Advantages:
- supports margin as underlying cost varies;
- allows users to trade quality, speed and balance;
- works across heterogeneous AI workloads.
Disadvantages: may expose technical complexity indirectly, cost and customer value can diverge and provider efficiency changes require rate governance.
Most mature implementations combine product actions with cost weighting: recognizable outputs are priced in integer credits, while internal telemetry protects margin.
The conversion table
The conversion table is the real price list. Treat it as a public commercial contract, not a hidden configuration value.
For each action, specify:
- action name and product state;
- base credit amount;
- quantity dimension, if any;
- model, quality or speed multiplier;
- rounding rule;
- estimate shown before confirmation;
- final settlement rule;
- failure and cancellation treatment;
- effective version and date.
Prefer memorable amounts. A common action costing 7.384 credits suggests false precision and is difficult to plan. Integer credits or understandable increments usually work better.
Show representative workflow totals, not only atomic actions:
| Workflow | Components | Expected credit use |
|---|---|---|
| Prepare one product image | Background removal + standard generation | 14 |
| Create a campaign set | 8 standard images + 2 high-resolution variants | 166 |
| Produce a short clip | Storyboard + 30-second render | 96 |
A workflow estimate helps buyers translate a package of 1,000 credits into useful output.
Do not hide variable consumption
Some actions cannot be known exactly in advance. Text generation may depend on output length; an agent may call several tools; a video task may require retries.
Use one of four patterns.
Fixed action cost
Charge the same number for a defined operation and absorb ordinary variance. This gives the best predictability when variance is bounded.
Pre-execution estimate
Estimate consumption from inputs and selected settings. Show a range or maximum before the customer confirms.
Reservation and settlement
Reserve an upper-bound quantity, run the operation and settle actual consumption. Release the remainder immediately.
available balance after reservation = starting balance − reserved credits
final balance = starting balance − settled credits
User-defined maximum
Let the customer set a credit ceiling, output length, number of steps or quality level. Stop gracefully when the limit is reached.
Never allow an autonomous process to drain the entire organization wallet without visibility or controls. Use budgets and sub-wallets for agents, projects and API keys.
A real wallet ledger
A wallet balance is financial infrastructure. Do not maintain it as one mutable number with no transaction history.
Use an append-only or fully auditable ledger with explicit transaction types: purchase, subscription grant, promotional grant, reservation, settlement, release, refund, manual adjustment, expiration, transfer, and chargeback reversal.
Reservation, settlement and release have to be separate types. A credit held for work in progress is neither spent nor available, and a ledger that cannot express that state will drift from reality.
Each transaction should carry a unique identifier, the account and wallet, the amount and direction, the balance category, the source action or order, an idempotency key, a timestamp, the expiration lot where relevant, the conversion-table version, the actor or system, and the reason with audit metadata.
The conversion-table version is what lets you answer "why did this cost twelve credits" a year after the rates changed.
Calculate balance from ledger entries or maintain a reconciled projection. The product, billing system and support dashboard must agree.
A customer-facing history should translate internal entries into understandable language. “Ledger adjustment type R-17” is not adequate evidence for a missing balance.
Purchased, included and promotional balances
Credits acquired in different ways may have different terms. Store them in distinct lots or categories.
Purchased credits
The customer paid directly for the balance. Refund, expiration and transfer rules may be regulated and should be conservative.
Subscription allowance
A recurring package grants credits for a defined period. Unused allowance may reset, roll over within a limit or accumulate. State the rule prominently.
Promotional credits
Trial, referral or recovery grants can have shorter expiration and narrower use. They should not silently replace purchased credits at checkout.
Service credits
Compensation for an outage may be restricted to future service and have contractual treatment different from cash refund.
Define consumption order. A common rule is to use the balance that expires first, while protecting purchased funds from unnecessary expiration. Show customers which lots remain and when they expire.
Whether credits roll over or expire
Expiration changes behavior and economics.
Periodic allowance that resets
A monthly subscription includes credits available during that billing period. Resetting keeps package economics bounded and is familiar, but customers may feel they lose value during low-use months.
Limited rollover
Unused allowance can roll for a fixed number of months or up to a cap. This accommodates variable demand without creating unlimited liability.
Purchased balance without expiry
This is easiest to defend as stored paid value. It creates long-lived service obligations and requires dormant-balance policy.
Purchased balance with expiry
This may simplify old-price obligations and encourage use, but creates trust, legal and accounting risk. Disclose expiry before purchase, send reminders and avoid relying on unused value as the primary margin source.
Promotional expiry
Time-limited grants are common and generally easier to explain when the date is clear.
Model the outstanding balance liability and expected redemption. Breakage—credits never used—may affect accounting, but should not be engineered through obscurity.
Pack sizes and package allowances
Pack and allowance design affects accessibility, cash flow and effective unit price.
Small packs
Lower the barrier to trial and fit intermittent users. Payment fees and support can make them uneconomic.
Large packs
Improve cash collection and can support volume discounts. They increase refund, expiration and shelfware risk.
Subscription allowance
Creates recurring revenue and gives customers regular capacity. It should correspond to a recognizable workflow volume.
Automatic top-up
Adds a pack when balance falls below a threshold. Let customers choose: top-up amount, trigger balance, monthly top-up cap, payment method and alert recipients.
Never enable auto top-up through ambiguous consent. A customer should be able to pause it without disabling account access.
Organization commitment
An enterprise may buy an annual credit pool shared across projects. Define pooling, overdraft, expiration, rate lock and reporting.
Use a table to explain effective pricing:
| Purchase | Credits | Price | Effective price per credit |
|---|---|---|---|
| Small pack | 500 | €15 | €0.030 |
| Standard pack | 2,000 | €54 | €0.027 |
| Volume pack | 10,000 | €240 | €0.024 |
If discounts are large, verify that customers cannot resell or transfer balance in unintended ways.
Credits and unit economics
For each action:
action revenue = credits consumed × realized revenue per credit
action contribution = action revenue − variable action cost
Realized revenue per credit depends on the lot used. Promotional credits may produce zero direct revenue, subscription credits have an allocated package value and discounted packs have lower realized rates.
Track contribution by action type, model or provider, quality setting, customer cohort, acquisition source, credit source, pack size, and usage percentile.
Credit source belongs in that breakdown. Consumption funded by promotional grants has a cost and no revenue, and mixing it with purchased credits hides where the margin actually is.
Do not calculate margin from nominal list price if most usage comes from discounted, included or promotional credits.
Stress-test:
- longest permitted inputs;
- highest-resolution outputs;
- repeated retries;
- low cache rates;
- third-party price increases;
- currency movement;
- users selecting only the lowest-margin action;
- annual balances purchased under an old conversion table.
A blended credit economy can hide cross-subsidies. That may be acceptable if deliberate and bounded.
Version conversion rates
Product actions and delivery costs change. The conversion table therefore needs versioning.
A rate change should define which actions are affected, the new credit amount, the effective date, what happens to queued work, how existing subscriptions are treated, what happens to balances already purchased, the communication to customers, and the migration and rollback plan.
Purchased balances are the sensitive one. Repricing what a customer already bought changes the value of money they have already paid, and they will describe it in those words.
Increasing an action from 10 to 15 credits is a 50% effective price increase for the same output. Treat it with the same rigor as changing a currency price.
Possible protections include:
- a notice period;
- temporary old-rate access for existing commitments;
- additional balance grant;
- conversion of old credits into preserved monetary value;
- new model choice at a different rate;
- package price change instead of silent consumption change.
Do not rewrite historical ledger entries under the new table. Every settlement must retain the rate version applied at the time.
Model and provider changes
AI products may switch providers, optimize prompts or introduce models with different cost and quality.
Separate internal model identifiers from durable customer-facing service classes where possible. A “Standard image” action can remain stable while the vendor improves the implementation, provided output quality and economics remain within the promise.
Expose model-specific rates when model choice is itself valuable: customers may require a particular capability, latency, provider or data policy. Then show the exact credit cost before use.
If optimization reduces variable cost, the vendor may keep rates, lower credit consumption or improve the included service. Evaluate competition, value and margin rather than assuming cost-plus pricing.
If cost rises suddenly, avoid retroactive depletion. Use limits, temporary availability controls and prospective rate changes.
Reservations, cancellation and failure treatment
Expensive asynchronous actions need clear state transitions.
A robust flow:
- estimate maximum credits;
- confirm sufficient available balance;
- create an idempotent reservation;
- execute the action;
- settle actual billable credits on success;
- release the remainder;
- reverse settlement automatically for a qualifying failure.
Define outcomes:
| Outcome | Credit treatment |
|---|---|
| Vendor rejects before work | No settlement; release reservation |
| Vendor-caused failure | Release or refund automatically |
| Duplicate client retry with same idempotency key | One reservation and settlement |
| Customer cancels before expensive work | Release reservation |
| Customer cancels after material processing | Apply disclosed partial or full charge |
| Partial usable output | Apply published partial-result rule |
| Content-policy rejection | State whether screening creates a charge before submission |
The product should never leave reservations hanging indefinitely. Use timeout reconciliation and customer-visible status.
Negative balances and race conditions
Concurrent requests can consume more than the available wallet unless reservations are atomic.
Requirements include:
- atomic balance checks and reservations;
- idempotency for repeated requests;
- deterministic ordering or conflict handling;
- organization-level concurrency controls;
- limits on negative balance;
- recovery for delayed metering;
- reconciliation jobs;
- alerting for invariant violations.
Decide whether limited overdraft is allowed. Postpaid enterprise accounts may have a credit line; prepaid self-service accounts may stop when available balance is insufficient.
If the product allows negative balance during delayed settlement, show pending usage and prevent the dashboard from presenting the old amount as safely available.
Teams, projects and cost centers
One organization wallet may be too broad. A team needs to know who consumed what.
For organisations, offer usage by workspace, project and API key, labels or cost-centre tags, project budgets, child-wallet allowances, role-based purchasing permission, approval thresholds, centralised top-up, and consolidated transaction exports.
Approval thresholds and child wallets are what make credits acceptable to a finance team. Without them, a shared balance is an unallocated budget that any team can spend.
A child wallet can reserve part of an organization balance without creating a separate purchase. Define whether unused allocations return automatically.
Avoid forcing every user to buy personal credits when the organization is the payer. Personal wallets can fragment value and complicate procurement.
Explain credit pricing on the buying surface
A pricing page should answer four questions immediately:
- How many credits are included or purchased?
- What do common actions cost?
- What happens when the balance reaches zero?
- Do credits roll over or expire?
Then provide:
- a full conversion table;
- workflow examples;
- a calculator;
- top-up rates;
- model and quality differences;
- refund and failure treatment;
- usage dashboard screenshots or descriptions;
- enterprise pooling and commitment rules.
Do not rely on “up to 1,000 generations” if normal settings produce far fewer. State assumptions and give a realistic range.
Use currency alongside credits in checkout and usage history where practical. The goal is comprehension, not maximizing the number of steps needed to discover effective price.
Customer comprehension of credits
Credits create two layers of translation:
currency → credits → product outcomes
Test both.
Give participants a package, conversion table and scenario. Ask:
- How many workflows can you complete?
- What is the effective price of one normal output?
- Which operation consumes the most?
- What happens to unused balance?
- What will happen when balance is insufficient?
- Would a different quality setting change the cost?
Record the calculation process, not only whether the participant likes credits. Repeated arithmetic errors indicate the abstraction is too difficult.
Compare with direct currency and direct unit alternatives. Credits should win because they simplify a heterogeneous product, not because the company prefers a game-like interface.
Shadow the credit economy
Before real balances control access, run the conversion table against production-like events.
Before launching or changing the model, measure expected credits by account, whether common workflows remain affordable, how quickly balances deplete, contribution per action, the accuracy of reservations, refunds after failures, concurrency conflicts, promotional cost, expected unused balance, and the outlier accounts.
Workflow affordability is the check that protects adoption. If a routine task costs a noticeable share of the monthly allowance, customers will stop doing it and describe the product as expensive.
Then give test users visible shadow balances. Ask whether the depletion matches their mental model. A technically correct ledger can still be commercially confusing.
Test month boundaries, allowance grants, subscription changes, refunds, expired lots, transferred workspaces and conversion-rate versions.
A six-week implementation plan
Week 1: define purpose and actions
- List billable product actions and customer workflows.
- Map variable cost and value for each action.
- Decide why credits improve on direct currency or usage units.
- Draft a simple conversion table.
Week 2: design balance policy
- Separate purchased, included and promotional lots.
- Define rollover, expiration and consumption order.
- Choose packs, subscription allowances and top-up behavior.
- Review legal and accounting treatment.
Week 3: build ledger and reservations
- Implement idempotent wallet transactions.
- Add reservation, settlement, release and refund states.
- Protect concurrent balance updates.
- Create reconciliation and audit tooling.
Week 4: model and research
- Replay real actions under the conversion table.
- Stress-test cost and margin.
- Test workflow calculations with customers.
- Revise confusing values and low-margin actions.
Week 5: shadow launch
- Display non-binding balances and transaction history.
- Test depletion alerts and top-up controls.
- Reconcile every failure and reservation timeout.
- Train support on balance investigation.
Week 6: controlled paid pilot
- Enroll a limited cohort with explicit terms.
- Monitor purchase, consumption, top-up and contribution.
- Review confusion and disputes daily.
- Decide whether to expand, revise or reject the abstraction.
Metrics for credit-based products
| Area | Metric | What it reveals |
|---|---|---|
| Activation | Accounts completing first valuable credit action | Whether grants lead to real product use |
| Comprehension | Pricing and balance support contacts | Whether the abstraction is understandable |
| Consumption | Credits consumed by action and cohort | Product mix and depletion behavior |
| Conversion | Trial-grant accounts purchasing credits | Commercial quality of free usage |
| Repeat purchase | Accounts buying or topping up again | Recurring utility outside subscription labels |
| Allowance use | Consumed / granted subscription credits | Package fit and renewal risk |
| Breakage | Expired or dormant balance by source | Unused value and outstanding obligation |
| Economics | Contribution per action and credit source | Sustainability under discounts and grants |
| Reliability | Ledger mismatches and reservation timeouts | Integrity of wallet infrastructure |
| Trust | Refunds, disputed deductions and surprise depletion | Fairness and clarity |
| Concentration | Share of consumption by action and account | Dependency and margin exposure |
Track monetary revenue and cash separately from credit consumption. Selling a pack and consuming it are different economic events.
Common failure modes
Arbitrary exchange rate
The product chooses a large fictional number with no planning benefit. Customers still convert everything back to currency.
Hidden action costs
Users learn the credit amount only after clicking. Balance depletion feels random.
Silent inflation
The same output begins consuming more credits without treating the change as a price increase.
Breakage as strategy
Pack sizes and expiration are designed so customers routinely lose paid value. Short-term margin creates long-term distrust.
One mutable balance
Purchased and promotional value are combined without history. Support cannot explain expiration or refunds.
Charging vendor failures
Failed jobs and automatic retries consume credits. The vendor benefits from unreliability.
No reservation system
Concurrent expensive operations overspend the wallet or fail after work is delivered.
Unlimited agent drain
An automation can consume organization-wide value without a project budget or maximum.
Nominal-margin analysis
The team values every consumed credit at list pack price even though it came from a discount, grant or subscription allowance.
Excessive conversion complexity
Models, settings and features create dozens of multipliers. Credits no longer simplify the rate card.
Practical credit-pricing checklist
Strategic fit
- Credits simplify several heterogeneous billable actions.
- Direct currency or one natural unit would not be clearer.
- Customers can connect balance to recognizable workflows.
- Prepayment or allowance creates real customer or risk value.
- The system is not designed primarily to obscure price.
Conversion table
- Every action has a visible, versioned credit cost.
- Common workflows have realistic examples.
- Variable actions show estimates or maximums before execution.
- Rounding, model, quality and failure rules are explicit.
- Effective price changes receive pricing governance.
Wallet and policy
- Purchased, subscription, promotional and service lots are separate.
- Rollover, expiration and consumption order are disclosed.
- Ledger entries are immutable or fully auditable.
- Reservations and settlements are atomic and idempotent.
- Refunds and corrections retain source references.
Customer control
- Current, pending and expiring balances are visible.
- Transactions use understandable product language.
- Auto top-up requires explicit configurable consent.
- Projects and API keys can have budgets or limits.
- Alerts arrive before depletion or unusual consumption.
Economics and evidence
- Contribution is modeled by action and credit source.
- Promotional grants and discounts are included in realized economics.
- Historical actions have been shadow-rated.
- Heavy workloads and concurrent operations were tested.
- Customers can calculate normal workflow affordability.
- Success includes repeat value, trust and margin—not only credit sales.
Credits must stay legible
Credits should simplify a diverse product into one understandable balance. They should let customers plan useful work, choose among actions and control spend while allowing the vendor to cover variable cost.
Make the conversion table visible. Separate balance sources, preserve an auditable ledger, reserve before expensive work and refund failures automatically. Treat every change in credit consumption as a pricing decision, not a silent configuration update.
A healthy credit economy is not measured by how much purchased value expires. It is measured by whether customers understand what they can accomplish, consume credits through valuable outcomes and willingly replenish the balance.