A Deep Technical Breakdown of How One UPI Transaction Actually Moves Money

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#

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.