Decoding How UPI-Like PhonePe Works

6 min read18 hours ago

–

Press enter or click to view image in full size

Source: By the author

Sending money used to be a headache. If you remember the days before UPI, you know the struggle of** NEFT, IMPS, and RTGS. **You had to ask for a

• 6-digit account number,
• an 11-digit IFSC code
• Branch Code & Name

Add a beneficiary, and then wait 30 minutes to 24 hours just to send ₹500 to a friend.** It was like filling out a digital deposit slip every single time.**

The Old Way: NEFT, RTGS, and IMPS

Press enter or click to view image in full size

Source: Hip

For the newbies who never faced the struggle, here is how we used to move money before UPI changed the game. Think of these as the ancestors of modern payments:

1. NEFT (National Electronic Funds Transfer): This was the “slow train” of banking. It did not send money instantly. Instead, it collected transactions in piles (batches) and sent them every 30 minutes. If you missed the train, you waited for the next one.
2. RTGS (Real-Time Gross Settlement): This is the “VIP Lane.” It sends money instantly, but it is exclusively for big spenders. You can only use it if you are sending more than ₹2 Lakhs.
3. IMPS (Immediate Payment Service): This was the first “fast” option. It worked 24/7 and was instant. However, it was clunky. You still had to type in that long account number and IFSC code perfectly. One wrong digit, and your money could go to a stranger.

Then came UPI (Unified Payments Interface), and suddenly, money became as easy to send as a WhatsApp message. But what is actually happening behind that “Processing” screen? As an engineer or a curious user, you might wonder how a Google Pay app talks to an HDFC bank account securely in milliseconds.

In this blog, we will tear down the system design of UPI and look at how it actually works under the hood.

The Concept: Why UPI is Different

The core innovation of UPI is that it decouples the banking utility (holding money) from the user experience (the app).

In the old model, if you had an SBI account, you had to use the SBI app. With UPI, you can use Google Pay, PhonePe, or CRED to manage your SBI account. The system acts as a massive router (switch) that connects every bank to every app using a standard set of APIs.

This is powered by the VPA (Virtual Payment Address).

The Magic of VPA (Virtual Payment Address)

VPA is the secret sauce. It is an alias like divy@okicici or 9876543210@ybl.

Think of VPA like an Email Address for your money.

• Traditional Banking (Account + IFSC): This is like knowing a computer’s IP Address (e.g., 192.168.1.1). It is hard to remember and easy to type wrong.
• UPI (VPA): This is like a Domain Name (e.g., google.com). You type the name, and the system automatically looks up the IP address in the background.

When you send money to the NPCI (National Payments Corporation of India), it acts like a DNS server. It looks at its central database (the Mapper) and says, "Ah, this VPA is linked to Divy’s savings account at ICICI Bank with this specific account number."

System Design: The Real Architecture

Press enter or click to view image in full size

Source: By the author

This is where we get technical. Most people think Google Pay talks to your bank. It does not. Google Pay is just a UI layer (TPAP). It needs a licensed bank to talk to the network.

Here are the 5 key actors in a transaction:

1. TPAP (Third Party App Provider): The app you use, like Google Pay or PhonePe. They provide the interface but cannot touch the banking network directly.
2. PSP Bank (Sponsor Bank): This is the bridge. Since Google is a tech company, it partners with banks like Axis, HDFC, or ICICI to connect to the network. This is why your handle is @okaxis (Google + Axis) or @ybl (PhonePe + Yes Bank). The app talks to the sponsor bank, and the sponsor bank talks to the network.
3. NPCI Switch: The central router. It receives traffic from** sponsor banks (like Axis Bank) **and routes it to the correct destination.
4. Remitter Bank (Issuing Bank): The bank where the money is leaving (e.g., your actual SBI savings account).
5. Beneficiary Bank (Acquiring Bank): The bank where the money is going (e.g., your friend’s HDFC account).

Step-by-Step Walkthrough: The Lifecycle of a Transaction

Let’s follow a real example. Imagine Divy wants to send ₹1,000 to his friend Vishal Kumar.

• Divy uses Google Pay and has an account in SBI.
• Vishal uses PhonePe and has an account in HDFC Bank.
• Axis Bank acts as the hidden** “sponsor”** for Google Pay.

Here is exactly what happens in the few seconds you see the “Processing” spinner.

Step 1: The Initiation (Divy -> Google Pay -> Axis Bank)

Divy scans Vishal’s QR code or enters his VPA (vishal@ybl) and enters his 4-digit UPI PIN.

This is the first layer of security.

Google Pay takes that PIN and encrypts it immediately. Google Pay cannot read this PIN, and it does not know if Divy has money in his account.

It takes this encrypted package and hands it over to its partner, Axis Bank.

Axis Bank can communicate with NPCI

Think of Axis Bank here as a secure courier or a gateway. Its only job is to take the request from the app and get it into the banking network. It does not check balances; it just verifies the device and passes the parcel forward.

Step 2: The Routing (Axis Bank -> NPCI)

Axis Bank forwards the request to the NPCI (National Payments Corporation of India).

NPCI is the central switch.

It acts like a traffic controller. It looks at the request and sees what Divy’s VPA is @oksbi. It immediately knows that this request needs to go to SBI for approval.

Step 3: The Decision (NPCI -> SBI)

This is the most critical step. NPCI sends the request to SBI (the remitter bank).

SBI receives the encrypted PIN and unlocks it using its private key. Now, the bank’s server asks two questions:

1. Is the PIN correct?
2. Does Divy have ₹1,000 in his account?

If the answer to both is “Yes,” SBI cuts (debits) ₹1,000 from Divy’s account right there. It then sends a “Success” signal back to NPCI saying the money has been secured.

Step 4: The Credit (NPCI -> HDFC Bank)

Now that NPCI knows the money is safe with SBI, it turns to the receiver’s side. It sends a message to HDFC Bank (Vishal’s bank) saying that SBI has debited the amount and HDFC should now credit it to Vishal.

HDFC Bank adds ₹1,000 to Vishal’s account and sends a confirmation back to NPCI.

Step 5: The Confirmation (HDFC -> PhonePe -> Vishal)

The money has moved, but Vishal doesn’t know yet.

Once HDFC confirms the credit, NPCI sends a digital signal to the PhonePe server. PhonePe receives this signal and instantly triggers a push notification on Vishal’s phone saying, “You have received ₹1,000 from Divy.”

Why Do Transactions Sometimes Fail?

You might have seen the dreaded “Payment Processing” or “Failed” message. In a distributed system like this, failures are inevitable.

• The Timeout: If Debit succeeds but Credit times out (maybe the friend’s bank server is slow), your money is cut, but the friend didn’t get it.
• The Auto-Reversal: NPCI runs a reconciliation process. If it sees the money was cut but not delivered, it automatically instructs your bank to reverse the transaction**. This is why you get the money back within a few days (or often minutes).**

The “Sponsor Bank” Nuance

You might notice in your transaction history (or the PDF logs) that Google Pay IDs often look like name@okaxis or name@okicici.

This is because Google and PhonePe are tech companies, not banks. They cannot connect directly to the RBI banking network. They need a Sponsor Bank (like Axis, HDFC, or ICICI) to plug them into the NPCI switch. So even if you link your SBI account to Google Pay, the technical handshake might be handled by Axis Bank’s infrastructure acting as the gateway for Google.