India's UPI at Scale: Infrastructure Realities for Payment Operators

India’s Unified Payments Interface processed 228.3 billion transactions worth ₹299.7 lakh crore (roughly $3.6 trillion) in 2025, up from 172.2 billion in 2024 — a 33% year-on-year volume increase (NPCI/Worldline India Digital Payments Report, 2026). In December 2025 alone, UPI logged 21.6 billion transactions — a monthly record and a rate of approximately 7,500 transactions per second sustained over a full calendar month (NPCI, December 2025). For operators building payment infrastructure that touches South Asia or the Indian diaspora globally, UPI is not a nice-to-have integration. It is the payment modality of record for over a billion people.

What that means operationally is more nuanced than the headline numbers suggest. UPI’s architecture is open but layered. Its zero-MDR policy is politically entrenched but structurally unsustainable. Its international expansion is accelerating but unevenly implemented across corridors. Each of these dimensions has direct consequences for how operators should design integrations, model unit economics, and plan compliance posture.

The Technical Stack: VPA, NPCI Switch, and the PSP Layer

UPI runs on IMPS (Immediate Payment Service) infrastructure managed by the National Payments Corporation of India (NPCI), with a real-time settlement layer built on top. The architecture has three distinct tiers:

Member banks — 675 banks participate as of mid-2025. They hold customer accounts, handle KYC, and expose APIs to the NPCI switch for credit/debit operations. Every UPI transaction ultimately debits one member bank and credits another.

The NPCI switch — the central routing and settlement engine. It receives transaction requests, resolves VPA-to-account mappings, routes credit requests to the destination bank, and confirms settlement. Average processing time is under 1.5 seconds for the NPCI leg; end-to-end transaction time depends on member bank latency.

PSPs and Third-Party Apps (TPAPs) — the interface layer that users actually interact with. PhonePe, Google Pay, Paytm, and bank-native apps all operate as TPAPs. PSPs handle VPA creation, user authentication, and API communication with the NPCI switch. Critically, TPAPs do not hold money — they are pure routing and interface layers.

Virtual Payment Addresses

The VPA (or UPI ID) is the identifier that makes UPI operationally distinct from most other instant payment systems. A VPA looks like username@bankname (e.g., merchant123@hdfc) and maps to a specific bank account via the DICT maintained by NPCI. Users can create multiple VPAs per account and can use a VPA from any TPAP regardless of which bank holds the underlying account.

For merchants, this means the QR code (or payment link) encodes a VPA, not a bank account number. From an operator integration standpoint, this provides a stable identifier that survives bank account migrations — as long as the VPA-to-account mapping is updated in NPCI’s DICT. It also means that for reconciliation, VPA is the canonical identifier, and operators must map VPAs back to their internal merchant records rather than relying on bank account numbers.

UPI Collect vs UPI Intent

UPI has two primary payment flows. Collect is a pull request: the merchant initiates a payment request to the customer’s VPA, the customer approves via their TPAP, and the debit executes. Intent (also called UPI Intent or QR-based flow) is a push: the customer scans a QR or taps a deep link, which opens their preferred TPAP pre-populated with the merchant’s VPA and amount, and the customer confirms.

For e-commerce, Intent flows dominate because they require no prior relationship between the merchant and the customer’s VPA. Collect flows are more common in invoice-based B2B contexts where the payee knows the payer’s VPA in advance. Operators building merchant integrations should default to UPI Intent/QR flows and treat Collect as a supplementary channel.

The MDR Debate: What Operators Need to Model

UPI’s zero-MDR policy — no merchant discount rate for accepting UPI payments — has been government policy since January 2020. The government provides a ₹1,500 crore ($180 million) annual incentive pool to partially compensate PSPs and banks for processing costs, but this covers only an estimated 11–14% of actual ecosystem operating costs. NPCI, PSPs, and member banks effectively cross-subsidize UPI from other revenue streams.

This is structurally unsustainable at scale, and the policy debate is no longer whether MDR should return but when and in what form. A Parliamentary Standing Committee report in early 2026 proposed a tiered approach: zero MDR for street vendors and small merchants (those below a transaction volume threshold), with a nominal MDR — likely in the 0.1–0.3% range — for large commercial merchants. The Finance Ministry issued a June 2025 clarification that “no MDR on UPI is currently planned,” but the committee’s proposal has legislative momentum.

What This Means for Operators

Any operator modeling the economics of UPI-based payment flows over a 3–5 year horizon should build in a scenario where MDR of 0.1–0.3% is applied to high-volume merchants. In the near term, UPI remains a zero-cost rail — which is structurally advantageous against card alternatives (debit typically runs 0.9–1.0% MDR in India, credit cards 1.5–2.0%). If MDR is introduced at 0.25%, UPI remains significantly cheaper than card but loses its “free” distinction.

