ayuuw

upi infra

#Table of Contents

breif

You probably use UPI every single day.

You scan a QR code.

You enter an amount.

You enter your UPI PIN.

And a few seconds later:

Payment successful.

It feels almost trivial.

But behind those few seconds is a fairly complicated payment infrastructure connecting banks, payment applications, merchants, authentication systems, and NPCI.

And the interesting part is that the app you use isn't actually the entire payment system.

When you open Google Pay, PhonePe, BHIM, or another UPI application, you're interacting with only one part of a much larger ecosystem.

So what actually happens when you send someone ₹500?

Where does the request go?

Which bank actually moves the money?

What does NPCI do?

And what happens when something goes wrong?

Let's find out.

Where Did UPI Come From?

Before UPI, India already had electronic payment systems.

There were systems for things like:

  • bank transfers
  • card payments
  • IMPS
  • NEFT
  • RTGS

But there was a problem.

Different payment systems had different experiences, and transferring money between people wasn't always as simple as opening an app and scanning a QR code.

The idea behind UPI was to create a common interface for bank-account payments.

The pilot launch of UPI happened in April 2016.

The goal was simple:

Make different banks interoperable through a common payment infrastructure.

Today, the scale is enormous.

According to NPCI's published statistics, UPI processed more than 22.7 billion transactions in June 2026, with a total value of roughly ₹28.9 trillion. NPCI also reported 731 banks live on UPI for that month.

That's an absurd amount of traffic.

And yet, from the user's perspective, the process still looks like:

Scan -> Enter amount -> Enter PIN -> Done

There is a lot happening in between.

What Exactly Is UPI?

UPI stands for Unified Payments Interface.

The first thing to understand is that:

UPI is not a bank.

And:

UPI is not an app.

Instead, UPI is a payment infrastructure that allows participating banks and applications to communicate through a common system.

NPCI operates the UPI network and describes itself as the owner, network operator, service provider, and coordinator of the UPI network.

A very simplified architecture looks like this:

User -> UPI App -> UPI Infrastructure -> Bank

But there are actually several different participants involved.

Who Are The Players?

There are a few important components we need to understand.

NPCI

The National Payments Corporation of India, or NPCI, operates the UPI network.

It provides the infrastructure that connects participating members and coordinates the UPI ecosystem.

Think of NPCI as the layer that allows different banks and payment applications to participate in the same payment network.

UPI App

This is the application you actually use.

For example:

Google Pay
PhonePe
BHIM
Bank UPI Apps

The app provides the interface for:

Scan QR
Enter amount
Select bank account
Authenticate payment
View transaction status

But the app itself isn't necessarily the bank holding your money.

That's an important distinction.

PSP Bank

PSP stands for Payment Service Provider.

A PSP bank provides the banking infrastructure required for a UPI application to participate in the ecosystem.

Third-party applications can participate through banking relationships rather than directly becoming banks themselves. RBI describes TPAPs as third-party applications that participate through banking entities connected to UPI.

Remitter Bank

This is the bank associated with the person sending the money.

For example:

You -> HDFC Bank

HDFC would be the remitter bank for that transaction.

Beneficiary Bank

This is the bank associated with the person receiving the money.

For example:

Merchant -> ICICI Bank

ICICI would be the beneficiary bank.

Merchant

The merchant is the person or business receiving the payment.

They may accept UPI through:

QR
Intent
Collect Request
Other UPI integrations

NPCI lists QR, intent, application-based, and collect modes among the available merchant integration modes.

So What Happens When You Scan A QR?

Let's say you're buying a coffee.

The merchant has a UPI QR code.

You open your UPI app and scan it.

Something like this happens:

QR -> UPI App -> Payment Request

The QR code contains information that helps identify the intended payment destination.

Your application reads that information and shows you the payment details.

You enter:

₹500

and press:

Pay

But the money hasn't simply jumped from your phone to the merchant's phone.

Now the actual payment processing begins.

The Payment Flow

Let's assume:

Your bank       -> Bank A

Merchant's bank -> Bank B

You are using a UPI application.

A simplified view is:

You -> UPI App -> UPI Infrastructure -> Bank A
                                      -> Bank B

The exact internal architecture is more complicated than this simplified diagram, but this gives us the basic idea.

The important thing is that the UPI ecosystem connects the different participants.

Your UPI app doesn't need a completely separate payment network for every bank.

That's the whole point of interoperability.

Authentication

Before the transaction can be completed, you need to authenticate the payment.

That's where your UPI PIN comes in.

You enter your PIN.

Conceptually:

Payment Request -> Authentication -> Authorized Transaction

