文档

Credits and billing

How the credit ledger, paid periods and Stripe payments stay separate on purpose.

Where credits come from

Every verified paid invoice grants its allowance once per billing period. The grant is keyed to the invoice, so replaying the same webhook never doubles a balance. Opt-in welcome credits use an explicit start cutoff so old accounts are never retroactively gifted, and staff adjustments only ever land through the audited console with a reason attached.

Credits are granted, never simulated: a preview deployment shows no balance at all rather than a fake one.

How balances stay honest

The balance is derived from an append-only ledger: every grant, purchase, debit and adjustment is one immutable row, and the current balance is the last row's closing value. A balance can reach zero but never goes negative, and no duplicate write can appear for the same reference.

Blocking an account keeps its paid entitlements but forbids consumption until the account is restored. Nothing on the ledger is erased on cancellation or refund; those are separate accounting events.

Billing versus credits

Stripe owns money: checkout, the customer portal, invoices, refunds and cancellations. The credit ledger owns metering: allowances from paid periods and consumption by usage. A credit adjustment in the admin console never charges or refunds a payment, and a refund does not silently claw back granted credits.

When a customer asks where a number came from, support reads the ledger: each row shows when, what kind, how much and the resulting balance.

Low balances and upgrades

Below the dashboard threshold, the account surfaces a low-balance notice that links to pricing and billing. The starter grants allowances per paid plan period rather than selling credits loose; model top-ups as a plan change or an audited adjustment until you deliberately build an à-la-carte purchase.