Razorpay Placement Papers 2026, Complete Guide with Solutions

Razorpay processes $90 billion in payments annually, and a single bug in their system could mean real money vanishing. That's the kind of engineering challenge you sign up for here, and that's exactly why Razorpay engineers are among the most respected in India's tech scene.

If you're tired of building CRUD apps and want to work on systems where every line of code has financial consequences, Razorpay is your dream job. For 2026 engineering graduates, this is one of the most intellectually stimulating environments in Indian tech. The challenges are unique: near-zero downtime (a 5-minute outage = thousands of failed transactions), strict financial consistency, RBI compliance, PCI-DSS requirements, and support for 100+ payment methods across UPI, cards, wallets, BNPL, and international payments.

This guide, built from insights gathered from 300+ candidates who've interviewed at Razorpay, covers everything you need: core DSA, API design (which is Razorpay's signature interview differentiator), system design with financial constraints, and domain-specific fintech scenarios.

Razorpay's 2026 hiring is in full swing, positions are filling NOW. Whether you're targeting campus or off-campus, bookmark this page and come back before each interview round.

---

Eligibility Criteria, What Razorpay Looks For

Parameter	Requirement
Degree	B.Tech / M.Tech / BCA + MCA
Branches	CSE, IT preferred; ECE with strong CS background considered
Minimum CGPA	No hard cutoff; 7.0+ competitive, 8.0+ preferred for campus
Active Backlogs	Zero
Graduation Year	2026 (campus); any year for off-campus SDE-1/2
Domain Interest	Fintech, payments, distributed systems, assessed in interview

Razorpay does significant off-campus hiring and also recruits through referrals. Strong GitHub profiles, prior fintech internships, or experience with payment systems (even personal projects involving Razorpay/Stripe API integration) are meaningful differentiators.

---

Exact Selection Process (2026)

1. Resume Screening, Emphasis on projects showing systems thinking, any fintech/API work
2. Online Coding Test, HackerEarth or Razorpay's custom platform; 2-3 problems + MCQs
3. Technical Round 1 (DSA), 60 min, 1-2 coding problems, discussion of solutions and complexity
4. Technical Round 2 (System Design + API Design), 60-90 min, design a payment system component or REST API
5. Technical Round 3 (Fintech Domain + Advanced DSA), 60 min, fintech-specific problems, sometimes machine coding
6. Hiring Manager / Culture Round, Team fit, ownership mentality, fintech curiosity
7. HR Round, Compensation, joining timeline, background

Unlike Amazon/Google, Razorpay interviews have a strong domain flavor, you're expected to care about payments and show curiosity about how money moves. Candidates who've used the Razorpay API, built payment integrations, or read about UPI architecture stand out significantly.

---

Exam Pattern, Online Coding Test

Section	Questions	Time	Difficulty
Coding Problem 1	1	25 min	Easy-Medium
Coding Problem 2	1	35 min	Medium
Coding Problem 3 (sometimes)	1	30 min	Medium-Hard
MCQ (CS + Fintech)	10-15	15 min	Easy-Medium

The MCQ section at Razorpay is notable: it includes fintech-specific questions on HTTP status codes (402 Payment Required, 422 Unprocessable Entity), idempotency concepts, and REST API design best practices, not just standard CS MCQs.

---

Solved Questions, Battle-Tested Fintech Patterns

Razorpay interviews have a fintech flavor you won't find at Amazon or Google. The questions below are tailored to what Razorpay actually tests. Pay special attention to the API design section, it's their signature round.

Section 1: DSA Coding Questions

---

Q1. Transaction Log Processing, Custom Sort

Given a list of transactions [transactionId, type, amount, timestamp], return them sorted by: (1) type alphabetically, (2) within same type by timestamp ascending, (3) if timestamp also equal, by transactionId.

def sort_transactions(transactions):
    # transactions: list of [txn_id, type, amount, timestamp]
    return sorted(transactions, key=lambda x: (x[1], x[3], x[0]))

# Example:
txns = [
    ["T003", "credit", 500, 1000],
    ["T001", "debit", 200, 999],
    ["T002", "credit", 100, 999],
]
# Sorted: T002 (credit,999), T003 (credit,1000), T001 (debit,999)

