Client and server

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.

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:

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:

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 §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).