# Review the same key with a different amount

A duplicate check must distinguish a matching retry from conflicting reuse. Test a valid request whose material value changes while its key stays the same.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Establish one accepted intention

Submit a synthetic command with an account, target and amount using a known key. Record the normalised payload and result.

Then reuse the key with a different valid amount. The service should reject the conflict according to its contract. It should neither execute the new amount nor return the old result as if the changed request had been satisfied.

Repeat with a changed target and currency. These fields often reveal whether the fingerprint covers business meaning or only a convenient subset.

## Inspect normalisation

Compare omitted defaults, explicit defaults, field order and equivalent formatting. Decide which differences should count as the same request and verify the implementation applies that rule consistently.

Avoid a raw JSON string comparison if harmless property order can differ between clients. Conversely, do not normalise away a meaningful distinction simply to reduce conflicts.

Keep the canonicalisation version stable or provide a migration rule. A server update that fingerprints old requests differently can turn legitimate retries into conflicts.

## Review atomicity and result states

Find the storage uniqueness rule that prevents concurrent claims. A preflight lookup alone is not enough when two requests arrive together.

Inspect how the effect and result are committed, including the external-call uncertainty window. Ask what a retry receives while the first request is still running and after a response is lost.

Review which errors are stored and when a key becomes reusable. The contract should be explicit enough that callers know whether to retry the same key or create a genuinely new intention.

## Check scope and lifetime

Use the same key from a different account and verify no result leakage or unintended collision. Test retrieval after a permission change.

Inspect retention relative to offline and operator replay. A guarantee demonstrated only during the immediate request window may not cover the product's supported recovery behaviour.

The review should leave a precise definition of same request, conflicting request and expired request. Those definitions are more valuable than a broad claim that the endpoint is idempotent without explaining its boundaries.

## Sources

- [Stripe: idempotent requests](https://docs.stripe.com/api/idempotent_requests)
- [PostgreSQL: INSERT and conflict handling](https://www.postgresql.org/docs/17/sql-insert.html)