How UPI Works

Quick Answer

When you scan a QR code at a grocery counter and approve a transaction, your smartphone moves zero money. Your phone is not an electronic wallet, and no digital currency travels through cellular radio waves.

Your phone is simply an input and authentication terminal.

What actually happens is a synchronized sequence of cryptographically protected financial messages coordinated across five separate institutions:

1. Your UPI App (TPAP): Captures the recipient's address and amount, but never sees or handles your UPI PIN.
2. The NPCI Common Library: A sandboxed cryptographic module inside the app that collects your PIN and encrypts it using Public Key Infrastructure (PKI) into an opaque, tamper-proof credential block.
3. The NPCI Central Switch: The national clearinghouse that validates the recipient's Virtual Payment Address (VPA) and orchestrates the transaction between banks.
4. Your Bank (Remitter / Issuer Bank): Verifies the encrypted PIN inside a certified Hardware Security Module (HSM), checks your available balance, and executes an atomic debit on your savings account in its Core Banking System (CBS).
5. The Recipient's Bank (Beneficiary / Acquirer Bank): Upon receiving authorization from NPCI, executes an atomic credit to the merchant's account in its Core Banking System.

Your account balance drops and the merchant's balance rises in two to three seconds. However, the commercial banks themselves do not transfer central bank funds between each other immediately; they settle their net obligations in scheduled batches throughout the day through the Reserve Bank of India's (RBI) Real-Time Gross Settlement (RTGS) system.

---

The System Architecture: Who Does What

To understand how a payment clears, you must separate the visible branding on your phone screen from the regulated financial institutions operating underneath:

Tier	Real-World Entity	Primary Responsibilities	Regulatory Constraints
TPAP (Third-Party App Provider)	Google Pay, PhonePe, Paytm, CRED	Renders UI, scans QR codes, manages device binding.	Cannot hold customer deposits or inspect raw UPI PINs.
Payer PSP (Payment Service Bank)	Axis Bank, ICICI Bank, HDFC Bank, SBI	Provides the regulated banking API gateway connecting the TPAP app to the NPCI switch.	Must hold a banking license under RBI regulations.
NPCI Central Switch (Switch & Directory)	National Payments Corporation of India	Central transaction switch and VPA directory (Central Mapper). Coordinates interbank messages.	Pure messaging switch; does not hold consumer balances.
Remitter Bank (Issuer Bank / Debit Leg)	Where your savings account lives	Holds your deposit ledger. Validates MPIN inside an HSM and debits Core Banking (CBS).	Carries primary liability for authorizing account debits.
Beneficiary Bank (Acquirer Bank / Credit Leg)	Where the merchant's account lives	Holds payee account. Credits payee CBS ledger and notifies merchant soundbox or terminal.	Must post credits instantly upon receiving valid switch message.

When you pay a merchant using Google Pay connected to your State Bank of India account, Google Pay does not touch the money. SBI debits your account, NPCI routes the message, and HDFC Bank credits the merchant's account. Google Pay is simply the digital messenger.

---

Phase 1: Addressing and Resolution (ReqValAdd)

Traditional bank transfers require an account number and an 11-digit IFSC code. UPI replaces this with a Virtual Payment Address (VPA), such as store9182@hdfcbank or 9876543210@upi.

When you point your camera at a store counter QR code, your phone reads a standard URI string defined by the BharatQR and NPCI specification:

upi://pay?pa=store9182@hdfcbank&pn=Sharma%20Groceries&mc=5411&tid=TX1092837&am=150.00&cu=INR

This string carries four critical pieces of metadata:

• pa (Payment Address / VPA): The merchant's alias (store9182@hdfcbank).
• pn (Payee Name): The registered business or personal name (Sharma Groceries).
• mc (Merchant Category Code): An ISO 18245 code classifying the business type (5411 = Grocery Stores / Supermarkets).
• am (Amount): Optional pre-filled transaction value.

Why VPAs Exist

Exposing raw account numbers on physical store counters creates severe privacy and fraud risks. A Virtual Payment Address (VPA) acts as an abstraction layer:

