x402 is an open protocol that turns the long-dormant HTTP 402 Payment Required status code into a working machine-payment handshake: a server can tell a client exactly how to pay for a resource, in the response itself, and the client can pay and retry in the same exchange. No account creation, no stored card, no API key — payment is the authentication.
Where 402 came from
HTTP 402 has been reserved "for future use" since the original HTTP/1.1 specification in the 1990s. It was never standardized for anything, which left it sitting unused for three decades while 401 (Unauthorized), 403 (Forbidden) and 404 (Not Found) became some of the most recognizable codes on the web. x402 is what happens when someone finally builds the "future use" the spec always gestured at: a status code whose entire job is "you need to pay, and here's exactly how."
The full round trip
Concretely, an x402 exchange is two HTTP requests:
1) GET /api/security/abc123 (no payment attached)
<- HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"x402Version": 2,
"accepts": [
{
"scheme": "exact",
"network": "eip155:8453",
"payTo": "0xf8A376...def22f",
"asset": "0x833589...bdA02913",
"amount": "10000",
"maxTimeoutSeconds": 120
}
]
}
2) [agent settles a payment matching one accepts[] entry]
3) GET /api/security/abc123
Header: PAYMENT-SIGNATURE: <base64 proof>
<- HTTP/1.1 200 OK
{ ...the resource... }Everything an agent needs to decide whether and how to pay is in that first 402 response — no separate pricing page, no documentation lookup, no signup flow. That's the entire value proposition in one exchange.
Reading an accepts[] entry
| Field | Meaning |
|---|---|
scheme | How the payment is constructed and verified. exact is the common case: pay this exact amount. Other schemes exist for different settlement mechanics (e.g. batched settlement). |
network | A CAIP-2 chain id — eip155:8453 is Base, solana:5eykt4Us... is Solana mainnet. A resource can list multiple accepts[] entries across several networks; the caller picks whichever it can settle. |
payTo | The address that receives payment. On Agent Bazaar this goes straight from the caller's wallet to the provider's — the marketplace is never in the payment path. |
asset | The token contract (almost always USDC in practice, though the protocol doesn't require it). |
amount | In the asset's base units — e.g. 10000 for 0.01 USDC (6 decimals). |
maxTimeoutSeconds | How long the quoted price is valid before the caller needs to re-request the 402. |
Facilitators, and why most integrations don't need to think about them
Settling an on-chain payment and then proving that settlement to the server can be handled two ways: the caller submits the transaction itself and includes proof, or a facilitator — a third-party service both sides trust — verifies and relays settlement so the client library only has to sign, not manage RPC nodes and confirmation polling. Most x402 client libraries default to using a facilitator, which is why "pay with x402" from an agent's side is usually a handful of lines, not a blockchain integration project. See solana-x402 for a zero-dependency reference implementation that supports both self-verified and facilitator-routed settlement.
What x402 deliberately doesn't do
x402 has no concept of accounts, sessions, or identity beyond a wallet address. It doesn't handle discovery (that's what a marketplace like this one, or an MCP tool list, or an A2A agent card is for) and it doesn't handle subscription billing or usage aggregation across calls — every request is priced and paid independently. That narrowness is a feature: it's a payment primitive other systems compose on top of, not a full commerce platform trying to do everything.
Try it
Every resource on Agent Bazaar publishes real accepts[] — see an example, or read the full guide to actually writing the client code in How Do AI Agents Pay for APIs?