Look at the retry loop, not the pitch. The client issues a plain GET. If the status is anything other than 402 it returns immediately [2]. On a 402 it parses `X-Payments-Required`, which in the worked example carries a JSON object with amount, currency, recipient and chain [4]. It then signs an ERC-20 `transfer` against the canonical USDC contract on Base, waits for the receipt, and fails loudly if the receipt status is not 1 [5]. The transaction hash goes into `X-Payment` as a JSON blob, the loop sleeps one second so the server can index the transaction, and the same GET runs again [6][7]. Three attempts, then a RuntimeError [3].
That is the whole mechanism. Two headers, one status code, otherwise vanilla HTTP/1.1 or HTTP/2 [1]. The compatibility argument is real: nothing here needs a new transport, a new client library, or a handshake. An agent that can already retry a 401 can be taught to retry a 402.
The cost of adoption sits in the parts the convention does not specify. The example sends payment before it has the resource, so atomicity is a property of the server's behaviour, not of the flow [8]. If the server takes the money and returns 500, the loop pays again on the next attempt. Nothing in the snippet caches a receipt against a URL. Nothing bounds spend. The amount is read from a header the server controls, cast to a float, and handed to the signer without a ceiling check [4][5]. A per-vendor API key at least has the decency to be a fixed liability.
Then there is latency. The helper waits for the transaction receipt with a 30-second timeout, and the author's comment puts two blocks on Base at roughly two seconds [9][5]. Add the deliberate one-second back-off [7]. So a first call to a paid endpoint carries something on the order of three seconds of settlement before the retry even leaves the client: two seconds of inclusion plus the one-second sleep, on the source's own numbers [10]. For a batch job, fine. For an inner loop at the quoted $0.005 per LLM token [11], the settlement is more expensive than the work.
That is the transfer question for anyone reading this as a replacement for invoicing. The stated design goals are atomicity, statelessness and reuse of the existing HTTP client stack [8]. Reuse holds on the evidence in front of us. Statelessness holds, in the narrow sense that no secret is provisioned per vendor. Atomicity does not follow from the code shown, and the per-call economics only work if the price per call is large relative to a few seconds of blocking. What would have to be true for it to fit a hot path: settlement moves off the critical path, or the server accepts a signed authorisation it can settle later. Neither appears in this source.
One structural note in the convention's favour. Because the price arrives in a response header rather than a contract negotiated in advance, a server can quote per call, and a client can decide per call. That is a genuinely useful property for machine callers, and it is not something an API key plus a monthly invoice can express [12].
Worth being precise about what this material is. It is a single explainer with a self-contained Python snippet, using httpx, web3 and eth_account, against a hypothetical x402-protected translation service [13]. It documents a convention and a client. It does not show a server implementation, a verifier, or a deployment.
