x402 Explained: HTTP-Native Micropayments for AI Agents (With Real Code) A developer has introduced x402, an HTTP-native micropayment specification that enables AI agents to pay for external services using stablecoins directly within the HTTP request/response flow. The protocol repurposes the HTTP 402 status code to signal payment requirements, allowing agents to discover prices, make payments, and receive resources without leaving the HTTP context. The developer provides real code examples demonstrating how to implement x402 on both the server and agent sides. When autonomous AI agents need to call external services—LLM inference, data feeds, compute functions—they often encounter two practical problems: The x402 specification addresses both by embedding a lightweight payment handshake directly into HTTP status codes. Agents can discover a price, pay it with a stablecoin, and receive the requested resource—all without leaving the HTTP request/response flow. x402 is an extension of the HTTP status code space. It repurposes the 402 Payment Required code originally reserved for future use to signal that a resource is behind a paywall. The response includes a WWW-Authenticate header that conveys: x402 . Upon receiving a 402, the client can: Authorization header. Because the flow stays within HTTP, existing libraries, proxies, and caching layers continue to work unchanged—only the client needs to understand the 402 flow. | Component | Role | |---|---| | Resource Server | Exposes endpoints that may return 402. Holds a price list and validates payments. | | Payment Processor | Usually a smart contract on a low‑cost L2 e.g., Base that escrowed USDC and emits an event on successful transfer. | | Client Agent | Implements the 402 handshake: reads the challenge, signs/pays, retries with proof. | | Metadata | The WWW-Authenticate header contains a JSON object x402 scheme with fields: amount , asset , network , paymentPointer , maxTimeout . | WWW-Authenticate: x402 amount="0.05", asset="USDC", network="base:8453", paymentPointer="pay:0xA1b2.../invoice" Cache-Control: no-store for paid resources to avoid stale content. These trade‑offs mean x402 is best suited for services where the per‑call cost is low enough to absorb the blockchain overhead, and where agents can tolerate a few seconds of latency for guaranteed payment. Below is a self‑contained example that demonstrates: /summarize endpoint with x402. Note : For brevity, the payment processor is a mock contract that simply records the payer and amount. In production you would deploy a real ERC‑20 escrow contract e.g., OpenZeppelin’s ERC20Votes with a receive fallback and verify the transaction via an RPC call or a subgraph. server.js js // server.js const express = require 'express' ; const app = express ; const PORT = 3000; // Mock price: $0.05 USDC per call const PRICE USDC = BigInt '5000000' ; // 6 decimals = 0.05 1e6 const USDC ADDRESS = '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913'; // Base USDC app.use express.json ; function x402Challenge { return x402 amount="${Number PRICE USDC/1e6 }", asset="USDC", network="base:8453", paymentPointer="pay:${USDC ADDRESS}/invoice" ; } // Protect endpoint app.get '/summarize', req, res = { const auth = req.headers.authorization || ''; // Expect proof: "x402