A 402 Response Is Not Always a Payment Challenge
Story type: documented external endpoint observations with public GitHub issues.
An HTTP 402 response tells a client that payment is required. It does not, by itself, give the client enough information to pay.
That difference showed up in two Observatory findings that Payload reported publicly. One endpoint returned a 402 without a parseable x402 challenge. Another set of paid catalog routes answered HTTP 200 without presenting a challenge at all.
We are describing the observed response classes, not questioning either operator's intent. A route may be intentionally free, temporarily misconfigured, or described by a stale catalog entry. The integration problem remains: the catalog expectation and the live behavior do not match.
Finding one: a 402 with no usable challenge
Payload's nonpaying probe of POST https://conc-exe.xyz/api/concierge-security-scan returned HTTP 402 without a parseable x402 challenge. The observation took about 16 seconds during the October 15, 2026 scan.
A standard client cannot turn that response into a payment because the challenge does not provide usable payment terms. The client knows payment is required, but not how to satisfy the requirement through the expected protocol.
Payload filed the observation as theconcierge99-hue/gold-panel issue 2:
https://github.com/theconcierge99-hue/gold-panel/issues/2
Finding two: paid listings that answered without a challenge
Payload also observed Locus catalog routes answering HTTP 200 without payment. The clearest recorded example was POST https://api.locus.report/api/locus-radon-zone, which answered without an x402 challenge despite a paid catalog listing. A second Locus route was recorded with the same class of behavior.
Payload filed the drift report as velinussage/locus-agent-skill issue 2:
https://github.com/velinussage/locus-agent-skill/issues/2
The issue frames the question fairly. The live routes may be intended as free answers, or the catalog may be stale. Either way, a buyer or agent planning around the catalog cannot rely on the listed payment behavior until the two records agree.
Why these failures matter
Payment automation depends on a short chain of facts:
- Is payment required?
- How much is required?
- Which asset and network should be used?
- Which recipient should be paid?
- What evidence should the client return after authorization?
A malformed 402 breaks the chain at the first step. A paid listing that answers 200 breaks a different expectation: the client's planning, accounting, and access logic may assume a payment event that never occurs.
Both problems can look vague from the client side. The application may report a generic payment failure, retry without new information, or mark a healthy service as unavailable.
A safer way to test
Use a nonpaying probe first and preserve the evidence:
- request method and URL;
- response status;
- response headers and body;
- whether a challenge can be parsed;
- the network, asset, amount, and recipient when present;
- the catalog entry used for comparison;
- the exact probe time.
Then classify the result narrowly. “402 without a parseable challenge” is a precise claim. “Endpoint answered 200 without a challenge although the catalog lists it as paid” is also precise. Neither claim requires guessing why the operator configured it that way.
Free next step
Before paying an unfamiliar endpoint, run the free local status tooling in the callx402 npm package and compare the live response with the service catalog or manifest. Payload's free x402 Manifest Check Action is also available through the services catalog at https://payloadhq.github.io/services.html.
The paid next step
When the evidence shows a real challenge or classification problem, callx402 hosted failure_classification and diagnose can provide a deeper read of the supplied failure evidence. Hosted diagnose costs $0.10 by x402 or $2.00 by card. callx402 does not diagnose every failure and does not guarantee recovery.
Evidence note: Payload made nonpaying probes only. No 402 challenge was answered and no payment was submitted for these observations.