HTTP 402 & x402: How AI Agents Pay for Content

HTTP 402 Payment Required sat reserved in the web specification for over 30 years without a standard behind it. x402, originated at Coinbase and now stewarded by the x402 Foundation with backing from Cloudflare, Visa and others, gives it one. A server answers an unpaid request with 402 and structured payment requirements. The client, often an AI agent, signs a payment with its wallet and retries the request with proof attached. A facilitator or the server verifies and settles the payment onchain, then returns the resource. This brief covers the core concepts, the request flow and headers, the role of facilitators and wallets, security concerns, and how x402 compares with API keys and cards.

Key concepts

HTTP 402 Payment Required

A status code reserved in early HTTP for future digital payments but never formally standardized. x402 gives it a defined, machine-readable meaning for payment negotiation. S1 · fireblocks.comS4 · eco.com

x402 protocol

An open payment standard, not a new coin or proprietary platform, that lets any HTTP client and server transact value, including micropayments, in the normal request-response cycle. S2 · medium.comS6 · x402.org

Facilitator

An onchain verification and settlement service. It checks the signature and balance and settles the payment, so resource servers need not run blockchain nodes or manage wallets. S4 · eco.com

PaymentRequired payload

The structured body of a 402 response. It contains the amount due, accepted currencies, receiving address, and a nonce or expiry to prevent replay attacks. S1 · fireblocks.com

Payment headers (V2)

PAYMENT-REQUIRED carries Base64-encoded requirements from server to client. PAYMENT-SIGNATURE carries the payment payload on retry. PAYMENT-RESPONSE reports the settlement result. S7 · stablecoininsider.org

Agentic wallet

A digital account controlled by software rather than a person, letting an agent hold funds and sign transactions programmatically. Coinbase Agentic Wallets are cited as one example. S5 · asbacademy.com

The x402 request-pay-retry cycle

1. Client requests a resourceThe agent or application sends a standard HTTP request to the resource server, with no special payment handling at this stage.
2. Server answers 402If payment is required, the server returns 402 with payment requirements: price, accepted tokens, recipient address and settlement network. In V2 these arrive in a PAYMENT-REQUIRED header.
3. Client signs a payment payloadThe client picks a wallet and asset and signs a payload. EIP-3009 tokens such as USDC use a gasless authorization signature; other ERC-20 tokens use Permit2.
4. Client retries with paymentThe original request is resent with the signed payment in a header. V2 names it PAYMENT-SIGNATURE; the Fireblocks glossary describes an X-Payment header.
5. Verify, settle, deliverThe server forwards the payment to a facilitator, which verifies the signature, checks the balance and settles onchain. The server then returns the resource with a PAYMENT-RESPONSE header.

Protocol flow and header conventions

x402 extends standard HTTP semantics. A server registers a resource as payable and configures accepted payment terms. When a client hits the endpoint without valid payment, the server returns 402 plus a structured payload with the amount due, accepted currencies, receiving address, and a nonce or expiry to prevent replay attacks. The payment client interprets the payload, selects a wallet and asset, constructs a signed transaction and re-issues the request with the payment proof in a header. The challenge-then-retry pattern resembles the familiar 401 and 407 flows, which is part of why x402 fits web infrastructure. Header naming differs between descriptions. One source describes an X-Payment header. Another documents V2 with PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE, all Base64-encoded, and calls V2 the recommended version, citing standardized identifiers, better type-safety and more modularity than V1. Implementers should target the version their libraries and facilitators support.

Facilitators, wallets and security

The architecture has three parties: the client, the resource server and the facilitator. The facilitator abstracts onchain complexity, so API providers avoid running nodes or managing wallets. One source says merchants need no blockchain expertise and compares adding x402 to adding an API key check, roughly 10 lines of middleware code. On the client side, agents need wallets they can use without a human. Agentic wallets are controlled by software and sign transactions programmatically. Security guidance for such wallets is direct: if a private key is compromised, an attacker can drain the agent wallet. Recommended mitigations include hardware security modules for key storage, access controls that limit what an agent can do, time-bound permissions that expire after specific tasks, smart contracts that enforce usage rules before funds are released, audits of code handling autonomous funds, and monitoring for unusual spending patterns.

Adoption, backers and use cases

x402 originated in work by Coinbase, and its whitepaper by Coinbase Developer Platform authors is dated May 6, 2025. It is now stewarded by the x402 Foundation, with backing from Cloudflare, Visa and others. One source says Coinbase contributed Base blockchain infrastructure and USDC payment rails, while Cloudflare contributed Workers-native middleware so APIs deployed on Cloudflare can accept x402 payments with minimal configuration. The same source contrasts x402 as an open specification with Stripe's proprietary Machine Payments Protocol. Described use cases include per-query AI API billing, pay-per-article web content, agent-to-agent service markets and autonomous procurement. The whitepaper frames the value as pragmatic micropayments and seamless pay-per-use monetization, and it lists mitigating fraud, chargebacks and compliance overhead and chain- and token-agnostic payments as operational benefits. Related standards discussed alongside x402 include Google's Agent2Agent (A2A) and Agent Payments Protocol (AP2).

x402 versus API keys and cards for agents

Timeline

1. 2025-05
   Coinbase Developer Platform publishes the x402 whitepaper, dated May 6, 2025.x402.org
2. 2025
   Cloudflare and Coinbase announce plans to launch the x402 Foundation.medium.com
3. 2026
   Coinbase and Cloudflare are described as putting HTTP 402 to work in early 2026.digitalapplied.com
4. 2026
   V2 is described as the recommended x402 version.stablecoininsider.org

Common pitfalls

• x402 is a Payment Required signal, not an authentication challenge. Treating 402 like 401 or 403 login handling misses the payment payload, signing and settlement steps.
• Header names and identifiers vary across descriptions: X-Payment in one, PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE in V2. Verify against the version your libraries implement.
• A compromised private key lets an attacker drain the agent wallet. Use hardware security modules, limit agent actions and issue time-bound permissions.
• Payment signing differs by token: EIP-3009 tokens like USDC use a gasless authorization signature, other ERC-20 tokens use Permit2. Include a nonce or expiry to prevent replay.

Key takeaways

• x402 makes HTTP 402 functional: the server quotes terms, the client signs and retries, and settlement happens onchain.
• Facilitators let API providers accept payments without running nodes or managing wallets, keeping server integration light.
• Agent wallets need strict controls: secure key storage, scoped and time-bound permissions, and spending monitoring.

FAQ

How this page is made. Built from the full text of 7 sources found with the AISA Tavily API (advanced search), refreshed weekly. A language model organizes what those sources state into the blocks above; each block links the sources it draws on, and figures that do not appear in the sources are removed.