Bill an AI product with usage credits Per-seat pricing does not fit a product whose cost per request is real and variable. Credits do — and they are the billing model most likely to be rebuilt badly in-house.

A credit balance looks like a number in a table until you run it in production. Then: a retried request double-debits a customer. A worker crashes between calling the model and writing the debit. Two concurrent requests both read the same balance and both decide there is enough. A refund has to put credits back without inventing them. A monthly grant has to land exactly once even if the scheduler fires twice.

Every one of those is a correctness bug that shows up as money being wrong, which is the category of bug customers do not forgive.

• Credit writes require a durable idempotency key, unique per account. A replayed request is recognised as the same write, not applied twice.
• Every movement posts to a double-entry ledger in the same transaction as the balance change, so the books cannot disagree with the balance.
• Prepaid top-ups and recurring grants use the same primitives as the rest of billing.
• Refunds return credits through the ledger rather than by editing a number.
• Signed webhooks when a balance moves or runs low, so you can prompt a top-up.

Money is handled as integer cents throughout, with one rounding path. There is no second place where a total gets re-derived slightly differently.