Turn Different AI Actions into One Credit Balance
Map AI actions to credit costs, fund wallets from plans, deduct safely after successful work, and design renewal, expiry, top-up, and low-balance behavior.
Updated 2026-08-14
Your product extracts documents, generates financial reports, and creates images. Each action has a different supplier cost. Showing customers tokens, OCR pages, and model seconds would make the product harder to buy.
Credits create one customer-facing balance across those actions. They work only when the exchange is understandable and the ledger remains trustworthy.
Decide what one credit means
Start with the cost sheet. Compare the real cost of each successful action, then choose a simple credit scale.
Different AI actions spend one balance customers can understand.
Document extraction
2 creditsLow supplier cost
AI financial report
5 creditsSeveral models + OCR
Image generation
12 creditsHigher variable cost
Credits do not need to equal supplier cost exactly. They should preserve the meaningful differences between actions while staying easy to explain.
Use three checks:
| Check | Question |
|---|---|
| Cost | Does the credit amount protect margin? |
| Value | Does a higher-value action justify more credits? |
| Simplicity | Can the customer compare actions without a calculator? |
Publish the credit cost before the action when it could affect the customer’s decision. “Generate report · 5 credits” is clearer than discovering the deduction afterward.
Fund the wallet from the plan
In the plan’s Credit Grants tab, add a recurring grant for Growth: 1,000 credits each month.
Growth starts each billing cycle with a clear balance.
A Tirdad credit grant defines:
- the number of credits;
- one-time or recurring cadence;
- the recurring period;
- expiration at the billing cycle or no expiry;
- conversion and top-up rates;
- its source: plan, add-on, or subscription.
For a monthly promise, recurring credits that expire with the billing cycle are usually easiest to understand: each cycle starts with the stated amount. If unused credits roll over, say so deliberately and model the growing liability.
Use a one-time grant for a launch promotion, support correction, or negotiated adjustment. Keep the source in the ledger so “Why does Noura have 200 extra credits?” has an answer.
Put the grant into a customer wallet
The wallet is the customer’s running balance. Tirdad supports prepaid and postpaid wallets; the right choice depends on who carries the risk.
| Wallet policy | What happens at zero | Best fit |
|---|---|---|
| Prepaid | Stop or require top-up | Self-serve and strict spend control |
| Prepaid + auto top-up | Purchase more at a threshold | Uninterrupted use with a clear limit |
| Postpaid | Continue and settle later | Approved customers with credit terms |
Do not let the implementation choose this policy by accident. It changes customer risk, your collection risk, and the product experience.
Check, complete, then deduct once
Noura has 620 credits. A financial report costs 5.
Noura generates a report that costs 5 credits.
For actions that may fail, a safe product flow is:
- show the expected credit cost;
- confirm the wallet has enough balance for a prepaid policy;
- run the product action;
- deduct after the success condition is met;
- use the action ID as the idempotency key;
- return the new balance.
If the action must reserve expensive capacity before completion, define reservation, release, and finalization explicitly. Never leave a failed job as an unexplained permanent deduction.
Keep the balance explainable
The wallet ledger should answer how every credit arrived and where it went.
Every balance change keeps its reason.
| Transaction | Change | Balance | Reason |
|---|---|---|---|
| Monthly grant | +1,000 | 1,000 | Growth subscription |
| Report 87 | −5 | 995 | AI report |
| Image generation | −12 | 983 | AI image |
| Top-up | +500 | 1,483 | Purchased credits |
Tirdad wallets expose a real-time balance and transaction history. Configure low-balance alerts before customers reach zero. If you enable auto top-up, state the threshold, amount, and whether the top-up is invoiced.
The customer should be able to distinguish:
- credits included with the subscription;
- credits purchased through top-up;
- promotional or manual credits;
- usage deductions;
- expired credits;
- refunds or corrections.
Decide which credits are spent first
When several grants share a wallet, priority and expiry matter. A sensible policy often spends credits that expire sooner before credits that never expire. Purchased credits may deserve different treatment from promotional credits.
Write the rule in customer language and test it. A balance that is mathematically correct but expires the wrong credits first still feels unfair.
Handle zero balance as a commercial moment
At zero, choose the next step before shipping:
- stop the action and offer top-up;
- trigger an approved auto top-up;
- suggest an add-on or higher plan;
- continue through a postpaid wallet for eligible customers.
The right answer depends on the promise you sold. Do not silently allow an unlimited negative balance, and do not block an enterprise workflow that contractually continues.
Test every balance-changing moment
Before launch, verify:
- the first subscription creates the correct grant;
- recurring credits arrive once at renewal;
- the same debit request cannot charge twice;
- a failed AI action does not keep credits;
- credits expire according to the stated rule;
- a top-up uses the documented conversion rate;
- low-balance alerts fire at the intended threshold;
- cancellation stops future grants;
- every displayed balance equals the transaction history.
Credits simplify the units customers see. They should never hide where money, margin, or balance went.