Designing AI Billing: Subscriptions, Credits, Refunds, and Idempotency

AI billing is a product decision and an engineering problem. This guide compares subscriptions and credits, then connects pricing to model cost, operation weights, refunds, and duplicate-charge prevention.

Start With the Value Metric, Billing Unit, and Payment Model

Should an AI tool cost $19 or $29 a month? That question comes too early. Start with three decisions: the value customers pay for, the unit used to measure consumption, and the way payments are collected. Subscriptions and credits can coexist: a monthly subscription can include credits, with extra packs available when usage grows.

A useful sequence is to define the value metric, choose a billing unit, select the pricing model, add guardrails, and review the results regularly. A value metric might be hours saved or tasks completed; the billing unit might be tokens, images, conversations, or resolved tickets. The charging model determines whether those units are bundled into a subscription, purchased as credits, or billed after use. Alibaba Cloud discusses these distinctions in its enterprise AI pricing analysis.

Subscriptions and Credits: The Practical Trade-offs

The biggest benefit of subscriptions is not a higher unit price, but upfront and predictable revenue: fixed monthly inflows, measurable renewal rates, and acquisition budgets that can be back-calculated from LTV. The cost is that usage risk stays on the supply side—heavy users exhaust quotas, and light users hesitate at renewal. Credits are the opposite: revenue fluctuates with usage, but users have a clear sense of 'how much I spent,' costs can be passed through per use, and gross margin is less likely to be destroyed by a small number of extreme users.

Why Inference Costs Complicate a Fixed Monthly Fee

Prompt length, model tier, retries, and accumulated context all change inference cost. Consider an illustrative workload of 10,000 conversations, each using 8,000 input and 2,000 output tokens. At assumed rates of $1.20 per million input tokens and $6 per million output tokens, the model bill is $96 + $120 = $216. Charging customers $2 per conversation produces $20,000 in revenue; charging $0.99 per resolution produces $9,900 only if all 10,000 conversations are billable resolutions. These are different commercial measures, not interchangeable estimates of inference cost. The gap must also cover infrastructure, support, payment fees, and other operating costs. The rates here are assumptions for the calculation, not a current price quote.

Batch processing and caching can reduce the underlying bill when supported by the provider and workload. Measure their real effect on your application before setting credit coefficients. A fixed customer price can retain those savings as margin; usage-based pricing can pass some savings through to customers.

Predictable Access Versus Balance Anxiety

The mental account for subscriptions is 'a cost already paid,' so users tend to use more, and perceived value is easier to establish; the mental account for credits is 'a balance that is still decreasing,' so users estimate the price before every generation. Friction concentrates in three places: top-ups interrupt creative flow, insufficient balance stops tasks midway, and failed generations still consume charges. The solution is not complicated: keep the balance in the navigation bar, show an estimated consumption range before generation, set auto-top-up thresholds, refund failures automatically, and explain the reason in the transaction record. When the experience is done right, credits do not feel stingy; instead, they reinforce the perception of 'paying only for actual output.'

Chatbots: Match the Plan to the Usage Pattern

Start with three measurements. First, unit-cost variance: a short Q&A session can be far cheaper than a long-document or multi-step reasoning task. Second, the ratio of monthly usage at p90 to p50: a large gap indicates that heavy users need separate limits or overage pricing. A ratio above 5 can be a useful investigation trigger, rather than a universal cutoff. Third, inference cost as a share of revenue: a figure above 30% can be a warning sign, but the acceptable share depends on the rest of your cost structure and target margin.

The conclusion is usually layered: for a general-purpose assistant aimed at individuals, a monthly plan better matches user cognition—what users buy is the reassurance of 'can chat anytime'; for B2B customer service and knowledge-base Q&A, billing per session or per resolution fits the value better and is easier to explain to procurement. When both types of users are in the customer base, use 'subscription as the base + credit tiers.'

Image Tools: A Three-Tier Plan

Image tools are the most typical category for mixing subscriptions and credits; the cost per image is the sum of multiple calls for resolution, model, upscaling, moderation, and so on. The package structure is as follows (the numbers are examples and must be back-calculated from your own per-image cost):

Assign credits by operation rather than charging the same amount for every image. An illustrative schedule might use 1 credit for a standard image, 4 for HD upscaling, and 2 for inpainting. Validate each coefficient against actual cost. For an operation costing C and consuming k credits, the minimum price per credit is C ÷ [k × (1 − target gross margin)]. If a standard image costs $0.02, consumes 1 credit, and targets a 70% gross margin, the price is about $0.067 per credit. Include payment fees and other variable costs in C, and test the other operations before setting pack prices.

API Billing Configuration: Credits, Refunds, and Idempotency

API pricing must satisfy two standards at the same time: externally, use 'calls' or 'tasks' as the billing unit so developers understand it at a glance; internally, use tokens or GPU-seconds to calculate the real cost. Bridge the two with credit coefficients rather than exposing token prices directly to customers. A common approach is tiered unit pricing plus a monthly commitment, with overage settled at a higher unit price:

