How x402 Works: One AI Agent Payment Over HTTP 402, Step by Step

When an AI agent pays with x402, there is no checkout page, card form or account. The payment rides inside the web request the agent was already making. The x402 documentation calls it "the open payment standard that enables services to charge for access to their APIs and content directly over HTTP," built around the HTTP 402 Payment Required status code and licensed under Apache-2.0.

This explainer follows one payment under the current protocol, version 2. For the wider map of agent payment rails, see our guide to AI agent payments. For who governs x402, see our earlier piece on the x402 Foundation.

The three parties in an x402 payment

The x402 v2 specification names three roles. The resource server wants to be paid, for example an API. The client is "any application or agent" that wants the resource. The facilitator is "a service that handles payment verification and blockchain settlement." It is optional: a server can settle on its own, and the x402 FAQ says anyone can run a facilitator.

One payment, step by step (x402 v2)

1. The buyer, often an AI agent, requests a resource.
2. The server answers 402 Payment Required with payment instructions in a PAYMENT-REQUIRED header.
3. The buyer signs a payment payload and resends the request with a PAYMENT-SIGNATURE header.
4. The server verifies and settles the payment, itself or through a facilitator's /verify and /settle endpoints.
5. If the payment is valid, the server returns the resource.

The steps come from the x402 docs and the header names from the spec's HTTP transport document. For the agent, it is one retry of the same request with a signed payment attached. No login, session or stored card.

What changed between v1 and v2

Older tutorials show different headers. Coinbase's original launch post used X-PAYMENT and X-PAYMENT-RESPONSE. Those are v1 names.

The spec dates v2.0 to December 9, 2025 (the x402 blog says December 11) and lists CAIP-2 network identifiers, restructured payment objects and support for extensions. Later repository changes, including a Lightning scheme in September 2026, still sit under version 2. We found no announced v3.

Why the facilitator cannot change the payment

The FAQ is direct: every payment payload "is signed by the buyer and settled directly onchain," and a facilitator that tampers with it "would fail signature checks."

Our reading: the facilitator is a courier and a checker, not a custodian. It can refuse to settle or go offline, but it cannot change the amount or the recipient. The real trust question moves upstream: should the agent have signed that payment at all?

What it costs and how fast it settles

x402.org promises "zero protocol fees"; buyer and seller pay only network fees (gas). The FAQ says many facilitators charge nothing and settlement takes about one second.

Coinbase runs a commercial facilitator that, by its own count, has processed more than 100 million transactions. Its facilitator page says the first 1,000 onchain transactions each month are free, then $0.001 each, and verification is always free. It also runs OFAC and Know Your Transaction checks that decline sanctioned or high-risk addresses. That screening belongs to Coinbase's service. The protocol itself does no identity checks.

What assets and networks it uses

Stablecoins are the primary use case, and USDC is the spec's canonical example. x402.org says the standard "supports all EVM-compatible chains, Solana, and more." The network support page also lists TON, Stellar, XRPL, Cardano and others, but separates protocol support from production support, meaning a facilitator that actually works for your setup.

Block said on September 24, 2026 that it contributed Bitcoin Lightning payments to the protocol. Fiat is not native, though gateways can add on- and off-ramps. Stripe's x402 support, for example, takes USDC on Base, settles through the Coinbase facilitator, requires an approved access request, and per its machine payments docs settles to your Stripe balance in fiat.

Refunds: the buyer cannot reverse exact, the seller can refund

The common exact scheme moves a fixed amount once. The FAQ calls it a push payment, irreversible once executed. There is no card-style chargeback in the protocol, so the buyer cannot claw it back, but the same FAQ says a seller can refund by sending a new token transfer back to the buyer.

With upto, the client authorizes a maximum and pays only for actual usage, which suits metered AI inference. The newer auth-capture scheme, first committed in May 2026 and updated to v1.1 on August 25, adds a built-in flow for hold, capture, void and refund for payments that "may later need to be undone."

A refund scheme is not a legal right to your money back. Who carries the loss when an agent pays the wrong party is covered in our piece on who is liable when an AI agent pays.

Where x402 fits, and where it does not

Live deployments point to digital goods. AWS made AgentCore payments generally available on August 18, 2026, using upto "for pay-per-inference and dynamic pricing use cases." Cloudflare introduced Wallets on August 4 so agents can try new APIs, and opened a closed beta of its x402-based Monetization Gateway on September 30.

Our reading: x402 fits APIs, data feeds, paywalled articles and per-request compute, where the server can confirm payment and deliver in one response. It fits poorly with in-person services such as a clinic visit or a legal consultation, which need scheduling, identity, deposit holds and routine refunds that a plain stablecoin push payment does not handle well.

Limitations

This is based on the public spec, docs and vendor pages as read on October 9, 2026. The spec changes often, vendor fees and network lists can change without notice, and we did not run a live payment. This is not legal or financial advice.