You scan a QR code. You enter your PIN. Two seconds later, the shopkeeper's phone buzzes. Money moved from your bank account to theirs, instantly, across potentially two completely different banks, with no cash, no card swipe, no delay.
Most people treat this as magic. It isn't. It's one of the most well-engineered payment infrastructures on the planet, and understanding how it works makes you appreciate both how clever the design is and why it occasionally fails the way it does.
This article walks through the full system: why UPI was invented, what the architecture looks like, which players are involved, and exactly what happens from the moment you scan a QR code to the moment that payment confirmation appears on screen.
The Problem UPI Was Built to Solve
Before UPI, sending money digitally in India was a painful chore. You had to juggle account numbers and IFSC codes, choosing between slow systems that took hours or fast ones that still required a long list of bank details, and making it way too frustrating for simple things like paying a street vendor or splitting a dinner bill.
UPI changed everything by replacing that entire mess with a single, easy-to-remember ID (like yourname@bankhandle) that sends money instantly. Turning that simple idea into something that works reliably for millions of people across hundreds of banks was the massive engineering challenge handed to the NPCI.
The Four Layers of the UPI Architecture
Before tracing a transaction, you need to understand who the players are. UPI has four distinct layers, each with a specific role.
Layer 1: The PSP App (Payment Service Provider)
This is the app on your phone. Google Pay, PhonePe, Paytm, and every other UPI app falls into this category. Their job is to provide the user interface: the screen where you scan the QR, enter the VPA, type the amount, and confirm with your PIN. They are the front end of the entire system.
What most people don't realise is that these apps have zero direct connection to the payment network. Google Pay cannot move money on its own. It has no banking license. It cannot talk to NPCI. To enter the actual payment network, each PSP app must partner with a bank.
Layer 2: The PSP Partner Bank
Every PSP app is backed by a partner bank that holds its UPI license and acts as the gateway into NPCI's network. Google Pay partners with Axis Bank, ICICI, HDFC, and SBI. PhonePe partners with Yes Bank, ICICI, and Axis. Paytm Payments Bank is its own entity.
When you initiate a payment in Google Pay, the app doesn't talk to NPCI. It talks to its partner bank, and that bank talks to NPCI. This distinction is important: NPCI trusts only licensed banks, not apps.
Layer 3: NPCI (National Payments Corporation of India)
NPCI is the backbone. It's not a payment gateway and not a bank. It is the infrastructure layer that makes the entire system possible. NPCI operates a closed, trusted network that only communicates with licensed member banks. No public API access. No direct integration for third parties. Every transaction flows through NPCI, and NPCI alone decides whether a transaction goes through.
Think of NPCI as the air traffic control system for money. It doesn't fly the planes, but nothing moves without its coordination.
Layer 4: The Issuing and Acquiring Banks
The issuing bank is where the sender's money lives. The acquiring bank is where the receiver's money goes. These are your regular banks: SBI, HDFC, ICICI, Kotak, and every other bank that has joined the UPI network. They hold the actual accounts and execute the debit and credit instructions that NPCI sends them.
What a VPA Actually Is
Before tracing the transaction flow, it helps to understand the VPA more concretely.
A VPA like john@oksbi or merchant@ybl is a pointer. It maps to a real bank account behind the scenes, but the sender never needs to know which account. NPCI maintains the mapping between VPAs and actual bank account details internally.
When you scan a QR code, you're not scanning anything exotic. A UPI QR code is just a VPA encoded in a standard format. Scanning it is the same as typing the VPA manually. The QR format exists purely to reduce the chance of typos.
Your VPA is registered when you set up UPI on any app. The app links your phone number, your bank account, and creates a VPA for you. The @handle part (like @oksbi, @ybl, @axl) identifies which PSP partner bank manages that VPA.
The Full Transaction Flow: What Happens When You Pay
Let's trace a complete transaction. You are paying a shopkeeper ₹500. You use PhonePe. Your account is at HDFC. The shopkeeper uses Google Pay and their account is at SBI.
Step 1: You create the payment intent
You open PhonePe and scan the shopkeeper's QR code. The app reads the VPA encoded in the QR, say shopkeeper@oksbi. You enter ₹500 and confirm. At this point, a payment intent is created inside the app: from your VPA, to shopkeeper@oksbi, amount ₹500.
Step 2: PhonePe forwards the request to its partner bank
PhonePe cannot touch NPCI directly. So it sends this payment intent to its PSP partner bank, which in this scenario is Yes Bank. The request includes your VPA, the destination VPA, the amount, and a unique transaction reference ID.
Step 3: Yes Bank forwards to NPCI
Yes Bank is a licensed member of NPCI's network. It takes PhonePe's payment request and forwards it to NPCI over the secure trusted network. NPCI now knows a payment has been initiated.
Step 4: NPCI resolves the VPAs and checks balance
NPCI looks up both VPAs internally. It identifies that your VPA points to an HDFC account and the shopkeeper's VPA points to an SBI account. NPCI then sends a request to HDFC asking: does this account have at least ₹500 available?
HDFC responds: yes.
Step 5: Authentication
NPCI sends back a challenge through the chain. Yes Bank passes it back to PhonePe, and PhonePe shows you the PIN entry screen. This is where you enter your UPI PIN. That PIN is not stored in the app. It is encrypted and sent back through the same chain to HDFC, which is the only entity that can verify it.
This is a critical security design. The PSP app, including Google Pay and PhonePe, never sees your actual PIN. It only passes the encrypted value through. Only your issuing bank (HDFC in this case) has the key to verify it.
Step 6: HDFC debits your account
Once HDFC validates your PIN, it debits ₹500 from your account and sends an acknowledgment back to NPCI confirming the debit was successful.
Step 7: NPCI credits the receiver's account
With the debit confirmed, NPCI instructs SBI to credit ₹500 to the shopkeeper's account. SBI does this and sends back an acknowledgment to NPCI.
Step 8: Both parties get notified
Only when NPCI receives acknowledgment from both banks (debit confirmed, credit confirmed) does it mark the transaction as complete. NPCI notifies Yes Bank, which notifies PhonePe, which shows you the success screen. Simultaneously, SBI notifies Google Pay (via ICICI, the shopkeeper's PSP partner bank), and the shopkeeper's phone buzzes.
The entire sequence takes roughly one to three seconds under normal conditions.
Why Transactions Fail (And Why Money Sometimes Comes Back)
The failure mode you've experienced: you pay, your account is debited, but the receiver says the money didn't arrive. This feels alarming, but the system handles it deliberately.
The transaction is only marked complete when NPCI receives acknowledgments from both the issuing bank (debit) and the acquiring bank (credit). If the acquiring bank's server is busy, overloaded, or temporarily unreachable, the credit acknowledgment never comes.
When NPCI doesn't receive acknowledgment within a timeout window, it initiates a rollback. It instructs the issuing bank to reverse the debit. Your money comes back. This is the reconciliation mechanism working correctly.
The delay between the debit and the reversal, sometimes minutes, sometimes a few hours for edge cases, is why it feels broken even when it isn't. The system is designed to never lose money in transit. Either both sides complete or neither side completes.
Why NPCI Exists Instead of Banks Talking Directly
You might reasonably ask: why not just have HDFC and SBI talk to each other directly? Why the intermediary?
Direct bank-to-bank integration doesn't scale. India has over 200 banks on the UPI network. If each bank had to maintain direct integrations with every other bank, that's potentially thousands of bilateral agreements, security audits, API contracts, and reconciliation systems. Every new bank joining the network would require bilateral connections with every existing member.
NPCI solves this with a hub-and-spoke model. Every bank integrates once with NPCI. NPCI handles the routing. When HDFC needs to send money to SBI, it doesn't need to know anything about SBI's systems. It just tells NPCI, and NPCI handles the rest.
This also centralises regulation and fraud detection. NPCI can monitor the entire transaction graph in real time, flag suspicious patterns, and enforce rules uniformly across the network without each bank building its own detection systems from scratch.
The Scale That Makes This Impressive
NPCI processed over 13 billion UPI transactions in a single month in 2024. That's roughly 5,000 transactions per second at peak load, with real-time settlement requirements, across hundreds of banks, with fault tolerance built in.
Building a system that handles that load while maintaining consistency (no double spends, no money lost in transit, no transaction completed partially) is a genuinely hard distributed systems problem. Every transaction requires coordinated state changes across at least two banks and NPCI simultaneously. If any one of them fails mid-transaction, the system has to roll back cleanly.
The fact that UPI works as reliably as it does, with failure rates that are low enough to be occasional annoyances rather than a reason to avoid the system, is a significant engineering achievement. Most of the internal implementation details of how NPCI manages this at scale are not publicly documented, which is both frustrating from a learning perspective and understandable from a security perspective.
![[System Design] GraphHopper Distance Matrix: Self-Host OSRM vs Haversine for Route Optimization](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fyoo5j6x1kubw2zbx6ayz.png)
