Same idempotency key, different amount, same response

Had a retry bug where a client resent a payment request with a corrected amount but reused the idempotency key from the failed first attempt. Gateway matched on the key, found a cached response, and returned it — original amount, original transaction ID, 200 OK. No error about the mismatch. No flag anywhere in the response body.

We assumed idempotency keys were scoped to "this exact request," so reusing one with changed parameters would either fail validation or create a new charge. Neither happened. The provider's docs did mention that keys are matched independently of payload, but that line was three paragraphs below the retry example, and nobody reads past the retry example.

Took us a day to find because the symptom wasn't a failed payment, it was a correct-looking payment for the wrong amount. Our reconciliation job flagged a mismatch between order total and charge total, and from there it was logs-first debugging to figure out why a request with amount=4200 returned a response for amount=3800.

Fix was boring: generate a new key whenever any field in the request changes, not just on network-level retries. But the bigger question is why idempotency scoping isn't more consistently payload-aware across providers — some hash the body into the key check, some don't.

Anyone built a wrapper that enforces key-to-payload binding client-side instead of trusting the gateway's matching logic?