Your UPI PIN is used to authenticate the transaction.

It isn't something that should be shared with the merchant or another person.

NPCI explicitly warns users not to share their UPI PIN and distinguishes it from an MPIN issued by a bank.

Once authentication succeeds, the payment can proceed.

Now The Interesting Part

Let's say you're sending:

₹500

from Bank A to Bank B.

The system needs to process a financial transaction involving both sides.

Conceptually:

You -> UPI App -> UPI -> Bank A -> Bank B -> Merchant

Bank A needs to authorize the debit.

Bank B needs to receive the corresponding payment.

The relevant systems need to record the transaction and communicate its status.

Eventually your app receives the result:

Payment Successful

And the merchant receives the payment.

NPCI's FAQ says that merchants receive the money immediately after the customer confirms the payment, into the merchant pool bank account or merchant bank account according to the agreement.

From your perspective, this all happened in a few seconds.

But Is The Money Actually Moving Instantly?

This is where things get interesting.

There is a difference between:

transaction processing

and

settlement.

They're related, but they're not the same thing.

Think about a very simplified example.

Suppose:

Bank A -> Bank B
₹10,000

Bank B -> Bank A
₹7,000

Instead of thinking about every individual transaction independently, the system can determine the net obligation:

Bank A -> Bank B
₹3,000

Real settlement is much more complicated than this example, but the idea of calculating obligations between participants is important.

NPCI maintains settlement infrastructure for UPI and publishes formal settlement and dispute processes.

So:

Payment processing != Settlement

The user sees an immediate payment experience, while the financial system still has to reconcile and settle obligations between participating institutions.

What Happens If Something Goes Wrong?

Now imagine this.

You press:

Pay

Your bank processes the transaction.

But your internet connection dies before the response reaches your phone.

You see:

Payment failed

But did the transaction actually fail?

Maybe.

Or maybe the payment succeeded and only the response was lost.

This is one of the hardest problems in distributed payment systems.

You can end up with a situation like:

Bank:

₹500 debited
       |
       X
Response lost
       |
       ↓
User:

"Did my payment fail?"

The system therefore needs much more than a simple request/response API.

It needs mechanisms for:

  • transaction status
  • reconciliation
  • retries
  • dispute handling
  • reversals
  • failure recovery

NPCI's UPI infrastructure includes formal settlement and dispute processes for handling these situations.

The Problem With Retrying Payments

There's another interesting problem.

Suppose your app sends:

Pay ₹500

The request reaches the payment system.

But the response times out.

Your app doesn't know whether the transaction succeeded.

So it retries:

Pay ₹500

What if the first request already succeeded?

You definitely don't want:

₹500
+
₹500
=
₹1000

when you intended to pay only ₹500.

This is a classic distributed-systems problem.

Payment infrastructure needs mechanisms to distinguish:

New Transaction

from:

Retry of Existing Transaction

This is where concepts such as transaction identifiers, idempotency, state tracking, and reconciliation become extremely important.

The exact implementation details aren't all publicly exposed, so we shouldn't pretend to know NPCI's private internal implementation.

But the underlying engineering problem is universal.

How Does UPI Handle This Much Traffic?

Now consider the scale again.

NPCI reported:

June 2026

22.7 billion+ transactions
₹28.9 trillion+ transaction value
731 banks live on UPI

That's not something you can handle with one server sitting in a data center.

A system operating at this scale needs distributed infrastructure.

Conceptually:

                    -> Server
Requests -> Infrastructure -> Server
                    -> Server
                    -> Server

Multiple components can process traffic in parallel.

There also needs to be redundancy.

If one component fails, the entire payment ecosystem cannot simply disappear.

This means large payment infrastructure needs things like:

  • horizontal scaling
  • redundancy
  • failover
  • monitoring
  • capacity management
  • disaster recovery
  • reconciliation

The exact physical topology of NPCI's infrastructure is not something we should invent, but these are fundamental requirements for operating a system at this scale.

UPI Is Basically A Distributed System

And this is probably the most interesting way to look at UPI.

Forget the QR code for a moment.

Forget the app.

Think about the underlying problem.

You have:

User
  ->
UPI App
  ->
PSP / Banking Infrastructure
  ->
UPI Network
  ->
Payer Bank
  ->
Beneficiary Bank
  ->
Merchant

Every one of these components can potentially experience:

  • network failures
  • timeouts
  • overloaded systems
  • delayed responses
  • duplicated requests
  • partial failures

And yet the system has to answer one very important question:

Did ₹500 actually move?

That's a distributed systems problem.

Except here, the data isn't just data.

