x402 Native Payments: HTTP 402 Protocol for AI Agents
x402 is an open payment standard that lets AI agents and machines pay for APIs, data, and digital services directly over HTTP. It revives the long-dormant HTTP 402 (Payment Required) status code, replacing API keys, accounts, and subscriptions with per-request stablecoin micropayments that settle on-chain in about two seconds. This post is my deep-dive research summary of how x402 native payments work, why they exist, and where the protocol stands today.
TL;DR
- x402 is an HTTP-native payment protocol: a server answers with
402 Payment Required+ machine-readable pricing, the client pays with a signed stablecoin authorization, retries the request, and gets the resource. - It was open-sourced by Coinbase in May 2025, and is now stewarded by the x402 Foundation under the Linux Foundation — 40 member organizations including Visa, Mastercard, Stripe, Google, AWS, and Cloudflare.
- The core "exact" scheme uses EIP-3009 (
transferWithAuthorization) on EVM chains — a gasless, signed ERC-20 transfer that a facilitator verifies and settles, no wallet custody required by the seller. - Real numbers (mid-2026): 100M+ transactions on Base since launch (Chainalysis), average payment around $0.20–$0.31, but >95% of activity is still protocol signaling — real commercial volume is small but growing.
- For a paid API or data service, x402 is currently the fastest path to production for agent payments: one line of middleware on the server, one wrapper on the client.
Why the agent economy needs a new payment rail
Autonomous AI agents are becoming economic actors. They buy API credits, cloud storage, market data, and inference — thousands of sub-dollar purchases per day, with no human at the keyboard. Juniper Research projects agentic payments to grow from $8 billion in 2026 to $1.5 trillion by 2030.
But the payment systems of the internet were built for humans, not software. A card checkout assumes a person fills a form, passes 3D Secure, and can dispute a charge for up to 120 days. An agent calling ten APIs to answer one prompt cannot do any of that. This is the gap x402 fills: it makes payment part of the HTTP request/response cycle itself, so an agent's HTTP client is also its payment client.
HTTP 402: a status code that waited 27 years
The 402 status code is nearly as old as the web. It first appeared in RFC 2068 (1997) and was carried into RFC 7231 (2014) as "reserved for future use" — the only 4xx code with no defined semantics. The original vision was browsers paying for content, but card micropayments were economically unworkable: with a $0.30 + 2.9% minimum fee per transaction, nobody could profitably charge a penny per page. So the internet evolved around advertising and subscriptions, and 402 sat dormant for almost three decades.
What changed is not the HTTP layer — it's the settlement layer underneath. Stablecoins (primarily USDC) are programmable, final, and divisible to fractions of a cent. Layer-2 networks like Base settle in seconds for fractions of a cent in gas. Sending money finally costs roughly what sending data costs, which makes per-request machine payments viable for the first time.
Why legacy payment rails fail agents
| Rail | Typical fees | Settlement | Chargeback risk | Fits agents? |
|---|---|---|---|---|
| Credit card | $0.30 + 2.9% | Days (batch) | Yes, up to 120 days | No — human checkout, fraud checks, reversal windows |
| ACH / bank transfer | Low | 1–3 days | Yes | No — too slow, needs accounts |
| PayPal | ~3% + markup | Instant auth, days to settle | Yes | No — account-centric |
| Ethereum L1 | $1–$5 + gas | 1–2 min confirmations | No | Too expensive for micropayments |
| x402 on Base | ~$0.0001 gas (nominal) | ~200 ms–2 s | No — irreversible | Yes — designed for machines |
Beyond cost, the deeper problem is discovery and trust: legacy rails force accounts, API keys, and pre-registration, which an agent cannot do autonomously at scale. x402's answer is that the payment is the credential — no account, no API key, no subscription.
How x402 works: the 402 handshake
The whole protocol is one HTTP retry from the client's perspective — and eleven messages on the wire. Here is the complete handshake across the four participants:
Figure: the 11-message x402 handshake. Colors match the participants — lavender = Client (the AI agent), green = Resource Server, amber = Facilitator, red = Blockchain (Base). Step 3 is a client-local signing action; step 7 (settle) runs asynchronously after the request is fulfilled, and the resource is only returned at step 11 once settlement has confirmed.
- Request — the client (agent or app) sends a normal HTTP request to the protected resource (
GET /weather). - Payment Required — the server answers
HTTP/1.1 402 Payment Requiredwith aPAYMENT-REQUIREDheader carrying the Base64-encodedPaymentRequiredobject: price, token, network, and payee. (Servers may also emitWWW-Authenticate: Paymentfor MPP interop.) - Sign — the client picks one of the offered payment requirements and signs a payment authorization with its wallet — an EIP-3009
transferWithAuthorizationfor the exact scheme. - Retry with payment — the client resends the request with a
PAYMENT-SIGNATUREheader containing the signedPaymentPayload. - Verify — the resource server validates the payload itself or delegates to a facilitator (
POST /verify). - Valid — the facilitator returns a verification response; if invalid, the server re-issues the 402.
- Settle — after fulfilling the request, the server broadcasts the payment via
POST /settle(or settles directly on-chain). - Broadcast — the facilitator submits
transferWithAuthorizationto the blockchain. - Confirmed — the payment lands on-chain in about two seconds (~200 ms on Base).
- Receipt — the facilitator returns the settlement receipt (the transaction hash).
- 200 OK — the server returns the resource with a
PAYMENT-RESPONSEheader carrying the receipt.
The key property: no custody. The facilitator never holds the client's funds — it only verifies a signed authorization and broadcasts it, so the client keeps full control of its wallet.
Protocol internals: messages, roles, and the facilitator API
x402 separates three concerns: Types (data structures), Logic (scheme- and network-specific payment formation/verification), and Representation (how payments travel over HTTP, MCP, or A2A). Three roles participate:
- Resource server — sells access to an API, file, or service.
- Client — the paying entity (agent, app, human's wallet).
- Facilitator — verifies and settles payments on one or more networks; can be self-hosted, a third party, or embedded in the resource server.
The core messages (v2 spec):
PaymentRequired— carried in thePAYMENT-REQUIREDheader. Containsx402Version, an optional human-readableerror, theresource(URL, description, mimeType, tags, icon), andaccepts[]— one or morePaymentRequirementsobjects (scheme, CAIP-2 network, amount in atomic units, asset address, payTo address, maxTimeoutSeconds, scheme-specificextra).PaymentPayload— carried in thePAYMENT-SIGNATUREheader. The client echoes the chosenacceptedrequirement plus a scheme-specificpayload(for exact EVM: an EIP-712signatureand an EIP-3009authorizationwith from/to/value/validAfter/validBefore/nonce).SettlementResponse— returned in thePAYMENT-RESPONSEheader after settlement: success flag, transaction hash, network, payer.
The facilitator interface is a small REST API: POST /verify (validate an authorization without broadcasting), POST /settle (broadcast the verified payment), and GET /supported (advertise supported scheme/network pairs and signer addresses). A separate Discovery API (GET /discovery/resources) lets clients find monetized resources — this powers "Bazaar"-style marketplaces where agents can discover and pay for APIs.
Payment schemes and networks
A scheme is a logical way of moving money; a network is where it settles. Clients and facilitators must both support a (scheme, network) pair.
exact(EVM) — the first shipping scheme. Uses EIP-3009transferWithAuthorization: the client signs a typed-data authorization (from, to, value, validAfter, validBefore, nonce) and the facilitator broadcasts it — gasless for the client, since the facilitator covers gas. Verification includes signature validity, balance, exact amount match, time window, parameter matching, and transaction simulation.exact(SVM) — the same idea on Solana via SPLTransferChecked, with strict instruction-layout and compute-unit-price bounds to prevent gas abuse.upto— authorizes up to a maximum; the seller settles actual usage against the cap (e.g., LLM token generation where cost is only known after the call).batch-settlement— escrow plus off-chain vouchers, so sellers can redeem many small charges on-chain in batches instead of settling every HTTP request.
Networks use CAIP-2 identifiers: eip155:8453 (Base mainnet), eip155:84532 (Base Sepolia), eip155:43114 (Avalanche), solana:..., plus SDKs for AVM, Aptos, Stellar, TVM, Hedera, and others. Assets are ERC-20 tokens implementing EIP-3009 (USDC first) on EVM; any SPL token on Solana.
Security: replay protection and trust minimization
Micropayments fail if a captured payment can be replayed. x402 layers four defenses:
- Unique nonce — every authorization carries a 32-byte random nonce (EIP-3009), and the smart contract rejects nonce reuse at the protocol level.
- Time windows —
validAfter/validBeforebound each authorization's lifetime (typically seconds), so a stale capture is worthless. - Cryptographic signatures — EIP-712 typed-data signatures bind the authorization to the exact payer wallet.
- Simulation before settlement — facilitators simulate the transfer to fail fast on insufficient funds rather than burning gas.
The protocol's trust-minimization principle: no payment scheme may allow the facilitator or resource server to move funds beyond what the client authorized. The facilitator never takes custody — it only verifies and submits the client's signed instruction.
x402 vs the other agent-payment standards
x402 is not alone. Four competing (and partly converging) standards shipped in about a year:
| x402 | MPP (Stripe+Tempo) | AP2 (Google) | L402 (Lightning) | ACP (OpenAI+Stripe) | |
|---|---|---|---|---|---|
| Origin | Coinbase → Linux Foundation | Stripe + Tempo (2026) | Google + 60 partners | Lightning Labs (LSAT) | OpenAI + Stripe (2025) |
| 402 header | PAYMENT-REQUIRED |
WWW-Authenticate: Payment |
A2A/MCP extension | WWW-Authenticate: LSAT |
Not 402-based |
| Auth model | Stateless: payment = credential | Signed challenges; fiat via Shared Payment Tokens | Cryptographically signed mandates (Intent + Cart) | Macaroon + Lightning invoice | Human-confirmed checkout, scoped SPT |
| Settlement | USDC on Base (primarily) | USDC on Tempo; cards via Stripe | Cards, stablecoins, RTP | Bitcoin Lightning | Merchant's existing card rails |
| Best for | Paid APIs/data services | Stripe users wanting one API | Delegated spending with audit trail | Sub-cent Bitcoin payments | Retail checkout inside ChatGPT |
The philosophical difference is authorization: x402 is deliberately minimal ("if the agent can pay, it can access"), AP2 adds auditable user-delegation mandates, and MPP bridges crypto and fiat rails. The protocols already interop — x402 and AP2 share an A2A extension, and Stripe sits in the x402 Foundation while supporting both MPP and x402.
Governance and ecosystem: the x402 Foundation
In April 2026 Coinbase donated x402 to the x402 Foundation at the Linux Foundation; the foundation formally launched in July 2026 with 40 member organizations, including premier members Visa, Mastercard, American Express, Stripe, Adyen, Fiserv, Google, AWS, Cloudflare, Ripple, Circle, MoonPay, and the Solana Foundation. AWS Payments' Alin Dragos chairs the board; an executive director search and technical steering committee are in place.
Key ecosystem moves in 2026:
- July 23, 2026 — Coinbase opened agent payments to all Coinbase Business customers: accept USDC from AI agents via x402 with settlement through Coinbase Payments, no integration required. The same day it shipped a CDP x402 SDK (managed wallets + spend controls) and expanded Coinbase for Agents. Coinbase reports agent traffic overtook human traffic on its Base docs in June 2026.
- Amazon Bedrock AgentCore Payments (May 2026) — AWS agents can pay for services in USDC via x402.
- Base MCP — connects Base Accounts (transfers, swaps, x402 payments) to ChatGPT, Claude, Codex, and Cursor via Model Context Protocol.
- Agentic.market (April 2026) — a discovery marketplace for x402-enabled services; plus community directories like x402scan.com and Pay.sh.
- Stripe supports x402 on Base; the Bazaar MCP server makes paid APIs discoverable by agents.
SDK coverage is broad: TypeScript (@x402/core, @x402/evm, @x402/svm, @x402/axios, @x402/fetch, @x402/express, @x402/hono, @x402/next, @x402/mcp, ...), Python (pip install x402), and Go.
Adoption: what the numbers actually say
The honest picture is "early but real":
- 100M+ transactions on Base within nine months of launch (Chainalysis); 165M settled transactions across ~480,000 agents per Coinbase/Base; 200M+ cumulative by June 2026 (Major Matters adoption tracker).
- Average payment ≈ $0.20 (Artemis, March 2026) and <$0.31 (Keyrock's "Who Pays the Agent?" report); 98.6% of machine payments settled in USDC.
- Payments over $1 grew from 49% to 95% of value transferred between early 2025 and early 2026 (Chainalysis) — a sign usage is moving beyond experiments.
- The caveats matter: >95% of on-chain activity is protocol signaling — testing, self-dealing, and wash trading — not buyer-seller exchange. CoinDesk reported real daily commercial volume around $28,000 in March 2026, and early counts were inflated by the PING memecoin mint.
So: the plumbing is being stress-tested at scale, but genuine commerce is a rounding error today. That is exactly what the Coinbase Business launch (no merchant integration required) is designed to change over the next two quarters.
Business models x402 enables
- Pay-per-article / pay-per-download — a Substack writer charges $0.25 per article instead of forcing a subscription; a research journal charges per whitepaper.
- Per-inference AI monetization — a vision API charges $0.005 per image classification; a voice API $0.10 per clip; LLM calls billed via the
uptoscheme. - Per-second / per-unit usage — video per second watched, GPU compute per minute ($0.50/GPU-min), cloud storage per GB.
- Real-time data — a trading agent pays $0.02 per market-data request; legal research $0.10 per court ruling.
- Authenticated pricing — combine with Sign-In with Ethereum for verified-user discounts (the protocol explicitly supports this).
For providers the pitch is operational, not just commercial: no chargebacks, no PCI scope, no invoicing, instant settlement, and no stored cards — while agents gain autonomous access without pre-registration.
Hands-on: integrating x402
Server side (Express) — one middleware call:
import express from 'express'
import { paymentMiddleware } from '@x402/express'
const app = express()
app.use(paymentMiddleware({
'GET /weather': {
accepts: [{ scheme: 'exact', network: 'eip155:8453', amount: '1000000', asset: '0x...USDC', payTo: '0x...' }],
description: 'Weather data'
}
}))
app.listen(3000)
Client side (fetch) — one wrapper:
import { wrapFetchWithPayment } from '@x402/fetch'
const fetchWithPayment = wrapFetchWithPayment(fetch, { wallet })
const data = await (await fetchWithPayment('https://api.example.com/weather')).json()
The flow even works from plain curl: request → read the PAYMENT-REQUIRED header → attach a signed PAYMENT-SIGNATURE → retry. Testnet facilitators and mock servers make local development possible without real funds.
My learning summary
Studying x402, the strongest insight is that the protocol's minimalism is the product. It does not invent a new transport, a new identity system, or a new wallet format — it attaches money to an HTTP status code that was reserved for exactly this 27 years ago, and leans on EIP-3009 + stablecoins + L2s for everything else. That is why a standard with zero protocol fees and ~2-second settlement could get Visa, Mastercard, Stripe, Google, and AWS to the same table within a year of open-sourcing.
The open questions are the real ones: whether the >95% signaling volume converts into commerce (the Coinbase Business toggle is the experiment), whether upto and batch-settlement schemes mature into production, and whether the standards converge (x402 ↔ MPP ↔ AP2) instead of fragmenting. For builders, the takeaway is practical: if you sell an API that agents will call, x402 is a five-line integration today, and the ecosystem — foundation governance, CDP SDK, Bedrock, Bazaar — is already in place. The plumbing works; the market is being measured right now.
FAQ
What is x402?
x402 is an open payment standard that lets clients — especially AI agents — pay for APIs and digital services over plain HTTP, using the HTTP 402 status code and signed stablecoin authorizations (EIP-3009). It replaces API keys, accounts, and subscriptions with per-request micropayments.
Is x402 a blockchain?
No. x402 is a payment protocol layered on top of existing blockchains (Base, Ethereum, Solana, Avalanche, and others) via a facilitator that verifies and settles payments. The blockchain settles the money; HTTP carries the payment request and proof.
Does an agent need a wallet to pay with x402?
Yes — the client signs authorizations with a wallet holding the payment token (e.g., USDC). Managed/MPC wallets and spend controls are available through Coinbase CDP and other providers; sellers never need to hold client funds.
How much do x402 payments cost?
The protocol itself charges no fees. Costs are blockchain gas only — a fraction of a cent on Base, around $0.00025 on Solana. Compare with card rails at $0.30 + 2.9% per transaction.
What is the difference between x402 and MPP?
Both use HTTP 402 for agent payments. x402 (Coinbase, now the Linux Foundation) uses the PAYMENT-REQUIRED header and settles primarily in USDC on Base; MPP (Stripe + Tempo) uses WWW-Authenticate: Payment and adds a fiat path via Stripe's Shared Payment Tokens. They are converging in practice.
Who governs x402?
The x402 Foundation, hosted at the Linux Foundation, with 40 member organizations including Visa, Mastercard, American Express, Stripe, Google, AWS, Cloudflare, Circle, and the Solana Foundation. Coinbase open-sourced the protocol in May 2025 and donated it in April 2026.
References
- x402 Protocol Specification v2 — x402 Foundation
- x402 Whitepaper — Coinbase Developer Platform (May 2025)
- x402 repository — SDKs, docs, examples
- RFC 7231 — HTTP/1.1 Semantics (402) — IETF
- EIP-3009: Transfer With Authorization — Ethereum
- Visa, Stripe and Google join x402 Foundation — CoinDesk, Jul 2026
- Coinbase's x402 has processed over 100 million transactions on Base — crypto.news (Chainalysis data)
- x402 Foundation: 200M transactions later, real volume is still tiny — Forkast, Aug 2026
- Coinbase opens USDC payments from AI agents to all business customers — Stablecoin Insider, Jul 2026
- Agentic payments: x402, AP2 and MPP for builders — CodeDecoders
- AI Agent Payment Protocols Compared — Voidly
Related reading on this site: HTTP/1.x connection management, more HTTP posts, payment bookmarks, and all posts.