x402 Flow Simulator
Step through the x402 payment protocol over HTTP — the 402 quote, EIP-3009 payment signature, facilitator verify/settle, and delivery — plus failure, facilitator-less, and agent-discovery variants.
GET /premium-data
Plain HTTP request — no payment attached yet.
The client requests the protected resource like any other endpoint: no account, no API key, no session. The x402 middleware on the resource server sees no PAYMENT-SIGNATURE header and short-circuits before the handler runs.
What the x402 protocol does
x402 activates the long-reserved HTTP status code 402 Payment Required as a real payment mechanism: a server quotes a price in machine-readable form, the client signs a stablecoin transfer authorization (USDC via EIP-3009 Transfer With Authorization), and retries the same request with the signed payload attached as a header. Verification and on-chain settlement are typically delegated to a facilitator service, so a resource server can charge per request with a few lines of middleware and no blockchain infrastructure of its own.
The protocol was introduced by Coinbase in May 2025 and is now stewarded by the x402 Foundation. Protocol v2 (December 2025) renamed the headers (X-PAYMENT → PAYMENT-SIGNATURE) and switched network identifiers to CAIP-2 (base → eip155:8453). Use the x402 Header Decoder to inspect the actual wire format of each header shown in this simulator.
Why it matters for payment engineers
x402 is the payment counterpart of the settlement shift covered in the Stablecoin Reference: where card networks are moving the settlement leg onto stablecoin rails, x402 moves the entire payment into the HTTP request/response cycle — no authorization hold, no clearing batch, no T+1. The trade-offs land elsewhere: replay protection lives in EIP-3009 nonces instead of ISO 8583 STANs, "decline codes" are facilitator error strings instead of DE39 values, and there is no native dispute or chargeback layer at all.
Common questions
Does the client pay gas for every request?
No. The client only signs an EIP-712 message — broadcasting the transfer (and paying gas) is done by the facilitator or the resource server. That is what makes sub-cent payments viable.
What prevents the server from charging more than authorized?
The signed authorization fixes the exact value, recipient, and validity window. The token contract re-validates the signature on-chain, so any tampering invalidates the transfer. The "exact" scheme also requires the settled amount to match the quoted amount precisely.
What happens on replay — the same header sent twice?
The EIP-3009 nonce is burned at the contract level on first settlement; a second settlement attempt with the same authorization reverts. Facilitators additionally reject reused nonces at verification time.
Flows follow the x402 v2 specification (x402 Foundation) and the Coinbase facilitator documentation. The simulator is illustrative — no network requests are made and nothing runs outside your browser.