Every payment had an idempotency key. She was still charged twice.

transcript

Every payment in your design has an idempotency key. Retries are safe. Then a user tweets: you charged me twice for one electricity bill.

The interviewer asks how. The candidate starts with what the key covers. A retry of one attempt carries the same key. Same payment. But close the app, reopen it, and pay again? That's a fresh key. A new payment.

So, three suspects. One: two separate attempts, two keys. Two: AutoPay paid the bill, and so did she. Same day. Three: a real bug. Say, a UPI collect retried under a new reference.

The fix for suspect one: a second guard, on user and bill. Separate from the key. A payment for this bill that hasn't failed? The app asks: pay again? For suspect two, AutoPay checks for a confirmed or in-flight payment first.

So which was it? Pull both payments and their events. An AutoPay key is the mandate and the cycle. See one? AutoPay plus manual. Two different app keys? Two attempts.

And the refund? At once. Before the root cause is known. Two payments for one bill means one is a duplicate. She shouldn't wait for your debugging.

An idempotency key makes a retry safe. A second attempt needs its own guard.

Full breakdown in the lecture.