x402 Native Payments: HTTP 402 Protocol for AI Agents

· 29 min read

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:

x402_handshake f1 Client s1 1. GET /weather f1->s1 t1 Resource Server s1->t1 f2 Resource Server s2 2. 402 Payment Required PAYMENT-REQUIRED: price · token · payTo f2->s2 t2 Client s2->t2 f3 Client s3 3. sign transferWithAuthorization (EIP-3009) f3->s3 f4 Client s4 4. retry + PAYMENT-SIGNATURE f4->s4 t4 Resource Server s4->t4 f5 Resource Server s5 5. POST /verify f5->s5 t5 Facilitator s5->t5 f6 Facilitator s6 6. valid ✓ f6->s6 t6 Resource Server s6->t6 f7 Resource Server s7 7. POST /settle (after fulfill) f7->s7 t7 Facilitator s7->t7 f8 Facilitator s8 8. transferWithAuthorization f8->s8 t8 Blockchain s8->t8 f9 Blockchain s9 9. confirmed (~2 s) f9->s9 t9 Facilitator s9->t9 f10 Facilitator s10 10. receipt (tx hash) f10->s10 t10 Resource Server s10->t10 f11 Resource Server s11 11. 200 OK + data PAYMENT-RESPONSE f11->s11 t11 Client s11->t11

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.

  1. Request — the client (agent or app) sends a normal HTTP request to the protected resource (GET /weather).
  2. Payment Required — the server answers HTTP/1.1 402 Payment Required with a PAYMENT-REQUIRED header carrying the Base64-encoded PaymentRequired object: price, token, network, and payee. (Servers may also emit WWW-Authenticate: Payment for MPP interop.)
  3. Sign — the client picks one of the offered payment requirements and signs a payment authorization with its wallet — an EIP-3009 transferWithAuthorization for the exact scheme.
  4. Retry with payment — the client resends the request with a PAYMENT-SIGNATURE header containing the signed PaymentPayload.
  5. Verify — the resource server validates the payload itself or delegates to a facilitator (POST /verify).
  6. Valid — the facilitator returns a verification response; if invalid, the server re-issues the 402.
  7. Settle — after fulfilling the request, the server broadcasts the payment via POST /settle (or settles directly on-chain).
  8. Broadcast — the facilitator submits transferWithAuthorization to the blockchain.
  9. Confirmed — the payment lands on-chain in about two seconds (~200 ms on Base).
  10. Receipt — the facilitator returns the settlement receipt (the transaction hash).
  11. 200 OK — the server returns the resource with a PAYMENT-RESPONSE header 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 the PAYMENT-REQUIRED header. Contains x402Version, an optional human-readable error, the resource (URL, description, mimeType, tags, icon), and accepts[] — one or more PaymentRequirements objects (scheme, CAIP-2 network, amount in atomic units, asset address, payTo address, maxTimeoutSeconds, scheme-specific extra).
  • PaymentPayload — carried in the PAYMENT-SIGNATURE header. The client echoes the chosen accepted requirement plus a scheme-specific payload (for exact EVM: an EIP-712 signature and an EIP-3009 authorization with from/to/value/validAfter/validBefore/nonce).
  • SettlementResponse — returned in the PAYMENT-RESPONSE header 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-3009 transferWithAuthorization: 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 SPL TransferChecked, 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 windowsvalidAfter/validBefore bound 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 upto scheme.
  • 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

Related reading on this site: HTTP/1.x connection management, more HTTP posts, payment bookmarks, and all posts.