ContractLens · x402 tooling · 2026-10-13

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

Check yours (free, 10 per day)

Use the full URL your buyers call, including required query params. GET endpoints on Base USDC, x402 v1 and v2.

For agents and CI: GET https://contractlens-api.appin60.com/payability?url=… costs $0.01 USDC via x402 (Base or Arbitrum). The free form calls /payability-free.

Keep it payable: 30-day monitor, $0.99

We probe your endpoint every hour the same way and email you the moment it stops (or starts) being payable, with the exact rejection reason. One payment of $0.99 USDC on Base; no subscription, no account. It starts right away and the first check result comes back in the response.

Signs a USDC transfer authorization in MetaMask, Coinbase Wallet or Rabby on Base; the facilitator pays the gas. Agents: GET https://contractlens-api.appin60.com/monitor?url=…&email=… via x402.

What we found on 2026-10-13

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

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):

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.

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]