# What happens between a 402 challenge and the paid response

> The exact x402 mechanics an autonomous agent runs to call a paid endpoint — discover the resource, get the 402, sign the payment, settle through a facilitator, and replay.

Published 2026-06-28 · Updated 2026-08-15 · HTML version: https://invoket.com/blog/how-an-agent-discovers-and-buys-a-paid-api

---

An autonomous agent buys access to a paid API in one tight loop: **discover** the
resource, send a request, receive **`402 Payment Required`** with machine-readable
payment options, **sign** one of them, have it **verified and settled** through a
facilitator, then **replay** the request and get `200` with the result. No account,
no API key, no session — the payment travels with the request. This article walks
the mechanics step by step, with sources for each part of the protocol, and grounds
them in Invoket's own discovery surfaces. It is the *how* that follows the *why* in
[Why an API key does not work for an autonomous agent](/blog/why-agents-pay-per-call-instead-of-api-keys).

## The loop in one line

The [x402](https://github.com/coinbase/x402) standard defines the whole exchange
as **discover → 402 → pay → replay**. The server answers an unpaid request with a
`402` describing how to pay; the client attaches a signed payment and replays the
same request; the server verifies, settles, and returns the resource. Per the
[x402 whitepaper](https://www.x402.org/x402-whitepaper.pdf) and the
[Coinbase Developer Platform overview](https://docs.cdp.coinbase.com/x402/welcome),
that is the entire protocol — everything below is detail on each arrow.

## 1. Discover the resource

Before it can pay, an agent has to *find* the endpoint and learn what it costs.
There are two complementary discovery paths, and Invoket exposes both.

**By intent, through a registry.** Because Invoket settles through the Coinbase
CDP facilitator, every paid resource is indexed in the **CDP x402 Bazaar** — the
registry that agent runtimes already query. The official x402 **MCP** server
exposes a `search_resources` tool, so an agent finds endpoints by describing the
problem ("screen an IBAN", "validate a phone number") rather than by knowing the
vendor in advance. See [For agents](/docs/for-agents) for the search surfaces.

**By reading the origin directly.** Every x402 origin can publish a
machine-readable map of itself. Following [RFC 8615](https://www.rfc-editor.org/rfc/rfc8615.html)
(the `/.well-known/` convention), Invoket's gateway answers a discovery cascade:

- **`/.well-known/x402`** — the manifest: a list of every paid resource URL on
  the origin, the bootstrap entry point for a crawler.
- **`/openapi.json`** — the OpenAPI description: methods, parameters and response
  shapes for each endpoint, so an agent can build a valid request.
- **`/catalog`** — the living catalog in **Bazaar x402 format**: for each
  resource, its method, its price and the list of accepted rails. This is the
  **source of truth** for what to call and how to pay.

The two paths converge on the same answer: the Bazaar tells an agent *that* a
relevant endpoint exists; the catalog tells it *exactly* how to settle the call.

## 2. Send the request and read the 402

The agent calls the resource with no payment attached. The gateway answers
**`402 Payment Required`** with the payment requirements — an `accepts` array,
one entry per rail it will take:

```json
{
  "x402Version": 2,
  "error": "payment required",
  "resource": { "url": "https://api.invoket.com/iban/resolve?iban=…" },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "<stablecoin contract>",
      "amount": "<atomic amount>",
      "payTo": "<recipient>",
      "maxTimeoutSeconds": 60
    }
  ]
}
```

Each entry is a self-describing offer: a `scheme`, a `network` (CAIP-2), an
`asset`, an **atomic** `amount` in the asset's smallest unit, and a `payTo`
recipient. The values above are placeholders on purpose — **the real asset,
amount and recipient are served live by the gateway**, never copied into an
article. The agent picks a rail it can settle and reads the price from
[`/catalog`](https://api.invoket.com/catalog). Probing is free: a bare request
only returns the challenge, and no money moves until a valid payment is replayed.

## 3. Sign the payment payload

The agent selects one entry from `accepts` and builds a **payment payload** for
that rail. For an `exact` scheme on an EVM network, the payload is an
authorization the agent's wallet **signs locally** — for USDC this is an
[EIP-3009](https://eips.ethereum.org/EIPS/eip-3009) `transferWithAuthorization`,
a gasless transfer the holder authorizes without broadcasting it themselves. The
private key never leaves the agent; signing is the only thing it does. The signed
payload is base64-encoded and carried in the **`PAYMENT-SIGNATURE`** request
header on the replay ([x402 spec](https://github.com/coinbase/x402),
[CDP overview](https://docs.cdp.coinbase.com/x402/welcome)).

## 4. Verify and settle through the facilitator

When the replay arrives, the server has to confirm the payment is valid and move
the funds — without running its own blockchain node. That is the **facilitator's**
job. Per the [x402 specification](https://github.com/coinbase/x402), the resource
server either checks the payment itself or:

1. **`POST /verify`** — sends the payment payload and the requirements to the
   facilitator, which validates the signature, amount, asset and network against
   the offered rail and returns a verification result.
2. **`POST /settle`** — asks the facilitator to submit the transfer on-chain for
   the payload's network and scheme.

This separation is why a seller needs **no chain infrastructure**: the CDP
facilitator settles ERC-20 stablecoin transfers across networks such as Base and
Solana on the server's behalf. Invoket uses the CDP facilitator, which is exactly
what makes its endpoints discoverable in the Bazaar in the first place.

## 5. Replay and receive 200

Once settlement succeeds, the server returns **`200 OK`** with the resource in the
body and a **`PAYMENT-RESPONSE`** header carrying the settlement proof
(the transaction reference), base64-encoded. The agent now has both the answer it
paid for and an on-chain receipt — in the same request cycle it started. You are
**charged only on success**: a failed or unsigned request never debits the wallet.

## The whole loop, against Invoket

Putting the arrows together, an agent that needs one IBAN check runs:

1. **Discover** — find `iban/resolve` by intent in the CDP Bazaar, or read
   `/.well-known/x402` → `/openapi.json` → `/catalog` directly.
2. **Request** — `GET https://api.invoket.com/iban/resolve?iban=…` with no
   payment.
3. **402** — read `accepts`, pick a rail (e.g. USDC on Base), read the price from
   `/catalog`.
4. **Sign** — wallet signs the payment payload locally; attach it as
   `PAYMENT-SIGNATURE`.
5. **Settle** — gateway verifies and settles via the facilitator.
6. **Replay → 200** — same request, now paid; the response body is the resolved
   IBAN, with the receipt in `PAYMENT-RESPONSE`.

In practice the client SDK collapses steps 2–6 into one wrapped `fetch`: the
[Quickstart](/docs/quickstart) shows the runnable probe → sign → replay code, and
[Payments and rails](/docs/payments-and-rails) explains atomic amounts and which
rails Invoket accepts. The agent writes the call once; the loop runs itself.

## What stays off the page

A protocol description should not freeze the parts that move. Prices, atomic
amounts, the `payTo` recipient and any signature are **authority data**: they live
behind the live `402` challenge and the [catalog](https://api.invoket.com/catalog),
not in a blog post. This article describes the mechanism; the gateway settles the
call. When the two disagree, the gateway is right.

## Sources

- x402 protocol, headers and facilitator flow — [coinbase/x402 (GitHub)](https://github.com/coinbase/x402),
  [x402.org](https://www.x402.org/), [x402 whitepaper (PDF)](https://www.x402.org/x402-whitepaper.pdf),
  [Coinbase Developer Platform: x402 overview](https://docs.cdp.coinbase.com/x402/welcome).
- HTTP 402 semantics — [RFC 9110, HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html),
  [MDN: 402 Payment Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402).
- Discovery convention — [RFC 8615, Well-Known URIs](https://www.rfc-editor.org/rfc/rfc8615.html).
- Signed transfer authorization — [EIP-3009: Transfer With Authorization](https://eips.ethereum.org/EIPS/eip-3009).