# Client and server

> The roles and responsibilities of the agent (client) and the merchant (server) in x402.

x402 has two principal participants:

- **The client (agent)** — the party trying to access a paid resource. May be a Node script, an LLM agent, a browser tab, or any HTTP client.
- **The server (merchant)** — the party hosting the paid resource. An Express, Hono, Fastify, or Next.js app, typically.

A third party — the **facilitator** — exists to keep the merchant out of chain-specific code. Its role has its own [page](/docs/core-concepts/facilitator).

## Client responsibilities

The client owns:

- The signing key for its account. For the `exact` scheme this is an EOA; for `aa-native` it is the EOA that owns an ERC-4337 SCW.
- The choice of which `accepts` entry to satisfy when the merchant offers multiple.
- The HTTP retry on 402.
- Decoding the `PAYMENT-RESPONSE` header to obtain the on-chain receipt.

The reference implementation handles all of this through `x402Fetch({signer})`. The agent's code is a single fetch call:

```ts
const f = x402Fetch({ signer: aaNativeSigner({...}) });
await f("https://merchant/api/resource", { method: "POST", body });
```

## Server responsibilities

The server owns:

- The price and asset list. Encoded in `PaymentRequirements` and emitted on every 402 response.
- The decision of when to invoke the protected handler (after `/verify` succeeds, typically) and when to settle (after the handler returns 2xx, typically).
- Forwarding `/verify` and `/settle` calls to the facilitator.
- Attaching the `PAYMENT-RESPONSE` header on the final 200.

The reference middleware (`@nerochain/x402-server`) handles the wire format and the facilitator round-trips automatically. The server author writes a normal handler:

```ts
app.use("/api/llm", x402Express({...}), (req, res) => {
  res.json({ ok: true, payer: req.x402Payer });
});
```

`req.x402Payer` is populated by the middleware after a successful `/verify`. It is the SCW (or EOA, for `exact`) that paid for this request.

## What the client never knows

- The merchant's facilitator URL.
- Whether the merchant verifies before or after running the handler.
- The merchant's HMAC secret for talking to the facilitator.
- The on-chain submission path (bundler, paymaster). The agent only sees the eventual `transactionHash`.

The agent's interface is just HTTP plus a signed payload. The merchant could swap facilitators, schemes, or chain-side details and the agent's code would still work.

## What the server never knows

- The agent's private key.
- The agent's bundler or paymaster URLs (the agent talks to those itself when constructing the UserOp for `aa-native`).
- Anything about the agent's account model beyond `userOp.sender` (the SCW address).

## Trust model

The merchant trusts the facilitator's `/verify` result and the bundler's UserOp receipt. A merchant that needs stronger settlement assurance can independently re-read `eth_getTransactionReceipt` and the `ReceiptLog` event from the settlement contract before serving the response. See [Settlement finality](/whitepaper.pdf) (whitepaper §5.4).

The agent trusts that the `PAYMENT-REQUIRED` headers in 402 responses describe what the merchant will actually settle. A merchant that emits one set of requirements and tries to settle a different amount is rejected at the verifier (`spec_mismatch`).