How would you design idempotent capture for a UPI or card payment API?
PICTURE THIS: A REST CALL
Simple meaning
The merchant sends a unique merchant transaction id
WHY — Idempotency instead of guessing?
Why interviewers care about Idempotency:
question about Idempotency.
trade-offs, and what you would actually do on a Backend project - not buzzwords.
Name the idea, why it exists, then one short example.
End with when you use it and one common pitfall.
STEPS — What happens step by step?
Before you speak the answer, walk the interviewer through these steps:
- 1The merchant sends a
unique merchant transaction id
- 2your payments table has
a unique constraint on it.
- 3A retry after a
timeout looks up that id and returns the original status instead of charging twice.
- 4Combine that with an
idempotency key on the HTTP layer and a state machine so CAPTURED cannot be captured again.
- 5Common mistake
What juniors usually get wrong.
- 6Close
When you pick this over the alternative.
EXAMPLE — See it in action
Here's a short line you can speak, broken into clear beats:
Note: Adapt this scaffold to your own project — keep it under 60–90 seconds.
Key takeaway
The merchant sends a unique merchant transaction id your payments table has a unique constraint on it.