A payment API supports idempotency keys. Duplicate charges still occur occasionally. The server implementation is correct. Where is the bug?

What the interviewer is testing

Whether you know the client-side failure that defeats a correct server implementation.

The bug

The client generates a new key on each retry.

An idempotency key must be generated once per logical operation and reused across every retry of that operation. If the client generates it inside the retry loop — or regenerates it when the HTTP call is constructed — each attempt carries a different key, and the server correctly treats them as distinct operations.

This is common, invisible in testing (where retries rarely occur), and only manifests during the network conditions that make retries necessary.

The related client-side variants

A new key on user-initiated retry: the user presses "pay" again after a timeout and the client treats it as a fresh operation. The key should be tied to the checkout session or the cart, not to the button press.

Key derived from a timestamp or random value at request construction rather than at operation creation.

Multiple client instances — a mobile app and a web session for the same order — generating independent keys.

The correct client design

Generate the key when the operation is created — when the user commits to paying — and persist it with the operation locally. Every attempt, including after an application restart, uses that key. Deriving it deterministically from a stable business identifier such as the order id is even more robust, because it survives losing local state.

The server-side details worth confirming anyway

Store the key with the result and return the stored response on a repeat, rather than merely rejecting the duplicate — the client needs the outcome. Persist the key and the effect atomically. Handle concurrent requests with the same key via a lock or unique constraint. Bind the key to the request payload, so a client reusing a key with different parameters gets an error rather than the wrong cached response.

What a strong answer adds

Retention: keys must be kept at least as long as a client might retry, commonly 24 hours or more, and a duplicate arriving after the window will be processed. That window should be stated in the API documentation rather than left as an implementation detail.

Common weak answers

Adding server-side deduplication on payload hash, which breaks legitimate identical payments. Concluding the server is wrong.