Receipts and cost-plus

Transparent ledger is a platform rule: every charge has a receipt, every credit has a source, and you can audit your own spending without asking us. This page is the anatomy of the three receipt surfaces.

The ledger row — every charge, every mode

Whatever you call and however you pay, the charge lands as a row you can read back (GET /v1/account for balance, the transactions list for history, or the dashboard — same data):

• direction — debit (a charge) or credit (a top-up or a reversal).
• amountMicros — micro-dollars: 1200 = $0.0012.
• serviceKey — what you paid for, e.g. cputools.image.convert, llm.summarize.
• status — verified once settled. A failed op’s charge is reversed: undelivered work is not kept.

The x402 receipt — PAYMENT-RESPONSE

On the lodestone path, a successful response carries a PAYMENT-RESPONSE header: base64-encoded JSON with success, network, payer (your wallet), amount (micros), and transaction. One honest caveat: settlement is asynchronous — the on-chain transfer fires within seconds of the response, so the transaction field may be empty at response time. Your wallet’s history (queryable by wallet identity later) carries the transaction hash once settled.

The cost-plus usage receipt — ceiling vs charged

Most ops have a published fixed price: the 402 challenge (or your quote) states it, and that exact amount is charged. Cost-plus products — today the LLM task-router — are different, because the true cost is only known after the upstream call. The contract:

1. You authorize the ceiling. The published per-increment ceiling is what the 402 advertises (x402 upto mode) or what the prepaid hold reserves. It is the most the call can cost — by construction, never exceeded.
2. You pay the actual. chargedMicros = ceil(providerCostMicros × (1 + markupPct/100)) — the provider’s own reported cost plus the published markup (6% today), nothing else.
3. The receipt shows both. The response’s usage object itemizes the math:

{
  "result": "…",
  "truncated": false,
  "usage": {
    "model": "anthropic/claude-haiku-4.5",
    "inputTokens": 512,
    "outputTokens": 187,
    "providerCostMicros": 97,
    "markupPct": 6,
    "chargedMicros": 103,
    "ceilingMicros": 50000
  }
}

Field by field: model — the model the registry resolved for your tier; inputTokens / outputTokens — the provider’s token counts; providerCostMicros — the provider’s reported cost, verbatim; markupPct — the platform markup applied; chargedMicros — what you actually paid (always ≤ ceilingMicros); ceilingMicros — what you authorized. The same receipt is written onto the ledger row’s metadata, so the response and your ledger can never disagree.

If the upstream call fails, nothing was delivered and nothing is kept — the hold releases (prepaid) or the settlement reverses (x402). If the output hit the task’s cap, truncated: true tells you, and the charge stands (the work was done).

Two charges, two receipts

When one call produces two priced things (compute + storage, for instance), they appear as separate ledger lines, each with its own serviceKey and amount — never a blended number you cannot decompose.