Juspay-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Payment orchestration sits between a merchant and a dozen acquirers, gateways, and bank rails, and its whole job is to keep a single logical payment coherent while the systems underneath it time out, retry, and answer out of order. Machine coding rounds in the style of Juspay and other orchestration-layer companies borrow their scenarios directly from that seam.
What makes this round style distinctive is that the failure model is the specification. You are not asked to build a checkout; you are asked to build the thing that decides which downstream to try, what to do when it does not answer, and how to be sure a retry did not create a second charge. This page covers the commonly reported format, the evaluation lens, and Gronex repositories in the same style.
What a Juspay-style machine coding round looks like
Expect roughly 90–120 minutes to build a routing-and-reconciliation slice: a payment router that picks a gateway by rules (method, issuer, amount band, health), falls back on failure, and records an attempt trail; or a callback processor that consumes gateway notifications and drives a payment to a terminal state. The statement typically supplies the routing rules as a table and one sentence that carries all the weight — attempts must never double-charge the customer.
The attempt model is where candidates separate. A payment is not a row with a status; it is a parent intent with an ordered list of attempts, each with its own gateway reference and outcome. Designing it that way makes fallback, partial success, and late callbacks expressible. Designing it as a single mutable status field makes the "the first gateway answered success ten seconds after we failed it over" question unanswerable, and that question is reliably asked.
Routing rules themselves are graded as data, not code. The follow-up is almost always a new rule — prefer a specific acquirer for one issuer, stop routing to an unhealthy gateway, split traffic by percentage — so a chain of if-statements that encoded the initial table is the expensive answer. Interviewers also probe the health signal: how you would mark a gateway degraded without a full circuit-breaker implementation in the room.
How you’re evaluated
Attempt-level modelling
A payment intent that owns many attempts, each with its own reference and outcome, so fallback and late responses have somewhere to live.
No duplicate charge, ever
Retries and replayed callbacks converge on one debit. The reviewer builds the interleaving that would double-charge and runs it.
Routing rules as data
Selection driven by an evaluated rule set with explicit precedence and tie-breaks — extendable without touching the payment flow.
Terminal-state discipline
Once a payment is successful or reversed, nothing moves it. Pending is a real state with its own resolution path, not an error.
Common mistakes that fail this round
- Collapsing the payment into one row with one status, leaving no place to record the second attempt.
- Treating a gateway timeout as a definite failure and retrying elsewhere with no reconciliation for the original.
- Hard-coding the routing table into nested conditionals, so the added rule in the follow-up costs a rewrite.
- Letting a late success callback overwrite a payment that was already reversed.
- Keying idempotency on the gateway reference only, which does not exist yet at the moment you need to deduplicate the request.
Quick tips for the room
- Say "attempts" in your first sentence; it frames the whole design well.
- Give every mutation an idempotency key you generate before calling out.
- Make the gateway an interface with a fake in tests — never a real HTTP call.
- Answer "did it succeed?" with "unknown until reconciled", not yes or no.
How to prepare
Build the attempt model once by hand: intent, attempts, transitions, and a resolve step that can be run repeatedly against the same callback without changing the outcome. Then write out, in words, what your design does in the four awkward interleavings — timeout then success, success then duplicate callback, failure then late success, and a retry arriving before the first attempt resolved. Rounds in this style spend most of the discussion inside those four.
The repositories below drill the same mechanics against failing tests. The webhook problem is the callback processor with duplicates and reordering built in; the duplicate-side-effects problem (free) is the double-charge scenario in its purest form; the queue-consumer problem adds backoff and a dead-letter path; and the ledger problem covers the books that have to reconcile afterwards.
Practice problems in the Juspay-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.
Webhook Event Idempotency & Ordering
The gateway-callback problem: duplicate and out-of-order notifications that must not move a payment twice.
Open the challenge →Duplicate Charges After a Consumer Restart
The double-charge scenario isolated: at-least-once delivery meets a side effect that must happen once. Free to try.
Open the challenge →Queue Consumer Idempotency & Retry
Retry mechanics with teeth: idempotent effects, bounded backoff, and a dead-letter path for the poison record.
Open the challenge →Payment Ledger Consistency
The books behind the router: append-only entries that still reconcile after partial failure and replay.
Open the challenge →API Debugging: Idempotent POST
Make a POST honour its Idempotency-Key so a client retry returns the first outcome instead of charging again.
Open the challenge →FAQ
Were these problems asked at Juspay?
No. Every problem here is a Gronex original written in the style of payment-orchestration rounds — the kind of problem asked in rounds like Juspay’s. We never republish a company’s actual interview questions, and Gronex is not affiliated with Juspay.
Do I need to know gateway or UPI internals?
No. The statement always supplies the downstream behaviour you must handle. What the domain contributes is the standard: an unknown outcome is a state you model, not an error you log, and a retry must be provably free of second effects.
How much should I build versus discuss?
Build the single-threaded attempt model and make it demo-able, then discuss health signals, circuit breaking, and reconciliation jobs. Attempting a real circuit breaker inside the clock is a common way to arrive with nothing running.
What separates this from a general payments round?
A wallet round asks whether your balance arithmetic is safe. An orchestration round asks whether your system stays correct when the thing you delegated to stops answering — so fallback, attempt trails, and late-callback handling carry the weight.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Juspay. 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 Juspay.