Most x402 monitoring stops at the wrong question.
“Is your server alive?” is easy to answer. A ping, a status code, a green light. Done. What it doesn't tell you is whether the payment will actually clear when your agent tries to pay.
We built a layer to check that. And in building it, we found something the whole x402 ecosystem needs to know.
The three questions you should be asking
When we designed CORTX's monitoring stack, we split it into three layers based on what each one actually verifies.
Layer 1 — Is the service reachable? A lightweight check. Availability, the 402 response, payment terms, price validity. No money moves. Runs every 15 minutes. Near-zero cost. This is what most monitoring does and calls it finished.
Layer 2 — Would a payment actually clear? This is the layer we just built. We call the facilitator's /verify endpoint with a signed EIP-3009 authorization — the exact authorization a real payment would use — but we don't call /settle. No USDC moves. We just ask: if we paid right now, would it work?
Layer 3 — Did someone pay and receive the result? A full synthetic payment. Real USDC, end-to-end, through every stage of the x402 pipeline. This runs daily.
Each layer catches a different failure mode. Layer 1 tells you the server is alive. Layer 2 tells you the payment infrastructure is working. Layer 3 tells you the product was actually delivered.
We expected Layer 2 to be straightforward. It wasn't.
The HTTP 500 that changed everything
The first time we ran payment readiness checks, we got this back from x402.org:
HTTP 500: No facilitator registered for scheme: exact and network: baseThis didn't come from the service we were checking. It came from x402.org — the facilitator we'd been routing payment authorizations to by default.
The problem: x402.org doesn't know about bankr.bot's services. bankr.bot runs their own facilitator at https://api.bankr.bot/facilitator. They specify it directly in their 402 response. We were routing to the wrong place and getting a 500 that looked like a service failure — but was actually a routing failure.
Those are not the same thing. Not even close.
Facilitators are not universal
This is the finding we want every x402 builder to internalize: x402.org is not a registry for all x402 services.
Each service can specify its own facilitator URL in their 402 response. It can appear at up to three different levels in the response body. If your implementation doesn't check all three — if it just defaults to x402.org — you'll fail for any service that runs its own facilitator, and you'll get a 500 that gives you no useful signal.
We looked at six endpoints in our test run. Every single bankr.bot service (five of them) specifies https://api.bankr.bot/facilitator as their facilitator. Zero of them would have worked if we'd kept routing to x402.org.
The correct discovery order — check each of these in the 402 response, use the first valid HTTPS URL you find:
matchingOption.extra.facilitatormatchingOption.facilitator(top level of the accepted payment option)paymentRequirements.facilitator(root of the payment terms object)
If nothing is found at any level, fall back to the default. But check all three first.
What payment readiness verification looks like when it works
After we fixed the facilitator discovery, here's what we got from a single run against our full service set:
- 5 of 6 services: ready, authorization valid
- Facilitator:
https://api.bankr.bot/facilitator(discovered from the 402 response, not hardcoded) - Authorization TTL: 60 seconds
- Average
/verifylatency: ~95 ms - USDC spent: zero
The one failure (Exa.ai) was unrelated to the facilitator — it uses a non-standard field name in its payment terms. A separate fix.
95 milliseconds to know whether a payment would succeed. No money at risk. That's the whole point of this layer.
There is also a replay risk question worth addressing directly: the signed EIP-3009 authorization has a 60-second TTL. The /verify call goes to the same facilitator the service already trusts — so that facilitator holds the signed authorization during any real payment flow anyway. The exposure window is not meaningfully different from a real paid check.
What we've added to the open spec
We've updated the x402 Reliability Specification (v0.2) with two additions — both built from running this against live services on Base mainnet, not from spec-writing in a vacuum.
Facilitator Discovery — a formal definition of the three-level lookup algorithm any implementation should use. Includes the distinction between a facilitator routing error and a service failure, and why conflating them produces misleading monitoring results.
Payment Readiness Verification — a defined middle tier with its own evidence record format, error codes (FACILITATOR_NOT_REGISTERED, VERIFY_TIMEOUT, VERIFY_REJECTED), and cadence guidance. If you're building x402 reliability tooling, this is the pattern.
The spec also formalizes the three-tier model — lightweight checks, payment readiness, and full verification — as a recommended approach rather than leaving it implicit. Each tier has its own evidence record format and is designed to run independently.
If you are building on x402
Check your facilitator discovery. If your implementation assumes x402.org handles everything, test it against a service that runs its own facilitator. The 402 response is the authoritative source — always read it.
The updated spec is open at github.com/danbuildss/x402-reliability-spec. Issues and contributions welcome.