Razorpay-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Razorpay-style machine coding rounds interview for a specific engineer: one who treats money as an invariant, not a number. You get a payments-flavoured problem — a wallet, a transfer, a subscription charge, a webhook consumer — and a fixed window to hand back a service that runs and never loses or duplicates a rupee.
The domain makes idempotency and correctness the whole game. A retried charge must apply once, a webhook that arrives twice must book one payment, a transfer must be atomic or not happen at all. This page breaks down the commonly reported shape of Razorpay-style rounds, how they’re graded, and Gronex problems in the same style you can rehearse in a real repository.
What a Razorpay-style machine coding round looks like
The typical shape is around 90 minutes, solo. You get a payments-slice problem — an append-only wallet ledger, an account-to-account transfer, a subscription proration engine, an idempotent webhook consumer — with functional requirements and the failure modes spelled out. You produce a small, runnable service demoed at the end.
Working code is the entry ticket; correctness under retries and concurrency is the subject. Razorpay-style rounds probe "what if the request is retried", "what if two debits race the same balance", "what if the webhook is delivered twice or out of order" — money problems where the wrong answer is a real financial bug.
The follow-up adds a path — a refund against a partially captured payment, a second charge type, a reconciliation step. The round checks that your ledger and state machine absorb it while keeping the books provably balanced.
How you’re evaluated
A running demo
Requirements implemented and the money flow executable end to end without crashing while the interviewer drives it.
Idempotency & exactly-once
A retried charge or a redelivered webhook applies exactly once — the single most probed property in a payments round.
Ledger correctness
Append-only entries instead of mutated balances, so held plus settled plus refunded always reconciles to what was ever captured.
Concurrency safety
Racing debits, transfers, and webhook deliveries never oversend, double-book, or deadlock.
Common mistakes that fail this round
- Mutating a balance field instead of keeping an append-only ledger, so refunds and retries corrupt the books.
- Ignoring idempotency keys, so a retried charge or redelivered webhook books the payment twice.
- Treating the transfer as two independent updates instead of one atomic operation.
- Assuming webhooks arrive once and in order — they don’t, and the round tests exactly that.
- Reaching the demo with a design but no runnable, correct money flow.
Quick tips for the room
- Model money as an append-only ledger from the first line — never a mutable balance.
- Put an idempotency key on every money-moving operation before writing the logic.
- Make transfers atomic: both legs commit or neither does.
- Assume webhooks are duplicated and out of order, and dedupe by event id.
How to prepare
Practise the loop under a timer with money invariants front of mind: take a wallet or transfer problem, set 90 minutes, and drive it to a runnable demo where a retried request provably applies once. That single property is what a Razorpay-style round separates candidates on.
The Gronex problems below mirror the format from the other side — real backend repositories with failing tests over ledgers, transfers, and idempotent consumers, so you rehearse the exact correctness muscle the round grades. Start with the free API-contract problem, then take the wallet and transfer problems.
Practice problems in the Razorpay-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
An append-only wallet ledger: idempotent debits, refunds that survive partial captures, and balances that reconcile.
Open the challenge →Bank Account Transfer & Deadlock Prevention
Atomic account-to-account transfers with ordered locking so concurrent transfers never deadlock or lose money.
Open the challenge →Subscription Billing & Proration Engine
Upgrades, downgrades, and mid-cycle changes prorated correctly, with idempotent charge generation.
Open the challenge →Message Queue Consumer Idempotency & Retry
Process each event exactly once under duplicate and out-of-order delivery — the webhook-consumer core.
Open the challenge →API Validation & Error-Shape Debugging
Fix a payments-style API’s validation and error contract so every bad request fails predictably. Free to try.
Open the challenge →Notification Preference & Delivery
Preference-aware, idempotent delivery across channels without duplicate sends. Free to try.
Open the challenge →FAQ
Were these problems actually asked at Razorpay?
No. Every problem here is a Gronex original built in the same style — payment-grade invariants, idempotency, ledgers, and webhook handling with working-code grading. We never republish any company’s actual interview questions, and Gronex is not affiliated with Razorpay.
Why is idempotency the recurring theme?
Because in payments a duplicate is not a cosmetic bug — it is someone charged or paid twice. Retries and redelivered webhooks are normal operating conditions, so a payments round tests exactly-once behaviour first.
Which language should I practise in?
The one you’ll interview in. Gronex repositories run the same test suites in Java, Python, and C++, so the ledger and idempotency patterns transfer directly.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Razorpay. 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 Razorpay.