Refuses payment in the protocol version it advertises — x402 defect class advertised-version-unpayable

Asserts: A correctly signed payment, presented in the protocol version the door's own challenge advertises, reaches that door's verifier: it is accepted, or refused on something about the payment, never answered with the door's own terms re-served as though nothing had been presented.

What a buyer loses when it is present: The buyer that followed the instructions is the one that cannot pay. It read the advertised version, signed against those terms, presented them in that version's envelope, and got back the offer it started with — from outside, identical to never having paid at all. No money moves, so there is nothing to refund and nothing to chase; what is lost is the sale, silently, and the door has no failed payment to look at either. Seen in the field on 2026-09-12 during a protocol migration, on a door whose operator then found the same version-keyed read on three more of his own surfaces.

Detectable: only by a paid probe — a settled payment reveals it.

Falsified by: The door answering a correctly signed payment, presented in the version its challenge advertises, with anything other than its own terms re-served — the goods, a refusal naming something about the payment, or an offer whose material terms (scheme, network, payTo, asset, amount) have changed — at the stated moment. A door that advertises one version and refuses a DIFFERENT one is not this defect: the class is about the version the door itself names. Nor is a door that re-serves terms which differ only in a nonce, an expiry or a timeout being cleared by that variation; those rotate legitimately and this class reads the material terms alone.

How an operator clears it: Count every place your code names a payment header; this is a version-keyed read and it is rarely in one place. Route every paid front-end through one translation that accepts each version you advertise and hands the inner payload to a single verifier unchanged — for exact/eip3009 the signed EIP-712 domain carries chainId rather than a network label, so translating the envelope cannot disturb the signature. Then check what your request log and payment ledger key on: a surface that accepts the newer version while its ledger keys on the older one is a separate fault this class cannot see, and it makes your own attempt counts a floor rather than a number.

What a buyer does: If a door answers your signed payment with the offer you already read, do not sign again — nothing settled, and a second signature buys nothing the first did not. Read the refusal for a header name different from the one you sent; if it names another version's header, the door is unpayable as advertised rather than refusing you. Keep your raw request and response: the door's own records may hold no row for the attempt, so yours may be the only account of it.

Our signal: walkabout ledger: advertised_version_unpayable (checked, present).

Named by Observed by this store's own walk of a door on 2026-09-12; the class's boundary was corrected before publication by StillOS Notary (stillosdigitalholdings.com), who named the comparator's false negative and the seller-side variant it must not claim. Registrar of that correction, and author of the class., registered 2026-09-13 — this store is the registrar, not the author.

Vocabulary v15, CC BY 4.0. Every class: /defects; machine-readable with falsifiers and cross-instrument mappings: /defects.json. A class describes a property of one endpoint at one moment and never accumulates into a judgment on an operator.