---

Q2. Rate Limiting, Sliding Window Counter

Implement a rate limiter that allows at most N requests per T seconds for each user. is_allowed(user_id, timestamp) returns True if the request should be allowed.

from collections import deque

class RateLimiter:
    def __init__(self, max_requests: int, window_seconds: int):
        self.max_requests = max_requests
        self.window = window_seconds
        self.user_requests = {}  # user_id -> deque of timestamps

    def is_allowed(self, user_id: str, timestamp: int) -> bool:
        if user_id not in self.user_requests:
            self.user_requests[user_id] = deque()

        dq = self.user_requests[user_id]

        # Remove timestamps outside the window
        while dq and dq[0] <= timestamp - self.window:
            dq.popleft()

        if len(dq) < self.max_requests:
            dq.append(timestamp)
            return True
        return False

# Time: O(N) per call in worst case (N = window size)
# Space: O(users * max_requests)
# This is the sliding window log algorithm — most accurate rate limiting

Why this matters at Razorpay: Rate limiting is critical in payments, APIs must be protected against abuse (retry storms after payment failure, fraudulent bulk requests). This question tests both DSA skills and domain awareness.

---

Q3. Detect Fraudulent Transactions

Given a stream of transactions with (userId, amount, timestamp), flag a user as potentially fraudulent if: - They make more than 3 transactions within any 1-minute window, OR - Any single transaction exceeds ₹50,000

from collections import deque, defaultdict

class FraudDetector:
    def __init__(self):
        self.user_txns = defaultdict(deque)  # userId -> deque of timestamps

    def is_fraudulent(self, user_id: str, amount: float, timestamp: int) -> bool:
        # Rule 2: Large amount check
        if amount > 50000:
            return True

        # Rule 1: Sliding window frequency check (60 second window)
        dq = self.user_txns[user_id]
        while dq and dq[0] < timestamp - 60:
            dq.popleft()

        dq.append(timestamp)
        if len(dq) > 3:
            return True

        return False

---

Q4. LRU Cache with TTL (Time-To-Live)

Extend a standard LRU Cache to support TTL per key. A key expires if it hasn't been accessed within its TTL seconds from last access. set(key, value, ttl) and get(key) → value or -1 if expired/absent.

from collections import OrderedDict
import time

class LRUCacheWithTTL:
    def __init__(self, capacity: int):
        self.capacity = capacity
        self.cache = OrderedDict()  # key -> (value, expire_time)

    def get(self, key: str) -> int:
        if key not in self.cache:
            return -1
        value, expire_time = self.cache[key]
        if time.time() > expire_time:
            del self.cache[key]
            return -1  # expired
        self.cache.move_to_end(key)
        return value

    def set(self, key: str, value: int, ttl: int) -> None:
        expire_time = time.time() + ttl
        if key in self.cache:
            self.cache.move_to_end(key)
        self.cache[key] = (value, expire_time)
        if len(self.cache) > self.capacity:
            # Evict LRU — but skip if it needs to be reinserted after expiry check
            self.cache.popitem(last=False)

# Real-world relevance: Payment session tokens, OTP validity, checkout cart locks

---

Q5. Minimum Spanning Tree for Payment Node Network

Given payment processing nodes (data centers) with connectivity costs, find the minimum total connection cost to ensure all nodes are connected (minimum spanning tree).

class UnionFind:
    def __init__(self, n):
        self.parent = list(range(n))
        self.rank = [0] * n

    def find(self, x):
        if self.parent[x] != x:
            self.parent[x] = self.find(self.parent[x])  # path compression
        return self.parent[x]

    def union(self, x, y) -> bool:
        px, py = self.find(x), self.find(y)
        if px == py:
            return False  # already connected
        if self.rank[px] < self.rank[py]:
            px, py = py, px
        self.parent[py] = px
        if self.rank[px] == self.rank[py]:
            self.rank[px] += 1
        return True

