Payload 的 x402 驗證器將 9 個正常付款端點誤判為故障

Story type: documented incident from Payload's Observatory scans.

Our automated x402 endpoint validator flagged nine live payment endpoints as broken. The endpoints were fine. Our validator was the problem.

That distinction matters. A scanner that confuses a protocol compatibility difference with a payment failure can send developers chasing healthy integrations, trigger false incident reports, and damage trust in an operator that did nothing wrong.

What went wrong

Payload's Observatory checks publicly cataloged x402 payment endpoints with nonpaying, method aware probes. The goal is simple: request an endpoint without paying, read the payment challenge it returns, and record whether a standard client could act on that challenge.

During October 2026 scans, the validator returned INCOMPLETE_CHALLENGE for nine endpoints:

• two Strale endpoints;
• four Waltsoft endpoints;
• one endpoint each from uxus.finance, SlamAI, and itsgloria.

The common detail was an unrecognized network format. The old validator recognized CAIP 2 network identifiers, but it did not correctly recognize valid legacy x402 network formats. It treated a format it could not parse as evidence that the endpoint had failed.

That inference was wrong.

Why it matters

An automated checker is useful only when its verdicts separate three very different states:

1. the endpoint returned a valid challenge;
2. the endpoint returned a defective or missing challenge;
3. the checker could not make a reliable determination.

Our old validator collapsed the second and third states. Once that happens, every downstream decision gets worse. A developer may spend hours debugging a working integration. A marketplace may downgrade a healthy service. An operator may receive a defect report based on the observer's parser rather than the operator's response.

The cost is not a fabricated financial figure. It is wasted engineering time, false operational work, and confidence lost in automated evidence.

How we investigated

We treated the validator as a suspect, not as an authority.

First, we preserved the original observations and the registry entries. Then we traced the validator's network recognition logic and found that the runtime copy still used the older CAIP 2 only rule. The corrected validator was already available in the Payload Observatory GitHub repository at revision 8c9ace89be839514e621207befc8abe7144fbd85.

The corrected version recognizes legacy x402 network forms, detects x402 v1 body challenges, and classifies shared egress proxy failures as PROXY_BLOCKED instead of blaming the endpoint.

We installed the corrected code without changing the Observatory data. All eleven data files were checked before and after the code swap, and their hashes matched apart from the intended registry and validation updates. Then we reprobed the same nine endpoints.

All nine returned VALID_402. All nine registry entries returned to ACTIVE status. Two Strale endpoints carried valid x402 v1 challenges using the legacy base network slug. The four Waltsoft endpoints and the uxus.finance endpoint carried a compatibility note for a legacy network slug. The SlamAI and itsgloria endpoints returned valid challenges with no compatibility note.

The earlier verdicts were withdrawn.

The corrected approach

Before declaring a payment endpoint defective, check the checker.

Free endpoint verification checklist

1. Record the request method, URL, response status, response body, response headers, and probe time.
2. State which x402 version and network formats the checker understands.
3. Test whether the challenge is valid under a supported legacy format before calling the network identifier invalid.
4. Separate a proxy failure, timeout, or parser limitation from an endpoint verdict.
5. Reprobe with the corrected parser before reporting a defect.
6. Preserve the original result when a verdict changes so the correction stays auditable.

You can also run the free local tools in the callx402 npm package for a local status check before moving to a deeper diagnostic.

Where Payload fits

Payload built the Observatory checks because x402 failures are often reported with too little evidence. callx402 by Payload, powered by Veyline, is the paid diagnostic layer for cases where the response really does contain a failure. Its hosted diagnose action costs $0.10 by x402 or $2.00 by card. It classifies specific payment failure evidence. It does not diagnose every possible failure, and it does not guarantee recovery.

The lesson from these nine endpoints is narrower and more useful: evidence comes before blame. When the tool and the endpoint disagree, verify both.

Publication note: This account is based on Payload's Observatory detection record from October 15 and 16, 2026, including the correction recorded in section 24 of that record.