Failure modes a 402 response cannot rule out
A liveness probe asks one question: does an unpaid request return HTTP 402 with payment requirements? That proves the endpoint is up and speaks the protocol. It does not prove anyone can actually pay it.
Everything on this page produces a perfectly valid 402. Every case is something we found in production while monitoring the x402 ecosystem around the clock: 70,000+ monitored endpoints on Base and Solana (90,000+ tracked in total), continuous probes, on-chain settlement tracking. None of these cases are visible from the outside unless you look for them specifically, and a directory that surfaces them does something more useful than scoring uptime, as long as it labels them precisely instead of folding them into a failure rate.
Format and honesty standard follow the excellent FAILURE-MODES.md from nohumans.directory. They documented cases 5 and 7 first; we verified them against our own data and added what they had not seen. Where a check costs nothing, we say how to run it. Where a field comes from an operator's declaration rather than our own measurement, we say so. Everything else here is measured.
1. Solana payTo has no token account
Symptom. The payment dies in simulation and never reaches the chain. The 402 challenge looks completely normal.
Cause. On Solana, a wallet receives USDC in an associated token account (ATA). If the payTo wallet has never held the token, that account does not exist, and the reference clients do not create it. The payer signs the transaction, so the instruction set is fixed before the facilitator sees it; adding the account creation afterwards would invalidate the signature. A community researcher sampled 865 settlement transactions across four facilitator fee-payer addresses (two of which we could attribute to Coinbase from our own registry) and found zero recipient ATA creations.
What we see. About one in five Solana receiver wallets advertised across the ecosystem right now cannot collect: 37 out of roughly 170 we track. The shape mirrors the healthy side of the ecosystem: fan-out operators, one wallet serving dozens of routes. The worst case is a single dead wallet advertised on 71 payable-looking endpoints. In total those 37 wallets appear on around 360 live endpoints across about 70 hosts. Everything those operators can see looks fine.
Detection. Derive the ATA from payTo and mint, then ask the RPC whether the account exists (getAccountInfo). Deterministic, free, no cooperation from the operator needed. One caveat from production: a missing ATA at a single point in time is not proof, because wallets get created. We only flag a receiver after two sightings six hours apart, after watching how easily one snapshot can lie.
2. The rent-reclaimer: the ATA existed, and was closed
Symptom. Identical to the case above. The payment dies in simulation.
Cause. Closing an ATA returns its rent deposit (about 0.002 SOL). Some operators collect for a while, close the account, and keep the rent. The account is gone, but the settlement history proves the wallet could collect once.
What we see. 7 of the roughly 170 Solana wallets we track. We classify these as a warning, not as broken: the operator demonstrably knows how to fix it, because they did it once.
Detection. ATA missing plus any on-chain settlement history to that ATA. If history exists, someone collected before, and the listing deserves a warn rather than an avoid.
3. payTo is the zero address
Symptom. Nothing, from the buyer's side. The 402 is valid, and payments even settle. They settle into the void.
Cause. Misconfigured endpoints advertise 0x0000000000000000000000000000000000000000 as the receiver. Transfers to that address are USDC burns, not revenue. We found them because they polluted our settlement aggregates until we purged and flagged them.
What we see. Found in our own settlement ingestion, in data from otherwise well-formed endpoints.
Detection. Compare the advertised payTo against the zero address. Trivial and free.
4. The receiver changes over time
Symptom. None at any single moment. Every individual 402 is valid.
Cause. A listed endpoint whose payTo suddenly changes is a takeover or rug signal. One-shot verification cannot see this at all; it only exists as a pattern over time.
What we see. This is the temporal dimension of verification, and it is why our watch product exists: subscribers get alerted on payTo changes, price changes, spec regressions, and delistings, because none of these are visible in any single probe.
Detection. Snapshot the 402 accepts on a schedule and diff them. Alert when the receiver, the price, or the schema changes, or when a previously compliant endpoint regresses.
5. EIP-712 domain name does not match the token
Symptom. The facilitator rejects with invalid_exact_evm_token_name_mismatch. Nothing settles.
Cause. The exact EVM scheme signs an EIP-712 authorization whose domain must equal the token contract's on-chain name(). Mainnet USDC reports "USD Coin". The Base Sepolia test token reports "USDC". Code written against testnet and moved to mainnet keeps the wrong string.
What we see. Real case, ours: we run a paid x402 storefront, and a wrong domain value breaks signature recovery for every single customer payment. We keep the value pinned and documented, because getting it wrong once was enough. First documented by nohumans.directory; we can only confirm it is real.
Detection. For common assets a lookup table is enough. For the general case, an eth_call to name() on the asset contract. Free.
6. Endpoint and client speak different spec versions
Symptom. The client reports no payment requirements, or crashes. The endpoint is correctly configured.
Cause. x402 v1 returns the challenge in the response body with an accepts array. v2 may return it in a payment-required header with an empty body, and renames fields (maxAmountRequired becomes amount). A client implementing one side cannot see a challenge from the other.
What we see. Both transports appear in our live probe data across the ecosystem.
Detection. Probe both transports and record which one each endpoint answers. Important: this is a compatibility fact about a pair, not a defect on either side, and it must not be scored against anyone. We agree with nohumans on this completely.
7. The facilitator does not support the advertised network
Symptom. The payment fails at /verify. The 402 itself is valid.
Cause. The endpoint advertises a network its configured facilitator will not settle on. The classic case: developed against a testnet facilitator, moved to mainnet by changing only the network variable.
What we see. First documented by nohumans.directory, including the painful detail that their own endpoints had it twice. We cannot add production cases of our own yet, for the reason below.
Detection. Fetch {facilitator}/supported and compare it against the advertised network. The catch: the 402 challenge usually does not name the facilitator, so this check needs the operator to declare it. Our submission form asks for the facilitator URL (optional) for exactly this reason. Without a declaration we have partial coverage: we track on-chain which facilitator addresses actually settle on which chains, so we know what the big ones support in practice. Measured, not declared.
What verification can honestly claim
Verification is not one thing. It has layers, and they cost different amounts:
The third row used to go unchecked everywhere. It does not anymore: we run the Solana part of it across the ecosystem now, and cases 1 and 2 above are its output. The last row is the one no one-shot check can ever cover, and it is the reason continuous watching exists as a product at all.
What we do not check
Whether the response contains what was advertised. The "delivers" row needs a real payment and a semantic check of the answer, so at any scale it belongs in sampling, not in the main loop.
Facilitator mismatches without a declared facilitator. Case 7 is undetectable from the outside unless the operator says which facilitator they use. If you run an endpoint, declare it when you submit; it makes your listing verifiable.
Anything client-side. The shared-wallet balance race documented in the nohumans addendum lives entirely on the paying side. No endpoint probing can reproduce it.
Found a failure mode we have not seen? We monitor this ecosystem continuously and would genuinely like to hear about it. If you run an endpoint and want to know which of these apply to you: search for it on the front page, or submit it if it is not listed yet.