It's money.

Why Does UPI Feel So Simple?

Because all of this complexity is hidden from you.

From your perspective:

Scan -> Pay -> Success

Behind the scenes:

Scan
  ->
Payment Request
  ->
Authentication
  ->
Bank Processing
  ->
UPI Infrastructure
  ->
Beneficiary Processing
  ->
Transaction Status
  ->
Reconciliation
  ->
Settlement

The user interface is simple because the infrastructure underneath it is doing the hard work.

And that's what good infrastructure should do.

You shouldn't have to think about it.

UPI vs Your UPI App

This is worth clearing up because it's one of the most common misconceptions.

Suppose you're using:

PhonePe

That doesn't mean:

PhonePe = UPI

Similarly:

Google Pay != UPI

The application is one participant in the ecosystem.

UPI is the underlying interoperable payment infrastructure.

A simplified model is:

UPI App -> UPI Ecosystem -> Banks

That's why you can use different applications to interact with the same bank account and pay merchants using the same UPI infrastructure.

NPCI itself lists the UPI app, payer PSP, remitter bank, payee PSP, beneficiary bank, users, and merchants as participants in the ecosystem.

What About UPI Lite?

UPI also has variations designed for different use cases.

One example is UPI Lite.

UPI Lite is designed for low-value transactions and is intended to reduce the load on a remitter bank's core banking system for those transactions. NPCI describes it as using the existing UPI ecosystem while reducing real-time load on core banking systems.

This is a good example of an important infrastructure principle:

You don't always need to involve the most expensive part of the system for every tiny operation.

If millions of low-value transactions can be handled through a different architecture while maintaining the required controls, the overall system can become more efficient.

The Security Layer

A payment system obviously can't just trust every request that arrives.

UPI incorporates multiple layers of security and authentication.

For users, one of the most visible pieces is:

UPI PIN

But the infrastructure also needs to deal with things such as:

  • authentication
  • transaction limits
  • fraud detection
  • risk controls
  • secure communication
  • device and application security
  • dispute management

The exact internal fraud-detection systems used by individual banks and participants aren't publicly documented in enough detail to describe them precisely.

And that's important.

When talking about financial infrastructure, we should distinguish between publicly documented architecture and assumptions about how the backend might be implemented.

The Bigger Picture

The most interesting thing about UPI isn't the QR code.

A QR code is just a convenient way of telling your payment application:

"Here is who I want to pay."

The difficult part comes afterwards.

The system needs to:

Identify the payment
        ->
Authenticate the user
        ->
Route the transaction
        ->
Process the transaction
        ->
Return a result
        ->
Handle failures
        ->
Reconcile records
        ->
Settle obligations

And it has to do this billions of times.

Every month.

Conclusion

The next time you scan a UPI QR code, remember that you're not simply sending money from one phone to another.

Your phone is interacting with an ecosystem involving payment applications, PSPs, banks, NPCI's UPI infrastructure, transaction processing, reconciliation, and settlement.

From the outside:

Scan -> PIN -> Payment Successful

Underneath:

User -> App -> UPI -> Banks -> Processing -> Reconciliation -> Settlement

And that's what makes UPI interesting from an engineering perspective.

The hard part isn't making a payment work once.

The hard part is making billions of payments work reliably, securely, and interoperably across hundreds of banks and millions of users.

That's the infrastructure behind UPI.

And you probably interact with it every single day without ever seeing it.

BONUS

But What About Google Pay and Apple Pay?

We've talked about UPI, but there's another interesting question.

When you add your credit or debit card to Google Pay or Apple Pay, does the app simply store your actual card number and send it to the merchant every time you pay?

Not necessarily.

Modern mobile payment systems use a concept called tokenization.

The basic idea is simple:

Instead of giving every transaction your real card number, use a substitute number that represents your card.

Let's see how that works.

Your Card Has a Real Number

Suppose your physical card has a card number:

4111 1111 1111 1111

This is your actual card number, commonly referred to as the PAN or Primary Account Number.

If every payment exposed this number to every merchant, stealing card information would be much easier.

So payment networks introduced tokenization.

Instead of giving the merchant the real card number:

4111 1111 1111 1111

the payment system can provide a token representing that card.

Conceptually:

Real Card Number -> Token

The token can then be used for payment without exposing the underlying card number in the same way.

How Does Google Pay Do It?

When you add a card to Google Pay, Google can provision a device token, also called a DPAN, for that card.

Google's documentation describes the DPAN as a uniquely generated token that is used instead of the actual card number for supported device-tokenized payments. ([Google for Developers][2])

So conceptually:

