Paid AI credits convert model usage into a service balance customers can buy through WHMCS. Configure the underlying costs accurately before choosing pack prices. The protected minimum checks your entered assumptions; it cannot guarantee a margin when those assumptions are stale or incomplete.
IN THIS ARTICLE
01 Enter the cost model
- Confirm the selected provider and model in AI engineers & credits. Obtain the provider's current input and output token prices for the actual model and billing arrangement.
- Open Token cost & loss protection. Enter the input and output costs per million tokens in the fields' stated units.
- Review the currency conversion, Input-equivalent tokens per credit and safety margin. Keep an internal record of when you verified these values.
- Set the retail rate per thousand credits and inspect Protected minimum / 1K and Price floor covered.
- Configure the credit packs you intend to sell and check their individual prices against the minimum.
- Save, then test a quote and purchase using the currencies and tax settings your customers use.
How does AI usage become a paid credit charge?
The calculation uses input-equivalent tokens. Output tokens are weighted using the configured relationship between output and input cost, so an output-heavy response can consume more credits than a similarly sized input. A credit is not the same as one question, one action or one completed repair.
For a paid request, the module reserves an estimated amount and settles against the provider-reported usage. Unused reservation returns to the balance. Account for this when reading a balance during an in-progress request.
02 Choose customer-friendly packs
Use a small range of packs with clear prices and amounts. The configuration supports up to four packs and a low-credit warning threshold. Explain where the balance is used and that the final cost varies with request size and the work performed.
Check invoice tax and currency display rather than comparing only the raw pack amount with the amount customers pay. A low retail price can still be unsuitable after payment fees, support effort and your own commercial commitments.
03 Maintain the pricing
Recheck the cost fields whenever you change the model, provider, exchange-rate assumptions or retail offer. Inspect actual usage and provider invoices during the first rollout. If a pack is rejected as below the price floor, correct the intended price or the verified cost inputs instead of entering artificial costs to bypass the protection.
Keep model pricing claims out of evergreen customer articles unless you maintain them. Link customers to the live credit purchase screen for their current pack amounts and prices.
04 Check a representative request
Run a short question and a longer supported task on a test service, then compare the recorded input, output and charged credits with your configured assumptions. Use a realistic range of tasks rather than one unusually small example when deciding whether a pack is commercially suitable.
Record the observed usage without promising customers that future work will cost exactly the same amount. Conversation context and generated output can differ on each request. Review the provider bill and WHMCS sales records over the first operating period to identify gaps between your forecast and actual expenditure. Adjust future pricing and published offers through your normal commercial change process, with existing customer commitments taken into account.