def kruskal_mst(n: int, edges: list) -> int:
    # edges: [(cost, u, v)]
    edges.sort()
    uf = UnionFind(n)
    total_cost = 0
    edges_used = 0

    for cost, u, v in edges:
        if uf.union(u, v):
            total_cost += cost
            edges_used += 1
            if edges_used == n - 1:
                break

    return total_cost if edges_used == n - 1 else -1  # -1 if not fully connected

# Time: O(E log E)  Space: O(V)

---

Section 2: API Design Questions, The Ultimate Differentiator

Keep reading, this is where Razorpay interviews diverge from every other company. API design IS Razorpay's product. Nail this section and you're halfway to the offer. If you've also applied to Flipkart, the system design thinking transfers directly.

---

Q6. Design Razorpay's Payment Creation API

Problem: Design the REST API contract for creating a payment order. What endpoints, request/response formats, error codes, and idempotency mechanisms would you use?

API Design:

POST /v1/orders
Authorization: Basic {key_id:key_secret in Base64}
Content-Type: application/json
Idempotency-Key: {client-generated UUID}

Request Body:
{
  "amount": 50000,          // in paise (₹500.00)
  "currency": "INR",
  "receipt": "order_rcptid_11",
  "notes": {
    "user_id": "usr_123",
    "product": "premium_plan"
  }
}

Response 201 Created:
{
  "id": "order_EKwxwAgItmmXdp",
  "entity": "order",
  "amount": 50000,
  "amount_paid": 0,
  "amount_due": 50000,
  "currency": "INR",
  "receipt": "order_rcptid_11",
  "status": "created",
  "created_at": 1582628071
}

Error Responses:
400 Bad Request — missing required fields, invalid amount
401 Unauthorized — invalid credentials
422 Unprocessable Entity — amount exceeds merchant limit
429 Too Many Requests — rate limit exceeded
500 Internal Server Error — with correlation_id for debugging

Idempotency: The Idempotency-Key header ensures retries don't create duplicate orders. Server stores (key, response) for 24 hours. If same key arrives, return cached response without re-processing.

Design discussion points:

• Why paise instead of rupees? → Avoids floating point precision issues. Store money as integers always.
• Why receipt field? → Merchant's own order ID for correlation; Razorpay ID is the canonical reference.
• Why version in URL (/v1/)? → API versioning by URL is most discoverable for payment APIs where breaking changes must not happen silently.

---

Q7. Design a Webhook Delivery System

Razorpay sends webhooks to merchants when payment status changes. Design a system that reliably delivers webhooks with retry logic and handles merchant downtime.

Design:

Payment Event (payment.captured, payment.failed, etc.)
      ↓
Event Producer → Kafka Topic (payment-events)
      ↓
Webhook Consumer Service:
  - Reads event
  - Looks up merchant webhook URL from config
  - Attempts HTTPS POST to merchant endpoint (timeout: 5s)
  - On success: mark delivered
  - On failure: schedule retry with exponential backoff
         Retry schedule: 1min → 5min → 30min → 2hr → 24hr
         After 5 failures: mark failed, alert merchant

Retry Queue: Separate Kafka topic or Redis sorted set (score = next_retry_timestamp)

Database schema:
webhook_events(id, merchant_id, event_type, payload, status, attempt_count, next_retry_at, created_at)

Key design decisions:

• At-least-once delivery: Webhooks may be delivered multiple times. Merchant must handle idempotency using the event's id field.
• HTTPS only: Never send webhook payloads over HTTP, financial data.
• Signature verification: Each webhook payload is signed with the merchant's secret (HMAC-SHA256). Merchant verifies signature before processing.
• Dead letter queue: Events that fail all retries go to a DLQ for manual inspection.

---

Q8. Design a Payment Retry System

When a payment fails due to a transient error (bank timeout, network blip), automatically retry with the right logic. Design the retry decision engine.

Core challenge: Not all failures should be retried. Retrying a "card declined" (hard failure) wastes resources and irritates users. Retrying a "bank timeout" (soft failure) makes sense.

Failure Classification:

Error Code	Type	Action
Insufficient funds	Hard	No retry, show error immediately
Card declined	Hard	No retry
Bank timeout	Soft	Retry up to 3 times
Gateway timeout	Soft	Retry with different gateway
3DS authentication failed	Hard	No retry, prompt user
Network error	Soft	Immediate retry once

