The 25-year-old status code that finally has a use
HTTP 402 Payment Required has been "reserved for future use" since the original HTTP spec. x402 is that future: a convention for using 402 to do real machine-to-machine payments over plain HTTP. No new protocol, no special port — just a 402 response with a structured body the client knows how to pay.
The handshake, concretely
A client requests a paid resource. The server responds 402 with an "accepts" array — each entry describing a way to pay: the scheme (e.g. "exact" for an exact-amount EVM/USDC transfer), the network (e.g. Base mainnet), the asset, the amount, and where to send it. The client picks a scheme it supports, makes the payment, attaches proof, and retries the request. The server verifies and returns the resource.
Because the 402 body is machine-readable, the agent does not need a human-built integration per API. Any x402-aware client can pay any x402 server.
Discovery: how agents find what they can pay for
A 402 only happens once you hit an endpoint. To find endpoints in the first place, x402 has a discovery layer — a catalog of resources, each with its canonical accepts[] entry. Crawlers and agent frameworks index these catalogs so an agent can ask "what can I buy?" before it spends anything.
A well-formed catalog lists each resource with its price, network, asset, and pay-to address, so an agent (or a directory like an x402 scanner / bazaar) can plan a purchase programmatically.
Credits vs on-chain
x402 supports more than one settlement scheme on the same resource. A server can accept a canonical on-chain USDC transfer AND a faster native-credit scheme. Agents that want instant, gas-free settlement use credits; agents that want pure on-chain settlement use the USDC scheme. The 402 body advertises both.