{
  "plan": "pro",
  "included_credits": 20000,
  "overage_per_1000_credits": 3.5,
  "credit_rules": [
    { "model": "small", "per_1k_input": 1, "per_1k_output": 3 },
    { "model": "standard", "per_1k_input": 3, "per_1k_output": 9 },
    { "model": "reasoning", "per_1k_input": 10, "per_1k_output": 30 }
  ],
  "min_charge_per_call": 1,
  "failure_policy": "no_output_refund_full",
  "idempotency": "required"
}

Three constraints are worth writing into the design document: a minimum billing unit prevents ultra-short calls from diluting cost; the failure policy determines the refund standard; and idempotency keys prevent duplicate charges. The monetization mechanisms of AI products usually revolve around SaaS subscriptions, usage-based pricing, and outcome-based pricing, and related research summarizes these three mechanisms in the same way (Research on AI Product Monetization Mechanisms), which can help you determine which tier your product falls into.

Five Ways to Combine Subscriptions and Usage

1. Pure usage-based: usage is highly uncertain with clear peaks and troughs; the risk is unpredictable revenue.
2. Quota subscription: monthly fee includes a fixed quota, stops when exceeded; suitable for budget-sensitive enterprise procurement.
3. Overage subscription: monthly fee includes a quota, with overage billed per unit; suitable for businesses with seasonal increases.
4. Credit-based prepaid consumption: buy once, deduct per use; suitable for one-off projects and managed services.
5. Subscription + monthly credit top-up: monthly fee issues credits, carried over according to rules; balances cash flow and usage elasticity.

The trade-off is between signup friction and revenue predictability. A fixed fee can discourage occasional users; pure usage billing can make budgets harder to forecast. Hybrid plans are useful when customers want a predictable baseline but their workload has a long tail. Make overage consent, caps, and credit expiration clear before purchase.

Four Billing Rules to Define Before Launch

First, set different credit coefficients for different models. A lightweight model at 1x, a main model at 3x, and deep reasoning at 10x are only a starting point; the coefficients must be back-calculated from the real unit cost. Second, write the refund rules clearly: full refund for model errors or no output; refund credits and record the reason for timeouts or interruptions; no refund when generation succeeds but the user is dissatisfied, but offer a retry discount instead. Third, guardrails must go into the contract, not just the console: usage caps plus alerts, billing thresholds that trigger pre-authorization, and per-task rate limiting. Fourth, bills must be explainable: every transaction record should carry the request ID, model, token count, and credit deduction so users can reconcile at month-end. Under high concurrency, charging must also be idempotent—retries of the same request use the same idempotency key, and both deduction and refund take effect only once.

Four pre-launch checks: measure the p50, p90, and p99 of unit cost before pricing; write the value metric in one sentence; translate every action into a traceable credit coefficient; launch guardrails and failure refunds first, then open large top-ups.

Keep Payment Collection Separate From Credit Accounting

Checkout creation and payment webhooks collect money; your application still needs its own credit ledger, refund rules, and idempotency guarantees. The We0 payment workflow is one implementation reference. Treat verified payment events and credit adjustments as separate, traceable operations.

FAQ

If we already offer subscriptions, can we still add credit packs?

Yes, and it is usually the optimal path: subscriptions serve as the base entitlement, while high-frequency or overage demand is directed to credit packs. This does not affect existing users' renewal expectations and can absorb burst usage. The key is that both mechanisms are explainable on the same bill.

Should credits be refunded when generation fails?

Differentiate by failure type: no output (error, timeout, interruption) is fully refunded; output produced but the user is dissatisfied is not refunded, but a retry discount is offered instead. All refunds carry a reason record, and idempotency keys prevent duplicate refunds.

How can we prevent a small number of high-frequency users from destroying our margins?

Combine in-plan quotas and rate limits, usage alerts, and an explicitly agreed overage policy. Stress-test prices using p99 costs and plausible concurrency, then enforce hard caps where needed. A percentile-based estimate alone cannot guarantee margin on every request.

Related Tools

• Unit cost distribution table (record p50/p90/p99 and model tiers)
• Credit coefficient matrix (model × operation type × unit cost)
• Stripe credit-based billing model configuration documentation

Related Links

• Pricing Enterprise AI Products: Lessons from Real-World Production (Alibaba Cloud)
• The Monetization of AI Products: Based on Closed-Loop Business Models (RePEc/IDEAS)
• Set up a credit-based pricing model (Stripe documentation)

A Practical Starting Point

Subscriptions and credits allocate usage risk differently. Subscriptions provide a predictable baseline; credits connect additional consumption to additional payment. Choose using measured unit costs, usage distribution, and target margins. A practical starting point for many AI tools is a subscription with included credits and clearly priced overage, supported by understandable bills, failure refunds, and idempotent accounting.

Adapted from the We0 article on AI pricing.

This article was edited with AI assistance.