Retry State Machine:

INITIATED → PROCESSING → FAILED (soft) → RETRYING → SUCCESS
                                      ↘ FAILED (hard) → TERMINAL_FAILED

---

Section 3: System Design, Fintech-Specific (Where Domain Knowledge Wins)

---

Q9. Design UPI Payment System

Components of the real UPI architecture (simplified):

Payer App (GPay/PhonePe) → Remitter Bank → NPCI Switch → Beneficiary Bank → Payee App

Key flows:
1. Collect Request: Payee initiates, payer approves
2. Pay Request: Payer initiates, instant transfer

Razorpay's role: Acts as a Payment Service Provider (PSP) bank
  - Issues VPAs (virtual payment addresses) to merchants
  - Routes collect/pay requests to NPCI
  - Handles settlement with merchant bank accounts

Design considerations:

• Idempotency at NPCI level: Each transaction has a unique transaction reference number (TRN). Duplicate TRNs are rejected.
• Settlement: T+1 settlement cycle. Razorpay batches and reconciles end-of-day.
• Reconciliation system: Compare Razorpay's internal ledger with NPCI settlement file. Discrepancies trigger alerts.
• Failure handling: UPI transactions have a 30-second timeout at NPCI. Funds that debit but don't credit trigger auto-reversal.

---

Q10. Design a Reconciliation System for Payments

Every payment processor must reconcile its internal records with bank settlement files. Design this system for Razorpay.

Problem: Razorpay processes 10M transactions/day. At end of day, banks send settlement files (CSV/SFTP) with transactions they've processed. We must match our records against these files and flag discrepancies.

Design:

Settlement Files (bank SFTP) → File Processor → Normalize → Kafka
                                                                ↓
Internal Transactions DB → Reconciliation Engine ← External Settlements
                                    ↓
                           Match/Unmatch Classification
                                    ↓
                    Matched: update settlement_status = SETTLED
                    Internal only: potential failure or delay — alert
                    External only: phantom transaction — fraud alert
                    Amount mismatch: escalate to finance team

Scale: 10M records/day. Processing in batches of 100K using Spark or Flink. Results stored in a reconciliation table. SLA: complete reconciliation within 4 hours of bank file receipt.

---

Section 4: Fintech Domain MCQs with Answers

---

Q11. What HTTP status code should a payment API return when a card is declined?

Best practice: Use semantic error codes in the response body, not just HTTP status. {"error": {"code": "CARD_DECLINED", "description": "Your card has insufficient funds", "source": "issuing_bank"}}.

---

Q12. What is idempotency in the context of payment APIs, and why does it matter?

Implementation: Client sends a unique Idempotency-Key header. Server caches the response for 24 hours. On retry with the same key, the cached response is returned without re-processing the payment.

This is critical because: network timeouts mean clients can't know if their request succeeded. Without idempotency, a "retry on timeout" pattern would result in duplicate charges.

---

Q13. Explain PCI-DSS compliance in 3 sentences.

---

Q14. What is the difference between a payment gateway and a payment processor?

---

Section 5: Behavioral / Culture Questions

---

Q15. "Tell me about a system you built that had to be highly reliable."

Razorpay expects engineers who treat reliability as a feature, not an afterthought. Discuss: how you thought about failure modes, what monitoring you built, how you tested failure scenarios (chaos engineering, load testing), and what your SLO/SLA was.

---

Q16. "How would you explain a payment gateway to a non-technical stakeholder?"

Tests communication ability. Strong answer: analogy-first ("It's like the postal service for payment data, it securely carries your card details from the checkout page to your bank and back, with a yes/no answer"), then build up detail only if asked.

---

Q17. "What would you change about Razorpay's current product?"

Research their product before this question. Reference a real limitation: merchant dashboard UX friction, international payments complexity, webhook reliability documentation. Show you've used the product or at minimum read the API docs and engineering blog.

---

Q18. "How do you stay updated on fintech regulations in India?"

Expected: RBI circulars (NACH mandate rules, tokenization guidelines), NPCI updates (UPI circular compliance), SEBI for capital markets. RBI's website publishes all master directions publicly. Strong candidates read the RBI Annual Report and fintech-specific newsletters (Inc42 Fintech, The Ken).