1. The app extracts the VPA and fires an address resolution request (ReqValAdd) through its PSP bank to the NPCI switch.
2. The NPCI switch consults its Central Mapper database.
3. The mapper translates store9182@hdfcbank into: $$\text{Account Number: } 50100481928312 \quad\mid\quad \text{IFSC: } \text{HDFC0000128}$$
4. The switch returns a RespValAdd payload containing the verified legal name of the merchant. The app displays "Sharma General Store" on your screen before you enter your PIN, defeating QR-swapping phishing attacks.

---

Phase 2: The Cryptographic Boundary (NPCI Common Library)

The most critical engineering question in UPI security is: Why can't Google Pay, PhonePe, or a malicious third-party app intercept your 4-digit or 6-digit UPI PIN?

If third-party apps could read the PIN directly from the smartphone keyboard, a rogue app update or compromised background script could capture credentials and drain customer accounts.

To make this mathematically impossible, NPCI enforces a strict isolation architecture:

[ UPI Host App: Google Pay / PhonePe ]
               │
               ▼ Taps "Proceed to Pay"
[ Surrenders Screen Control via OS API ]
               │
               ▼
┌────────────────────────────────────────────────────────┐
│ The Common Library Isolation Boundary                  │
│ NPCI Common Library (CL) Native Sandbox                │
│                                                        │
│  - Renders custom keypad under OS FLAG_SECURE          │
│  - Screen recording & screenshots blocked by OS kernel │
│  - Encrypts PIN with Remitter Bank Public Key (PKI)    │
│  - Generates opaque CredsBlock                          │
│                                                        │
│  CredsBlock = Encrypt(PIN + TxnID + Amount + Salt)     │
└────────────────────────────────────────────────────────┘
               │
               ▼ Returns opaque ciphertext only
[ Host App transmits CredsBlock to Switch ]
               │
               ▼
[ Remitter Bank Hardware Security Module (HSM) ]
  - Tamper-proof silicon vault
  - Decrypts and verifies PIN against bank ledger

1. OS-Level UI Sandboxing

When it is time to authorize a payment, the host app surrenders UI control to the NPCI Common Library (CL)—a certified binary package embedded into every licensed UPI app. The keypad is rendered with the Android FLAG_SECURE flag enabled, preventing background screen recorders, keyloggers, or screenshot tools from intercepting input.

2. Public Key Encryption at Source

The moment your finger taps the digits, the Common Library encrypts the PIN using Public Key Infrastructure (PKI) with the Remitter Bank's certified public key ($PK_{\text{bank}}$). Neither the app nor NPCI possesses the matching private key.

3. The CredsBlock

The encrypted PIN is packed alongside cryptographic salt, the transaction ID, the timestamp, and the exact amount to form an opaque payload called the CredsBlock:

$$\text{CredsBlock} = \text{Encrypt}{PK{\text{bank}}}(\text{MPIN} \parallel \text{Timestamp} \parallel \text{TxnId} \parallel \text{PayerVPA} \parallel \text{Amount} \parallel \text{Salt})$$

Because the CredsBlock binds the encrypted PIN mathematically to the specific transaction ID and amount, an attacker intercepting the data packet over public Wi-Fi cannot re-transmit it to authorize a different payment or tamper with the amount.

4. Hardware Security Module (HSM) Validation

The encrypted CredsBlock travels untouched through the app, through the sponsor PSP bank, and across the NPCI switch until it reaches the Remitter Bank's data center.

At the bank, the payload is routed directly into a Hardware Security Module (HSM)—a physically hardened, FIPS 140-2 Level 3 certified cryptographic vault. The bank's private key resides permanently inside the HSM silicon. The HSM decrypts the CredsBlock, validates the MPIN against the secure credential repository, and returns a binary boolean: AUTH_SUCCESS or AUTH_FAIL.

At no point in the journey does your plain-text UPI PIN exist in app memory, network logs, or intermediate server caches.

---

