What current x402 does, and what it does not

Request, 402, sign, verify, serve

A client asks for a paid HTTP resource. If no acceptable payment is attached, the server returns 402 with machine-readable requirements. The client signs a scheme-specific payload and retries. The server verifies, settles according to the scheme, and returns the resource with settlement feedback.

Source: Welcome to x402 — x402 Foundation Docs

Guide: The HTTP 402 Flow

Charge over HTTP without protocol accounts

The Foundation introduction describes x402 as a way for services to charge for APIs and content over HTTP without accounts, sessions, or credential management as part of the protocol. Buyers and sellers still choose wallets, facilitators, and product policy around that handshake.

Source: Welcome to x402 — x402 Foundation Docs

Guide: What Is x402?

Is not a wallet, chain, or processor

x402 is a transport-level payment handshake plus reference SDKs. It does not move value by itself, hold balances, issue cards, or render a paywall. Implementations still choose networks, assets, signers, facilitators, refund policy, and user experience.

Source: Welcome to x402 — x402 Foundation Docs

Guide: What Is x402?

Defines no protocol fee

The current introduction states that x402 as a standard has no fees built in. Gas, facilitator pricing, and seller overhead are outside that claim. Do not quote “fee-free” as a network or provider fact without checking that provider.

A facilitator or chain fee is not a protocol fee. Name the layer before you name the cost.

Source: Welcome to x402 — x402 Foundation Docs

Guide: x402 vs Subscriptions and API Keys

PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE

v2 uses three headers, each a Base64-encoded JSON string. PAYMENT-REQUIRED is the server offer. PAYMENT-SIGNATURE is the client authorization. PAYMENT-RESPONSE is settlement or error feedback. New integrations should treat those names as the target.

Current

PAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSE

Stale v1

X-PAYMENT / X-PAYMENT-RESPONSE

Source: HTTP 402 — x402 Foundation Docs

Guide: x402 Header Format

Does not use X-PAYMENT as the current client header

The migration guide maps v1 X-PAYMENT to v2 PAYMENT-SIGNATURE, and v1 X-PAYMENT-RESPONSE to v2 PAYMENT-RESPONSE. v2 also adds PAYMENT-REQUIRED for the 402 offer. Facilitators may still speak both versions during migration; new servers should not emit legacy names unless they have an explicit compatibility requirement.

Current

req.header("PAYMENT-SIGNATURE")

Stale v1

req.header("X-PAYMENT")

A 402 loop after “I attached payment” is often a v1 client talking to a v2 server, or the reverse.

Source: Migration Guide: V1 to V2 — x402 Foundation Docs

Guide: v1 to v2 Migration

Does not always settle onchain in the same round trip

The HTTP 402 page is explicit: whether funds move onchain in the same HTTP round trip depends on the scheme. exact and upto typically settle immediately. batch-settlement confirms authorization up front and redeems later according to the network binding.

Source: HTTP 402 — x402 Foundation Docs

Guide: Payment Schemes

Does not keep x402Version: 1 as the current wire value

v1 objects carry x402Version: 1. v2 objects carry x402Version: 2. A decoder that only looks at JSON validity will accept both. A current client should reject or migrate version 1 rather than treat it as today’s handshake.

Current

x402Version: 2

Stale v1

x402Version: 1

Source: Migration Guide: V1 to V2 — x402 Foundation Docs

Guide: v1 to v2 Migration

exact authorizes the advertised amount

exact is the fixed-price scheme: the buyer authorizes the advertised amount, and the payment must match it. The FAQ notes that exact requires strict equality — no overpayment or underpayment. It fits paid articles, deterministic API calls, and one-off files.

exact is a push payment. Refunds are a new business transfer or a different scheme, not an automatic chargeback.

Source: Payment Schemes — x402 Foundation Docs

Guide: Payment Schemes

upto authorizes a maximum, then charges usage

upto is for single-request usage billing. The buyer authorizes a maximum; the seller charges actual usage up to that ceiling. The current FAQ lists TypeScript, Go, and Python support on EVM. The authorized maximum is a safety bound, not a suggested price.

Source: Payment Schemes — x402 Foundation Docs

Guide: Payment Schemes

batch-settlement accumulates vouchers against a channel

The current scheme overview documents batch-settlement for high-volume or repeated micropayments. The buyer deposits once, signs off-chain vouchers per request, and sellers redeem in batches. Per-request pricing still uses an up-to ceiling. The FAQ lists TypeScript and Go today, with Python planned.

