Get a customer's credit balance
What this customer has left to spend, one entry per currency they have
ever held a balance in. Derived from the same ledger an invoice
spends, so available is what the next invoice in that currency will
take before charging the rest.
A new invoice spends the balance after tax and records it as
balanceApplied. Card verification charges and payment-link checkouts
never spend it. Voiding an invoice gives back what it spent.
An automatic charge below the minimum (the card gateway’s own floor,
or the merchant’s higher minimum) is never sent. The invoice is marked
paid and its amount becomes debt on the balance: balance goes
negative and available stays at 0. The next invoice in that currency
collects it, with a negative balanceApplied that adds to its
amountDue.
Promotional credit lots that are active, unexpired and not yet spent
are listed in grants and counted in available. The next invoice
spends them before tax (soonest expiry first, then promotional before
prepaid, then oldest), so they lower its VAT like a discount and show
as grantApplied. A lot only pays invoices in its own currency.
Prepaid credit taxed when bought (vatTiming: at_purchase) is spent
before tax in the same order, but only on lines taxed the way its
top-up was (the same tax category and rate, in the lot’s tax): an
exempt, zero-rated or export line, or one after a rate change, is
billed normally. A lot bought at a price with VAT included is shown
in that price’s terms in amount, remaining and available, so
10,000 bought with VAT inside reads 10,000 and covers 10,000 of usage
priced the same way.
Prepaid credit taxed when used (vatTiming: at_redemption) is spent
after tax, like cash, in balanceApplied: lots expiring soonest
first, then those that never expire, then the money balance last. A
top-up awaiting payment shows in pending, never in available.
unbilled counts usage so far in the customer’s open periods
against the credit: what the invoices at their period ends would
draw if the usage stopped now, priced the way those invoices will
be. projectedAvailable is what would be left, the number to compare
with zero before serving a request, and projectedShortfall what
those invoices would still collect. Usage is only as fresh as what
you have sent, and stopping at zero is your call.
held is what open holds would take, priced on top of that usage
(POST /customers/{id}/credit-holds), and comes off
projectedAvailable too. To stop a customer exactly when their
credit runs out, reserve before each request instead of reading
this: a hold is refused when the credit can’t cover it.
Needs the credits:read scope on a restricted key.
Authorizations
Use a Bouclay secret key (sk_test_..., sk_live_...) or restricted key
(rk_test_..., rk_live_...).
A secret key can call every endpoint. A restricted key can only call the
endpoints its scopes cover. A scope is {resource}:{access}, for example
customers:read or refunds:write, and write includes read. GET
requests need read access and everything else needs write, except
POST /subscriptions/{id}/items/{item}/preview, which only needs
subscriptions:read. A request outside the key's scopes gets 403 permission_denied naming the missing scope, and its Idempotency-Key
is not used up.
Publishable keys (pk_...) are rejected by server-side API endpoints. A
key's mode scopes what it can see and charge: a test key can never reach
a live card.