The Step-by-Step Transaction Lifecycle

Phase 3: The Two-Legged Transaction Flow (ReqPay)

Once the payment instruction (ReqPay) arrives at the NPCI switch, the switch coordinates two discrete atomic database transactions:

The Debit Leg

1. NPCI sends the debit order to the Remitter Bank.
2. The bank verifies the CredsBlock inside its HSM and checks available funds.
3. The bank's Core Banking System (CBS) (such as Finacle, BaNCS, or Flexcube) executes an atomic debit:

   UPDATE accounts 
   SET balance = balance - 150.00 
   WHERE account_number = '1029384756' AND balance >= 150.00;
   

4. The Remitter Bank returns an affirmative acknowledgement to NPCI.

The Credit Leg

1. With customer funds locked in the debit leg, NPCI instructs the Beneficiary Bank to post a credit.
2. The Beneficiary Bank's CBS executes an atomic credit to the payee ledger:

   UPDATE accounts 
   SET balance = balance + 150.00 
   WHERE account_number = '9876543210';
   

3. The Beneficiary Bank confirms success back to NPCI.
4. NPCI emits the final confirmation message (RespPay) to both apps.

When Leg 2 completes, the beneficiary bank fires a webhook to the merchant's payment processor, triggering the instant audio chime on the counter soundbox: "Received 150 rupees on PhonePe."

The Invariant Rule: Debit First, Credit Second

Notice the strict causal order:

• The Remitter Bank must execute the debit first.
• NPCI never sends the credit instruction to the merchant's bank until your bank has explicitly confirmed that money has been subtracted from your ledger.
• If your bank reports insufficient funds, an account freeze, or an invalid PIN during Leg 1, the transaction aborts instantly. The merchant bank is never contacted.

---

Phase 4: Clearing vs. Settlement (Where does the money move?)

A fundamental misconception is that commercial banks transfer cash between each other the moment your payment succeeds.

They do not.

If banks attempted to execute real-time interbank wires for every ₹10 chai purchase, the national interbank settlement infrastructure would collapse under computational and liquidity gridlock.

UPI separates retail clearing (authorizing payments and updating customer accounts in real time) from institutional settlement (moving central bank money between banks):

[ Retail Clearing Layer: Real-Time (~2 seconds) ]
  Customer A debited ₹150  ──►  Merchant B credited ₹150
  Customer C debited ₹500  ──►  Merchant D credited ₹500
                                 │
                                 ▼
[ NPCI Deferred Net Settlement (DNS) Calculation ]
  Aggregates millions of transactions across all member banks
  Calculates single net position per bank:
    - Bank X net debtor:  -₹8,00,000
    - Bank Y net creditor: +₹8,00,000
                                 │
                                 ▼
[ Institutional Settlement Layer: RBI RTGS Batches ]
  RBI debits Bank X Settlement Current Account in e-Kuber
  RBI credits Bank Y Settlement Current Account in e-Kuber

System Layer	Mechanism	Timing	What Actually Happens
Account Posting (Retail Level)	Real-Time Gross Messaging	1 to 3 seconds	Remitter bank updates your balance ledger ($-\text{₹}150$); Beneficiary bank updates merchant balance ($+\text{₹}150$).
Interbank Settlement (Institutional Level)	Deferred Net Settlement (DNS)	Scheduled batches (multiple times a day)	The two banks settle their cumulative obligations in central bank money through RBI's RTGS system.

1. Deferred Net Settlement (DNS)

Throughout the day, NPCI acts as a central clearinghouse. It records every debit and credit across all member banks without moving sovereign funds.

NPCI continuously aggregates these micro-obligations and calculates the multilateral net position for each bank: $$\text{Net Position}_{\text{Bank}} = \sum \text{Total Inbound Credits} - \sum \text{Total Outbound Debits}$$

2. Multilateral Net Settlement Batch (MNSB)

At scheduled intervals throughout the day, NPCI closes a settlement cycle and generates a Multilateral Net Settlement Batch (MNSB) file. This file summarizes the net balance for every commercial bank in India. Instead of settling 500 million individual payments, NPCI resolves the entire network into a concise matrix of net debtors and net creditors.

