---
title: Razorpay Backend Interview Questions (2026 Guide)
description: Real Razorpay backend engineer interview questions — idempotency, webhooks, ledgers, low-level design and system design rounds, with answers and a prep plan.
url: https://usegreenroom.app/blog/razorpay-backend-engineer-interview-questions
last_updated: 2026-07-27
---

← Back to blog

India · Razorpay

# Razorpay backend interview questions and process

July 27, 2026 · 11 min read

![Razorpay backend interview questions guide — cover from Greenroom, the AI mock interviewer](/assets/blog/razorpay-backend-engineer-interview-questions-hero.webp)

The candidate — call him Rohit — had a genuinely good system design answer. Load balancer, service, database, a queue for good measure. He drew it in six minutes flat. Then the interviewer asked the only question that matters at a payments company: "The bank charged the customer, then your server crashed before writing the row. What does the customer see?" Rohit said, "It would retry." The interviewer asked, "Retry what? You never wrote down that it happened."

That's the pivot every candidate meets in **Razorpay backend interview questions**. The DSA and low-level design rounds are standard product-company fare, but the moment money enters the diagram, the interview becomes about failure: partial failures, duplicate requests, lost acknowledgements, and who is out of pocket when a network call times out. I built Greenroom after freezing in an interview I'd prepared hard for, so this guide covers what Razorpay asks and how to reason through it out loud.

## The Razorpay backend engineer interview process in 2026

Razorpay runs a fairly consistent backend loop, with system design weighted heavier as you go up levels. What candidates report as the **Razorpay backend interview process**:

- **Online assessment** — timed DSA problems. Clean, compiling code matters more than a clever one-liner.
- **DSA / coding round** — medium-difficulty problems with a strong preference for readable solutions and stated complexity.
- **Low-level design round** — model a system in classes: entities, states, transitions, concurrency. This round is emphasised more at Razorpay than at most Indian product companies.
- **System design round** — the payment gateway itself, or a piece of it. Idempotency, webhooks, ledgers, reconciliation.
- **Hiring manager + culture** — an outage you owned, a tradeoff you regret, how you handle being on call.

The thread running through all of it: correctness under failure beats throughput. A design that handles a million requests per second but can double-charge one customer is a no-hire. Say that sentence back to yourself before every round.

![Razorpay backend engineer interview process diagram — online assessment, DSA round, low-level design round, system design round, hiring manager and culture round](/assets/blog/razorpay-backend-engineer-interview-questions-diagram.webp)

The Razorpay backend loop: five rounds, with low-level design carrying unusually heavy weight compared to peer companies.

## Idempotency: the question behind every other question

If you take one thing from this guide, take this. **Idempotency** is the most-asked concept in Razorpay backend interviews, and it shows up disguised as a dozen different questions: "what if the client retries," "what if the network times out," "what if two requests arrive at once," "what if our webhook is delivered twice."

The answer shape interviewers want: the *client* supplies a key, the *server* makes the key unique in the database, and the uniqueness constraint — not the application logic — is what enforces correctness.

```sql
CREATE TABLE payment_attempts (
  idempotency_key  VARCHAR(64) PRIMARY KEY,
  merchant_id      BIGINT      NOT NULL,
  amount_paise     BIGINT      NOT NULL,
  status           VARCHAR(16) NOT NULL,  -- created | authorized | captured | failed
  response_body    JSONB,
  created_at       TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```

Then the flow, which you should narrate in this order: insert the key first and let a duplicate insert fail; on conflict, return the stored response rather than re-executing; only then call the bank. Doing the bank call first and the insert second is the mistake that ends the round.

```python
def create_payment(key, merchant_id, amount_paise):
    try:
        db.execute(INSERT_ATTEMPT, key, merchant_id, amount_paise, "created")
    except UniqueViolation:
        prior = db.fetch_one(SELECT_ATTEMPT, key)
        return prior["response_body"]      # same request, same answer

    result = bank.authorize(key, amount_paise)   # key forwarded downstream
    db.execute(UPDATE_ATTEMPT, key, result.status, result.body)
    return result.body
```

