Nestor G Pestelos Jr · Reference · Print this page
Reference
x402 (HTTP 402 Payment Protocol)
Updated September 2026
x402 is an open protocol that implements the HTTP 402 Payment Required status code to enable automated payments for autonomous AI agents and machine-to-machine services.[1] It allows web servers to gate API endpoints, computational resources, and raw data behind cryptographic micro-settlements, completing negotiation and payment in a single HTTP request-response flow without human intervention or subscription setup.[2]
Background and Origin
The Internet Engineering Task Force (IETF) specified the HTTP 402 status code in RFC 2068 and reaffirmed it in RFC 9110, designating it as "Payment Required" for future digital cash schemes.[1] For three decades, web infrastructure left status code 402 largely unstandardized because consumer payments defaulted to browser redirects, credit card forms, and proprietary OAuth token exchanges.
The emergence of autonomous software agents exposed the operational limits of card networks and human subscription models. Earlier protocols, such as L402 (formerly LSAT), paired HTTP 402 with the Bitcoin Lightning Network and Macaroons to enable API micropayments.[3] x402 generalized this approach for web standards, using Ethereum-compatible signed typed data (EIP-712), Solana payloads, and stablecoins like USDC to settle machine transactions directly over standard HTTP headers.[2] Initially introduced by Coinbase developers, governance was transferred to the independent x402 Foundation to maintain a neutral internet standard.[4]
Protocol Handshake
The x402 interaction executes across standard HTTP communication steps:
- Initial Resource Request: The client (such as an autonomous LLM agent) issues an unauthenticated HTTP GET or POST request to a protected API endpoint.
- Challenge (HTTP 402): The server responds with status code
402 Payment Required. The response header or JSON body contains payment parameters: acceptable token (such as USDC), price per request, destination wallet address, network chain identifier, and a unique cryptographic nonce to prevent replay attacks. - Payment Authorization: The client reads the challenge, verifies that the price falls within its pre-programmed spending mandate, and signs a payment payload with its private key.
- Resubmission: The client repeats the original request, attaching the signed authorization in a designated HTTP header (such as
PAYMENT-SIGNATURE). - Verification and Delivery: The server or an intermediary facilitator verifies the signature against the blockchain network. Once verified, the server serves the requested data with status code
200 OK.
Economic Rationale for Agents
Human commerce relies on high-trust, aggregated billing. Credit card interchange fees impose fixed costs (often 20 to 30 cents per transaction plus 2 to 3 percent), rendering transactions below one dollar economically unviable. Consequently, API providers sell access through recurring monthly subscription tiers or bulk prepaid credit balances.
Autonomous agents break this pattern. An agent often needs a single query from a specialized database, three seconds of GPU compute, or real-time sensor verification from an unfamiliar server. Negotiating terms of service or entering credit card credentials stalls machine execution. x402 eliminates subscription overhead by enabling granular pay-as-you-go settlement, where an agent pays fractions of a cent per request directly from its embedded cryptographic wallet.[5]
Implementations and Industry Support
Infrastructure providers and developer frameworks adopt x402 across several tiers of the software stack:
- Edge and Security Gateways: Cloudflare integrated HTTP 402 workflows through its Monetization Gateway and Agents SDK, allowing web publishers to charge scraping bots and AI crawlers per page read rather than relying solely on robots.txt blocks.[6] Similarly, AWS WAF rulesets support bot monetization using 402 challenges.
- Agent Frameworks: Coinbase AgentKit provides pre-packaged client libraries that automatically parse 402 challenges and sign payment headers during autonomous browser or API execution.[2]
- Facilitator Services: Third-party clearinghouses manage batch settlement and gas abstraction, allowing servers to accept signed payments without forcing the server operator to maintain complex node infrastructure.
Distinctions from Traditional Payment Rails
The table below summarizes the operational differences between traditional payment systems and x402:
| Dimension | Traditional Card Rails | x402 Protocol |
|---|---|---|
| Identity | Verified human cardholder via KYC and billing address | Cryptographic public address and spending mandate |
| Unit Economics | Multi-dollar minimum to amortize fixed interchange (20 to 30 cents) | Sub-cent micropayments via Layer-2 blockchains |
| Interaction Model | Interactive checkout forms, redirects, CAPTCHAs | Autonomous protocol handshake inside HTTP request cycle |
| Settlement & Dispute | Subjective 60-day chargeback window | Immediate cryptographic on-chain finality |
See also
References
- ↑ R. Fielding, M. Nottingham, J. Reschke, "HTTP Semantics," RFC 9110, Section 15.5.3: "402 Payment Required," Internet Engineering Task Force, June 2022. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.3
- ↑ "x402 Protocol Specification," x402 Foundation documentation. https://github.com/coinbase/x402
- ↑ "L402 Protocol: Lightning-Native Authentication and Payments," Lightning Labs documentation. https://docs.lightning.engineering/the-lightning-network/l402
- ↑ "The x402 Foundation: Open Standards for Agentic Payments," MetaMask Developer Resources (2025/2026).
- ↑ "Micropayments and Stablecoin Settlement for Machine-to-Machine Commerce," Circle Developer Documentation (2025/2026).
- ↑ "Monetizing AI Crawlers and Agents via HTTP 402," Cloudflare Technology Blog (2025/2026).