x402 payment flow: quotes, verify, settle and replays

What this experiment demonstrates

Jenya's research agent requests sample chapters from the Belgavi's Book Store API. Each request gets a 402 with a PAYMENT-REQUIRED quote: scheme exact on eip155:84532, an amount, the store as payTo and maxTimeoutSeconds. The agent checks the quote against its own maximum and pinned payTo, signs an EIP-3009 transferWithAuthorization, and retries with PAYMENT-SIGNATURE. The merchant then uses a facilitator's read-only /verify and state-committing /settle in the order its flow defines.

Flows, header names and the error codes invalid_network, invalid_exact_evm_payload_recipient_mismatch and invalid_exact_evm_payload_authorization_valid_before follow the x402 v2 specification read on 2 November 2026. Everything else is a deterministic model: no signature, wallet, facilitator or chain is called, nonces are placeholders, prices are illustrative rupee figures, verify takes one second, settle latency has a fixed slow-tail pattern (request 7 takes eight times the base), and the client sets validBefore to request time plus maxTimeoutSeconds.

Run controlled comparisons

Start with the defaults: ten requests at ₹2.00, the authorization flow (verify, prepare, settle, respond) and two concurrent replays of the first payload. Ten chapters are served and ten payments settled, ₹20.00 in all, and both replays are rejected at settlement because the nonce is already used.

Now change one thing at a time. Set the merchant to verify, respond, settle later: twelve chapters are served, two without a valid payment, and two replayed payloads are accepted, because the read-only verify passes both copies before either settles. Tick the merchant nonce cache: back to ten served and no replay accepted. Instead set replays to arrive after settlement: verify now fails its simulation and both are refused, but with respond on header and no verify they are still served unpaid. Back at the defaults, set the facilitator latency to 8: request 7 settles at 65 seconds against a 60-second window and expires, leaving nine served and settled; at latency 7 all ten settle, and with latency 10 a maxTimeoutSeconds of 90 settles all ten. Set the price to 600 paise against a 500-paise maximum: all ten quotes are declined; untick the budget check and ten payments go over budget. Choose the payTo rewrite: three quotes are declined by the pinned client; untick the pin and three payments go to the proxy while those chapters are not served. Choose the wrong network: twelve paid requests are rejected, but with respond on header all twelve are served without payment. Tick the missing chapter file: nine served and nine settled in the authorization flow, while the upfront flow settles ten and records one charge without delivery.

Inspect the trace and keep evidence

The table lists every request and replay with the quote, the client decision, the merchant and facilitator outcome, and whether the chapter was served and the payment settled; red rows are unsafe and amber rows were not served. The trace shows each 402 quote, client refusals, the facilitator results and the final summary. Start trace, Next step, Show all and the slider control how much of the trace is visible; the metrics always describe the whole run. Reset restores the defaults and Export JSON downloads the inputs, metrics and trace.

Limits and production translation

Real deployments sign EIP-712 typed data, check balances, simulate transfers on chain, and face network fees, reorgs and the settlement_pending case, none of which the model includes. Amounts on the wire are token atomic units, not rupees. What carries over: check amount, asset, network, payTo and paymentFlow before signing; prefer the authorization flow; never respond before at least one verify or settle; settle before responding or keep a nonce cache; size maxTimeoutSeconds for the facilitator's slow tail; and log the nonce, verify result and settlement hash for every paid response.