3. Final Settlement via RBI RTGS

Every bank licensed to participate in UPI maintains a dedicated settlement account directly with the Reserve Bank of India (RBI) inside its core banking system, e-Kuber.

NPCI transmits the MNSB file to the RBI's Real-Time Gross Settlement (RTGS) engine. The RBI central ledger executes bulk accounting transfers, debiting net debtor banks and crediting net creditor banks. Once the RBI updates these reserve accounts, the transactions achieve legal settlement finality (as detailed in How Money Moves Between Indian Banks).

---

Phase 5: Pending States and The RBI T+1 Auto-Reversal Rule

Every user has experienced the frustration of a payment hanging in "Pending": money was deducted from your account, but the shopkeeper received nothing.

Why does this happen in an instantaneous system?

Distributed Network Partitions

A UPI transaction spans five independent computer networks over public cellular airwaves. If a fiber cut, cellular packet loss, or database timeout occurs after the Remitter Bank executes the debit leg but before NPCI receives the acknowledgement:

• The Remitter Bank knows it deducted the money.
• NPCI never receives confirmation and cannot safely instruct the Beneficiary Bank to credit the merchant.
• The transaction enters an ambiguous state: Pending.

Because NPCI did not receive an explicit Credit-Success within the network timeout window (typically 30 seconds), the transaction enters a De-coupled Pending State (U-State).

The RBI T+1 Auto-Reversal Mandate

Because banking ledgers require double-entry mathematical balance, money cannot vanish into thin air. Under RBI Circular DPSS.CO.PD No.629/02.01.014/2019-20 on Harmonisation of Turn Around Time (TAT):

1. NPCI's automated reconciliation engine cross-examines logs from both banks at the end of each clearing cycle.
2. If the Beneficiary Bank confirms that no credit leg occurred, NPCI flags the transaction as Failed Post-Debit.
3. NPCI dispatches an automated reversal instruction to the Remitter Bank's CBS to credit the customer's balance back.

Requirement	Regulatory Mandate
Permitted Resolution Time (TAT)	$T + 1$ business days ($T$ is transaction date)
Mandatory Auto-Reversal	The bank must automatically reverse funds to the customer without requiring a formal complaint.
Penalty for Delay	₹100 per day credited automatically to the customer for every day of delay beyond $T + 1$.

Transaction Date (T) ──► Leg 2 Fails ──► Automatic Reconciliation Window (T+1)
                                                    │
                                                    ├─ Reversed by T+1: Clean resolution.
                                                    │
                                                    └─ Delayed beyond T+1: Bank must pay
                                                       ₹100/day compensation to customer.

If your account is debited on Monday ($T$) and the transaction fails to complete, your bank has until Tuesday ($T + 1$) to credit the money back. If the funds arrive on Thursday ($T + 3$), the bank is legally obligated to credit ₹200 directly into your account as compensation.

---

Why This Architecture Matters

The Unified Payments Interface is frequently celebrated as a triumph of software design, but its true genius is protocol architecture and layer decoupling:

• Identity Abstraction: Replacing account numbers and IFSC codes with Virtual Payment Addresses.
• Zero-Trust UI Isolation: Protecting PIN credentials inside the sandboxed Common Library.
• Decoupled Clearing & Settlement: Delivering two-second retail confirmations while settling institutional obligations in bulk via RBI e-Kuber.

When you scan a QR code, you are not simply tapping a phone screen. You are commanding a distributed, fault-tolerant network of commercial bank ledgers, central bank settlement accounts, and hardware encryption vaults—all operating in perfect unison in less than three seconds.

---

To understand how payment instructions travel when cellular networks are completely down, read the companion explainer on How UPI Works Without an Internet Connection. To understand how sovereign central bank accounts settle interbank debts, read How Money Moves Between Indian Banks. You can also explore how cards operate under the four-party model in How Credit Cards Actually Work.