Explainer

What is an x402 receipt?

August 2026 · Traceipt team

An x402 receipt is a cryptographically signed record that a specific x402 (HTTP 402) payment settled on chain, binding the on-chain transaction to what was bought, who paid, and who was paid — so the payment can be reconciled, audited, and verified later, independently of the parties involved.

The x402 protocol gives machines a way to pay for things over HTTP: a server answers 402 Payment Required with a price, the agent settles in a stablecoin (typically USDC), and retries the request. What the protocol does not give you is a record. The chain shows that money moved between two addresses — it does not show what was purchased, under what terms, or on whose behalf. A receipt closes that gap.

Two senses of "x402 receipt" — don't confuse them

The term is used two ways, and they solve different problems:

The protocol's settlement receipt. In the x402 spec itself, the server returns a PAYMENT-RESPONSE header after settlement, carrying the transaction hash and settlement metadata. This proves this request was paid — it's part of the payment handshake, held briefly by the client, and typically discarded. The draft-vauban IETF work formalizes cryptographic receipts at this protocol layer.
The audit-grade receipt — the sense this page (and Traceipt) is about. A durable record that outlives the request: bound to the settlement and to the commercial context (what was bought, who paid, who was paid), signed, chained, anchored, and independently verifiable years later. The protocol receipt tells the payer "you paid"; the audit receipt lets a payer prove to a third party what the payment was for.

They compose: the protocol's settlement response is one of the inputs an audit-grade receipt binds. If you're asking "did my request get paid," the header answers it. If you're asking "what do I hand my auditor in March," you need the second kind — which is the rest of this page.

Why agent payments need receipts

An autonomous agent making ten thousand micropayments a month produces ten thousand bank-statement lines with no invoice, no vendor, and no reason attached. Three groups of people then have a problem:

Finance cannot reconcile spend against anything — there is no purchase record to match a transaction to.
Auditors will not sign off on unexplained outflows, however small each one is.
Regulators increasingly assume the record exists: the EU AI Act (Article 12) expects high-risk systems to log their actions automatically, and MiCA expects transaction records tied to settlement and kept for years.

Anatomy of a good x402 receipt

A receipt is only as strong as what it binds together and how it resists tampering. The properties that matter:

Settlement-bound: The receipt should only exist if the money actually moved — issued after the transfer is confirmed on chain, and referencing the transaction hash.
Context-bound: It ties the payment to the purchase: what was bought, who paid, who was paid. This is the part the chain alone cannot tell you.
Signed: A digital signature (e.g. Ed25519) over the receipt's contents, so any edit invalidates it and the issuer cannot be impersonated.
Tamper-evident in sequence: Receipts chained together — so one cannot be quietly edited, inserted, or removed after the fact.
Anchored: The chain of receipts folded into a Merkle root published on chain, so anyone can prove a given receipt existed by a given time.
Independently verifiable: Signature, chain, and anchor should verify offline, against published keys, in any language — with no SDK and no dependence on the issuer still being around. An audit record is only worth what it proves when the vendor is out of the room.
Filable by a human: For accounting, the receipt should render to a document an accountant can file — e.g. a VAT-aware PDF with a scan-to-verify code.

How verification works

Check the signature against the issuer's published public keys — proves the receipt is authentic and unmodified.
Check the settlement — the referenced transaction exists on chain and matches the amount, payer, and payee.
Check the chain — the receipt's position in the tamper-evident sequence is intact; nothing was edited or removed around it.
Check the anchor — the Merkle proof connects the receipt to a root published on chain, establishing it existed by that point in time.

All four checks can run offline. A receipt that passes them is evidence a stranger can trust — an auditor does not have to trust the agent, the merchant, or the receipt issuer. You can watch all of this happen in the in-browser verifier — paste a receipt or load the live mainnet example and watch the checks run against Base.

Receipts vs. logs vs. block explorers

Application logs say what the agent claims it did. They are editable, unsigned, and prove nothing to a third party.
A block explorer proves value moved between addresses — but carries no purchase context and answers nothing about why.
A signed receipt is the join between the two: verifiable settlement plus the commercial context, in a form that outlives both parties' databases.

This is the record Traceipt produces: a receipt signed the moment an x402 payment clears in USDC on Base, chained, Merkle-anchored, offline-verifiable against published keys, and exportable as a VAT-aware PDF. Self-hostable if you'd rather run it yourself. For how alternatives approach the same problem, see Traceipt vs x402b.

Request Traceipt access How Traceipt works

Related reading: the x402 protocol and whitepaper · Traceipt FAQ · llms.txt. This page describes engineering properties, not legal requirements; whether a rule applies to your deployment is a question for counsel.