# A Deep Technical Breakdown of How One UPI Transaction Actually Moves Money - Source: https://intervueclub.com/blog/how-one-upi-transaction-moves-money - Author: Dhananjay Aggarwal - Published: 2025-12-28 - Tags: payments, upi, distributed-systems UPI apps never touch money. A step-by-step walk through the banks, PSPs and NPCI switch behind one payment, and why the design keeps apps replaceable. UPI is often described as a “simple instant payment system.” That description is accurate only at the user interface level. At the system level, UPI is a **bank-controlled, NPCI-routed, multi-actor distributed transaction system** where apps are deliberately kept away from any authority over money movement. This article explains: - Why UPI apps cannot and must not talk to NPCI directly - How Virtual Payment Addresses act as routing aliases, not identifiers - Why a single payment can involve up to four banks - A **step-by-step walkthrough** of the real UPI transaction flow using the diagram below ## First Principle: UPI Apps Do Not Move Money A UPI app does not: - Debit an account - Credit an account - Settle funds - Talk to NPCI core systems A UPI app only **initiates intent**. All financial authority sits with **regulated banks**. NPCI enforces this separation because: - Only banks are regulated entities - Only banks can perform **KYC, AML** and audit-compliant transactions - Only banks can maintain legally valid ledgers UPI is not an app network. It is a **bank network with app-based access**. ## Why NPCI Refuses Direct App Connectivity NPCI is not a payment processor in the traditional sense. It is a **centralized switch** that: - Routes validated interbank payment instructions - Maintains transaction state machines - Enforces protocol rules - Enables dispute traceability NPCI never: - Stores balances - Authenticates end users - Executes debits or credits Letting apps connect directly would: - Break RBI compliance boundaries - Destroy audit trails - Introduce unregulated debit authority So NPCI connects **only** to banks. ## Virtual Payment Address Is a Routing Alias, Not an Identity A common misconception is that a UPI ID is some kind of globally unique identifier. It is not. A VPA is simply an alias of the form: ``` username@bank mobile@bank ``` This alias maps internally to: - A specific bank account - A specific customer profile - A specific PSP bank The mapping exists: - Inside the PSP bank’s systems - Registered with NPCI only for routing NPCI does not know your account number. The app does not know your account number. Only the bank does. This is intentional isolation. ## Actors Involved in a Single UPI Payment Before reading the flow, it helps to clearly separate the roles. A single UPI transaction can involve **five distinct systems**. 1. **UPI App (Frontend Only):** collects intent and authentication input. 2. **Payer PSP Bank:** the bank providing UPI services to the payer’s app. 3. **Payer Bank (Remitter Bank):** the bank holding the payer’s actual account. 4. **NPCI UPI Network:** the central routing and state coordination layer. 5. **Receiver PSP Bank and Payee Bank:** the banks responsible for receiving and crediting funds. In many cases, the PSP bank and the account bank are the same. Architecturally, they are separate responsibilities. ## Walking Through the Diagram Step by Step ![UPI flow: the customer pays in PhonePe, which sends the request to ICICI Bank as payer PSP; the NPCI UPI network sends a debit request to HDFC as remitter bank, a credit request to SBI as beneficiary bank, and a notification to the receiver PSP.](https://intervueclub.com/blog/how-one-upi-transaction-moves-money/2.webp) ### Step 1: Payment Intent Initiation (PhonePe → Payer PSP) The user starts a payment in PhonePe. **PhonePe:** - Collects amount, payee VPA and UPI PIN - Creates a signed payment request - Sends this request to its **Payer PSP Bank** (for example, ICICI Bank) At this point: - No money has moved - NPCI is not involved - This is purely intent propagation ### Step 2: Debit Authorization (Payer PSP → Remitter Bank) The Payer PSP forwards the request to the **Remitter Bank**, which holds the payer’s account. The Remitter Bank: - Validates the UPI PIN - Checks account status - Checks balance - Places a debit hold - Generates a debit authorization response This is the **only point** where the payer’s money is touched. If this step fails, the transaction stops here. ### Step 3: Routing via NPCI (Remitter Bank → NPCI) Once the debit is authorized, the Remitter Bank sends a **debit-confirmed transaction message** to NPCI. NPCI: - Validates the message format - Assigns transaction identifiers - Determines the Receiver PSP from the VPA suffix - Routes the request forward NPCI does not: - Validate balances - Execute debits - Execute credits It is a deterministic router. ### Step 4: Credit Request (NPCI → Receiver PSP → Payee Bank) NPCI forwards the transaction to the **Receiver PSP Bank**. The Receiver PSP: - Forwards the credit instruction to the **Payee Bank** (for example, SBI) The Payee Bank: - Credits the receiver’s account - Updates its internal ledger - Generates a credit confirmation This is where the money is actually credited. ### Step 5: Confirmation Propagation (Payee Bank → NPCI → All Parties) The success response flows backward: - Payee Bank → Receiver PSP - Receiver PSP → NPCI - NPCI → Remitter Bank - Remitter Bank → Payer PSP - Payer PSP → PhonePe Only after this chain completes does the app show “Payment Successful”. The whole flow typically completes in milliseconds. ## Why This Architecture Scales and Survives Failures UPI follows classic distributed system principles: - Strong consistency at bank ledgers - **Stateless routing** at NPCI - Clear **ownership** of failure domains - Idempotent transaction identifiers - **Reversible transaction** states If a credit fails after a debit: - NPCI initiates a reversal - The Remitter Bank releases the funds - The audit trail stays intact No app-level retry can corrupt state, because apps never touch state. ## Why UPI Apps Are Intentionally Replaceable Because apps do not own: - Accounts - Balances - Identity - Settlement You can: - Change apps - Keep the same VPA - Use multiple apps at the same time The system stays stable because the **bank is the anchor**, not the app. This is not convenience-driven design. This is **regulatory-grade system isolation**. ## Final Takeaway UPI feels simple because its complexity is **structurally hidden**. The complexity still exists. Every payment involves: - Multiple banks - A central switch - Strict separation of authority - Real-time ledger coordination UPI is not a fintech innovation. It is a **national-scale, bank-first distributed payment protocol** that happens to expose a clean API to consumers. And that is exactly why it works.