Source: Payment Schemes — x402 Foundation Docs

Guide: Payment Schemes

Does not treat auth-capture as the advertised default trio

The live Foundation scheme overview documents exact, upto, and batch-settlement. auth-capture exists in the v2 spec tree and in the TypeScript EVM SDK as a delayed-capture / refundable family. Do not copy it as a production default until the installed SDK and facilitator actually register it.

A GitHub scheme file is evidence that a scheme exists. It is not evidence that every facilitator, network, or tutorial supports it today.

Source: Payment Schemes — x402 Foundation Docs

Guide: Payment Schemes

Declares when verify and settle run

Current scheme docs name three payment flows: authorization (verify before the handler, settle after), upfront (settle before the handler), and escrow (settle before and after). exact can opt into upfront via extra.paymentFlow. upto and batch-settlement currently support authorization only. Clients must skip a flow they do not recognize.

Source: Payment Schemes — x402 Foundation Docs

Guide: Payment Schemes

Names networks with CAIP-2 identifiers

v2 uses namespace:reference identifiers so clients can compare networks against policy without local nicknames. Base is eip155:8453. Base Sepolia is eip155:84532. Solana uses genesis-hash identifiers. The protocol page also documents TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium, XRPL, and Cardano forms.

Current

eip155:84532

Stale v1

base-sepolia

Source: Networks & Token Support — x402 Foundation Docs

Guide: Networks and Assets

Does not accept friendly v1 network aliases as current

The migration table is the current map: base-sepolia becomes eip155:84532, base becomes eip155:8453, solana-devnet and solana become the Solana CAIP-2 genesis hashes. A v2 payment that still says network: "base-sepolia" is a leftover, not a dialect.

Current

network: "eip155:8453"

Stale v1

network: "base"

Source: Migration Guide: V1 to V2 — x402 Foundation Docs

Guide: v1 to v2 Migration

Does not make every named chain production-ready

The networks page separates three questions: protocol support (can x402 express the payment), runtime support (can your server register the scheme), and production support (do you have a facilitator, self-hosted facilitator, or self-facilitation path). Any eip155 chain can be named. Settlement still needs a path.

Source: Networks & Token Support — x402 Foundation Docs

Guide: Networks and Assets

Resolves "$0.01" only where a default asset exists

Dollar-string pricing uses the chain’s configured default stablecoin. On chains without a default, sellers specify a TokenAmount with atomic units and an asset identifier. Custom ERC-20s also need EIP-712 name and version where that transfer method applies.

Source: Networks & Token Support — x402 Foundation Docs

Guide: Networks and Assets

Can verify and settle without holding funds

A facilitator verifies payloads against requirements and can submit settlement onchain. The current facilitator page says it does not hold funds or act as a custodian. The resource server still decides which offers to accept and whether a failed settlement blocks the response.

Source: Facilitator — x402 Foundation Docs

Guide: Facilitators: Verify and Settle

Does not make x402.org the production facilitator

The public x402.org facilitator is the package default for development. Current network docs list it as testnet-only: Base Sepolia, Solana Devnet, Stellar Testnet, Aptos Testnet, Hedera Testnet, and XRPL Testnet. It does not support Base mainnet. Mainnet needs a production facilitator, a self-hosted one, or self-facilitation.

Changing only the network field from eip155:84532 to eip155:8453 while keeping https://x402.org/facilitator is a documented failure mode.

Source: Networks & Token Support — x402 Foundation Docs

Guide: Facilitators: Verify and Settle

Can return settlement_pending instead of a fake failure

When a settlement is broadcast but confirmation cannot be established, current facilitator docs describe a non-terminal settlement_pending result carrying the transaction hash. The resource server retries settlement once and reconciles against the already-broadcast hash. This applies to exact, upto, and batch-settlement on EVM and SVM in v2.

Source: Facilitator — x402 Foundation Docs

Guide: Security and Reliability Checklist

Needs duplicate-settlement protection on Solana

Solana RPC can report success for a duplicate submission because the network deduplicates at consensus. A client could otherwise buy two resources with one payment. Current docs describe a short-lived SettlementCache, with entries evicted after about 120 seconds. Merchants who settle Solana themselves must implement equivalent detection.

Source: Facilitator — x402 Foundation Docs

Guide: Security and Reliability Checklist

Does not require a facilitator

Servers can verify and settle locally. Facilitators are recommended because they hide chain-specific verification, but they are a deployment choice. Self-facilitation is one of the three paths in the current facilitator page, alongside the public testnet facilitator and a managed production provider.

