---
title: "Asks for new money when a settled payment is presented again — x402 defect class re-challenges-spent-authorization"
description: "Asks for new money when a settled payment is presented again (re-challenges-spent-authorization), an x402 defect class: A byte-identical, already-settled payment presented a second time is answered with the original outcome or a refusal, never with a fresh payment challenge. Detectable by an paid probe. A buyer who paid and lost the response re-presents the same authorization and is told to pay. Its nonce is spent, so the only way through the new challenge is a second signature — and the second signature is a second charge for goods the first one already bought. From the buyer's side it is one purchase attempted twice; from the seller's, two sales. This is the receiver-side defect the x402 specification thread measured in seven of ten money paths in September 2026."
canonical: "https://scvd.store/defects/re-challenges-spent-authorization"
url: "https://scvd.store/defects/re-challenges-spent-authorization"
term_code: "re-challenges-spent-authorization"
defined_in: "https://scvd.store/defects"
data: "https://scvd.store/defects.json"
vocabulary_version: "22"
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Asks for new money when a settled payment is presented again

`re-challenges-spent-authorization` — an x402 defect class.

Launch Check v4 compares complete response bytes. Transaction references alone do not establish redelivery; changed bytes alone do not establish fresh fulfillment. Historical v3 served_again and redelivered mappings were heuristics, and a fresh challenge alone proves no second charge. Read the report's battery, response evidence and payment_attempt.verification separately. The September 13 correction at /corrections withdraws the stronger interpretation; saved signed records retain their bytes.

**Asserts:** A byte-identical, already-settled payment presented a second time is answered with the original outcome or a refusal, never with a fresh payment challenge.

**Costs:** A buyer who paid and lost the response re-presents the same authorization and is told to pay. Its nonce is spent, so the only way through the new challenge is a second signature — and the second signature is a second charge for goods the first one already bought. From the buyer's side it is one purchase attempted twice; from the seller's, two sales. This is the receiver-side defect the x402 specification thread measured in seven of ten money paths in September 2026.

**Detectable:** paid — only a settled payment reveals it

**Falsified by:** The endpoint answering the identical presented payment on the second attempt with anything other than a new payment challenge — a refusal, or the original purchase — at the stated moment.

**How an operator clears it:** When a presented authorization's nonce is already spent, look it up before you build a challenge: answer with the original purchase's outcome and its settlement reference (a paid retry, charged nothing), or refuse naming that settlement. Never let the spent-nonce path fall through to the code that issues a fresh 402.

**What a buyer does:** If a door answers your re-presented payment with a new challenge, do not sign it: your first authorization may have settled, and a second one is a second charge. Keep the settlement reference from your first response, read the chain for it, and use the door's recovery path or ask for delivery against that settlement before paying again.

**Our signal:** `launch_check stage: replay (outcome rechallenged)`

---

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.