Technology · ssh / indianDevelopers
How UPI Works Under the Hood: The Architecture Behind India’s Real-Time Payments
Understand how UPI connects apps, PSPs, banks and NPCI, with a developer-focused look at payment flow, authentication, failures and settlement.
Asha scans a QR code at Ravi’s shop, checks the amount, enters her UPI PIN, and sees a successful ₹500 payment. Ravi sees the credit on his side moments later. The experience feels like a single action: scan, authorize, done.
But the money does not live inside the app Asha opened. Asha and Ravi may use different UPI apps and bank with different institutions. The consumer interface is only one participant in a larger payment system that has to coordinate the sending side, the receiving side, authentication, interoperability, failure handling, and later inter-bank settlement.
That coordination happens at remarkable scale. NPCI’s UPI Product Statistics report 720 banks live on UPI in May 2026, with 23,201.93 million transactions worth ₹29,90,424.21 crore during that month — about 23.2 billion payments with a total value of roughly ₹29.9 lakh crore.
This article explains the architecture that can be supported by public NPCI and RBI documentation. It does not attempt to reverse-engineer NPCI’s private databases, services, message brokers, routing algorithms, cryptographic implementation, or deployment infrastructure.
UPI is not a payment app
The first useful distinction is simple:
UPI is not the same thing as the app on your phone.
NPCI describes UPI as an instant payment system developed by the National Payments Corporation of India and built over IMPS infrastructure. Its public documentation says UPI supports immediate bank-account transfers and capabilities including multiple participating accounts through an app, merchant payments, virtual payment addresses, QR- and intent-based payments, and two-factor authentication.
The Reserve Bank of India provides another useful architectural description. RBI describes UPI as an open-loop payment system: NPCI owns and operates the payment-system infrastructure, TPAPs develop end-user applications while working with PSPs connected to UPI, and payers and payees can use different apps and different banks while still transacting.
That distinction matters.
In a closed-loop platform, transactions remain inside a restricted network managed by the same platform or organization. RBI contrasts this with open-loop systems, which connect payers and payees without requiring a direct relationship between them.
A limited software analogy is email.
Your email application is not “email” itself; it is one interface into a wider interoperable system. Similarly, a UPI app is a user-facing entry point into UPI rather than the entire payment system.
The analogy stops quickly, though. Financial systems have far stricter requirements around authorization, financial state, settlement, disputes, and uncertain outcomes than ordinary messaging.
The participants behind a UPI payment
NPCI’s public UPI participant list names the UPI App, Payer PSP, Remitter Bank, Payee PSP, Beneficiary Bank, users, and merchants. RBI’s description of UPI also discusses Third Party Application Providers, or TPAPs, which develop and maintain end-user applications and collaborate with PSPs connected to the UPI system.
The payer is the person initiating the payment. The payee is the person or merchant receiving it.
The UPI app is the interface through which a user initiates or responds to UPI interactions. Some UPI applications are provided by banks; others are provided by TPAPs. Therefore, “UPI app” and “TPAP” should not be treated as universal synonyms.
The Payer PSP represents the payer-side PSP function. NPCI’s ecosystem glossary says this function can onboard a customer, create a UPI ID, create device binding used as a first authentication factor, and enable the customer to enter a UPI PIN when approval is required.
The Remitter Bank is the bank of the account holder sending the money.
The Beneficiary Bank is the bank of the account holder receiving the money.
The Payee PSP represents the receiving-side PSP function. NPCI says this function can onboard customers or merchants and allow them to receive money using an allocated UPI ID or initiate a collect request.
Finally, NPCI operates the UPI payment-system infrastructure that gives these different participants a common interoperable system through which they can transact. RBI describes NPCI as the owner and operator of that UPI infrastructure.
Conceptual participant model based on public NPCI and RBI documentation. It does not represent NPCI’s private service topology or exact message sequence.
The important point in that diagram is not the exact placement of every arrow. It is the separation of responsibilities.
The app that Asha touches, the payer-side PSP role, the bank holding Asha’s account, the bank holding Ravi’s account, beneficiary-side participants, and the common UPI infrastructure are distinct parts of the system.
What happens when Asha pays ₹500?
Return to our bakery.
Asha wants to pay Ravi ₹500. She uses a UPI app. Her account is held at Bank A. Ravi receives money into an account at Bank B.
The following is a conceptual responsibility flow, not a claim about NPCI’s exact private network hops, APIs, wire format, or internal processing order.
1. Asha identifies Ravi as the destination
Asha may scan Ravi’s QR code or use a UPI ID. NPCI publicly supports QR- and intent-based payments as well as virtual payment addresses. In a normal UPI-ID flow, Asha does not need Ravi’s account number and IFSC merely to address the payment.
That is an important abstraction: the user can work with a payment address rather than manually handling all of the recipient’s underlying bank details.
2. The app prepares the payment interaction
Asha checks the displayed recipient and amount, then chooses to proceed.
The app is responsible for presenting this interaction to her, but the app itself is not Asha’s bank account and does not become the entire payment network simply because it owns the screen.
3. Asha authorizes the transaction
NPCI defines the UPI PIN as a 4–6 digit passcode used to authorize bank transactions. Its current documentation also states that the UPI app does not store or read the user’s UPI PIN and warns users not to share it.
On the payer side, NPCI describes device binding as a first factor of authentication in the Payer PSP function. The UPI PIN can then be used when the customer must approve a financial transaction or relevant request.
The public documentation is enough to explain those roles. It is not enough to responsibly claim which private cryptographic modules, internal endpoints, encryption schemes, or message formats carry out PIN verification within every participant.
4. The payer side processes the sending side
Bank A is the Remitter Bank because it holds Asha’s sending account.
Conceptually, the payer-side participants have to establish that the transaction is authorized and that the sending side can proceed.
We deliberately stop at that level.
A responsible public architecture article should not invent an internal sequence such as:
app → REST endpoint → internal service → database lock → message queue → NPCI
unless authoritative technical documentation actually establishes that implementation.
5. UPI enables interoperable coordination
The NPCI-operated UPI system provides common payment infrastructure that allows the payer side and beneficiary side to participate in the same payment even when Asha and Ravi use different apps and different banks. RBI specifically identifies that ability as a feature of UPI’s open-loop architecture.
This is the architectural reason UPI is more interesting than a simple app-to-app transfer.
Ravi’s application does not need a custom bilateral payment relationship with Asha’s application for every possible combination of consumer app and bank.
6. The beneficiary side processes the receiving side
Bank B is the Beneficiary Bank because Ravi’s receiving account is held there.
Beneficiary-side participants process the receiving side of the transaction, allowing Ravi’s account to be credited.
Again, that is a description of responsibility — not a reconstruction of the exact order of private network messages.
7. The transaction obtains an outcome
When the transaction succeeds, user-facing systems can show the result.
But a distributed payment system also needs to represent cases where something goes wrong.
NPCI publishes explicit categories for business and technical declines and separately measures debit-reversal and pending-credit-confirmation cases. Those distinctions reveal something important about real-world distributed systems: “failure” is not one single state.
Why a UPI ID matters
A Virtual Payment Address, commonly presented to users as a UPI ID, is one of UPI’s most useful abstractions.
NPCI’s public documentation says a virtual address can be used for push and pull payments without requiring the customer to enter details such as an account number and IFSC for that flow. Its FAQ also notes that several bank accounts can be linked to the same virtual address depending on functionality offered by the PSP.
From a software-engineering perspective, the useful idea here is indirection.
The human-facing payment address is separated from the need to repeatedly expose or type the underlying banking identifiers.
That does not mean a UPI ID is literally equivalent to DNS, nor does it mean the same UPI ID is guaranteed to survive every app, PSP, or account change. NPCI’s FAQ explicitly notes that changing UPI apps may require re-registration and creation of a new VPA with the new PSP’s handle.
So the defensible architectural takeaway is narrower and more useful:
UPI provides an address abstraction over underlying payment details.
Interoperability is the architectural breakthrough
RBI’s open-loop description gets to the heart of UPI: payers and payees can use different UPI apps and accounts at different banks and still transact.
Consider what happens in a world built only from bilateral relationships. As more independent applications, financial institutions, and merchant platforms need to interact, every additional direct relationship adds integration and operational complexity.
A shared interoperable payment system reduces the need for that dense web of bilateral relationships.
This is best treated as a conceptual systems lesson rather than an exact mathematical topology.
We do not need to claim that UPI converts an N × M architecture into a precise N + M system. What the public material supports is much simpler: a common payment system allows otherwise separate apps and banks to participate in an interoperable network.
That separation also creates room for variation at the application layer. Different apps can offer different experiences while the underlying payment remains interoperable.
Authentication: device binding and the UPI PIN
UPI’s public documentation describes two-factor authentication and provides useful information about the payer-side model.
NPCI’s ecosystem glossary says the Payer PSP function can create device binding and identifies that binding as a first factor of authentication. NPCI’s FAQ also says users may need to re-register after changes involving the SIM, mobile device, or PSP application.
The second familiar element is the UPI PIN.
NPCI defines it as a 4–6 digit passcode used to authorize bank transactions. It warns users never to share the PIN, and its current FAQ states that the UPI app does not store or read it.
That produces one extremely important safety rule:
You do not enter a UPI PIN merely to receive money. Entering the UPI PIN authorizes a bank transaction that can debit your account.
Authentication controls also should not be confused with immunity from fraud.
A technically valid authorization mechanism cannot by itself stop every social-engineering attempt in which a person is tricked into approving something they did not intend.
System security and safe user behaviour address different parts of the risk.
Failure is part of the architecture
A toy payment example often looks like this:
debit payer → credit payee → return success
Real payment systems need more expressive outcomes because multiple independently operated systems and networks are involved.
NPCI’s UPI ecosystem statistics make several of those states visible.
A Business Decline (BD) is a decline caused by customer or business reasons rather than a technical reason. NPCI lists examples including an invalid PIN, incorrect beneficiary details, exceeding a per-transaction limit, exceeding the permitted number of transactions, or exceeding an amount limit.
A Technical Decline (TD) is a decline caused by technical reasons such as system unavailability or network issues on a bank or NPCI side.
NPCI also publishes a Debit Reversal Success measure. Its glossary describes cases where a customer account may be debited and the bank cannot immediately confirm the status of reversal of that debit. If reversal or credit is not processed instantly, the bank subsequently handles it under applicable RBI guidelines.
Finally, NPCI defines Deemed Approved / Pending Credit Confirmation cases as transactions where online credit confirmation has not been received from the beneficiary bank. If the beneficiary account is not credited online, the beneficiary bank subsequently processes the case under the applicable RBI guidelines.
Simplified payment-outcome concepts based on categories published by NPCI. Actual internal state transitions are not shown.
What an engineer can learn from those states
These categories demonstrate that “failed” is not one universal condition.
One request can be declined because a business rule is not satisfied.
Another can fail because a participant or network is unavailable.
In other cases, the system may need to resolve uncertainty around debit reversal or beneficiary credit confirmation.
That is a much better domain model for distributed software than pretending every operation ends instantly in a perfect binary:
SUCCESS
or:
FAILURE
But the limits of the inference matter.
These public categories do not tell us that UPI uses two-phase commit, sagas, exactly-once processing, eventual consistency, a specific retry strategy, or any particular queue or database technology.
The correct engineering lesson is about modelling uncertainty — not reverse-engineering an undocumented consistency protocol.
Instant payment and inter-bank settlement are not the same event
The word instant can create another misconception.
RBI’s published payment-systems material explains that in systems such as UPI and IMPS, funds can be credited to the beneficiary customer immediately while inter-bank settlement happens later according to predefined settlement cycles.
That distinction matters.
Asha and Ravi care about the customer-facing payment outcome: Ravi receives the credit and can see that the transaction succeeded.
The participating financial institutions also have obligations to settle with one another at the payment-system level.
Those are related parts of the same financial system, but they are not the same event.
We therefore should not explain UPI as if every underlying inter-bank settlement movement happens individually at precisely the instant that a QR payment is confirmed.
The current number and timing of settlement cycles can also change, so this article deliberately avoids hard-coding an old cycle count.
What UPI’s scale tells an engineer
The May 2026 figures — about 23.2 billion transactions across 720 live banks — give us hard evidence of scale without revealing how NPCI privately implements that scale.
From a systems-engineering perspective, infrastructure operating at that magnitude must care deeply about concerns such as capacity, availability, fault isolation, monitoring, and recovery.
Those are general engineering observations, not claims that NPCI uses a particular circuit-breaker library, distributed-tracing standard, message broker, database, or cloud provider.
Another useful lesson is organizational.
The system has to function across independently operated participants. One institution’s technology stack, deployment lifecycle, and operational constraints may differ substantially from another’s, while both still participate in a common payment ecosystem.
For anyone designing a large multi-party platform, that makes clear interfaces, bounded responsibilities, observability, and explicit failure semantics especially important.
For another Hyive systems-architecture deep dive, see Demystifying Kubernetes: An Engineer’s Deep Dive into K8s Architecture and Internal Mechanics.
UPI and IMPS are related, but they are not the same thing
NPCI explicitly says UPI is built over IMPS infrastructure.
Its FAQ also lists additional UPI benefits over IMPS, including P2P pull functionality, simplified merchant payments, a single-app experience for money transfer, and single-click two-factor authentication.
So describing UPI as merely:
“IMPS with a QR code”
misses much of what UPI adds.
A more useful mental model is that IMPS is part of UPI’s foundation, while UPI provides additional user-facing and ecosystem capabilities that make interoperable payments easier to initiate through apps, virtual addresses, merchant interactions, and collect requests.
This is also why focusing only on QR codes misses the architecture.
QR is one interaction mode.
The interesting system design is how applications, PSP roles, banks, and common UPI infrastructure participate in the payment.
Architecture lessons for software engineers
UPI’s publicly documented architecture offers several useful lessons beyond payments.
First, good abstractions remove infrastructure detail from the user’s job.
A VPA lets a payer initiate an ordinary address-based payment without repeatedly working with account number and IFSC details.
Second, interoperability can be more valuable than forcing everyone into the same product.
Asha and Ravi do not need the same application or the same bank. The common system is valuable precisely because different participants can cooperate.
Third, failure states deserve domain-level modelling.
Business Decline, Technical Decline, Debit Reversal, and Pending Credit Confirmation are not just different error messages. They represent materially different operational conditions.
Good distributed software benefits from similarly precise failure semantics.
Fourth, the user-interface layer and the system-of-record layer do not have to be the same product.
The application can focus on interaction while the financial accounts remain with participating institutions.
Finally, simplicity at the edge often depends on complexity being absorbed elsewhere.
The user sees:
scan → authorize → result
The system has to preserve interoperability, financial correctness, and useful failure behaviour across multiple independent participants.
That is an architectural lesson with value far beyond UPI.
What public documentation does not tell us
There is a temptation in technical writing to fill every blank with plausible infrastructure.
That is where otherwise useful architecture articles become unreliable.
The public NPCI and RBI material used for this article does not establish NPCI’s exact:
microservice boundaries,
programming languages,
database engines,
caches,
message brokers,
deployment platform,
cloud provider,
private API schemas,
internal routing algorithms,
retry policies,
replication model,
fraud-scoring implementation,
or transaction-consistency protocol.
We also cannot responsibly draw an “exact UPI sequence diagram” from high-level public participant definitions and pretend that it represents an internal NPCI trace.
That boundary does not make UPI less interesting.
It makes the explanation more credible.
There is still plenty to learn from what is publicly documented: the open-loop model, participant separation, virtual-address abstraction, two-factor authentication model, interoperability between apps and banks, explicit failure categories, immediate customer credit, and later inter-bank settlement.
For engineers, being precise about what is known, what is inferred, and what is unknown is itself part of good systems thinking.
Conclusion
Return once more to Asha’s ₹500 payment.
She scans Ravi’s QR code and authorizes a transaction.
Her UPI app gives her the interface, but it is not the payment system.
Her payer-side participants and Remitter Bank handle the sending side.
NPCI-operated UPI infrastructure enables interoperable coordination.
Ravi’s beneficiary-side participants and Beneficiary Bank handle the receiving side.
And the system has to represent the outcome correctly — including situations where the result is more complicated than a simple success.
That is the engineering achievement hidden behind an interaction that takes only a few taps.
UPI’s most useful architecture lesson is not a secret database choice, an undocumented message bus, or a hypothetical microservice diagram.
It is the way a common payment system allows independent applications and financial institutions to cooperate while keeping most of that complexity away from the user.
For a software engineer, that combination of abstraction, interoperability, explicit failure semantics, and clearly separated participant responsibilities is the real story under the hood.
Conversation
Comments
Sign in to join the conversation.