Source: Facilitator — x402 Foundation Docs

Guide: Facilitators: Verify and Settle

Uses 402 to publish machine-readable terms

In x402, HTTP 402 tells the client that payment is required and carries the details needed to pay programmatically: scheme, amount, asset, network, destination. That is the whole point of filling the reserved status. A human-readable paywall sentence is not a substitute for PAYMENT-REQUIRED.

Source: HTTP 402 — x402 Foundation Docs

Guide: The HTTP 402 Flow

Did not invent HTTP 402

RFC 9110 still records 402 as reserved for future use. x402 is an application of that reserved code, not a change to HTTP itself. Implementations that assume every user agent will know what to do with 402 are reading a protocol into the browser.

Source: RFC 9110: HTTP Semantics, Section 15.5.3 — IETF / RFC Editor

Guide: What Is x402?

Does not give browsers a standard payment UI

MDN notes that no standard browser handling exists for 402. A generic user agent treats it as a 4xx. x402 therefore depends on SDK-aware clients, wallets, agents, CLIs, or application-specific paywall packages such as @x402/paywall — not on a built-in browser wallet sheet.

Source: 402 Payment Required — MDN Web Docs

Guide: The HTTP 402 Flow

Can sell a resource without a seller account system

The client/server page describes the interaction as stateless HTTP. Clients do not need protocol accounts or session tokens beyond a signer. That is why agents can buy a single call. It is also why sellers who still need identity must add it themselves.

Source: Client / Server — x402 Foundation Docs

Guide: x402 vs Subscriptions and API Keys

Does not replace API keys or subscriptions

The FAQ asks “why not just use API keys” and answers with friction, not with a ban on keys. Payment can be separated from identity. Rate limits, revocation, entitlements, invoices, seats, and support still need an account plane when the product needs one. x402 is a commercial primitive for a request, not a CRM.

Source: FAQ — x402 Foundation Docs

Guide: x402 vs Subscriptions and API Keys

Can prove wallet control without repaying, via SIWX

Sign-In-With-X is an extension, not the core handshake. It uses CAIP-122 wallet authentication so a client can access previously purchased content without repeating the payment flow. If a 402 response has no SIWX data, a current client should pay or stop — not invent a session.

Source: Sign-In-With-X (SIWX) — x402 Foundation Docs

Guide: Client and Agent Guide

Does not natively settle cards or fiat off-ramps

The FAQ states that x402 does not natively support fiat off-ramps or credit-card deposits. Facilitators or third-party gateways can wrap those rails. The v2 launch post describes facilitators for ACH, SEPA, or cards as fitting the same payment model; that is a facilitator product claim, not a protocol guarantee.

Source: FAQ — x402 Foundation Docs

Guide: Facilitators: Verify and Settle

Lets an agent follow the same four steps as a human client

The FAQ is blunt: agents request, parse PAYMENT-REQUIRED, choose a requirement and sign, then retry with PAYMENT-SIGNATURE. They need some signing authority — a wallet, delegated wallet, or chain-specific signer. The production question is the policy wrapped around that signer.

Source: FAQ — x402 Foundation Docs

Guide: Client and Agent Guide

Fits behind an MCP server that owns the signer

An MCP server can call a paid endpoint with an x402-aware HTTP client, handle the 402, and return only the tool result to the model. The Foundation docs include an MCP guide. The model asks for a capability; the server enforces budget, host allowlist, and audit. Private keys do not belong in prompts.

Source: x402 Foundation Repository — GitHub

Guide: MCP and Agent Commerce

Can advertise resources to a catalog, via Bazaar

Bazaar is the discovery extension: a machine-readable catalog of x402 endpoints and MCP tools. Catalog indexing is a facilitator implementation detail, not something the OSS repo controls. A service that settles payments but never appears in a catalog has a facilitator/catalog problem, not proof that x402 failed.

Source: Bazaar (Discovery Layer) — x402 Foundation Docs

Guide: MCP and Agent Commerce

Does not authorize unbounded agent spend

A valid signature can still be a bad purchase. Current buyer guidance assumes the client evaluates scheme, network, asset, amount, destination, and policy before signing. This field guide does not teach agent checkout. Step-by-step seller and buyer tutorials belong at x402academy.com.

A hot key with no spend cap will drain itself through perfectly valid x402 messages.

Source: Quickstart for Buyers — x402 Foundation Docs

Guide: Security and Reliability Checklist