PhonePe-Style Machine Coding Round: Format, Tips & Practice Problems
UPI payment companies run backends where a duplicate is not a cosmetic bug — it is someone charged twice — and where every transaction lives in a state machine (initiated, pending, success, failed, reversed) that retries, timeouts, and webhooks all mutate at once. Machine coding rounds in the style of PhonePe pull their scenarios from exactly this world.
The distinctive pressure in this round style is retry safety at every boundary: the client that resubmits a payment after a timeout, the bank webhook that arrives twice, the reconciliation job that replays a day of events. This page covers the commonly reported format of PhonePe-style rounds, the evaluation lens, and Gronex repository problems in the same style — wallets, transfers, queue consumers, and the idempotency drill itself.
What a PhonePe-style machine coding round looks like
Expect roughly 90–120 minutes to build a payments slice: a wallet with credits, debits, and refunds; a peer-to-peer transfer service; or a transaction processor consuming payment events. The spec states invariants as absolutes — a balance never goes negative, a transaction reaches exactly one terminal state, a replayed request produces no second effect — and the follow-up discussion probes each one with the exact sequence that would break it.
The signature scenario is the ambiguous timeout. A payment request times out: did it succeed? The client retries; the original then also completes. Rounds in this style want to see an idempotency-key design handle this natively — same key returns the first outcome, the state machine refuses a second terminal transition — rather than a dedupe hack bolted on afterwards. Transaction status handling (pending is a real state, not an error) gets similar attention.
Because payment backends are event-driven, the round often includes an asynchronous element: process a stream of transaction events where duplicates and out-of-order arrivals are guaranteed. Candidates who key effects by event identity and treat redelivery as normal pass; candidates who assume each event arrives once do not. Ledger-style records that can be reconciled against balances round out the expected vocabulary.
How you’re evaluated
Exactly-once money movement
Retried requests, duplicate webhooks, and replayed events produce exactly one debit, one credit, one effect. This is the round’s core question, asked five different ways.
Transaction state machines
Every transaction reaches exactly one terminal state through legal transitions — no success flipping to failed, no reversal of a pending payment, pending handled as a first-class state.
Ledger and reconciliation
Append-only records that explain every balance, so the books can be reconciled after any sequence of operations — including partial failures.
Failure honesty
A failed operation leaves no half-applied state, and errors are specific: insufficient balance, duplicate key, and illegal transition are three different answers.
Common mistakes that fail this round
- Treating a request timeout as a failure instead of an unknown outcome — the retry then double-pays.
- Deduplicating by amount-and-timestamp heuristics instead of an explicit idempotency key.
- Modelling transaction status as a free string mutated from anywhere, so illegal transitions slip through.
- Mutating a lone balance field with no transaction history — the first reconciliation question has no answer.
- Assuming events arrive once and in order, when the spec (and production) guarantees neither.
Quick tips for the room
- Design the idempotency-key flow before any endpoint; retrofit is surgery.
- Make transaction states an enum with one transition function — no direct writes.
- Keep money in integer paise and say so; float money ends interviews.
- When asked "what if it times out?", answer with states, not apologies.
How to prepare
Drill the wallet kata until the invariants are reflexes: append-only ledger, derived balances, idempotency keys on every mutation, integer minor units. Then rehearse the ambiguous-timeout conversation out loud — what your design does when a retry races the original — because rounds in this style reliably go there within the first twenty minutes of discussion.
The repositories below map the round end to end: the wallet and bank-transfer problems are the money core, the queue-consumer problem is the event-driven half with duplicates and retries built in, the idempotency debugging drill isolates the retried-POST scenario, and the retry-storm incident teaches the failure mode that retries create at scale. The loyalty problem (free) covers the cashback-and-rewards flavour with the same idempotent-event mechanics.
Practice problems in the PhonePe-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Wallet Transaction & Refund System
The payments core: ledger consistency, idempotent credits and debits, and cumulative refund caps.
Open the challenge →Bank Transfer & Deadlock Prevention
Peer-to-peer money movement under concurrency: atomic transfers and deadlock-free lock ordering.
Open the challenge →Queue Consumer Idempotency & Retry
The event-driven half of a payment backend: at-least-once delivery, idempotent effects, backoff, and a DLQ.
Open the challenge →API Contract Debugging: Idempotent POST
The ambiguous-timeout drill in isolation: make a POST honour its Idempotency-Key so replays return the same result.
Open the challenge →Incident Debugging: Retry Storm
What naive retries do at payment scale: diagnose and fix a self-inflicted traffic amplification with backoff.
Open the challenge →Loyalty Points and Tier Management
The cashback-and-rewards flavour: FIFO expiry, oldest-first redemption, idempotent earn events. Free to try.
Open the challenge →FAQ
Were these problems actually asked at PhonePe?
No. Every problem here is a Gronex original built in the same style — payment-grade invariants, idempotency, and state machines. We never republish any company’s actual interview questions, and Gronex is not affiliated with PhonePe.
How much of a PhonePe-style round is about idempotency?
More than any other single topic. Payments infrastructure is retried at every layer — clients, gateways, webhooks, reconciliation jobs — so the retried-request question appears in the spec, the code review, and the follow-up discussion. If you prepare one thing deeply, prepare this.
Do I need to know UPI internals for the round?
No. The scenarios are stated fully in the problem — wallets, transfers, transaction events. What the domain contributes is the grading standard: exact money accounting, one terminal state per transaction, and no effect applied twice, all of which the practice repositories above encode as tests.
How does this differ from a CRED-style round?
Both are fintech-strict, but the emphasis shifts: CRED-style rounds are reported to weight line-level code quality heavily, while PhonePe-style rounds lean into scale-flavoured correctness — event streams, duplicate webhooks, and reconciliation. The idempotency core is common to both.
Related
Gronex is not affiliated with, endorsed by, or sponsored by PhonePe. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from PhonePe.