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.
x402 through a card-rails lens
For engineers coming from ISO 8583 and card processing, the fastest way to understand x402 is by mapping its concepts onto the ones you already operate:
| Card rails | x402 | Notes |
|---|---|---|
| Authorization (ISO 8583 0100) | EIP-3009 signature + facilitator /verify | Both check "can this payment succeed?" — but x402 verification simulates the actual transfer against live chain state. |
| Auth hold on open-to-buy | None | Nothing is reserved. A verified payment can still fail at settle if the balance moved — mitigated by verifying and settling within seconds. |
| Clearing & settlement (T+1/T+2 batch) | On-chain transfer, seconds | See Settlement & Clearing for the card-side pipeline x402 collapses into one step. |
| STAN / retrieval reference | EIP-3009 nonce + tx hash | The nonce guarantees uniqueness; the tx hash is a publicly verifiable receipt. |
| DE39 response codes | Error strings | insufficient_funds, invalid_exact_evm_payload_signature, … — compare Response Code Reference. |
| Interchange + scheme fees | Gas (paid by facilitator/server) | Facilitators may charge their own fees; the protocol itself has none. |
| Chargebacks & disputes | None | Transfers are final. Refunds are voluntary reverse payments — a real gap for consumer-facing use. |
| PCI DSS scope | No card data | Nothing to vault: the "credential" is a single-use signed authorization. |
Where it fits alongside stablecoin settlement
x402 and card-network stablecoin settlement are complementary movements of the same shift. Visa and Mastercard are replacing the fiat wire in the issuer/acquirer settlement leg with USDC-family transfers while leaving authorization untouched — x402 goes further and replaces the entire payment with an on-chain transfer, but only for HTTP-addressable resources. One modernizes existing card flows; the other serves payments cards were never designed for (per-request API pricing, agent-to-agent commerce).
Open engineering questions
- Facilitator concentration. Running without one requires RPC access, a gas-funded hot wallet, and nonce management — so most traffic flows through a few hosted facilitators, a trust point the protocol otherwise avoids.
- Token coverage. EIP-3009 support is effectively USDC-only on EVM chains today; broader ERC-20 support needs new schemes or token upgrades.
- Compliance. The protocol carries no KYC, sanctions-screening, or travel-rule machinery; those obligations land on implementers and facilitators.
- Refunds and disputes. No native mechanism — services need their own refund policies, executed as ordinary reverse transfers.
Related: x402 Flow Simulator · x402 Header Decoder · Stablecoin Reference · Calldata & EIP-712 Decoder · Settlement & Clearing Guide