How UPI Actually Works? Is the MDR charge justifiable? Architecture, APIs, Settlement, Cost, MDR and the Economics Behind India’s Payment Network
UPI looks deceptively simple. You open Google Pay, PhonePe, BHIM or another UPI app, scan a QR code, enter an amount, authenticate the payment and see a green tick within seconds.
What the user experiences as a five-second interaction is actually a distributed financial system involving multiple applications, banks, payment switches, authentication systems, core banking systems, reconciliation engines, settlement accounts, security infrastructure and operational teams.
Government of India announced a new MDR framework for certain merchant UPI transactions in September 2026.
Under the new framework, person-to-person UPI transactions remain free regardless of value. Merchant payments up to ₹2,000 also remain free, and small merchants receiving up to ₹1 lakh per month under the P2PM category retain zero MDR. Specified P2M transactions above ₹2,000 may attract 0.4% MDR, capped at ₹300 for transactions of ₹75,000 and above. Essential sectors such as railways, fuel, telecommunications, insurance and agricultural inputs have a flat ₹5 structure, while certain capital-market transactions have a separate 0.02% rate capped at ₹300. The government estimates that roughly 96% of merchant transactions will remain unaffected.
That raises a much deeper question than simply!
Should UPI be free?
To discuss UPI pricing intelligently, we first need to understand what UPI actually is, who operates each layer, where money moves, where the technical cost occurs and how different companies in the ecosystem already make money.
What is UPI?
The first misconception to remove is the idea that UPI is Google Pay, PhonePe or BHIM. Those are applications built on top of UPI.
UPI itself is better described as an interoperability and payment orchestration layer connecting different banks and applications through a common framework.
NPCI describes UPI as a system that allows users to access accounts across participating banks through UPI applications while enabling fund routing and merchant payments. The official UPI participant structure includes UPI apps, payer PSPs, remitter banks, payee PSPs, beneficiary banks, users and merchants.
The simplest representation looks like this:
Customer
↓
UPI App / TPAP
↓
Payer PSP
↓
NPCI UPI Network
↓
Remitter Bank
↓
Beneficiary Bank
↓
Merchant / Receiver
The power of UPI comes from the fact that these participants do not need to belong to the same company. A customer using one application can pay someone using another application while both accounts sit at completely different banks.
That is interoperability. Before systems like UPI, digital payment networks tended to become fragmented around individual banks, wallets or payment products.
UPI creates a common rail underneath them.
Conceptually:
Any App
↓
Common UPI Protocol
↓
Any Participating Bank
This is why thinking about UPI as an app dramatically understates what was actually built.
The Main Participants in UPI
To understand the architecture, break the system into layers.
1. Customer or Payer
This is the person initiating the transaction. The customer may have an account with SBI, HDFC Bank, ICICI Bank or another UPI-enabled bank.
The customer does not necessarily use that bank's own application.
For example, someone may have:
Bank account:
SBI
UPI application:
Google Pay
That separation is one of UPI's most important features.
2. UPI App or TPAP
Applications such as Google Pay and PhonePe can participate as Third Party Application Providers, or TPAPs.
They provide the interface through which users perform actions such as:
- registering for UPI
- discovering accounts
- creating or using UPI IDs
- scanning QR codes
- initiating payments
- receiving payment requests
- viewing transaction states
- raising complaints
The app is therefore an important part of the experience, but in a normal bank-account UPI payment it is not simply receiving the customer's money into its own balance and then forwarding it. The bank accounts remain important.
3. PSP Bank
A Payment Service Provider bank performs another important role in the UPI ecosystem.NPCI's product documentation describes payer PSPs as member banks that can onboard customers into a UPI app and enable them to approve financial or non-financial requests. Payee PSPs can onboard customers or merchants to receive funds and resolve incoming payments.
Think of the PSP layer as part of the bridge between the application world and the banking/payment network.
A simplified flow becomes:
UPI App
↓
PSP Bank
↓
UPI Network
NPCI and the UPI Switch
At the centre of the system sits NPCI.
NPCI's UPI product booklet describes NPCI as the owner, network operator, service provider and coordinator of the UPI network.
Calling NPCI's role a “central router” is a useful simplification.
Suppose:
Payer:
SBI customer
Payee:
HDFC Bank merchant
The network needs to identify where the payment request belongs and coordinate the required participants.
Conceptually:
PhonePe / GPay
↓
PSP
↓
NPCI UPI Switch
↙ ↘
SBI HDFC
NPCI provides the interoperability layer that prevents every application from having to build a completely separate proprietary connection with every bank.
At August 2026 scale, NPCI reported 752 banks live on UPI, with approximately 24.51 billion transactions during the month worth about ₹29.82 lakh crore.
That scale matters when discussing infrastructure cost.
UPI is not operating a few million API calls on an ordinary SaaS backend. It is coordinating one of the world's largest real-time payment environments.
Remitter Bank and Beneficiary Bank
The remitter bank is the payer's bank.
The beneficiary bank is the receiver's bank.
NPCI describes the remitter bank as the institution whose customer's account gets debited and which authenticates the customer's UPI PIN. The beneficiary bank receives the credit into the beneficiary's account.
Example:
Rahul:
SBI account
Merchant:
HDFC account
Payment:
₹5,000
Simplified movement:
Rahul
↓
UPI App
↓
NPCI / participating PSP infrastructure
↓
SBI
Debit ₹5,000
HDFC
Credit ₹5,000
↓
Merchant
This is the point where another important system appears.
Core Banking Systems: Where the Actual Ledger Lives
Banks operate Core Banking Systems, often abbreviated as CBS.
A UPI switch does not replace the bank's core banking ledger.
The bank still needs to update the account.
Suppose the payer has:
Balance before payment:
₹25,000
UPI payment:
₹5,000
Balance after:
₹20,000
The financial impact eventually needs to be reflected in the bank's account ledger.
So a useful mental model is:
UPI = messaging + interoperability + orchestration
CBS = customer account ledger
This distinction becomes extremely important when analysing failures.
If an application does not receive a response, that does not automatically mean the bank failed to debit the account.
Distributed payment systems need to determine what actually happened at each participant.
What Happens When You Scan a UPI QR Code?
Now move from architecture to transaction flow.
Suppose you scan a merchant QR.
A typical high-level journey can be represented in eight stages.
- Scan QR / enter VPA
- Resolve recipient
- Confirm payment details
- Authenticate payer
- Create payment request
- Route request
- Debit and credit accounts
- Return final status
Each stage hides significant infrastructure.
Step 1: QR or VPA Capture
The app first needs a destination.
This may be provided through:
- QR code
- UPI ID
- payment intent
- collect request
- merchant integration
NPCI officially supports QR and intent-based payments alongside other UPI payment mechanisms.
A QR can carry information identifying the merchant or payee.
Dynamic merchant systems may additionally associate the payment with an order, invoice or transaction reference.
Step 2: Address and Merchant Resolution
A user does not want to send ₹50,000 to a mistyped identifier.
So UPI supports mechanisms for validating addresses and resolving relevant payment information.
NPCI's published list of UPI API families includes Validate Address, among several other transaction and account-management APIs.
From the user's perspective, this often appears as:
upi-id\@bank
↓
Merchant Name
That small interface confirmation may be backed by a network request.
UPI API Architecture
UPI framework exposes multiple request and response categories.
NPCI documentation publicly lists APIs including:
- ReqPay
- RespPay
- ReqAuth
- RespAuthDetails
- ReqTxn
- Validate Address
- Set Credentials
- Balance Enquiry
- Mandate API
- QR Validation API
- Check Transaction
- Request OTP
- List PSP
- List Account Providers
- List Keys
- List Accounts
among others.
A simplified developer-style representation might look like this:
Customer App
↓
ValidateAddress
↓
Authentication
↓
ReqPay
↓
NPCI routing
↓
Bank processing
↓
RespPay
↓
Check Transaction if required
Do not interpret this as the literal complete implementation of every UPI transaction. Actual payment protocols are considerably more detailed.
The important architectural idea is that payments are exchanged as structured financial messages between independently operated systems.
Authentication
The user then approves the transaction.
UPI provides two-factor authentication aligned with regulatory requirements, and NPCI describes the UPI PIN as part of the secure payment experience.
At a conceptual level:
User
↓
UPI App
↓
Authentication
↓
Payment authorised
Authentication deserves its own infrastructure because payment systems cannot treat a transaction request like an ordinary ecommerce button click.
Credentials, device state, cryptography, PIN handling and bank-side controls all become part of the security model.
Payment Request Creation
Once the user has chosen a recipient, entered the amount and authenticated, a payment transaction needs a unique identity.
A production-grade financial system typically tracks fields such as:
Transaction reference
payer identifier
payee identifier
amount
timestamp
merchant information
bank identifiers
transaction type
status
The network must distinguish one transaction from another even when requests are retried.
That leads to one of the most important concepts in payment engineering.
Idempotency: Why Retrying a Payment Must Not Debit Twice
Imagine this sequence:
Customer pays ₹5,000
↓
Bank successfully debits ₹5,000
↓
Network response is lost
↓
App does not receive confirmation
A badly designed system could retry the payment and debit another ₹5,000.
Financial systems cannot allow that behaviour.
A payment therefore needs reliable identifiers and duplicate-handling logic.
Conceptually:
Transaction:
TXN-ABC123
If the system later receives the same payment request again, it should be able to recognise the transaction and return the relevant state rather than producing another financial effect.
The general principle is:
messages may be retried; money must not move twice accidentally.
This is why payment infrastructure is fundamentally harder than a standard API call.
Transaction States Matter
A basic ecommerce database might use:
paid = true
Payments require more nuance.
A realistic transaction may move through states resembling:
INITIATED
AUTHENTICATED
PROCESSING
DEBITED
CREDITED
SUCCESS
And sometimes:
PENDING
FAILED
REVERSAL\_PENDING
REVERSED
Why?
Because different systems can temporarily disagree.
Example:
Payer Bank:
Debit successful
Beneficiary side:
Response delayed
App:
No final confirmation
The system cannot invent success or failure.
It needs another mechanism.
Check Transaction, Reconciliation and Reversals
NPCI lists a Check Transaction API in its public API framework.
The existence of transaction-status mechanisms illustrates a critical property of distributed payment systems: not every result arrives perfectly at the first attempt.
Networks fail.
Systems timeout.
Responses get delayed.
Banks temporarily go unavailable.
Hence payment infrastructure needs:
- status checks
- retries
- exception handling
- reconciliation
- reversals
- dispute systems
These functions are not optional extras.
They are part of what keeps a financial network trustworthy.
“Payment Successful” and “Bank Settlement” Are Different Things
One of the most important UPI concepts is the difference between:
customer-facing payment confirmation
and
interbank settlement.
The customer may see success almost instantly.
But participating banks still have financial obligations against each other across millions of transactions.
Suppose during a settlement period:
SBI customers → HDFC customers
₹100 crore
HDFC customers → SBI customers
₹80 crore
Instead of thinking about the network as physically settling every transaction one by one between banks, settlement infrastructure can calculate net positions.
In this simplified example:
SBI net payable to HDFC:
₹20 crore
NPCI's settlement documentation states that it calculates participating members' net debit or credit positions and uses settlement accounts maintained with RBI. The settlement account referenced is the member's RTGS account with RBI.
So:
Real-time user payment
≠
final interbank net settlement
They are connected, but they are not the same process.
Settlement Cycles
The settlement layer itself operates repeatedly through the day.
NPCI announced a revised framework effective November 3, 2025 in which settlement cycles 1 to 10 are used for AUTH transactions and cycles 11 and 12 separately process dispute-related settlements.
Again, this highlights why UPI cannot be analysed purely as a server receiving HTTP requests.
There is a financial-operations layer underneath the instant user experience.
Where Does UPI Actually Cost Money?
Now we can examine the economics more accurately.
The statement “UPI costs money to operate” is clearly true.
But the more useful question is:
Where does that cost occur?
There is no single cost centre.
UPI Application Layer
Consumer-facing apps require:
- product engineering
- mobile infrastructure
- account onboarding
- support operations
- fraud controls
- security teams
- backend infrastructure
- logging and observability
- transaction-history systems
- grievance management
At UPI scale, even displaying transaction histories, handling notifications and resolving support tickets represents meaningful infrastructure and personnel cost.
PSP and Bank Integration Layer
Banks and PSP infrastructure require:
- payment switches
- APIs
- networking
- routing
- participant integration
- transaction monitoring
- regulatory controls
- operational support
Banks also need to connect the payment system safely to their own core banking environments.
NPCI Network Layer
NPCI operates the network layer responsible for national-scale coordination.
Cost areas may include:
- payment switching infrastructure
- highly available systems
- capacity planning
- network operations
- security
- observability
- message processing
- participant connectivity
- resilience
- disaster recovery
- operational teams
The exact complete UPI cost stack is not publicly reducible to one published “₹X per transaction” number.
That distinction matters later when analysing MDR.
Bank Core Infrastructure
Banks maintain:
- core banking systems
- account ledgers
- integration services
- risk engines
- fraud monitoring
- reconciliation systems
- support teams
- data centres or equivalent infrastructure
- business continuity systems
Those systems exist for broader banking operations, not just UPI, so attributing their entire cost to UPI would also be misleading.
Cost allocation is a genuine accounting problem.
Security Costs
A national payment system has security requirements far beyond an ordinary consumer app.
Relevant areas include:
- encryption
- key management
- HSMs
- fraud monitoring
- threat detection
- identity and authentication systems
- audit infrastructure
- SOC operations
- compliance testing
- penetration testing
- incident response
- access controls
- disaster recovery
The network must also operate continuously.
Reliability requires redundancy.
Redundancy costs money precisely because backup systems appear “unused” until something fails.
Reconciliation and Exception Costs
Successful transactions are relatively easy.
Failures create operational cost.
Consider all the exceptions that a payment system must handle:
Debit succeeded but credit delayed
Payment status unknown
Customer reports duplicate debit
Merchant claims payment missing
Bank record does not match network record
Refund requested
Reversal pending
Dispute raised
NPCI's settlement documentation explicitly requires banks to reconcile NPCI reports with their own records and manage exceptional transactions.
That requires software plus people.
UPI's Scale Changes the Infrastructure Problem
August 2026 recorded approximately:
24.51 billion UPI transactions
worth:
₹29.82 lakh crore
across:
752 live banks.
That works out to roughly 790 million transactions per day on average.
But average traffic is not enough to design payment infrastructure.
Systems must handle peaks.
The network needs capacity for periods such as:
- festivals
- ecommerce sales
- salary days
- utility deadlines
- tax-related payment spikes
- major ticketing releases
This creates overprovisioning, redundancy and resilience requirements that do not appear when someone simply divides a monthly server bill by transaction count.
If UPI Costs Money, Why Was MDR Zero?
This is where the economics become interesting.
“Zero MDR” did not mean “zero economic cost.”
It meant the merchant was not paying a Merchant Discount Rate for those eligible bank-account UPI transactions under the regulatory structure.
The ecosystem still had operating expenses.
Government incentives helped fund part of that ecosystem.
For FY2024-25, the Union Cabinet approved a ₹1,500 crore incentive scheme for low-value BHIM-UPI person-to-merchant transactions. Eligible transactions up to ₹2,000 made to small merchants could receive a 0.15% incentive through the ecosystem.
The incentive was paid to the acquiring bank and then shared with other stakeholders such as issuer banks, PSP banks and app providers.
In other words:
Merchant:
₹0 MDR
Customer:
₹0
Infrastructure:
Still costs money
Funding:
Partly supported through incentives
and other commercial economics
So “UPI was free” was always shorthand for the user/merchant pricing experience—not a claim that technology and operations had zero cost.
The September 2026 MDR Framework
The policy changed for a limited category of merchant payments.
The government announced that:
- all P2P UPI transactions remain free irrespective of amount
- P2M payments up to ₹2,000 remain free
- qualifying small merchants under P2PM remain zero-MDR
- certain P2M payments over ₹2,000 attract 0.4%
- ₹75,000+ transactions have a ₹300 MDR cap
- essential/thin-margin sectors use a ₹5 flat MDR for relevant payments
- specified capital-market transactions attract 0.02%, capped at ₹300
- the government says roughly 96% of merchant transactions remain unaffected
- MDR is shared among ecosystem participants rather than collected as a tax by NPCI or the government
The framework also states that an amount equivalent to 5% of total MDR collections will contribute to a fund intended to promote UPI adoption among small merchants.
What Does 0.4% Mean in Rupees?
Consider ordinary eligible P2M payments:
Transaction
0.4% MDR
₹2,500
₹10
₹5,000
₹20
₹10,000
₹40
₹25,000
₹100
₹50,000
₹200
₹75,000
₹300
At ₹75,000 and above, the stated ₹300 cap applies under the announced framework.
This creates the central technical-economic question.
Does a ₹50,000 UPI payment consume ten times the infrastructure of a ₹5,000 UPI payment?
Not necessarily.
The payment still needs many of the same fundamental operations:
authenticate
route
validate
debit
credit
log
respond
reconcile
settle
A larger amount can create different financial risk exposure and potentially stronger risk-management concerns, but the raw compute, database and network cost does not mechanically increase in direct proportion to transaction value.
Therefore:
0.4% MDR should not be interpreted as a literal measurement of server cost.
It is a pricing and ecosystem-funding mechanism.
That is an important distinction.
Why Percentage-Based Pricing Exists Anyway
Financial systems have historically used ad-valorem, or percentage-of-value, pricing for many commercial payment products.
There are several reasons such models can be attractive to ecosystem participants.
They generate more revenue from higher-value commerce.
They are easy to calculate.
They allow low-ticket transactions to remain comparatively cheap.
They may help cross-subsidise lower-value transactions.
And they connect network revenue to the economic activity enabled by the payment system rather than only the number of technical messages processed.
Those are economic design arguments.
They are different from claiming:
“A ₹50,000 transaction literally costs ₹200 to process.”
Those two statements should never be confused.
Why a Flat Fee Can Also Make Technical Sense
An alternative pricing philosophy would charge approximately according to transaction-processing workload.
For example:
₹1 per successful transaction
or
₹2 per successful transaction
or tiered fixed fees
Such pricing would more closely resemble API or infrastructure economics because many of the same computational operations occur irrespective of the amount transferred.
But flat fees also create their own problem.
A ₹2 fee on a ₹20 payment equals 10%.
A ₹2 fee on a ₹50,000 payment equals 0.004%.
So purely flat pricing can disproportionately hurt very small transactions.
This is why there is no automatically perfect pricing model.
A Tiered or Hybrid Model
A third approach mixes several methods.
Conceptually:
Small payments:
₹0
Mid-range payments:
flat fee
Large payments:
capped percentage
Essential categories:
special rate
Interestingly, the 2026 framework already contains elements of this philosophy through exemptions, flat pricing for selected categories, a percentage rate for ordinary qualifying P2M payments and a ₹300 cap.
The debate therefore is not simply percentage versus flat fee.
It is about which activities should fund the ecosystem and in what proportion.
Where Does Razorpay's 2% Fit Into This?
Another common source of confusion is payment-gateway pricing.
Razorpay currently publishes a standard plan with a 2% platform fee, with GST applicable, for its payment gateway offering.
That does not mean NPCI takes 2%.
Razorpay is providing another layer of technology.
For an ecommerce website:
Customer
↓
Merchant Website
↓
Razorpay
↓
UPI / Cards / Netbanking
↓
Underlying payment networks
↓
Banks
A payment gateway can provide:
- checkout
- APIs
- webhooks
- dashboards
- transaction reporting
- reconciliation
- refunds
- multiple payment methods
- routing
- developer tooling
- merchant integrations
Razorpay's own terms describe its fee as containing payment-acceptance infrastructure and related technology services, and historically noted that UPI platform charges could represent technology fees even when regulated UPI MDR itself was zero.
This creates two conceptually separate layers:
Payment gateway economics
+
Underlying UPI rail economics
For the merchant, however, the practical question is the total cost of accepting payment, regardless of which participant receives which component.
Do UPI Apps Already Make Money Elsewhere?
Another relevant part of the discussion concerns business models.
Major payment applications can potentially generate commercial value from a broad customer relationship rather than relying only on a fee attached to every bank-account payment.
Financial apps can offer or distribute products such as:
- loans
- insurance
- investments
- merchant products
- credit
- commerce
- advertising
- financial services
That does not mean payment companies can simply sell personal UPI transaction data without restriction.
Those are two different claims.
The stronger economic argument is that UPI gives applications:
distribution, engagement and access to a large financial-services customer base.
Those can themselves be monetisable assets.
A platform that millions of users open repeatedly has commercial opportunities even when one particular action carries no direct transaction fee.
But Cross-Selling Does Not Make Infrastructure Free
The counterpoint is equally important.
A company earning money from insurance or lending does not automatically mean the payment rail has no cost.
Cross-subsidy is still subsidy.
If:
UPI operations cost money
and
insurance commissions finance them
the UPI infrastructure still has a cost.
It is simply being recovered from another product.
So the valid question is not:
“Do apps earn money elsewhere?”
The stronger question is:
“How much payment infrastructure needs to be directly funded through merchant fees after considering other revenue streams and public benefits?”
That requires more transparency around actual cost allocation and ecosystem economics.
What About the Cost of Cash?
Digital payments also need to be compared with the system they partially replace.
Cash is not economically free.
A physical-currency system requires:
- note printing
- transportation
- storage
- bank branches
- cash counters
- ATMs
- replenishment
- security
- counting
- sorting
- damaged-note processing
- reconciliation
- merchant cash handling
Digital payments can reduce some of those costs.
They can also reduce practical costs for businesses such as:
- handling till cash
- depositing physical money
- theft exposure
- manual reconciliation
- change-management problems
At the same time, digital payments create their own technology and cybersecurity costs.
So the relevant comparison is not:
UPI cost
vs
zero
but:
digital payment system cost
vs
physical cash system cost
plus the convenience, security and economic effects of each.
Data and Digital Financial Footprints
Digital payments also create information that cash normally does not.
Transaction histories can help build verifiable financial records.
The government itself cited enhanced access to credit through digital footprints as one benefit of promoting low-value UPI transactions.
That has economic value.
A merchant that previously operated mainly in cash may become easier for a lender to evaluate once digital revenue is visible.
That can expand access to formal credit.
However, transaction data also raises questions around:
- privacy
- consent
- data governance
- security
- profiling
- commercial use
Those issues belong in the overall economic calculation because digital infrastructure can produce value beyond merely transporting ₹500 from one bank to another.
P2P and P2M Are Different Categories
Another important distinction is the difference between person-to-person and person-to-merchant transactions.
Under the September 2026 framework, P2P remains free irrespective of amount.
That does not automatically convert every merchant payment into P2P merely because someone uses a UPI ID.
Merchant onboarding involves classification.
NPCI's merchant onboarding FAQ refers to merchant identifiers, Merchant Category Codes, account details and acquiring-bank configuration.
The network therefore has mechanisms for distinguishing commercial merchant participation from ordinary person-to-person transfers.
This matters because pricing rules depend on transaction classification.
Why Merchant Classification Matters
Consider two transfers:
Friend sends friend ₹5,000
versus
Customer buys ₹5,000 product
Technically both may result in one bank account being debited and another credited.
Economically they are different.
One is a personal transfer.
The other is payment acceptance by a business.
Payment policy can therefore treat them differently even when some underlying technical functions overlap.
That is exactly what the current MDR framework does.
The Real Economics of UPI
At this point the debate becomes much clearer.
There are at least five parties whose economics matter:
Customer
Merchant
UPI App / TPAP
Banks / PSPs
NPCI / payment infrastructure
There is also a sixth stakeholder:
Government / taxpayer
when subsidies or incentives are used.
Someone ultimately funds the system.
Possible models include:
merchant-funded
government-funded
cross-subsidised by financial products
bank-funded
app-funded
flat transaction pricing
percentage pricing
hybrid pricing
Zero direct merchant fee does not eliminate cost.
It changes who pays.
Is UPI MDR Technically Justified?
There are really two separate questions.
Question 1: Does UPI have meaningful ongoing operating cost?
Yes.
The architecture clearly requires substantial banking, network, security, reconciliation, support and reliability infrastructure.
The existence of explicit government incentive schemes and technical-uptime conditions also demonstrates that the payment ecosystem has ongoing operating and reliability requirements.
Question 2: Does the infrastructure cost scale directly with transaction value?
Not in the simple proportional sense implied by a percentage.
A ₹50,000 payment does not necessarily consume ten times the compute or network resources of a ₹5,000 payment.
Therefore percentage MDR is better viewed as a commercial funding formula rather than a literal cost-per-packet formula.
Whether such a formula is preferable depends on broader policy goals such as:
- adoption
- merchant affordability
- ecosystem sustainability
- infrastructure investment
- competition
- innovation
- financial inclusion
- taxpayer burden
Those are economic trade-offs, not purely engineering questions.
What Greater Transparency Could Add to the Debate
A more evidence-based public discussion would benefit from clearer answers to several questions:
What is the estimated annual operating cost of the UPI ecosystem?
How much falls on NPCI?
How much falls on issuer and acquiring banks?
How much do PSPs and TPAPs spend specifically on UPI?
How much government subsidy has historically supported the system?
What revenue does the new MDR framework realistically generate?
What portion goes to banks, applications and other participants?
How does merchant cost compare with the savings generated through lower cash handling?
How much does ecosystem scale reduce the marginal cost per transaction?
What portion of infrastructure cost is fixed versus transaction-dependent?
Without those numbers, debates easily collapse into two overly simplistic narratives:
“UPI is digital, therefore it should cost nothing.”
or
“UPI costs money, therefore any MDR is automatically justified.”
Neither conclusion follows from the architecture.
The Bigger Lesson From UPI
UPI's biggest innovation is not the QR code.
QR codes existed before UPI.
Its real achievement is interoperability.
It allows:
different apps
different banks
different merchants
different account providers
one common payment ecosystem
while making that complexity almost invisible to the consumer.
That invisibility is exactly why UPI can look “free.”
The user does not see:
switching
authentication
bank APIs
risk systems
reconciliation
settlement
fraud monitoring
core banking integration
disaster recovery
customer support
They see:
Scan
Pay
Success
Good infrastructure makes complexity disappear.
But invisible complexity is still complexity.
Final Takeaway
UPI should be viewed as a national-scale payment interoperability network, not simply as a mobile payment app.
When a user scans a QR, the transaction can involve a TPAP, PSP bank, NPCI's UPI network, remitter bank, beneficiary bank, core banking systems, authentication infrastructure, transaction-state management, reconciliation and later interbank settlement.
That system clearly carries ongoing cost.
At the same time, infrastructure cost and transaction value are not perfectly proportional.
A ₹50,000 payment does not automatically require ten times the servers, API calls or routing work of a ₹5,000 payment.
That means a percentage-based MDR should be analysed as an economic funding mechanism, not as a direct measurement of technical processing cost.
There are also broader considerations.
UPI reduces friction associated with cash, creates digital financial records, enables new financial products and gives payment companies valuable customer distribution. Government incentives have historically funded parts of the ecosystem, while payment gateways may separately charge merchants for merchant-facing technology such as checkout, APIs, dashboards, webhooks and reconciliation.
So the useful question is not:
“Should UPI cost money?”
Of course operating a payment network costs money.
The more useful questions are:
How much does it cost? Who should pay? How should that cost be divided? And should the pricing formula depend on transaction value, transaction count, merchant type or a hybrid of all three?
UPI solved one of the hardest technology problems in Indian finance: making hundreds of banks and applications behave like one interoperable payment network.
The next debate is largely an economic one:
how to fund that network without weakening the simplicity, affordability and adoption that made UPI successful in the first place.
Frequently Asked Questions About UPI Architecture and MDR
Is UPI free to operate?
No. UPI requires ongoing infrastructure, banking integrations, cybersecurity, fraud monitoring, reconciliation, settlement, customer support and high-availability systems. Zero MDR historically meant that eligible users or merchants did not directly pay the transaction fee, not that the ecosystem had zero operating cost.
Does NPCI hold the money during a UPI transaction?
No. NPCI operates the UPI network and switching layer that helps route and coordinate transactions. The actual account debit and credit are reflected in the participating banks' core banking systems.
Why can a UPI transaction show as pending?
UPI is a distributed payment system. A bank may process a debit while another response is delayed or a network request times out. Status checks, reversals and reconciliation help determine the final state.
Is MDR the same as Razorpay's payment gateway fee?
No. MDR relates to the economics of the payment-acceptance ecosystem, while a payment gateway may separately charge for merchant-facing services such as checkout, APIs, webhooks, refunds, routing, dashboards and reconciliation.
Does a higher-value UPI transaction cost proportionally more to process?
Not necessarily. Many of the same authentication, routing, debit, credit, logging, reconciliation and settlement operations are required regardless of transaction value. Percentage-based MDR is therefore better understood as a pricing and ecosystem-funding mechanism rather than a direct measurement of server cost.
