Can a buyer actually pay your x402 endpoint?

Answering HTTP 402 is not the same as being payable. A payment can still fail on a schema rule, an EIP-712 domain, a facilitator limit or a server bug, and the seller never sees it.

Free No account, no wallet x402 tooling, 2026-10-13

We tested this directly: for each endpoint we sent one payment signed by a fresh, unfunded wallet. No money can move. A payable endpoint rejects it only for insufficient balance. Any other answer means funded buyers are probably failing too, or that a buyer's agent cannot tell why it failed. Each check also reports whether your payTo has resources in the Coinbase Bazaar and when this URL's entry was last refreshed.

New, 2026-10-14: we re-ran the test on 4,256 routes from 1,735 CDP Bazaar sellers. 2,262 were payable. 38 sellers answer a rejected payment with "facilitator unavailable" (CDP's /verify returns HTTP 400 for a rejected payment, and hand-rolled code treats it as an outage), 41 return HTTP 500, 12 have Bazaar listings whose URL 404s, and 3 served the paid result to an empty wallet. Write-up and fixes. The checker below now handles POST routes and gives a fix hint.

Check yours

Free, 10 per day

Keep it payable: free 30-day monitor

We probe your endpoint every hour the same way for 30 days and email you when it stops (or starts) being payable, with the exact rejection reason. Free, no account, no wallet. The first check result comes back right away, with a live status badge (x402 | payable) you can put in your README or docs. POST-only routes are supported. Every email has a link that stops the monitor.

Start a monitor

3 active per email

Whole-origin audit: every paid route, free

One click checks every paid route we can find for your origin, GET and POST (up to 40): your /.well-known/x402, /openapi.json and your own CDP Bazaar listings, so you also see listed routes that now 404 or quote a price buyers cannot pay. Each row has the exact rejection reason and a fix hint.

Audit an origin

Free, 3 audits a day

What we found on 2026-10-13

Targets: every endpoint in the x402-list.com directory (offline when we checked on 2026-10-17) marked payment-ready that has a GET route priced in USDC on Base (305 endpoints, one per service).

305endpoints tested

94confirmed payable

132rejected for another reason

58unreachable at probe time

94 confirmed payable (rejected only for balance).
58 unreachable at probe time, and 10 no longer answered 402.
132 rejected the payment for some other reason. Most errors are opaque (Internal Server Error, payment_rejected, Payment required), so neither we nor a buyer's agent can tell whether a funded payment would pass.
6 are priced above $1, which the standard @x402/fetch client refuses by default (spendControls.maxAmountPerPayment). A default client cannot buy them at all. 2 more could not be signed by a standard client.
1 confirmed Coinbase facilitator schema rejection: its resource description is 511 characters. We hit the same error on our own endpoint at 572 characters and fixed it by cutting the description below 500. (Operator notified.)
1 served paid content in response to the unfunded signature: its paywall is not collecting.

Second sample: 979 Coinbase Bazaar sellers (same day)

We then probed one GET route per seller origin listed in the CDP Bazaar (Base, exact scheme), skipping origins already tested above. Every one of these has had at least one payment settle before. 444 were confirmed payable, 143 unreachable, 39 no longer answered 402, 340 rejected for a non-balance or opaque reason (some because the Bazaar URL lacks required parameters), and 10 were unsignable by a standard client. 3 listed sellers are confirmed casualties of the description cliff (508, 535 and 557 characters): they were payable once and are not now. We have told the two we could reach. Three "served without payment" hits turned out to be free help text, not paid data.

Most common non-balance rejections (first sample)

Endpoints	Error
23	`Internal Server Error`
12	`invalid_payload`
9	`payment_rejected`
7	`PAYMENT-SIGNATURE header is required`
7	`Payment required`
5	`missing required query parameter`
4	`Payment verification failed`
4	`invalid payment`

Checklist if yours fails

Keep resource.description under 500 characters (CDP facilitator).
Every EVM accepts[] entry needs extra.name and extra.version (USDC on Base: "USD Coin", "2"), or clients cannot sign.
Prices above $1 need buyers who have raised their client's spend cap.
Return the facilitator's invalidReason in your 402 response, not a generic error, so buyers' agents can tell "no funds" from "your server is broken".
Only serve content after verify (and ideally settle) succeeds.
Re-test after any change to route metadata. Our own payments broke silently for 33 minutes after we edited a description.

For AI agents: x402 API, priced per call

HTTP 402 USDC on Base or Arbitrum

People use the tools above for free. Agents and CI can call the same checks over x402, paid per call in USDC on Base or Arbitrum.

Endpoint	Price
GEThttps://contractlens-api.appin60.com/payability?url=…	$0.01USDC
GET/audit?origin=…	$0.25USDC
GET/monitor?url=…&email=…	$0.99USDC

Docs

Method

One GET without payment (expect 402), then one GET with a payment signed by a newly generated key that holds no funds, using the reference @x402/fetch client. Results are a snapshot. A rejection can come from a temporary outage, and an opaque error is not proof the endpoint is broken. Probe user agent: PayabilityProbe/1.0. Raw results are available on request: [email protected]