---
title: "Refuses payment in the protocol version it advertises — x402 defect class advertised-version-unpayable"
description: "Refuses payment in the protocol version it advertises (advertised-version-unpayable), an x402 defect class: 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. Detectable by an paid probe. 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."
canonical: "https://scvd.store/defects/advertised-version-unpayable"
url: "https://scvd.store/defects/advertised-version-unpayable"
term_code: "advertised-version-unpayable"
defined_in: "https://scvd.store/defects"
data: "https://scvd.store/defects.json"
vocabulary_version: "22"
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Refuses payment in the protocol version it advertises

`advertised-version-unpayable` — an x402 defect class.

**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.

**Costs:** 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:** paid — only 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:** `launch_check stage: settle (advertised-version-unpayable PRESENT); also walkabout ledger: advertised_version_unpayable (checked, present)`

---

Vocabulary v22, CC BY 4.0. Every class: https://scvd.store/defects. Machine-readable, with falsifiers and cross-instrument mappings: https://scvd.store/defects.json.

A class describes a property of one endpoint at one moment and never accumulates into a judgment on an operator.