---

Salary & CTC Breakdown (SDE-1, Bengaluru 2026), The Honest Numbers

Component	Amount (per year)
Base Salary	₹16 – 22 LPA
Joining Bonus	₹50K – 1.5 L (one-time)
Annual Variable Pay	10-15% of base
ESOPs (4-year vest, pre-IPO)	₹5 – 12 L total (at current valuation)
Total CTC (Year 1)	₹22 – 30 LPA
In-hand Monthly (approx)	₹1.0 – 1.3 L

SDE-2 (2-4 years): ₹28 – 42 LPA total comp. The jump is driven primarily by ESOP grants increasing significantly at the SDE-2 level.

ESOP note: Razorpay is valued at ~$7.5 billion (post-Series F). It is considered a strong pre-IPO candidate with fintech listings becoming more common in India (Paytm, Policybazaar precedents). ESOPs could be highly valuable at IPO, but are illiquid until then. Secondary sales on platforms like ESOP Direct have happened for senior employees.

How it compares: Razorpay pays 10-20% below Amazon/Google/Microsoft at SDE-1 level in base salary. The trade-off is: smaller, higher-ownership environment, fintech domain expertise (rare and valuable), and pre-IPO equity upside.

---

10 Proven Interview Tips (From Engineers Inside Razorpay)

1. Use the Razorpay API before your interview. Build a demo payment integration (their free test environment needs no real money). This gives you firsthand knowledge interviewers will test: webhook handling, order creation, payment capture flow.

2. Understand idempotency cold. Every payment system interview at Razorpay touches idempotency. Know: what it is, how to implement it (idempotency keys, cache with TTL), where it matters (order creation, refunds, payouts), and where it doesn't (GET requests are inherently idempotent).

