The vocabulary of credit billing.

A credit ledger is an append-only record of every credit issued, spent, held, or refunded, from which each user's balance is derived. Because balances come from the ledger rather than being edited directly, every change can be traced back to a transaction.

In Cred: Issues, deductions, and refunds in cred.diy commit the balance change together with its ledger row, so a balance does not move without a record, and every user's transactions can be listed through the API.

Application credits are an in-app unit of value that customers buy or earn and then spend on actions in a product, such as AI generations, API calls, or exports. They separate what a customer pays from what each action costs.

In Cred: You define your own credit types per project. They are distinct from CRD, the platform credit you spend to call the cred.diy API (1 CRD per call).

Prepaid credits are bought before they are used: the customer pays up front, receives a balance, and each use draws it down. The seller is paid before delivering the service, and the customer can see exactly what remains.

In Cred: Customers buy credit packages through hosted Stripe checkout or x402 stablecoin payments, and your server deducts credits as features are used.

Usage-based pricing charges customers according to how much of a product they consume rather than a flat fee. It is billed either in arrears (metered, invoiced later) or in advance (prepaid credits drawn down as used).

In Cred: cred.diy implements the prepaid form: usage is a credit deduction against a balance the customer already paid for, so there is no end-of-month invoice to collect.

Hybrid credit billing combines a recurring subscription that grants a monthly credit allowance with one-off top-ups for customers who need more. It gives predictable revenue without capping heavy users.

In Cred: A checkout becomes a subscription only when the request sends billing: "recurring"; credits are added after each paid invoice, and one-off packs can be bought alongside it.

A credit type is a named unit of value with its own balance, such as "AI tokens" or "export credits". Separate credit types let one product run several independent economies.

In Cred: Credit types belong to a project. Each user holds a balance per credit type, and swap pairs can convert between them.

A pricing tier is a fixed bundle of credits sold at a fixed price, such as 1,000 credits for $10. Tiers let customers compare packages using the same unit.

In Cred: Pricing tiers are created in the dashboard or API and used by hosted checkout; prices are validated against Stripe's $0.50 minimum charge.

A credit swap exchanges one credit type for another at a set rate, debiting one balance and crediting the other in a single atomic operation.

In Cred: Swap pairs define the exchange rate and an optional fee; a swap either completes fully or not at all.

An escrow hold reserves part of a user's balance so it cannot be spent elsewhere, then either releases it back or captures it to settle a transaction. It is how marketplaces protect both buyer and seller until work is delivered.

In Cred: Holds follow hold → release or capture. A capture can credit a different user, and a partial capture releases the remainder automatically.

An idempotency key is a unique value sent with a request so that retrying the same request has no additional effect. It makes it safe to retry payments and balance changes after a timeout.

In Cred: Keyed issue, deduct, refund, and saved-card charges return the original result when retried with the same key, so a balance is never moved twice.

Auto top-up automatically buys more credits on a saved payment method when a customer's balance runs low, so usage is never interrupted.

In Cred: A card is saved only from a checkout sent with save_payment_method: true; your server then calls POST /charge-saved with an idempotency key to buy a pack.

x402 is an open payment standard that uses HTTP's 402 Payment Required status as a price quote: the server states what a request costs, the client signs a stablecoin payment, and retries the request with it. It lets AI agents pay for APIs without accounts or checkout pages.

In Cred: cred.diy speaks x402 version 2 in both directions: agents can buy credits by paying, or pay inline for an individual API call.

An MCP server exposes tools over the Model Context Protocol so AI assistants such as Claude or Cursor can call them on a user's behalf in natural language.

In Cred: The cred.diy MCP server lets an assistant manage credits, users, pricing, swaps, and referrals in your project.

The merchant of record is the legal seller in a transaction: the party responsible for the payment, refunds, chargebacks, and the processor relationship.

In Cred: Which party is merchant of record depends on the payment rail you choose, which is why not every business can use every rail.