System design interview guide
Paytm System Design Interview: UPI, Ledgers, Idempotency
Short answer
Paytm system design moves real money between two banks over NPCI's UPI rails. An orchestrator writes each payment as PENDING with an idempotency key, runs risk checks, then drives the debit leg and the credit leg through NPCI. Every movement goes into a double-entry ledger. A reversal worker chases DEEMED payments to a final state, and reconciliation checks every row against bank and NPCI files.
Two courses by the author of this page:
770 lessons · 18 free to read
₹1,111 in India · $25 elsewhere, once
Get System DesignYou own this course
214 lessons · 10 free to read
₹1,333 in India · $35 elsewhere, once
Get Generative AI and Agentic AIYou own this course
Save your progress and get the interview checklist PDF
UPI processed 21.6 billion transactions in December 2025 alone, peaking near 7,500 transactions per second, and a single rupee can never be created or lost in any of them.
Designing Paytm is the canonical India payments problem. You have to move real money between two banks over the NPCI UPI rails, keep a double-entry ledger that always balances, make every operation idempotent so a retry never double-charges, reconcile against the bank end-of-day, and survive a Diwali sale spike that is 5 to 10x a normal Tuesday. It is less about clever algorithms and more about correctness under failure.
Where it shows up
Commonly asked at Paytm, PhonePe, Razorpay, Cred, Google Pay, Amazon Pay, Flipkart, Swiggy, Zerodha, and most India fintech and FAANG-India teams. It is the standard payments and ledger interview for SDE2 and above.
Spec sheetPaytm
- 01Platform transactions/day
- ~250M
- 02Average TPS
- ~3,000
- 03Peak TPS (festival / sale)
- 15K-30K
- 04Ledger writes per transaction
- 2 to 4
worked through below, with the maths
in this guide
Design Paytm, part by part
8 parts open to everyone · 3 with a free account · 3 with the course
You can read 8 of 14 parts. A free account opens the deep dive; the course opens all of it.
- Requirementsopen
- Scale estimatesopen
- High-level architectureopen
- How a Paytm UPI payment flows, step by stepopen
- Core componentsopen
- Data modelfree account
- Deep dives (6)free account
- Trade-offs to discussfree account
- What the interviewer asks nextwith the course
- The interview scorecardwith the course
- Mock interview on this questionwith the course
- How Paytm actually does itopen
- Frequently asked questionsopen
- Interview readiness checkopen
The hard parts of this design are taught step by step in the System Design course: Idempotency, Saga Pattern and Design a Payment System.
Why this question is asked
Payments is the one domain where eventual consistency is not an acceptable shrug. The interviewer is checking whether you understand that money movement is a distributed transaction across systems you do not control (the user's bank, NPCI, the merchant's bank), that the network will fail mid-flight, and that the only acceptable outcomes are "fully done" or "fully reversed" with a customer who can see exactly what happened. You earn the offer by talking about idempotency keys, a double-entry ledger, the DEEMED state, reconciliation, and what happens when the debit succeeds but the credit times out. You lose it by drawing a "Payment Service to Stripe" box and moving on.
This page is the free part.
The course goes deeper on the Paytm design
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers the Paytm design across a run of lessons, not one page. These 4 alone are about 170 minutes of step-by-step reading, 2 of them with code you run in the browser, all with a quiz.
- Idempotency
Why some operations are safe to retry and others charge you twice, and how to make everything safe.
- Distributed Transactions
Coordinating atomic operations across multiple nodes, the hardest problem in databases.
- Saga Pattern
Long-lived transactions without distributed locking, orchestration vs choreography for microservices.
- Design a Payment System
Design a payment processing system - ACID transactions, idempotency, reconciliation, retry strategies, and the saga pattern for distributed payments.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
You own this course
Continue with Idempotencypay once,
yours for life
The payment system design series
Every payment system rests on the same few ideas: an idempotency key so a retry never charges twice, a double-entry ledger so no money appears or vanishes, and daily reconciliation against the bank. These guides show those ideas inside real products.
- Design a payment systemStart here: the core pattern every guide below uses
- Design StripeCard payments API, idempotency keys, webhooks
- Design RazorpayPayment gateway for India: UPI, cards, settlement
- Design UPIIndia's central payment switch run by NPCI
- Design PayPalWallet, ledger and sagas across services
- Design Paytm(this page)UPI app and wallet, the DEEMED state
- Design PhonePeUPI at national scale, sharded MySQL
- Design a digital walletBalances, holds and captures
- Design a banking systemCore banking: ledger, available balance, NEFT/IMPS/RTGS
- Design CREDBill payments driven by order state machines
- Design fraud detectionScoring a payment in milliseconds
Live from the course bench
Before you design Paytm, try the questions it rests on.
Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- User links a bank account and creates a UPI ID (VPA) like name@paytm
- User pays a person or merchant by VPA, QR code, or phone number (push / pay)
- Merchant or user raises a collect request that the payer approves with their UPI PIN (pull / collect)
- User can load money into a Paytm wallet (PPI) and pay from wallet balance
- Every transaction has a status the user can poll: pending, success, failed, refunded
- Failed or timed-out debits are auto-reversed and money returns to the source
- Refunds can be issued by a merchant back to the original payer
- User sees a passbook / statement with a running balance that always reconciles
Non-functional requirements
- Exactly-once money movement: a retry must never debit twice
- The ledger must always balance (sum of debits equals sum of credits) at all times
- Strong consistency and durability on the money path; no lost writes
- P99 end-to-end UPI latency under a few seconds (NPCI round trip dominates)
- Survive 5 to 10x spikes during festivals, salary day, and flash sales
- Idempotent against client retries, network timeouts, and duplicate webhooks
- Auditable: every paisa movement is traceable to an immutable ledger entry
- Daily reconciliation with each bank and with NPCI settlement files
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Platform transactions/day
~250M
Paytm-class share of UPI plus wallet and gateway traffic. UPI as a whole crossed 640M+ transactions/day in 2025; a large PSP handles a sizeable slice. Round to a few hundred million for sizing.
Average TPS
~3,000
250M / 86,400 seconds is roughly 2,900. Paytm publicly cites a payment gateway capable of ~3,000 transactions per second, which lines up.
Peak TPS (festival / sale)
15K-30K
Apply a 5 to 10x peak factor for Diwali, salary day, and flash sales. UPI system-wide already peaks near 7,500 TPS; a single big PSP must provision well above its daily average.
Ledger writes per transaction
2 to 4
Double-entry means at least a debit and a credit row per money movement. Wallet load, P2M with fee, and refunds add more legs. Budget 2 to 4 immutable ledger rows per logical transaction.
Storage per transaction
~2 KB
Payment row plus ledger entries plus a state-machine event log. At 250M/day that is ~500 GB/day raw, roughly 180 TB/year before compression, partitioned by date and archived to cold storage after a retention window.
Read:write ratio
~5:1
Status polling, passbook loads, balance checks, and reconciliation reads dominate. The write path is the money path; reads are everything else and are served from read replicas and caches.
High-level architecture
A client (the Paytm app or a merchant SDK) hits an API Gateway that does auth, rate limiting, and device-fingerprint checks. Behind it, an Orchestrator (the Payment Service) owns the lifecycle of one transaction: it generates or accepts an idempotency key, writes a payment row in a PENDING state, runs synchronous risk and limit checks, and then drives the money movement. For a UPI payment, the orchestrator calls Paytm's UPI PSP layer, which speaks the NPCI API. NPCI is the central switch: it routes a debit-leg request (ReqPay) to the payer's bank, gets the debit result (RespPay), then routes a credit-leg request to the beneficiary's bank, and finally returns the combined result. For a wallet payment, no bank is involved; the orchestrator just moves balance inside Paytm's own PPI ledger, backed by an escrow account at a scheduled commercial bank. Every state change is appended to a double-entry Ledger Service: each money movement produces balanced debit and credit rows in a durable, append-only store. State transitions are also emitted as events to Kafka, which feeds asynchronous consumers: notifications, fraud scoring, analytics, settlement, and a Reconciliation Service that compares Paytm's view of every transaction against the bank and NPCI end-of-day files and flags any mismatch. A scheduled reversal worker chases DEEMED and timed-out transactions to a terminal state. The money path uses strong-consistency relational stores (sharded MySQL/InnoDB clusters); the read-heavy and analytics paths use replicas, caches, and a columnar warehouse. In a real interview, sketch this on the whiteboard before diving into any single box.
In a real interview, sketch this on the whiteboard before diving into any single box.
How a Paytm UPI payment flows, step by step
One UPI payment through the design above. A wallet payment skips the banks in steps 4 and 5 and moves balance inside Paytm's own ledger.
- 1
The request reaches the gateway
The app or merchant SDK calls the API Gateway, which checks auth, rate limits and the device fingerprint.
- 2
Save the payment as PENDING
The orchestrator generates or accepts an idempotency key and writes the payment row in a PENDING state before anything else.
- 3
Risk and limit checks
Synchronous risk and limit checks run before any money moves.
- 4
The debit leg
Paytm's UPI PSP layer calls NPCI. NPCI sends a ReqPay debit request to the payer's bank and gets the RespPay result.
- 5
The credit leg
NPCI sends the credit request to the beneficiary's bank and returns the combined result to Paytm.
- 6
Ledger rows and events
Each money movement adds balanced debit and credit rows to the ledger. The state change goes to Kafka for notifications, fraud, settlement and analytics.
- 7
Chase the unknowns
A scheduled reversal worker takes DEEMED and timed-out payments to a final state. A timeout is never treated as a failure.
- 8
Reconcile end of day
The Reconciliation Service compares every transaction against the bank and NPCI end-of-day files and flags any mismatch.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
API Gateway
Terminates TLS, authenticates the user or merchant, enforces per-user and per-merchant rate limits, and attaches an idempotency key (from the client, or generated server-side and returned). It is the first place a duplicate retry can be cheaply caught.
Payment Orchestrator
The brain of one transaction. Owns the state machine (INITIATED, RISK_CHECKED, DEBIT_PENDING, CREDIT_PENDING, SUCCESS, FAILED, REVERSED). It is deliberately stateless per request; all durable state lives in the payment row and the ledger. It calls risk, the UPI PSP, and the ledger in a strict order so a crash at any point is recoverable.
UPI PSP / NPCI Connector
Speaks the NPCI UPI API. Resolves a VPA to a bank account, fires the debit-leg ReqPay to the payer bank, then the credit-leg to the beneficiary bank, and interprets RespPay (SUCCESS, FAILURE, or DEEMED). Handles signing, mandates, collect requests, and the strict timeout windows NPCI imposes.
Ledger Service
An append-only, double-entry book. Every money movement writes balanced debit and credit rows in a single atomic transaction. Account balances are derived from the ledger, never edited in place. This is the source of truth for how much money exists and where it sits.
Wallet / PPI Service
Manages Paytm wallet balances, which are a prepaid payment instrument backed by a pooled escrow account at a bank. Loading money debits the user's bank (via UPI/cards) and credits their wallet ledger; the real cash sits in escrow. Wallet-to-wallet payments are pure ledger moves with no bank round trip, which is why they feel instant.
Risk / Fraud Engine
Runs synchronously in the hot path for hard rules (velocity limits, blocklists, NPCI per-transaction caps) and asynchronously for ML scoring (device, behavior, graph signals). A hard rule can block a payment before debit; soft signals raise a transaction for review and can trigger a hold.
Reconciliation Service
Ingests end-of-day settlement and switch files from each bank and NPCI, joins them against Paytm's internal ledger, and emits a break report for any transaction where the two disagree. It is the safety net that catches a debit the bank recorded but Paytm marked failed, and vice versa.
Reversal / Sweeper Worker
A scheduled job that finds transactions stuck in DEEMED or DEBIT_PENDING past their timeout, queries the bank/NPCI for the true outcome, and drives them to SUCCESS or REVERSED. NPCI now targets reversal of timed-out debits within about 30 seconds, so this worker runs aggressively.
Notification Service
Consumes ledger and state events from Kafka to push SMS, in-app, and webhook notifications to users and merchants. Webhooks to merchants are themselves idempotent and retried with backoff until acknowledged.
Data model
payments. One row per logical transaction. amount stored in paise (integer) never floats. idempotency_key has a UNIQUE constraint so a duplicate request collides at the database…
Every table for Paytm, its keys, and which store fits it and why.
Deep dives
Idempotency: retrying without double-charging. The hardest failure in payments is ambiguity. A client fires a pay request, the network drops the response, and the client retries. Did the first one go through? The fix…
6 deep dives on the parts that break at scale: Idempotency: retrying without double-charging; Double-entry ledger that always balances; The UPI flow: debit leg, credit leg, and the DEEMED state.
Trade-offs to discuss
Double-entry ledger vs a single mutable balance column. A mutable balance is simple and fast but a lost update or partial failure silently creates or destroys money, and you can never prove what happened. Double-entry is more…
6 decisions an interviewer expects you to defend, each with the alternative and why it loses here.
What the interviewer asks next
On a sale day, one huge merchant receives a flood of payments and its shard runs hot. How do you fix it?
4 follow-up questions with model answers, the interview scorecard for this question, and a mock interview on Design Paytm with the AI tutor.
How Paytm actually does it
Paytm's payment gateway is publicly described as capable of around 3,000 transactions per second, built on open-source MySQL with the InnoDB engine across many independent database clusters, one per business line, each tuned for its own read/write mix. The broader system it plugs into is UPI, run by NPCI as a four-party push-pull switch: a remitter-side PSP and bank, a beneficiary-side PSP and bank, with NPCI routing the debit leg and credit leg and returning a SUCCESS, FAILURE, or DEEMED result. UPI crossed 21.6 billion transactions in December 2025 and peaks near 7,500 transactions per second system-wide, with per-transaction P2P limits of ₹5 lakh and a push by NPCI to reverse timed-out debits within about 30 seconds. Paytm's wallet is a prepaid payment instrument (PPI): user balances are an internal ledger, while the actual cash sits pooled in an escrow account at a scheduled commercial bank, which is why RBI's PPI and escrow rules shape the design as much as the engineering does. The hard lessons in this space are universal: money is integer paise, retries carry idempotency keys, the ledger is double-entry and append-only, and reconciliation against the bank is the safety net that catches what the happy path missed.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Idempotency
foundation / core fundamentals
Distributed Transactions
advanced / distributed systems core
Saga Pattern
advanced / distributed systems core
Design a Payment System
capstone / capstone
Database Sharding
foundation / database fundamentals
Retry Patterns
advanced / reliability resilience
Rate Limiting for Resilience
advanced / reliability resilience
System design interviews at Indian tech companies
28 walkthroughs of the products Indian interviewers ask about, each with the real scale numbers, the architecture and the trade-offs that company had to make.
Food delivery and quick commerce
Payments and fintech
E-commerce
Travel and ticketing
Rides, logistics and services
Streaming and gaming
Frequently asked questions
interview readiness
Are you ready for Design Paytm?
Three questions from this guide. Answer them without scrolling up, the way you would have to in the room.
Go deeper
This guide is built on these 6 lessons. Each one teaches one piece of the Paytm design above, step by step.
- IdempotencySystem Design · core fundamentals · 28 min
- Distributed TransactionsSystem Design · distributed systems core · 42 min
- Saga PatternSystem Design · distributed systems core · 30 min
- Design a Payment SystemSystem Design · capstone · 70 min
- Database ShardingSystem Design · database fundamentals · 35 min
- Retry PatternsSystem Design · reliability resilience · 35 min
Practice with 770 system design lessons
Lifetime access for ₹1,111 in India or $25 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.
This one question is not enough for the interview.
Get all 200 questions in the System Design and Distributed Systems pack
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
NEWSystem Design Hands-On
Included in the System Design course: real systems, built live
Postgres Sharding: Complete Hands-On (PgBouncer + Citus). 2 h 36 min and 20 chapters: one PostgreSQL loaded until it breaks, then four shards behind a router you write, PgBouncer and Citus, with the 139-page slide deck. The first 15 minutes are free to watch.