# How Does x402 Work? The Payment Flow, Step by Step

x402 turns a paid API call into a single HTTP conversation. Instead of negotiating access out of band — creating an account, provisioning an API key, setting up billing — the price travels inside the protocol itself. The server states its terms with a 402 response, the client pays, and the request completes. This page walks through that exchange step by step, then looks at what a 402 response actually carries and who does what along the way.

## The four roles in an x402 payment

Every x402 exchange involves the same four participants, even when some of them are invisible:

- **The server** owns a paid resource — an API endpoint, a data feed, a tool call, a piece of content. It declares the price, checks that payment has been made, and fulfills paid requests.
- **The client** wants the resource. It is often an AI agent, but it can be any HTTP client with a funded wallet and software that understands the 402 challenge.
- **The facilitator** is a neutral third party that verifies the client's signed payment and settles it on-chain. Servers integrate with a facilitator instead of running blockchain nodes; our [facilitator directory](https://x402looker.com/facilitator/) lists the operators active in the ecosystem.
- **The blockchain** is the settlement rail. In this directory, payments settle in USDC on [Base](https://x402looker.com/chain/base/) or [Solana](https://x402looker.com/chain/solana/).

## The x402 payment flow, step by step

1. **Initial request.** The client sends an ordinary HTTP request to a paid endpoint — a `GET` or `POST` exactly like any other API call. No special headers are required yet.
2. **The 402 challenge.** The server sees no valid payment attached, so it responds with status `402 Payment Required` and a machine-readable description of its payment terms: how much, in what asset, on which network, and to which address.
3. **Payment construction.** Client software parses the terms, checks the price against its own budget or policy, and signs a payment payload — an authorization to transfer exactly the requested amount of USDC to the server's address on the specified network.
4. **Retry with payment.** The client repeats the original request, this time attaching the signed payload in a header. The request itself is unchanged; only the payment credential is new.
5. **Verification.** The server passes the payload to its facilitator, which checks that the signature is valid, that the amount, asset, network, and recipient match the stated terms, and that the funds are available.
6. **Settlement.** The facilitator submits the transfer to the blockchain and confirms to the server once it has settled. The server never touches a node, an RPC endpoint, or a gas fee.
7. **Fulfillment.** The server returns a normal `200` response carrying the paid resource. From the client's perspective, the whole negotiation took one extra round trip.

## What a 402 response contains

The 402 response is the heart of the protocol. Conceptually, it is a price quote rendered for machines, and it carries a small set of fields:

- **Amount** — the price of one fulfillment, expressed in the smallest unit of the accepted asset.
- **Asset** — the currency the server accepts, in practice USDC.
- **Network** — the chain on which payment must settle, such as Base or Solana.
- **Recipient** — the address that must receive the funds.
- **Scheme** — how the client should construct its payment payload so the facilitator can verify it.

Because these terms arrive as structured data rather than as a pricing page written for humans, a client can evaluate an offer programmatically: compare it against a budget, rank it against a competing endpoint, or decline it — all without scraping HTML or asking a person.

## Verification versus settlement

The facilitator performs two distinct jobs. Verification is a set of fast checks — signature, parameters, balance — that answer the question "is this payment good?" Settlement is the on-chain transfer itself, which answers "has the money actually moved?" Keeping the two steps separate lets a server validate a payment before it does expensive work, while the facilitator handles the slow, chain-specific parts of moving funds. The [infrastructure and facilitators](https://x402looker.com/category/infrastructure-facilitators/) category of the directory covers the services that operate this layer.

## Why this design works for machines

Three properties make the flow agent-native. First, it is stateless: there is no session, login, or cookie jar, so each request stands alone and any client can pay without an account. Second, it is uniform: every x402 endpoint speaks the same challenge format, so an agent can buy from a service it has never encountered before — the terms are self-describing. Third, it rides plain HTTP: agent frameworks, command-line tools, and hosted [MCP tool](https://x402looker.com/category/mcp-tools/) gateways can all participate without new transport code. That uniformity is what turns a directory of paid endpoints, from [data APIs](https://x402looker.com/category/data-apis/) to paywalled content, into something an agent can shop across.

See the flow in production: browse [live x402 services](https://x402looker.com/), or read [what x402 is](https://x402looker.com/what-is-x402/) for the higher-level picture.

## Frequently asked questions

### What does an x402 402 response contain?

A machine-readable description of the payment terms: the price, the accepted asset (typically USDC), the blockchain network, the recipient address, and how the client should construct its payment.

### What is the role of the facilitator in the x402 flow?

The facilitator verifies the client's signed payment payload against the server's terms and settles the transfer on-chain, so the server never has to run blockchain infrastructure.

### Does the client retry the request after paying?

Yes. The client repeats the original HTTP request with a signed payment payload attached; the server verifies and settles through its facilitator, then returns the paid response.

### Which blockchains does x402 settle on?

In the x402 Looker directory, services settle on Base or Solana, with the large majority settling on Base.

## Related

- [What is x402?](https://x402looker.com/what-is-x402/)
- [All facilitators](https://x402looker.com/facilitator/)
- [Infrastructure & Facilitators category](https://x402looker.com/category/infrastructure-facilitators/)
- [Base services](https://x402looker.com/chain/base/)
- [Solana services](https://x402looker.com/chain/solana/)