TL;DR
x402 is an open protocol from Coinbase that revives the HTTP 402 Payment Required status code as the basis for machine-to-machine payments. A server can require payment for any API endpoint by responding with HTTP 402 plus a structured payment challenge; the client — typically an AI agent — signs a stablecoin payment authorization and retries the request with the payment attached as an HTTP header. The protocol is designed for sub-cent settlement on Base (Layer-2 USDC), uses EIP-3009 signatures for gasless authorization, and is increasingly adopted by API providers serving AI agent traffic.
Why HTTP 402 needed reviving
HTTP 402 has been reserved in the HTTP specification since 1997, with the description “reserved for future use.” For nearly three decades there was no widely-agreed protocol-level meaning, and the few attempts to use it (Apple’s iAP, browser-based micropayments) failed at the standards level — usually because they required a centralized intermediary that no one trusted to operate.
The conditions that prevented adoption have changed. Stablecoins exist as a settlement asset that doesn’t require trust in any specific intermediary; AI agents exist as a use case where machine-to-machine payment is necessary rather than optional; HTTP-native payment is genuinely more efficient than out-of-band invoicing for sub-second commerce; and Layer-2 rollups with sub-cent fees make economically rational micropayments possible.
The protocol flow
A complete x402 transaction looks like this:
Step 1: the client makes a standard HTTP request to a protected resource. For example, an AI agent calls a paywalled image generation API.
Step 2: the server responds with HTTP/1.1 402 Payment Required and includes a JSON body specifying the price, the receiving address, the chain ID, the supported payment schemes, and a unique nonce. A typical response specifies "scheme": "exact" (payment of an exact amount), "network": "base", "asset": "USDC", and an amount in the smallest unit (e.g., "amount": "1000" for 0.001 USDC).
Step 3: the client constructs an EIP-3009 TransferWithAuthorization signature, which is a typed-data signature authorizing the server to transfer the specified USDC amount from the client’s wallet to the recipient. Critically, the client does not broadcast a transaction — it only signs. The signature includes the unique nonce from the server, preventing replay.
Step 4: the client retries the original request, this time including the signature in an X-PAYMENT HTTP header.
Step 5: the server verifies the signature, optionally calls a facilitator service to settle the payment on-chain (or batches it with other payments), and serves the response.
Why EIP-3009 specifically
The choice of EIP-3009 over alternatives like EIP-2612 (permit) or direct transfer reflects three design priorities. First, the client doesn’t pay gas: the recipient pays the on-chain settlement cost, which means an agent with a tiny USDC balance can transact without holding any ETH for gas. Second, off-chain authorization: the signature itself is cheap (no on-chain operation), so high-frequency payment patterns are economically viable. Third, explicit amount and recipient: unlike permit-based flows, which authorize a spender to transfer any amount up to a cap, EIP-3009 binds the signature to a specific amount and recipient, dramatically reducing the consequences of a misbehaving server.
The facilitator role
A facilitator is an optional service that handles the on-chain settlement step on behalf of the server. The reference Coinbase facilitator accepts the signed payment, batches multiple payments together, submits them to the chain, and returns settlement confirmations. This pattern is economically necessary because each individual payment is often smaller than the gas cost of settling it individually; batching restores efficiency.
Importantly, the facilitator is not trusted with funds — the EIP-3009 signature already specifies the recipient. The facilitator’s only role is to be the gas-paying party that submits the transaction. Multiple facilitator implementations exist, and the protocol does not assume any specific facilitator must be used.
When to use x402 vs alternatives
x402 makes sense when payments are frequent, small, and HTTP-native. AI agents calling paid APIs, micropayment-funded content access, agent-to-agent service calls in autonomous workflows. The protocol is less compelling for large-value transactions (where the protocol overhead is negligible relative to the transaction size and conventional flows work fine), for transactions requiring complex compliance flows (KYC, AML), or for cases where the buyer-seller relationship is durable enough to justify an account-based subscription.
For agents that need to span chains beyond Base, intent-based frameworks like Halliday’s solver competition fit better. For agents that need human-in-the-loop approval flows, Payman’s operator-side controls add value. For agents that need verifiable identity for merchant-side policy, Skyfire’s KYA passport layer extends what x402 provides at the payment layer.
Open questions
Three standardization questions remain unresolved. First, agent identity: x402 itself does not specify how the server should know which agent (or which agent’s owner) is paying. Skyfire’s KYA layer attempts to fill this, but no consensus exists on the standard interface. Second, dispute resolution: HTTP-native payments are final. There is no built-in chargeback mechanism. For high-value agent commerce, this is a real gap. Third, chain abstraction: although the protocol is chain-agnostic in principle, the network economics work best on a small subset of chains. Standardizing how a client and server negotiate which chain to use, in the presence of bridged USDC, is an ongoing discussion in the x402 working group.