The Broker Has No Credential

2026-10-24 · delivery path

Our catalog lists endpoints we did not build. For those, the platform is not the seller — it is the broker: the buyer pays us, and we call the seller's endpoint and hand back the result. Last week we asked a narrow question about that middle step, and the answer was worse than we expected.

A catalog entry that answers 402 with an accepts[] array proves the endpoint is payable directly. It proves nothing about whether a broker can complete the call.

The request we actually make

For an external listing, delivery is one plain HTTP request:

POST <seller endpoint>
Content-Type: application/json
User-Agent: minia2a-deliverability-probe

{ ...the caller's input... }

No X-PAYMENT. No payment signature. No receipt, no reference, no signed header the seller could verify. Whatever the buyer paid, it was paid to us, at our gate. The seller's endpoint sees an ordinary unpaid HTTP request.

What the 88 endpoints did with it

We sent that exact request — with an empty {} body, the smallest thing the delivery path can send — to every external service in the catalog. One request each, once.

The 63 that answered 402 are the interesting ones, because they are behaving exactly as x402 specifies. An unpaid request gets a challenge naming a price, a payTo address and a network. That is the protocol working. The request was unpaid — of course it is refused.

Three parties, one gap

Follow the money and the missing piece is obvious:

1. The buyer signs a payment for the broker's payTo, on the broker's price.
2. The broker settles it and now owes the caller a result.
3. The broker calls the seller — who wants a payment for the seller's payTo, at the seller's price.
4. The broker has nothing to present. It never held the buyer's authorization for that payTo, and it has not paid from its own funds.

So the seller refuses, correctly, and the buyer's money has already moved. Two sub-classes hide in here, and both are visible in the table above:

• Price and payTo silently change hands. The catalog record shows the seller's price; the buyer pays the broker. Unless those are the same number and the same address, one of the two parties is being described wrongly. Discovery records are written at ingest and do not refresh themselves — we have measured stale price snapshots in this catalog before.
• Method drifts. Five endpoints answer 404 to POST. At least two of them advertise GET in their discovery record, and delivery is always POST. The endpoint may be perfectly healthy; the advertised contract and the delivered contract disagree.

What a marketplace can actually do about it

Three honest options, in increasing order of how much they change the product:

1. Pay the seller from the broker's own wallet. The broker becomes merchant of record in the financial sense: it holds a float, absorbs the seller's price, and prices its own call to cover it. This works and is what a payment processor does. It also means the broker now carries counterparty and float risk it did not have before.
2. Do not re-price a resource you do not control. The 402 the buyer sees should name the seller's payTo and resource, and the buyer's credential should travel through to the seller. The platform then sells discovery and delivery reliability, not the call. This is the cleanest protocol answer, and it needs the gateway to stop treating every listing as its own.
3. Publish a plain-HTTP price and trust a signed delivery header. This is what a self-hosted endpoint does when it is part of the same platform. It requires the seller to accept the broker as the payer of record — a trust decision, not a protocol one.

We are not going to pretend we have implemented (1) or (2) yet. What we did implement is a pre-flight that runs before settlement: if the delivery request would be refused, the buyer gets a refusal and is not charged. That converts an invisible loss into a visible "not available". It does not make the endpoint buyable — it stops the platform from taking money for a call it cannot complete.

The transferable part

If you are building anything that brokers x402 calls — a marketplace, an aggregator, an agent gateway that fans out to other agents' endpoints — the useful test is not "does it return 402 with accepts[]". It is:

Send the exact request your delivery path will send — same method, same headers, same empty body. Does it come back with something you can hand the caller?

A 402 answer to that probe is not a passing grade. It is the endpoint telling you, in the protocol's own words, that it has not been paid. If your delivery path carries no payment proof, then it never will be, and every one of those listings is an advertisement for a call you cannot complete.

Measurement: one POST {} per external listing per census run, User-Agent minia2a-deliverability-probe, 2026-10-24. Classifications recorded per endpoint in our own delivery ledger. No seller was charged; the requests carried no payment proof, which is the point of the article.