Two follow-ups will come, so pre-empt them. How long do you keep keys? (Long enough to cover client retry windows — usually 24 hours or more — then archive.) What if you crash *between* the bank call and the update? (You don't know the outcome, so the row stays in `created`, and a reconciliation job later queries the bank for the real status. This is why the status column has more than two values.) Our [system design interview guide](/blog/system-design-interview-guide-india) covers the general vocabulary.

## Webhooks, retries and at-least-once delivery

Razorpay's product is partly webhooks, so expect a round or a large chunk of one on them — from both sides.

**As the sender:** you must deliver at least once, which means you will sometimes deliver twice. Design for it: an exponential backoff schedule, a dead-letter queue after N attempts, a delivery-attempts table so support can answer "did you send it," and a signature header so merchants can verify authenticity. Be honest that exactly-once delivery across a network is not achievable — the achievable goal is at-least-once delivery plus idempotent consumption.

**As the receiver:** verify the signature before parsing anything, respond `200` fast and process asynchronously, and dedupe on the event ID. Say out loud that a slow consumer causes sender retries, which causes duplicate events — the failure mode is a loop, not a single bad request.

- **Ordering** — events can arrive out of order. A `payment.captured` may land before `payment.authorized`. Handle by event timestamp and a state machine that ignores backwards transitions, not by assuming order.
- **Poison events** — one merchant's endpoint returning 500 forever must not block every other merchant's queue. Partition per merchant.
- **Replay** — merchants will ask you to resend a week of events. Design for it up front.

Our [REST API interview questions guide](/blog/rest-api-interview-questions) and [Kafka interview questions guide](/blog/kafka-interview-questions) cover the delivery-semantics layer in depth.

## Ledgers, consistency and the low-level design round

The **Razorpay low-level design round** typically asks you to model a payments primitive in classes: a wallet, a refund flow, a settlement, a split payment. What's being scored is whether your model can't represent an invalid state.

Key things to bring up unprompted:

- **Double-entry** — every movement is two entries that sum to zero. It sounds like accounting trivia; it's actually the cheapest possible invariant check, and mentioning it marks you as someone who has thought about money systems.
- **Money as integers** — store paise as `BIGINT`, never floats. If you write `float` on the board, expect to be stopped.
- **State machines** — `created → authorized → captured → refunded`, with explicit terminal states and no backwards edges. Enumerate the transitions rather than scattering `if` checks.
- **Concurrency** — two refunds for the same payment arriving simultaneously. Row-level locking (`SELECT ... FOR UPDATE`), optimistic locking with a version column, or a uniqueness constraint on the refund's idempotency key. Name which one you'd choose and why.
- **Immutability** — ledger entries are append-only. A correction is a new compensating entry, not an `UPDATE`. Auditors, and interviewers, care about this.

The [Razorpay backend engineer prep page](/prep/razorpay-backend-engineer-interview) has a compact round-by-round checklist, and our [DBMS interview questions guide](/blog/dbms-interview-questions) covers isolation levels — worth knowing, because "what isolation level, and what anomaly does that still allow?" is a very Razorpay follow-up.

## System design: designing the gateway itself

The senior design round is usually a version of "design Razorpay." Structure your answer in this order, and you'll cover what they're grading:

- **Requirements and scale first** — payments per second, latency budget, and the non-negotiable: no double charges, no lost money. Ask before drawing.
- **The core flow** — merchant server creates an order, client checkout collects the instrument, your gateway authorizes with the bank/PSP, then captures. Note where the money actually moves versus where a record is written.
- **The failure story** — timeouts to the bank, unknown outcomes, and the reconciliation job that resolves them. This is the part that distinguishes candidates.
- **Async everywhere** — queues for webhooks, settlements and notifications; synchronous only where the user is waiting.
- **Settlement and reconciliation** — end-of-day files from banks compared against your ledger, with a mismatch report. Say that mismatches are normal and the system exists to surface them, not to prevent them.
- **Multi-PSP routing** — routing traffic across acquiring banks by success rate and cost, with failover when one is degraded.

Answer with constraints first, then design, then failure modes. Drawing boxes before asking about consistency requirements is the single most common way to underperform here.

## Behavioral rounds: outages, ownership, and "why payments"

Razorpay's hiring-manager round leans on ownership, and the most reliable question is some version of "tell me about an incident you caused." They are not looking for a spotless record; they are looking for someone who noticed, told people quickly, fixed the cause rather than the symptom, and changed something afterwards.

Two-minute stories, first person, real numbers. "We had a bug" is invisible; "my migration locked the payments table for 90 seconds during peak, I rolled it back in four minutes, and we added a pre-merge check for lock-taking DDL" is a hire signal. Expect "why payments" too — the answer that lands connects to correctness being checkable, not to fintech being fashionable. Our [tell me about a time you failed](/blog/tell-me-about-a-time-you-failed) guide has the structure.

## LeetCode, Grokking, engineering blogs — where each fits

An honest map of the prep stack for this specific loop:

- **LeetCode** — necessary for the OA and DSA round; medium difficulty is the right target. It teaches you nothing about idempotency, which is most of the actual interview.
- **Grokking the System Design Interview and Designing Data-Intensive Applications** — the latter is genuinely the best preparation for the failure-mode questions in this loop. The chapters on consistency and on delivery guarantees map almost one-to-one onto Razorpay's follow-ups.
- **The Razorpay Engineering blog and public API docs** — read the payments and webhooks documentation as a candidate, not a developer. The docs describe the exact object lifecycle they'll ask you to design.
- **GeeksforGeeks and Blind interview experiences** — useful for calibrating round format and difficulty. Anecdotes, not a syllabus.
- **ChatGPT** — solid for generating LLD prompts and critiquing a written design. It won't ask "so what does the customer see?" at the exact moment your design has no answer.
- **Greenroom** — the spoken layer. [Ari, the AI interviewer](/), runs the round out loud, pushes the failure-mode follow-up when your design hand-waves, and scores structure and clarity. Fair tradeoff: Ari won't review your Java line by line; pair it with DDIA.

**The core truth:** Razorpay hires backend engineers who assume things will fail and design accordingly. Question banks prepare your first answer; only spoken practice prepares the third "and then what?" — which is where every payments round ends up.

## How to prepare for the Razorpay backend interview

- **Week 1:** DSA daily at medium difficulty, always stating complexity aloud. Clean code over clever code.
- **Week 2:** low-level design — model a wallet, a refund flow and a split payment in classes. Draw the state machine first, then write the classes, then explain both aloud.
- **Week 3:** the payments concept set — idempotency keys, at-least-once delivery, double-entry ledgers, isolation levels, optimistic vs pessimistic locking. Explain each in ninety seconds without notes.
- **Final week:** design "Razorpay" aloud twice, five behavioral stories in first person, two full spoken mocks with failure-mode pushback, and the [role-specific prep page](/prep/razorpay-backend-engineer-interview) the night before — not new material.

Interviewing across Razorpay's other tracks, or at similar Indian fintechs? The [Razorpay frontend engineer guide](/blog/razorpay-frontend-engineer-interview-questions) covers the machine coding round, the [Razorpay data engineer guide](/blog/razorpay-data-engineer-interview-questions) covers settlement and reconciliation pipelines, the [general Razorpay interview questions guide](/blog/razorpay-interview-questions) covers the company-wide loop, and the [PhonePe](/blog/phonepe-interview-questions) and [Paytm](/blog/paytm-interview-questions) guides cover the nearest comparable bars.

## Frequently asked questions

### What is the Razorpay backend engineer interview process?

Candidates consistently report an online assessment with timed DSA problems, a DSA and coding round, a low-level design round modelling a system in classes, a system design round on the payment gateway itself, and a hiring-manager plus culture round. Low-level design carries more weight at Razorpay than at most Indian product companies, and system design is weighted heavier at senior levels.

### What is idempotency and why does Razorpay ask about it?

Idempotency means the same request executed twice produces the same result as executing it once — critical when a client retries a payment after a timeout. Razorpay asks because duplicate charges are the most expensive possible bug at a payments company. The expected answer is a client-supplied idempotency key stored under a database uniqueness constraint, with the stored response returned on conflict.

### What system design questions does Razorpay ask?

The recurring prompt is designing the payment gateway or a component of it: order creation and capture, webhook delivery with retries, refunds, settlement and reconciliation, and multi-PSP routing across acquiring banks. Interviewers push hardest on failure modes — what happens when the bank call times out and you never learn the outcome.

### How do you answer webhook questions in a Razorpay interview?

Cover both sides. As sender: at-least-once delivery with exponential backoff, a dead-letter queue, a signed payload, per-merchant partitioning so one broken endpoint cannot block others, and a replay mechanism. As receiver: verify the signature first, return 200 quickly and process asynchronously, and deduplicate on event ID because duplicates are guaranteed, not exceptional.

### Is the Razorpay backend interview hard?

It is a high bar with an unusual emphasis. The DSA round sits at medium difficulty rather than hard, so pure algorithm strength is not the filter. The difficulty is domain depth — you are expected to reason fluently about partial failure, duplicate requests, ledger consistency and concurrency, and to do it out loud while an interviewer probes each answer.

### How many rounds is the Razorpay backend interview and how long does it take?

Most reported loops run four to six rounds — online assessment, DSA, low-level design, system design for mid and senior levels, and a hiring-manager round — over roughly two to five weeks. The gaps between rounds are usually scheduling rather than deliberation; use them to practise designing under spoken pushback.

Razorpay's loop is a failure-mode conversation, not a quiz. [Greenroom](https://usegreenroom.app/) runs mock backend interviews out loud with Ari — idempotency and design pushback included — and scores structure, clarity and depth. Free to start. Curious how it works? See [how AI mock interviews work](/blog/ai-mock-interview).