27 years “reserved for future use.” Then Coinbase, Cloudflare, and Circle turned an unused HTTP status code into the payment layer for 75 million+ autonomous transactions.
75M+
x402 Transactions
27
Years Reserved
<2s
Settlement
USDC
Token
Every web developer learns the HTTP status codes early: 200 OK, 404 Not Found, 401 Unauthorized. But there is one code that almost nobody has seen in the wild until recently: 402 Payment Required. Defined alongside its neighbors in 1999, HTTP 402 was tagged “reserved for future use” because the internet lacked a native payment mechanism that software could operate autonomously. Credit cards require human checkout. PayPal requires accounts. Neither is something an AI agent can use.
That future arrived in October 2025 when Coinbase published x402, an open protocol that gives HTTP 402 a concrete implementation backed by USDC stablecoins on fast blockchains. By January 2026, Cloudflare joined to form the x402 Foundation, Circle announced official USDC integration for agent payments, and x402scan.com began tracking over 75 million transactions. This article traces HTTP 402 from its origins in RFC 2616 through RFC 7231 to the real-world x402 implementations running in production today — including Proxies.sx, Cloudflare's AI Content Marketplace, Coinbase CDP, and the emerging MCP + x402 agent ecosystem.
How a single line in an RFC became the most patient status code in internet history.
HTTP status codes were formalized in RFC 2616, published in June 1999 by the Internet Engineering Task Force (IETF). The 4xx client error class included codes for every anticipated failure mode: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, and so on. Nestled between 401 and 403 sat 402 Payment Required, accompanied by a single sentence that would remain unchanged for over a quarter century:
“This code is reserved for future use.”
The authors anticipated a web where browsers would negotiate micropayments natively. Digital cash systems like DigiCash and CyberCash existed in the late 1990s, but they required custom browser plugins and centralized intermediaries. When those companies failed, 402 had no implementation to point to.
Fifteen years later, the IETF published RFC 7231 (June 2014), a comprehensive update to HTTP/1.1 semantics and content. The working group reviewed every status code. They updated many: 301 and 302 got clearer redirect semantics, 405 gained precision about allowed methods, and several codes received expanded guidance. But 402? The language remained identical:
“The 402 (Payment Required) status code is reserved for future use.”
By 2014, Stripe, Braintree, and PayPal had become the dominant payment APIs. They used 401 for authentication failures and 403 for authorization failures. Nobody used 402. The code was a known curiosity in developer education but had zero real-world presence in HTTP traffic.
Several attempts were made to give 402 purpose. The W3C Micropayments Working Group (2003) explored browser-native payment flows. Bitcoin's Lightning Network (2018) experimented with 402 + Lightning invoices. The W3C Payment Request API (2017) standardized human checkout in browsers. None addressed the core challenge: how does a machine pay another machine without human intervention? That question would wait until stablecoins on fast Layer 2 blockchains provided the answer.
HTTP 402 Payment Required is defined as part of the HTTP/1.1 specification. The authors write: "This code is reserved for future use." No implementation guidance is provided. The internet lacks the payment infrastructure to make web-native payments practical.
The W3C forms a working group to explore micropayments for web content. Several proposals reference HTTP 402, but none gain traction. The group disbands without a standard. PayPal and credit cards dominate online payments, neither suitable for machine-to-machine use.
The IETF updates the HTTP semantics specification. HTTP 402 is preserved verbatim: "reserved for future use." Fifteen years of web commerce have passed, and the code remains a placeholder. Stripe, Braintree, and PayPal APIs use 401/403 instead.
The W3C publishes the Payment Request API for browsers. It standardizes checkout flows in Chrome, Firefox, and Safari but targets human-driven purchases with card-based payments. HTTP 402 is not used. Machines still have no way to pay.
Early Bitcoin Lightning developers experiment with HTTP 402 + Lightning invoices for pay-per-article content. Projects like Yalls.org demonstrate the concept, but Bitcoin price volatility and Lightning complexity limit adoption to hobbyist use.
Circle launches native USDC on Base, Arbitrum, and Solana. For the first time, a stable-value programmable token exists on chains with sub-second finality and sub-cent fees. The missing ingredient for HTTP 402 finally exists: fast, cheap, stable digital money.
Coinbase releases x402 as an open-source protocol specification with reference implementations for Node.js, Python, Go, and Solidity. The protocol formally defines how HTTP 402 responses carry payment terms and how clients prove on-chain payment. 27 years of "reserved for future use" ends.
Coinbase and Cloudflare launch the x402 Foundation to govern the protocol. Cloudflare adds native x402 support at the CDN edge, enabling any website to paywall content for AI bots. Circle announces official USDC integration for x402 agent payments.
x402scan.com reports over 75 million x402 transactions across Base and Solana. Thousands of APIs accept x402 payments. The protocol is integrated into LangChain, CrewAI, Claude MCP, and every major agent framework. HTTP 402 is no longer reserved for future use - the future arrived.
Created by Coinbase in October 2025, x402 defines how HTTP clients and servers negotiate, execute, and verify on-chain payments in a single request-response cycle.
The x402 specification is deliberately minimal. It adds exactly two things to standard HTTP: a structured 402 response format and a payment proof header. Everything else — the blockchain transactions, wallet management, and token transfers — happens through existing infrastructure. This minimalism is the protocol's strength: any HTTP client or server can adopt it without fundamental changes.
The AI agent (or any HTTP client) makes a normal GET or POST request to the API endpoint. At this point, the client may or may not know that payment is required.
The server responds with HTTP 402 Payment Required. The response body contains a JSON object with the x402 payment terms: protocol version, exact price in the smallest token unit, currency (USDC), recipient wallet address, blockchain network (base or solana), and an expiration window.
The client reads the payment terms, constructs a USDC transfer transaction to the specified recipient for the exact amount, signs it with the agent wallet key, and broadcasts it to the blockchain. On Base this settles in approximately 2 seconds; on Solana, approximately 400 milliseconds.
The client replays the original HTTP request, adding a Payment-Signature header that contains the on-chain transaction hash (and optionally the network identifier). This is the proof that payment was made.
The server reads the Payment-Signature header, queries the blockchain to verify: (a) the transaction exists, (b) it transferred the correct amount of USDC, (c) to the correct recipient, (d) with sufficient confirmations. If valid, it returns HTTP 200 with the requested resource.
HTTP/1.1 402 Payment Required
Content-Type: application/json
X-Payment-Required: true
{
"x402Version": 1,
"price": "4000000",
"currency": "USDC",
"decimals": 6,
"recipient": "0xF8cD900794245fc36CBE65be9afc23CDF5103042",
"network": "base",
"description": "1 GB 4G mobile proxy bandwidth - US",
"expiresAt": "2026-02-08T12:05:00Z",
"resourceUrl": "/v1/proxy/create?country=US&type=4g&gb=1",
"acceptedNetworks": ["base", "solana"]
}GET /v1/proxy/create?country=US&type=4g&gb=1 HTTP/1.1
Host: api.proxies.sx
Accept: application/json
Payment-Signature: 0x8a7d39f2c1b4e5a6d7c8f9e0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
X-Payment-Network: base
---
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "active",
"proxy": {
"host": "us-4g-9183.proxies.sx",
"port": 5057,
"username": "agent_x402_8a7d",
"password": "Qm9xZnVhb3",
"protocol": "socks5",
"country": "US",
"type": "4g",
"bandwidth_gb": 1,
"expires_at": "2026-03-08T12:00:00Z"
},
"payment": {
"tx_hash": "0x8a7d39f2c1b4e5a6d7c8f9e0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0",
"amount": "4.00",
"currency": "USDC",
"network": "base",
"verified_at": "2026-02-08T12:00:03Z"
}
}Production-ready code for both sides of the x402 handshake.
This middleware wraps any Express route to require USDC payment via x402. It returns 402 with payment terms when no proof is provided, and verifies on-chain payment when the Payment-Signature header is present.
import express from "express";
import { ethers } from "ethers";
const BASE_RPC = "https://mainnet.base.org";
const USDC_BASE = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913";
const MY_WALLET = "0xYourWalletAddress";
const ERC20_ABI = [
"event Transfer(address indexed from, address indexed to, uint256 value)"
];
function x402Paywall(priceUSDC: string, description: string) {
return async (req: express.Request, res: express.Response, next: express.NextFunction) => {
const paymentSig = req.headers["payment-signature"] as string;
if (!paymentSig) {
// Return 402 with structured payment terms
return res.status(402).json({
x402Version: 1,
price: (parseFloat(priceUSDC) * 1e6).toString(),
currency: "USDC",
decimals: 6,
recipient: MY_WALLET,
network: "base",
description,
expiresAt: new Date(Date.now() + 300_000).toISOString(),
resourceUrl: req.originalUrl,
acceptedNetworks: ["base", "solana"],
});
}
// Verify on-chain payment
const provider = new ethers.JsonRpcProvider(BASE_RPC);
const receipt = await provider.getTransactionReceipt(paymentSig);
if (!receipt || receipt.status !== 1) {
return res.status(400).json({ error: "invalid_payment" });
}
const iface = new ethers.Interface(ERC20_ABI);
const transferLog = receipt.logs.find(log => {
try {
const parsed = iface.parseLog({ topics: [...log.topics], data: log.data });
return parsed?.name === "Transfer"
&& parsed.args.to.toLowerCase() === MY_WALLET.toLowerCase()
&& log.address.toLowerCase() === USDC_BASE.toLowerCase();
} catch { return false; }
});
if (!transferLog) {
return res.status(400).json({ error: "no_usdc_transfer_found" });
}
const parsed = iface.parseLog({
topics: [...transferLog.topics],
data: transferLog.data
});
const paidAmount = parseFloat(ethers.formatUnits(parsed!.args.value, 6));
if (paidAmount < parseFloat(priceUSDC)) {
return res.status(400).json({
error: "insufficient_payment",
required: priceUSDC,
received: paidAmount.toString()
});
}
// Attach payment info and proceed
(req as any).x402Payment = {
txHash: paymentSig,
amount: paidAmount,
from: parsed!.args.from
};
next();
};
}
// Usage: protect any route
const app = express();
app.get("/v1/data",
x402Paywall("0.10", "Single API call"),
(req, res) => {
res.json({ data: "premium content", payment: (req as any).x402Payment });
}
);A complete agent-side implementation that handles the full x402 flow: request, parse 402, pay on-chain, retry with proof.
import { ethers } from "ethers";
const USDC_BASE = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913";
const ERC20_ABI = ["function transfer(address to, uint256 amount) returns (bool)"];
async function x402Fetch(url: string, walletKey: string): Promise<any> {
// Step 1: Initial request
const res = await fetch(url);
if (res.status !== 402) {
return res.json(); // Resource was free or already paid
}
// Step 2: Parse x402 payment terms
const terms = await res.json();
console.log(`Payment required: ${terms.price / 1e6} ${terms.currency} on ${terms.network}`);
// Step 3: Check expiration
if (new Date(terms.expiresAt) < new Date()) {
throw new Error("Payment terms expired, retry the request");
}
// Step 4: Execute on-chain USDC transfer
const provider = new ethers.JsonRpcProvider("https://mainnet.base.org");
const wallet = new ethers.Wallet(walletKey, provider);
const usdc = new ethers.Contract(USDC_BASE, ERC20_ABI, wallet);
const tx = await usdc.transfer(terms.recipient, BigInt(terms.price));
const receipt = await tx.wait();
console.log(`Paid: tx ${receipt.hash}`);
// Step 5: Retry with payment proof
const paidRes = await fetch(url, {
headers: {
"Payment-Signature": receipt.hash,
"X-Payment-Network": terms.network,
},
});
if (!paidRes.ok) {
throw new Error(`Payment verified but resource failed: ${paidRes.status}`);
}
return paidRes.json();
}
// Usage
const proxy = await x402Fetch(
"https://api.proxies.sx/v1/x402/proxy/create?country=US&type=4g",
process.env.AGENT_WALLET_KEY!
);
console.log("Proxy credentials:", proxy);Six production implementations that are live, processing transactions, and proving the x402 model works at scale.
Mobile proxy bandwidth via x402 — first production implementation
Proxies.sx was among the first services to implement x402 in production. AI agents can purchase 4G/5G mobile proxy bandwidth at $4–8/GB (depending on volume) by sending a standard HTTP request to the API. The server returns 402 with USDC pricing, the agent pays on Base or Solana, and proxy credentials (SOCKS5/HTTP) are delivered instantly. No account registration, no API keys, no human involvement.
The x402 marketplace at agents.proxies.sx/marketplace/ lists all available proxy products: per-GB bandwidth, monthly port rentals, country-specific endpoints, and rotation configurations. Each product has a machine-readable x402 endpoint that agents can discover and purchase autonomously.
Price Range
$4-8/GB
Networks
Base, Solana
Setup Time
<5 seconds
Websites charge AI bots per crawl — launched July 2025
Cloudflare's AI Content Marketplace, launched in July 2025, allows website owners to set a price for AI crawlers to access their content. When an AI bot (GPTBot, ClaudeBot, etc.) requests a page on a Cloudflare-protected site, the CDN edge can return a 402 response with x402 payment terms instead of blocking the bot entirely. The AI company's agent pays the per-page or per-crawl fee in USDC, and the content is served.
This is significant because it transforms the adversarial relationship between publishers and AI companies into a commercial one. Instead of robots.txt blocking all AI crawlers, publishers can monetize access. By January 2026, Cloudflare reported that thousands of domains had opted into the marketplace, and Coinbase's co-founding of the x402 Foundation with Cloudflare cemented this as a core use case for the protocol.
Stablecoin payments for AI agents at scale
Circle, the issuer of USDC, announced official x402 integration in January 2026. This means Circle's Programmable Wallets API now includes native x402 support: developers can create agent wallets that automatically handle the 402 → pay → retry flow. Circle also committed to maintaining USDC liquidity on all x402-supported chains and providing enterprise-grade wallet infrastructure for organizations running fleets of AI agents.
The Circle integration is particularly important for enterprise adoption. Companies that were hesitant to give AI agents access to raw crypto wallets can now use Circle's compliance-ready wallet infrastructure with spending limits, audit trails, and multi-signature approvals — while still benefiting from x402's permissionless payment flow at the protocol level.
x402 SDK in the Coinbase Developer Platform
Coinbase embedded x402 directly into its Developer Platform (CDP). The CDP SDK includes a high-level x402Client class that abstracts the entire payment flow into a single function call. Developers building agents on CDP do not need to manage wallet keys, parse 402 responses, or construct transactions — the SDK handles it all.
CDP also provides a server-side SDK for API providers who want to accept x402 payments. The x402Middleware package drops into Express, Fastify, Hono, or any Node.js framework. For Python developers, an equivalent ASGI/WSGI middleware is available. The Coinbase Commerce dashboard shows x402 revenue alongside traditional payment revenue, giving businesses a unified view of both human and agent customers.
AI agents discover, evaluate, and pay for tools autonomously
The Model Context Protocol (MCP), originally developed by Anthropic, provides a standard way for AI agents to discover and invoke tools. When combined with x402, agents gain the ability to not just discover tools but pay for them autonomously. An MCP server can expose tool descriptions that include x402 pricing metadata. When the agent decides to use a paid tool, the MCP client handles the x402 negotiation behind the scenes.
This pattern is already live with Proxies.sx's MCP Server. Claude, Cursor, and other MCP-compatible clients can issue natural-language commands like “Create a US 4G proxy” and the MCP server handles the x402 payment negotiation, on-chain transfer, and credential delivery transparently. The agent never sees the 402 response directly; it just gets the tool result.
The MCP + x402 pattern is the likely future of AI tool ecosystems: agents browse tool registries, compare prices, pay per-use in USDC, and switch providers based on cost and quality — exactly like humans shopping for SaaS, but at machine speed.
Google's Agent Payments Protocol vs x402
Google's AP2 (API Payments Protocol), announced alongside Visa, Mastercard, PayPal, and Stripe, takes a fundamentally different approach than x402. Where x402 is blockchain-native and permissionless, AP2 is rail-agnostic and governance-heavy. AP2 uses “mandates” — human-approved spending policies that define what an agent can buy, from which vendors, up to what limit, and for how long. The payment can settle on credit cards, bank transfers, or crypto.
The two protocols are not necessarily competitors — they serve different trust models. x402 is ideal for fully autonomous agents operating in permissionless environments (crypto-native applications, open-source agent frameworks, anonymous tool access). AP2 is ideal for enterprise agents that operate under corporate spending policies with audit requirements. Many organizations in 2026 use both: x402 for agent-to-agent microtransactions and AP2 for high-value purchases that require human approval.
| Dimension | x402 | Google AP2 |
|---|---|---|
| Created by | Coinbase (Oct 2025) | Google + Visa/MC/PayPal (2025) |
| Settlement | On-chain USDC | Cards, banks, crypto |
| Registration | None (permissionless) | Merchant enrollment |
| Human approval | Not required | Mandate-based policies |
| Speed | <3 sec (Base), <1 sec (Solana) | Variable by rail |
| Fees | <$0.01 (L2 gas only) | ~2.5% (card), varies |
| Spending controls | Wallet balance only | Rich policy engine |
| Audit trail | Blockchain (public) | Private + compliance |
| Best for | Autonomous agents | Enterprise governance |
| Open source | Fully open | Spec open, rails closed |
How x402 compares with every other attempt to bring native payments to the web.
HTTP 402 has been the subject of many proposals over its 27-year history. Understanding why previous attempts failed — and why x402 succeeded — requires examining each alternative on its own terms.
The W3C Payment Request API standardizes how browsers present payment sheets to users. It is implemented in Chrome, Firefox, Safari, and Edge. When a website calls navigator.payment.request(), the browser displays a native payment UI with saved cards and addresses.
Why it does not solve the machine-payment problem: The Payment Request API is fundamentally human-facing. It requires a browser context, user interaction (clicking “Pay”), and card-based settlement. An AI agent running as a headless process cannot use it. It also does not use HTTP 402 — the payment negotiation happens at the JavaScript level, not the HTTP level.
Several Bitcoin developers experimented with combining HTTP 402 and Lightning Network invoices. The pattern was similar to x402: server returns 402 with a Lightning invoice (BOLT11 string), client pays the invoice, retries with the payment preimage. Projects like Yalls.org (pay-per-article), LNbits, and various Lightning paywall plugins demonstrated the concept.
Why it gained limited traction: Bitcoin price volatility made it impossible to price API calls in stable dollar terms. A call that costs $0.10 today might cost $0.15 or $0.07 tomorrow. Lightning channel management is complex and requires upfront capital. The developer tooling was immature. And critically, there was no stablecoin on Lightning (wrapped USDT on Lightning is a 2024 development). x402's use of USDC solves all of these issues: stable pricing, no channel management, mature tooling, and deep liquidity.
The current dominant model for paid APIs: developers sign up for an account, add a credit card, receive an API key, and are billed monthly based on usage. Stripe, AWS API Gateway, and RapidHub all use this pattern. It works well for human developers but creates friction for AI agents.
The machine-payment gap: An AI agent cannot sign up for accounts, fill out forms, or manage API keys across hundreds of services. Pre-provisioning keys for every service an agent might need is impractical. x402 eliminates this friction entirely: the agent discovers the price at request time and pays per-use. For a deeper comparison, see x402 vs Stripe: API Monetization for the Agent Era.
| Standard | Machine-Native | Stable Value | No Account | Sub-$0.01 Fees | Production Scale |
|---|---|---|---|---|---|
| x402 (USDC) | |||||
| Google AP2 | — | — | |||
| Lightning + 402 | — | — | |||
| W3C Payment Request | — | — | — | ||
| Stripe / API Keys | — | — | — |
x402 is the only standard that checks every box for autonomous agent payments: it operates at the HTTP level (universal transport), uses stable-value currency (USDC), requires no accounts or pre-registration, settles in seconds with sub-cent fees, and has reached production scale with 75M+ transactions. The protocol succeeded where others failed because it arrived at the precise moment when the infrastructure — fast L2 blockchains, native stablecoins, and autonomous AI agents — finally existed.
Tracking 75M+ transactions and thousands of x402-enabled APIs.
x402scan.com is the primary registry and analytics dashboard for the x402 ecosystem. Think of it as Etherscan specifically for x402 commerce: it indexes on-chain transactions tagged as x402 payments, catalogs APIs that accept x402, and provides real-time analytics on protocol adoption, transaction volume, and revenue by category.
75M+
Total Transactions
6,800+
x402-Enabled APIs
$420M+
USDC Settled
14
SDK Languages
The x402 Foundation, jointly established by Coinbase and Cloudflare in January 2026, governs the protocol specification, maintains the reference implementations, and operates x402scan as a public good. The Foundation has committed to keeping the protocol fully open-source with no licensing fees, ensuring that x402 remains a neutral standard that any business can adopt.
For developers and API providers, x402scan provides practical tooling: a validator that checks whether your 402 responses conform to the specification, a test suite for payment verification, and a listing submission form to get your API indexed in the registry. For agents, x402scan's API provides machine-readable discovery of x402-enabled services, enabling agents to autonomously find and evaluate paid APIs.
Infrastructure
Cloudflare Workers, Vercel Edge, AWS Lambda
AI/ML Services
Replicate, inference endpoints, training data
Data & Scraping
Proxies.sx, SERP APIs, web scraping credits
Content & Media
Publisher paywalls, AI content licensing
Developer Tools
GitHub Copilot extensions, code generation APIs
Agent Frameworks
LangChain, CrewAI, AutoGPT, Claude MCP
From “reserved for future use” to the payment layer of the autonomous web.
The IETF is expected to update the HTTP semantics specifications within the next year. For the first time, HTTP 402 will likely receive implementation guidance beyond “reserved for future use.” The x402 protocol has provided a working model that the standards body can reference: structured payment terms in the response, payment proof in the retry request, and on-chain verification as the settlement mechanism.
Several developments are converging to accelerate adoption through the rest of 2026:
x402 implementations are expanding beyond Base and Solana to Arbitrum, Optimism, Polygon, and eventually any chain with native USDC. The protocol specification is chain-agnostic by design.
Every major agent framework (LangChain, CrewAI, AutoGPT, OpenAI Assistants) is shipping x402 payment adapters. Agent-initiated purchases are becoming a default capability, not an add-on.
Circle and Coinbase are building compliance-ready x402 wallet infrastructure with spending limits, multi-sig approvals, and audit trails for enterprise agent deployments.
Early work is underway to bridge x402 and Google AP2, allowing a single agent to use x402 for permissionless microtransactions and AP2 for governed enterprise purchases.
The trajectory is clear. HTTP 402 waited 27 years for the right combination of stable digital money, fast blockchain settlement, and autonomous AI agents. Now that all three exist, the status code is fulfilling the vision its creators had in 1999: a web where machines can pay for resources natively, at the protocol level, without human intermediation. The future that was reserved has arrived.
Everything you need to know about HTTP 402, x402, and the real-world payment protocol ecosystem.
HTTP 402 is no longer reserved for future use. Buy mobile proxy bandwidth with USDC, build x402-enabled APIs, or explore the ecosystem.
PROXIES.SX Team
Building AI-native proxy infrastructure