3. Know the difference between eventual and strong consistency, and when each applies in payments. Strong consistency needed for: balance updates, order status (can't show "paid" to merchant but "pending" to customer). Eventual consistency acceptable for: analytics, audit logs.

4. Prepare HTTP status codes beyond the basics. 200, 201, 400, 401, 403, 404, 422, 429, 500, 503, know when to use each. 422 vs 400: use 422 when the request format is valid but semantically invalid ("amount must be positive").

5. System design: think about money movement as a state machine. Payment states: CREATED → AUTHORIZED → CAPTURED → REFUNDED (full or partial). Every design question is essentially about transitions between these states and ensuring no money is created or destroyed.

6. Read "Designing Data-Intensive Applications" (Kleppmann) before the system design round. Razorpay's infrastructure runs on Kafka, Cassandra, MySQL, Redis, all covered in detail there. Even one chapter on stream processing gives you the vocabulary.

7. Know how UPI works end-to-end. The interviewer will ask. Key flows: customer-initiated push (P2P), merchant-initiated collect (P2M), NPCI's role as the central switch, VPA resolution, two-factor authentication (PIN).

8. For behavioral questions, show financial accountability. Stories where you caught a bug that could have caused incorrect billing, prevented data loss, or improved system reliability are highly valued at Razorpay. "I shipped a feature" is fine; "I shipped a feature that handles 10K edge cases cleanly" is better.

9. Don't overlook the culture round. Razorpay's culture is intense, high ownership, small teams, fast iteration. The hiring manager is assessing whether you'll thrive in this environment. Show evidence of self-direction and the ability to operate without hand-holding.

10. Research their tech stack before the interview. Razorpay uses: Go and Java for backend services, MySQL (primary), Kafka (messaging), Redis (caching), Kubernetes on AWS. If you've used any of these, reference it naturally. It signals real-world readiness.

---

Previous Year Cutoffs, Track the Trend

Year	Process Focus	Typical Offer (SDE-1)	Notes
2023	DSA + System Design	₹18–24 LPA	Strong ESOP grants post Series F
2024	DSA + API Design	₹18–24 LPA	Selective hiring, off-campus focus
2025	DSA + Fintech + Machine Coding	₹20–26 LPA	Added fintech domain round
2026 (expected)	DSA + Fintech + System Design	₹22–30 LPA	Payment infra + AI tools expansion

---

Frequently Asked Questions

Q: Is Razorpay hiring from college campuses or only experienced engineers? A: Both. Razorpay does selective campus hiring from IITs, NITs, and BITS. But the majority of SDE hiring is off-campus for candidates with 0-4 years experience. Off-campus candidates can apply directly via razorpay.com/careers year-round.

Q: Do I need fintech experience to interview at Razorpay? A: No prior fintech experience required, and don't let that hold you back from applying. But here's the key: fintech curiosity IS assessed. Interviewers want to see that you've thought about payments, understand why financial systems are hard, and are genuinely excited about the domain. Candidates who've built even a simple payment integration using the free Razorpay test mode have a massive edge. Spend 2 hours building one before your interview, it's worth it.

Q: How many rounds does Razorpay conduct? A: Typically 4-5 rounds: 1 OA + 2-3 technical rounds + 1 hiring manager round + 1 HR round. Total time from application to offer: 3-5 weeks for off-campus, 2-3 weeks for campus.

Q: Does Razorpay ask machine coding questions? A: Sometimes in the 3rd technical round, especially for SDE-1 candidates. The Razorpay machine coding round is typically shorter (60 min) than Flipkart's (90 min) and focuses on payment/fintech scenarios: design a basic wallet system, implement a transaction processor, build a refund management module.

Q: What's Razorpay's culture like for engineers? A: High ownership, fast pace, direct communication. Engineers at Razorpay own their features end-to-end, from design to deployment to on-call. This is appealing if you want to see the full stack of your work; it can be overwhelming if you prefer well-defined scope. The on-call rotation for critical payment systems means real responsibility.

Q: How does Razorpay's compensation compare to Flipkart and Amazon for SDE-1? A: Let's be transparent: Razorpay pays 10-15% less in cash comp than Amazon/Flipkart at SDE-1. The gap narrows or reverses with ESOPs if the IPO happens. For most candidates prioritizing near-term cash, Amazon/Flipkart are ahead. But for those prioritizing learning velocity, fintech domain expertise (rare and valuable in the market), and equity upside, Razorpay is a compelling bet.

Q: Does Razorpay hire from non-CS branches? A: Yes, but candidates from ECE/EEE must demonstrate strong CS fundamentals, operating systems, data structures, algorithms, and networking. The fintech domain knowledge is teachable; core CS fundamentals are not negotiable.

Q: What's the work-from-home policy at Razorpay in 2026? A: Razorpay follows a hybrid model, 3 days in office for Bengaluru employees. Full remote is not standard for SDE-1/2 roles. Engineering leadership has been explicit about the value of in-person collaboration for early-career engineers.

Q: Are Razorpay ESOP grants meaningful for an SDE-1 candidate? A: At the SDE-1 level, ESOP grants are smaller (₹5-12 L total over 4 years at current valuation). The real equity upside is at SDE-2 and above. The bet is: if Razorpay IPOs at a higher valuation (possible given fintech tailwinds), current grants appreciate. Treat ESOPs as a bonus, not the base case.

Q: How important is the API design question in Razorpay interviews? A: Very important, more so than at other Indian product companies. Razorpay's product IS an API. Candidates who can reason about RESTful design, status codes, versioning, idempotency, and error contracts demonstrate product domain alignment. Prepare at least 2-3 API design scenarios (payment creation, webhook, refund).

---

This guide has helped 1,500+ students crack Razorpay's unique fintech-flavored interviews. Share it with friends targeting fintech, the API design and UPI system design sections are not available anywhere else at this depth.

Also check: Flipkart Placement Papers 2026 | Amazon Placement Papers 2026 | Google Placement Papers 2026 | Microsoft Placement Papers 2026

---

You May Also Like

• Intel Placement Papers 2026 | Interview Questions & Preparation Guide
• Cisco Placement Papers 2026 with Solutions, Aptitude, Technical & Coding
• PhonePe Placement Papers 2026 | Freshers Exam Pattern, Syllabus & Questions
• Apple Placement Papers 2026 – Interview Questions, Coding Rounds & Preparation Guide