HTTP reserved status code 402 — "Payment Required" — in 1997 and never used it. x402 finally gives it a job: a standard way for a server to say "this request costs money," and for a client (increasingly, an AI agent) to pay and retry, all inside the HTTP exchange.
The flow in three steps
1. Agent calls a paid endpoint
→ 402 Payment Required
{ accepts: [{ scheme, network, asset: "USDC", payTo, maxAmountRequired }] }
2. Agent settles payment on-chain (or via a facilitator)
3. Agent retries with X-PAYMENT: <settlement proof>
→ server verifies with the facilitator → 200 OK, request fulfilled
No accounts, no API-key exchange, no card form. The payment is per-call, machine-verifiable, and bounded by the challenge's stated amount — which is exactly the shape autonomous agents need: every dollar maps to a specific request, and the spend authority lives in the wallet, not in a stored credential.
What it's good for (and not)
Good: pay-per-use APIs, one-shot purchases by agents with wallets, topping up a balance without a billing relationship. Less good: high-frequency micro-calls where you'd rather prepay once (that's what credit balances are for) and anything needing delegated human authority with limits (that's the Stripe ACP pattern — a human authorizes a capped token the agent presents). Mature services offer all three; the rails are complementary, not competing.
A concrete example
Forward sells growth outcomes (leads, meetings, content, conversions) and exposes x402 as a first-class rail: POST /api/v1/credits/topup with no payment returns a real 402 challenge with accepts/payTo/facilitator; settle and retry with X-PAYMENT and the credits land — then checkouts spend them with hard caps, itemized charges, and automatic reversal on failed verification. The full agent flow is documented in llms.txt, and how the safety invariants work is covered in safe autonomous spending.