How x402 works end-to-end: HTTP 402 → signed USDC → settled data

protocol walkthrough · EIP-3009 · Base (eip155:8453) · 2026-07-13

x402 turns HTTP's long-reserved 402 Payment Required status into a working machine-payment rail. Here is the full lifecycle of one paid request against a live implementation (this API), with real numbers.

1. The challenge

An agent GETs https://api.newsgurus.ai/x402/regime with no payment. The server responds 402 with payment requirements: the scheme (exact), network (eip155:8453 — Base mainnet), the asset (USDC, 0x8335…2913), the receiving address, and maxAmountRequired (e.g. 2000 = $0.002 in 6-decimal USDC units).

2. The signature (gasless for the payer)

The agent signs an EIP-3009 transferWithAuthorization message: "transfer exactly this many USDC units from my wallet to that address, valid for this time window, with this nonce." Signing costs nothing and needs no ETH — the payer never submits an on-chain transaction.

3. The retry

The agent repeats the request with the signed payload attached (x402 v2 header transport: PAYMENT-SIGNATURE; v1 clients use X-PAYMENT). The server forwards it to a facilitator (Coinbase CDP's — free to sellers) which verifies the signature, amount, and nonce.

4. Verify → respond → settle (in that order)

Only after verification passes does the route handler run and return data. The facilitator then submits the authorization on-chain and the USDC lands in the seller's wallet — every sale is publicly auditable. The invariant worth copying if you build your own: verify before work, settle after success, and never withhold a response because settlement lagged.

What this enables

See it live

# the menu (free)
curl https://api.newsgurus.ai/x402/catalog

# the raw 402 challenge (free to look at)
curl -i https://api.newsgurus.ai/x402/regime

To complete a purchase from code, start at the buyer guide — about ten lines of Python.