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:

  1. Initial Resource Request: The client (such as an autonomous LLM agent) issues an unauthenticated HTTP GET or POST request to a protected API endpoint.
  2. 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.
  3. 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.
  4. Resubmission: The client repeats the original request, attaching the signed authorization in a designated HTTP header (such as PAYMENT-SIGNATURE).
  5. 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:

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

  1. 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
  2. "x402 Protocol Specification," x402 Foundation documentation. https://github.com/coinbase/x402
  3. "L402 Protocol: Lightning-Native Authentication and Payments," Lightning Labs documentation. https://docs.lightning.engineering/the-lightning-network/l402
  4. "The x402 Foundation: Open Standards for Agentic Payments," MetaMask Developer Resources (2025/2026).
  5. "Micropayments and Stablecoin Settlement for Machine-to-Machine Commerce," Circle Developer Documentation (2025/2026).
  6. "Monetizing AI Crawlers and Agents via HTTP 402," Cloudflare Technology Blog (2025/2026).