# My x402 resource is listed in the Bazaar but buyers say it does not work

Canonical: https://x402.chikocorp.com/blog/x402-bazaar-listing-not-working.html

A listing is not a server. The catalogue publishes what you declared; the buyer experiences what your
route does at that moment. When the two drift apart nothing errors — the resource simply stops
selling, and the only trace is an agent that gives up.

## Step 0 — Reproduce the buyer's request, not yours

```sh
curl -s -i https://your-api.example.com/paid/route
```

No auth headers, no cookies, no wallet. Read the status code and whether a challenge came back.

## Step 1 — Is the status a 402?

| You see | What it means | Where to look |
|---|---|---|
| 402 | The paywall is reached | go to step 2 |
| 200 | The payload is free | route order, CDN cache, static file shadowing, proxy |
| 401 / 403 | Auth gate before the payment layer | payment middleware first, auth after |
| 405 | Verb mismatch | step 2 |
| 404 / 410 | Route moved or retired, listing stayed | refresh discovery after deploy |
| 5xx | Crash, deploy, capacity, maintenance | your logs |

A 402 with an unreadable or missing challenge counts as a missing 402.

## Step 2 — Does the verb match the listing?

The most common silent breakage: the listing says `GET`, the handler charges on `POST`. The agent
follows the listing, gets a `405`, and stops before seeing a price. `Allow: POST` is a hint, not a
challenge. Publish the charging verb, or answer the listed verb with the challenge.

## Step 3 — Does the price match what the listing promised?

Compare four values between the live challenge and the catalogue entry: **amount**, **network**,
**asset**, **payTo**. A buyer with a spend policy refuses a price above the listed one, and a changed
payout address is indistinguishable from a scam from outside.

```sh
curl -s -X POST https://x402.chikocorp.com/api/preflight/inspect \
  -H 'content-type: application/json' \
  -d '{"resource_url":"https://your-api.example.com/paid/route","method":"GET","max_price_usd":1}'
```

## Step 4 — Is the Bazaar extension actually valid?

Check `extensions.bazaar.info` (a concrete example), `extensions.bazaar.schema` (a JSON Schema), and
that the example validates against the schema. Without it the agent knows the price but not how to
call you. Reference: https://github.com/coinbase/x402/blob/main/docs/extensions/bazaar.mdx and
https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md

## Step 5 — Does the facilitator settle?

Test with a funded wallet at the smallest amount you sell: the facilitator accepts the signature, the
transfer lands at `payTo`, and your handler delivers after settlement. Docs:
https://docs.cdp.coinbase.com/x402/seller/quickstart ·
https://docs.cdp.coinbase.com/x402/support/troubleshooting

This is the only step that costs money, and the only one no read-only checker can do for you.

## Step 6 — What sits in front of your route?

- **CDN cache** serving a 200 to agents that should have received a challenge.
- **WAF / bot rules** blocking agents with no browser fingerprint before payment.
- **Redirects** that drop the challenge header.
- **Proxy header buffers** too small for a large challenge (~14 KB in ours).
- **Compression middleware** mangling a base64 header.

Compare the headers your origin emits with the headers the internet receives.

## The pre-listing checklist

- [ ] The listed verb returns 402 to an unauthenticated request.
- [ ] The challenge is readable: amount, network, asset, payTo.
- [ ] The price on the wire equals the price in the listing.
- [ ] `extensions.bazaar` is present, valid, and its example validates.
- [ ] No CDN, WAF or auth gate intercepts the listed path.
- [ ] One real purchase settles and delivers, at the smallest amount you sell.

## FAQ

**Why does my endpoint answer 200 when the Bazaar says it costs money?**
The middleware is not in the path of that verb, or something answers first: static file, CDN cache,
proxy or auth gate.

**The listing says GET but my route charges on POST. What do buyers see?**
The GET, a 405 or a free 200, and they stop. An agent follows the listing, not your implementation.

**How long does a corrected listing take to propagate?**
The discovery layer is a crawler, not a live proxy. Expect a delay after you fix it, and verify your
endpoint rather than the listing.

**Is a healthy challenge enough to sell?**
No. It proves a buyer can construct a payment, not that it settles or that delivery happens.

Check any endpoint free: https://x402.chikocorp.com/verify