How an x402 payment works, step by step: one request, one payment

How an x402 payment works, step by step: one request, one payment

An x402 payment is five steps: the client asks, the server answers `402 Payment Required` with a price, the client signs a limited single-use transfer, the facilitator verifies and settles it on a blockchain, and the server delivers the resource with a receipt. This article, the second chapter of the Group's book *The x402 Economy*, follows one paid request from start to finish using version 2 of the protocol, released on 11 December 2025. The details are technical, but the shape is simple, and the shape is what matters.

Who takes part in an x402 payment?

Three roles.

• The client wants something. It might be a person's browser, a script, or an AI agent partway through a task.
• The resource server has something to sell: a web page, a data feed, an answer from a model, a file. It sets the price and decides what it will accept.
• The facilitator checks payments and puts them on the blockchain for the server. It is optional. A server that runs its own blockchain connection can do the facilitator's job itself. Most do not, for the same reason most shops use a card processor instead of connecting to the card network directly.

No party needs an account with another. The client does not sign up with the server. The server does not know who the client is, only that it paid. (The market at market.561.group uses Coinbase's developer platform facilitator.)

Step 1: What does the client send first?

An ordinary web request, with nothing in it that says "I intend to pay". It is the same request a browser sends for any page:

curl --include https://market.561.group/v1/publications/the-x402-economy

Step 2: How does the server name its price?

If the resource is not free, the server answers with status 402 instead of the resource, and attaches a header named PAYMENT-REQUIRED (HTTP header names are case-insensitive; the market sends it lowercase). The header carries a base64-encoded JSON message whose central part is a list called accepts: the ways the server will take payment. Each entry states:

The message also describes the resource: its address, a description and the kind of content it returns. A server can list several entries, for example the same price on Base and on Solana, and let the client choose. Version 2 names networks in the standard CAIP-2 format, so eip155:8453 is Base and an identifier beginning solana: is Solana.

Step 3: What does the client sign?

The client picks an entry it can pay and signs a payment. It does not send money yet. It signs a precise, limited permission.

On Base and similar networks, the permission uses a feature built into USDC called transfer with authorization, defined in a standard named EIP-3009. The signed message says, in effect: move this many units of USDC from my address to this address, valid after this moment and before that one, and here is a random number that makes this permission usable once. Anyone may submit the signed message to the blockchain, but it can only ever do what it says: that amount, to that payee, in that window, one time.

Concretely, the fields the client signs (as EIP-712 typed data, using the token's name and version from the extra field of the 402) are from, to, value, validAfter, validBefore and nonce.

A paper check is a fair comparison. The check names the payee and the amount; anyone can carry it to the bank, but no one can change it or cash it twice. The difference is that a bank takes days to clear a check, and the blockchain settles the transfer in seconds.

The client packages the signature, the authorization fields and the exact requirement it accepted into a JSON PaymentPayload, base64-encodes it, puts it in a header named PAYMENT-SIGNATURE, and sends the original request again:

GET /v1/publications/the-x402-economy HTTP/2
Host: market.561.group
PAYMENT-SIGNATURE: <base64 of the PaymentPayload>

Step 4: How does the server check the payment, and how does it settle?

The server passes the payment to its facilitator. The facilitator offers two operations, verify and settle (and a supported listing of what it handles).

• Verify checks that the signature is valid and recovers to the stated payer, that the amount and payee match the price, that the payer has the funds, and that the permission has not been used. A facilitator run by a regulated company also screens the payer's address against sanctions lists here; Coinbase's facilitator, for example, runs checks against the US Treasury's list of sanctioned addresses and declines sanctioned or high-risk addresses.
• Settle submits the signed transfer to the blockchain and reports the result.

The facilitator pays the small network fee for submitting the transfer, which is why the client needs only USDC and not a second token for fees. As of 2026-09-27, Coinbase's facilitator did the first 1,000 settlements each month free and charged $0.001 for each after that (see its documentation). The facilitator cannot change the amount or the destination; it serves only as the transaction broadcaster.

Step 5: What does the server deliver?

When settlement succeeds, the server sends the resource with status 200 and a PAYMENT-RESPONSE header. That header carries a receipt: whether the payment succeeded, the payer's address, the network and the transaction identifier, which anyone can look up on the blockchain. The client now has what it asked for and a public record that it paid.

What does an x402 payment leave out, on purpose?

The flow omits several things a card payment includes.

• There is no account. The server never learns a name, an email or a card number. It learns a blockchain address, which is a pseudonym.
• There is no chargeback. A blockchain transfer cannot be reversed by a bank. If the server takes the money and sends nothing, the client's remedy is outside the protocol. The practical protections are keeping payments small and preferring sellers with a record; see x402 security for buyers and sellers.
• There is no subscription. Each request pays for itself. Version 2 adds optional sessions, so a client that has paid can skip the full exchange for a while, but the basic unit is one request.
• There is no identity requirement. The protocol does not care whether the client is a person, a script or an agent. It cannot tell, and neither can anyone watching the blockchain. That is why counting the market is hard.

Are there payment schemes other than exact?

exact is the simplest scheme, not the only one. Coinbase's facilitator also supports two others on its EVM networks:

• upto lets a client authorize a maximum, with the server charging what the request actually used, which suits metered work such as a model that charges by length of answer;
• batch-settlement gathers many payments into one blockchain transaction to cut costs further.

The protocol leaves room for more schemes without changing the core exchange. For buyers, exact is the safest: you sign one fixed amount. With upto you must set the maximum as if the seller will charge all of it, because it may.

What changed between x402 version 1 and version 2?

The first version, released in May 2025, used headers named X-PAYMENT and X-PAYMENT-RESPONSE. Version 2 made several changes:

The live responses of market.561.group use the version 2 names. Its 402 also carries two extensions: a bazaar extension describing the offer's input and output for catalogs, and a sign-in-with-x extension that lets a wallet the operator has granted access prove it owns its address instead of paying.

What should I remember?

• A paid request has three parties: client, resource server and, usually, a facilitator.
• The server answers 402 with a price. The client signs a limited, single-use transfer and retries. The facilitator verifies and settles, and the server delivers with a receipt.
• There is no account, no chargeback and no subscription; each request pays for itself.
• Version 2 standardized the headers and network names and added extensions and sessions.

To do it yourself against a live market, read the software-agent quickstart. For the specification, see the x402 version 2 specification and its `exact` scheme for EVM.