Transaction correctness, idempotency and reconciliation - payments loops punish hand-waving about consistency.
Payments interviews are consistency interviews. The recurring question is what happens when a request is retried, a callback arrives twice, or the client times out after the bank has already debited. Idempotency keys, exactly-once effects built on at-least-once delivery, and a reconciliation process that catches the cases those miss are the core of any good answer.
Expect scale to be framed around bursts rather than steady state - festival sales, salary day, a cricket final. Designs that work at average load and collapse at ten times it are the standard failure. Regulatory and audit constraints also come up: immutable ledgers, append-only records, and being able to explain where every paisa went.
45-60 min
Medium difficulty problem solving with complexity discussion.
60-90 min
Model a wallet, ledger or payment flow with correct state transitions.
60 min
Payment processing, idempotency, reconciliation and burst capacity.
45 min
Ownership of correctness-critical systems and incident handling.
Correctness under retry and partial failure. Be ready to explain idempotency keys, how you get exactly-once effects on top of at-least-once delivery, what your reconciliation job catches, and what the user sees while a transaction is in an unknown state.
Burst capacity more than steady state. Festival sales and salary-day peaks are an order of magnitude above baseline, so capacity planning, queue depth and graceful degradation are fair and common follow-ups.
It helps but is not required. What matters is demonstrating that you treat money as a correctness problem - immutable records, explicit state machines, and a reconciliation path - rather than as ordinary CRUD.
Practise the rounds Paytm actually runs, and get scored on where you stand.