Your Card -> Tokenization -> Device Token / DPAN

And when you make a payment:

Phone -> Merchant -> Device Token

rather than simply sending the original card number.

Google explicitly says that when a cardholder makes a purchase using a device token, Google Pay sends the DPAN rather than the FPAN, which is the underlying funding card number. ([Google for Developers][1])

What Is the Point of a Token?

Imagine someone manages to obtain the token used for a particular payment.

They haven't necessarily obtained the same credential as your physical card.

That's one of the security advantages of tokenization.

Conceptually:

Physical Card -> Real Card Number -> Tokenization -> Device Token -> Merchant / Payment System

The token can be associated with a particular device, wallet, merchant, or payment context depending on the tokenization system.

So instead of having one credential exposed everywhere, you can have different tokens representing the underlying card.

Apple Pay Does Something Similar

Apple Pay also uses payment tokens.

Apple's documentation describes the payment object as containing an encrypted payment token. The token contains information needed to complete the transaction, including a device-specific account number and a unique, one-time-use cryptogram. ([Apple Developer][3])

So the conceptual flow looks like:

Card -> Apple Pay -> Payment Token -> Merchant / PSP

The merchant doesn't simply receive:

Your real card number

Instead, the payment token contains the information required for the payment to be processed.

Apple says that the merchant or its payment service provider can decrypt/process the token, after which it is passed into the normal card-payment processing flow. ([Apple Developer][3])

So Does Google Know Your Card Number?

This is where the privacy question becomes interesting.

The answer isn't simply:

Google sees everything

or:

Google sees nothing

There are multiple pieces involved.

For Google Pay device tokenization, Google documents a flow involving the issuer, a Token Service Provider, and Google. The issuer integrates with a TSP, and the TSP integrates with Google to provision and manage device tokens. ([Google for Developers][2])

So you can think about the system like this:

Card Issuer -> Token Service Provider -> Google Pay -> Device

The exact information available to each participant depends on the specific payment flow and token type.

This is why saying "Google Pay stores your card number and sends it to the merchant" is an oversimplification.

Google's current documentation explicitly distinguishes between:

  • device tokens
  • card-on-file credentials
  • cloud tokens

and says these are used in different scenarios. ([Google for Developers][4])

What Happens During a Payment?

Let's simplify the process.

Suppose you've already added your card to Google Pay.

You walk into a store and tap your phone.

Conceptually:

Phone -> Device Token + Transaction Cryptogram -> Payment Terminal -> Card Network -> Card Issuer

Google's documentation notes that device-tokenized payments use a DPAN and cryptographic mechanisms, with a device-stored key used to generate transaction cryptograms for contactless transactions. ([Google for Developers][1])

The card network can then map the tokenized credential to the underlying payment account and route the transaction to the issuer.

The issuer ultimately decides whether the transaction should be approved.

Why Is This More Secure?

Imagine you have your actual card number:

4111 1111 1111 1111

and you use it directly everywhere.

Now imagine instead:

Physical Card -> Tokenization -> Token A -> Token B -> Token C

Different tokens can represent the same underlying card in different contexts.

If one token is compromised, it doesn't necessarily expose the same credential as the physical card.

That's the fundamental security idea behind tokenization.

UPI Is Different

And this is where I'd connect it back to the main topic.

UPI and card tokenization solve different problems.

With a normal UPI bank-account payment:

UPI App -> UPI Infrastructure -> Banks

The payment is based around a bank account and UPI credentials.

With a tokenized card payment:

Wallet -> Token -> Card Network -> Issuer

The payment is based around a card account, with tokenization protecting the underlying card credential.

So:

UPI
= Bank-account payment infrastructure

while:

Google Pay / Apple Pay card payments
= Card payment infrastructure + tokenization

The fact that both can be accessed from a phone can make them look similar to the user, but underneath they are fundamentally different payment systems.

The Interesting Part About Tokenization

This is actually one of the coolest ideas in modern payment infrastructure.

You don't necessarily need to protect the original secret by sending it everywhere.

Instead:

Sensitive Credential -> Tokenization -> Less-sensitive representation

The payment network can then use the token to identify the underlying account without requiring the merchant to handle the original card number in the same way.

That's a general security principle:

Don't expose the most sensitive credential when a more limited credential can do the job.

And that's why the next time you tap your phone to pay, the interesting question isn't just:

"How did the payment happen?"

It's also:

"What credential actually left my phone?"

And in a tokenized payment, the answer may be a token rather than your actual card number.

~ That's it. Thanks for reading, and I hope you enjoyed the journey behind the scenes of UPI.