The more immediate commercial constraint is the government incentive pool: PSPs are incentivized based on transaction count rather than value, which creates a structural bias toward smaller transactions. Operators routing high-value B2B transactions via UPI should confirm their PSP’s MDR model explicitly — some have begun charging platform fees outside the formal MDR framework to offset cross-subsidy losses.

Transaction Limits and B2B Constraints

NPCI sets UPI transaction limits that member banks can restrict further but not exceed. The standard per-transaction cap is ₹1 lakh ($1,200) for most use cases. Selected categories have higher limits:

• UPI 123Pay (IVR-based UPI for feature phones): ₹5,000
• UPI Lite (offline/low-connectivity, stored on device): ₹500 per transaction, ₹2,000 balance
• Standard UPI: ₹1 lakh per transaction
• Verified merchant categories (healthcare, education, IPOs): ₹5 lakh

For B2B operators, the ₹1 lakh cap is the primary constraint. Vendor payments, payroll, and high-value invoice settlements that exceed this threshold require either stacking multiple UPI transactions (operationally clunky, audit trail fragmentation) or using RTGS/NEFT for amounts above the UPI limit. Most operators doing meaningful B2B volume in India maintain a dual-rail approach: UPI for transactions under ₹1 lakh, NEFT/RTGS for higher amounts.

UPI’s International Expansion: The Real Operator Picture

NPCI International (NIPL) is the entity responsible for UPI’s global rollout. As of mid-2026, UPI is accepted in eight countries: Singapore, Bhutan, Nepal, Sri Lanka, Mauritius, France, UAE, and Qatar. NIPL has stated targets of 4–6 additional countries in 2025 and a goal of 20+ countries by FY29 under the Viksit Bharat 2047 framework.

The most operationally significant live deployment is UPI-PayNow (Singapore), which went live in February 2023 as a bilateral linkage between India’s NPCI switch and Singapore’s PayNow infrastructure. Indian users can send up to ₹60,000/day to Singapore PayNow accounts using a phone number or VPA, with real-time settlement and RBI-approved FX conversion. This is the only UPI cross-border corridor where the transaction initiates from an Indian bank account to a foreign bank account using UPI rails end-to-end — other markets typically support only inbound UPI payments (Indian tourists paying merchants abroad).

Cross-border UPI transaction volumes jumped from 37,060 in FY24 to 755,000+ in FY25, with 601,000 transactions in just the first four months of FY26. The growth is real, but the absolute volumes remain small compared to domestic flows — this is a corridors-in-construction story, not a mature cross-border infrastructure.

Integration Realities for Non-Indian Operators

For operators outside India wanting to accept UPI:

• Inbound only: Most non-Indian operators can accept UPI payments from Indian tourists and diaspora through PSPs like Nuvei, Stripe, or Adyen’s India integrations. The transaction flow involves a licensed payment aggregator (PA) in India as the intermediary between the operator and NPCI.
• Requires PA licensing or partnership: Direct NPCI membership is not available to foreign entities. Operators must partner with an RBI-licensed Payment Aggregator. NPCI’s approved PA list includes Razorpay, PayU, Cashfree, CCAvenue, and others.
• FX risk sits with the PA: For cross-border UPI transactions, the PA converts INR to the merchant’s settlement currency. Operators should negotiate FX spread explicitly — PA-quoted rates typically embed 0.5–1.5% spread above mid-market.
• Settlement timing: UPI settlement in India is T+1 in INR to the PA’s nodal account. Cross-border settlement to the operator’s foreign bank account adds an additional T+1–2 for international wire, making effective settlement T+2 to T+3.

Fraud Exposure and the Dispute Architecture

UPI transactions are irrevocable once confirmed — there is no chargeback mechanism equivalent to card dispute rights. RBI has established the Dispute Resolution Mechanism (DRM) through NPCI, which handles cases where the customer’s account was debited but the merchant did not receive credit (a failed transaction scenario), but this is distinct from consumer-initiated fraud disputes.

For merchant fraud (customer disputes a transaction they did actually authorize), resolution goes through the member bank’s grievance process and ultimately the RBI Banking Ombudsman. Resolution timelines can stretch to 30–90 days. This creates asymmetric risk for certain merchant categories — particularly digital goods and travel — where the product or service has been delivered before any dispute is filed.

Sardine and other behavioral fraud vendors have built UPI-specific risk models, but the fundamental exposure is social engineering: the customer authorizes a fraudulent transaction willingly. Operators accepting UPI in high-risk verticals should factor the absence of chargeback rights into their fraud provisioning models, as the financial exposure timeline is longer than equivalent card disputes.

The operators who build UPI correctly understand that they are integrating a public infrastructure with regulatory constraints, subsidy dynamics, and dispute mechanics that differ fundamentally from card rails — not just a cheaper version of instant bank transfer.