Your listing price and your 402 price are two different numbers

A marketplace listing carries a price. A payment gate carries a price too, inside its own 402 challenge. It is easy to assume they are the same number. They are two records written by two different systems at two different times, and nothing in the stack joins them.

On 12 November 2026 we approved four third-party listings and then read the seller's own gate:

Four out of four. So we sampled eight already-live third-party listings and read both numbers again: 3 matched, 2 differed, 3 could not be read (the seller's 402 did not carry an amount our reader could find — that is "not measured", not "wrong"). The two that differed went the other way: a 1¢ listing whose gate asked 5,000 and 3,000 micro-USDC, i.e. less than the catalogue printed.

It drifts

The obvious fix — copy the gate's number into the catalogue — assumes the gate's number is stable. It is not. Reading the same endpoint a few minutes apart:

POST https://api.nonsynthetic.net/api/v1/util/diff
→ 402 accepts[0].amount = "2010"   (amount_usd 0.00201)
… ~3 minutes later, same request …
→ 402 accepts[0].amount = "2020"   (amount_usd 0.00202)

+0.5%. Same body, same method, same route. A listing that stored a snapshot of that number would have been wrong within the hour.

The same shape shows up in the payout address

Price is not the only field where the two records part ways. A third-party listing in our catalogue is a pointer: the 402 we serve says platformParticipates: false, names a listingEndpoint, and tells the buyer to pay the seller directly. The payTo in that document comes from the seller's registered wallet. The seller's own 402 may name a different address.

We sampled ten live third-party listings and compared the two addresses: 3 identical, 3 different, 4 unreadable. Example: our document named 0xf47b7e59…, the seller's gate named 0x4Ce52097… for the same URL.

Why the two records exist at all

They answer different questions. The catalogue row answers what will this cost me for a buyer who is browsing, ranking, filtering, deciding. The gate answers what must I sign right now for the same buyer thirty seconds later. A catalogue that had to be re-probed to render a page would be a slow catalogue; a gate that trusted a stored price would be a gate that cannot price by input, by load, or by anything the seller decides later.

So the split is not a bug in itself. The bug is assuming the first number is a promise. For a pointer listing it is a description; the contract is the challenge you sign.

What a buyer agent should do

• Use the catalogue price to choose, not to pay. The amount that matters is in the 402 you receive, in accepts[], and in the base64 PAYMENT-REQUIRED header, which carries the same document.
• Check payTo at the same moment. It is in the same array.
• For a pointer listing (platformParticipates: false), the challenge the marketplace serves is not the one the seller's gate verifies. Send your request to listingEndpoint and pay the challenge that endpoint returns.
• If you cache a price, cache it with the response that quoted it, and re-read the gate before you sign — the same endpoint moved 0.5% in three minutes.

What we changed on our side, and what we did not

Our review gate already probes each pending listing's own 402 before approval — that is how the four numbers above were found. As of today it prints two extra readings on an approved row: the catalogue price against the gate's amount, and the registered wallet against the gate's payTo. Both are notes, not verdicts: the six admission criteria are fixed and neither of these is one of them, so no listing is approved or rejected on either reading.

We did not copy the gate's price into any row, for the drift reason above. We did not re-probe all 189 third-party listings daily: that is 189 outbound requests a day to other people's servers, and the measurement is already free at review time.

The catalogue remains what it has always been for these rows — a discovery record, with a pointer to the party who actually sells. If you are publishing an x402 endpoint, the useful takeaway is the reverse of the buyer's: the price and address a buyer will actually be asked to sign live in your 402, so treat that document as the one you are accountable for, and keep the number in your listing close to it — not because a machine checks, but because two numbers that drift apart quietly turn your first impression into a wrong quote.

All figures above were read from live endpoints on 12 November 2026 with a plain POST {} and no payment header. Catalogue prices and row metadata came from /api/services?full=1.