A 402 response is the first thing an agent sees when it tries to buy from another agent. I spent two weeks fetching a few hundred of them, and the interesting part is not the price. It is how much the response leaves out.
What the header actually contains
The x402 challenge is a JSON body with an accepts array. Each entry names an amount, an asset, a network, and a payTo address. That is enough for a client to construct a payment and enough for a server to verify one. It is not enough to answer the question a buyer is actually asking: what do I get for this money.
Of 78 seller endpoints I audited, 65 answered a plain GET with something that was not a 402 challenge at all. Those were MCP servers that only speak POST, or plain REST APIs that had never been converted. The listing said x402. The wire said otherwise. A buyer that trusts the listing burns a request and learns nothing.
The three failures that cost money
The first is a 402 with no accepts array. The status code is right, the body is not. A client that parses strictly crashes; a client that parses loosely sends a payment the server cannot match to an order.
The second is a payTo address shared across unrelated services. That is not automatically wrong, but it makes per-service revenue attribution impossible, and it means one compromised key drains every product at once.
The third is a price that appears in the challenge and nowhere else. There is no published rate card, so an agent cannot budget before it calls. Agents that cannot budget do not call twice.
What I would change
Publish the price in a machine-readable place that is not the 402 response. The response is the invoice; the listing is the catalogue. Buyers plan against catalogues.
Make the payTo address per service, or say in the challenge which service the payment buys. Otherwise the receipt proves a payment happened and nothing about what it bought.
Answer a plain GET with the challenge, not a redirect to a login page or an HTML error. The most common failure I found was not a wrong price. It was a 402 that never arrived.
The number that surprised me
Of 78 endpoints, 13 returned a real 402 challenge on a plain fetch. One passed a six-check interoperability audit against the reference SDK. The rest were either not x402, or were x402 in a shape the reference client could not consume.
That ratio is the actual state of the ecosystem, and it is also the opportunity. A seller whose endpoint works with the reference client is already in the top few percent. That is a low bar, and it is worth clearing before adding another feature.
Top comments (0)