← Payment Reference GuidesInternet-Native Payments

The x402 Payment Protocol

How HTTP 402 Payment Required became a real payment rail: the request/quote/sign/settle handshake, the EIP-3009 stablecoin authorization underneath it, the facilitator model, and what it means for payment engineers coming from card rails.

The payment handshake

The whole protocol is one 402-and-retry cycle. With a facilitator (the common deployment), eight messages complete a paid request:

1

Request → 402 quote

  1. Client sends a normal request: GET /premium-data.
  2. Server responds 402 Payment Required with a base64 PaymentRequired object in the PAYMENT-REQUIRED header: an accepts array of payment options (scheme, network, amount, asset, payTo, timeout).
2

Sign → retry

  1. Client picks one option and signs an EIP-712 typed message — TransferWithAuthorization { from, to, value, validAfter, validBefore, nonce } (EIP-3009). The random 32-byte nonce prevents replay; the validity window bounds its lifetime.
  2. Client retries the identical request with the signed PaymentPayload base64-encoded in the PAYMENT-SIGNATURE header.
3

Verify → settle → deliver

  1. Server POSTs payload + requirements to the facilitator's /verify endpoint. The facilitator checks the signature recovers to the payer, the balance covers the value, the amount matches exactly, the time window is open — and simulates the transfer.
  2. On isValid: true, the server does the work, then POSTs the same body to /settle. The facilitator broadcasts transferWithAuthorization on the token contract, paying gas.
  3. Server returns 200 OK with the resource and the settlement receipt (success, tx hash, network, payer) base64-encoded in the PAYMENT-RESPONSE header.

Failure is cheap

If verification fails — insufficient_funds, expired window, bad signature — the server simply answers 402 again with the reason. Nothing was broadcast, so there is nothing to reverse: no auth hold to release, no chargeback, no reconciliation break. The unused authorization dies at validBefore.

Discovery: the Bazaar

Facilitators can expose a discovery API (GET /discovery/resources) listing x402-enabled endpoints with their payment requirements. An agent can compare prices upfront, pre-sign the payment, and attach it to its first request — skipping the initial 402 round-trip entirely.

Watch each variant animated: x402 Flow Simulator →