PhonePe holds 47% of UPI volume. NPCI's cap is 30%. Here's why no one can enforce it.

Three deadlines, one number that hasn’t moved

In April 2026, PhonePe processed about 1,033 crore UPI transactions and closed the month holding 47.07% of total UPI volume, according to data tracked by Inc42. Google Pay holds most of what's left. Together the two apps still account for close to four out of every five UPI transactions in the country. The number that's supposed to matter here is 30%, the ceiling the National Payments Corporation of India set as its UPI volume cap for any single third-party app provider. PhonePe alone is more than fifty percent over it.

The deadline to fix that is December 31, 2026, six months from now. It's also the third deadline. NPCI introduced the volume cap rule in November 2020, originally giving large providers until the end of 2022 to come into compliance. That date moved to the end of 2024. Then it moved again, to the end of 2026.

There's a wrinkle worth flagging before going further: PhonePe and Google Pay's combined share recently dipped below 80% for the first time, as smaller apps like BHIM, Navi, super.money, and WhatsApp Pay picked up ground, according to Outlook Business. That gets reported as the duopoly cracking.

The standard explanation for why a rule keeps slipping is regulatory capture: two large companies with a lot to lose, leaning on a quasi-public body that needs their cooperation to keep UPI running. That's probably part of it. But it's not the most interesting failure, and it doesn't explain why the underlying number has barely budged across five and a half years on the books. The more interesting failure is that the cap, as written, doesn't have a lever that can move the number it's named after.

What NPCI’s UPI volume cap actually says

The rule itself is simple to state. A third-party application provider, or TPAP in NPCI's terminology, is the category that covers PhonePe, Google Pay, and Paytm. None of them can account for more than 30% of total UPI transaction volume, measured on a rolling three-month window across the whole network. That network is enormous: RBI data put India's digital payment volumes, with UPI as the dominant contributor, past 180 billion transactions in FY25 alone.

What NPCI actually defined as the consequence of breaching that 30% line is narrower than the rule sounds. A TPAP over the cap doesn't get throttled, and its existing users don't get cut off. It has to stop onboarding new UPI users. Everyone already on the app keeps transacting exactly as before.

That distinction, freezing new accounts rather than reducing volume, is the entire story, and most coverage of this rule spends no time on it at all.

The lever doesn’t move the variable it’s supposed to control

Ask where UPI volume growth actually comes from for an app that already has hundreds of millions of registered users, and the answer isn't new sign-ups. It's existing users transacting more often: recurring autopay mandates for subscriptions and EMIs, a steadily growing base of small merchants taking UPI for the first time, bill payments, and P2P transfers scaling with India's broader shift away from cash. PhonePe and Google Pay aren't adding volume by recruiting people who don't already have a UPI app; that pool is close to saturated among the smartphone-and-bank-account population both apps already serve. They're adding volume because the average existing user does more UPI transactions per month than they did a year ago.

An onboarding freeze does nothing to that growth curve. Stop PhonePe from registering a single new phone number, and its transaction count keeps climbing anyway, because the people who already have the app are simply routing more of their financial life through it every quarter. That's mechanically why two deadline extensions have passed without PhonePe's share moving toward 30%: the rule's only defined enforcement action targets net-new accounts, and net-new accounts were never the majority driver of the number the rule is trying to cap.

Why a federated payment switch can’t meter this the way the deadline assumes

There's a second problem underneath the first, and it's architectural rather than behavioural. UPI isn't a single system NPCI runs end to end. It's a switch sitting between dozens of independent participants. A TPAP like PhonePe connects to UPI through one or more PSP (Payment Service Provider) banks, which handle settlement and compliance, while NPCI's Common Library coordinates the protocol between the TPAP's app and those banks. Every transaction routes bank to bank, with NPCI acting as the switch in the middle rather than as a central ledger holding a live running total for each TPAP.

Capping a TPAP's volume in any way more precise than “freeze onboarding” means NPCI has to aggregate that TPAP's transaction count across every PSP bank it uses, on a rolling three-month window, then trigger a specific account-level action at the app layer that sits on top of several banks at once. Nothing in the architecture NPCI documents offers a clean chokepoint for that aggregate-then-restrict action. Onboarding happens to be the one part of the flow that's a single API surface per TPAP, which is probably why it's the lever the rule landed on, not because it's effective, but because it's the part that was easy to build.

What the available levers would actually control

If NPCI wanted a lever that actually moved PhonePe and Google Pay's combined share, the realistic options are short, and each one has a gap large enough to explain why none has shipped.

The third option on that list, splitting volume across multiple legal entities, comes up often enough in industry conversation that it's worth naming directly. There's no public evidence PhonePe or Google Pay are pursuing it, and NPCI's own multi-bank PSP rules make a VPA handle unique to a single TPAP, which limits how cleanly volume could shift to a sibling entity without users actually switching apps.

The lobbying is real, and it’s aimed at a different lever entirely

In late April 2026, TechCrunch reported that Amazon, Meta (through WhatsApp Pay), CRED, MobiKwik, and Flipkart's Super.money were preparing to raise concerns directly with NPCI about PhonePe and Google Pay's dominance. The complaints, per that report and Outlook Business's coverage of the same meeting, are about user acquisition practices, product design, and access to high-value features like autopay mandates, not about the volume cap itself.

That's a tell. The companies with the most to gain from enforcement aren't asking NPCI to finally pull the onboarding-freeze trigger. They're asking for something adjacent: fairer access to the features that drive engagement on someone else's already-captured user base. NPCI's one concrete move in this direction so far came bundled with the extension announcement itself, when it lifted the user cap on WhatsApp Pay, clearing the way for Meta's app to onboard its entire existing WhatsApp base into UPI. That's the opposite kind of lever: loosening a restriction on a smaller player instead of tightening one on the larger two.

What probably happens by December 31, 2026

Nothing in the mechanism has changed since the last extension, and the underlying numbers haven't moved in the rule's favour. The lowest-friction outcome is a fourth deadline. The alternative, actually enforcing an onboarding freeze on PhonePe, punishes new users for a growth pattern that mostly isn't about new users at all, while leaving the 79% combined concentration untouched.

The version of this rule that would actually bite redefines what's being capped: existing transaction share rather than new-account growth. It also requires NPCI to build the cross-bank aggregation it doesn't have today, a multi-year infrastructure project, not a deadline. Until NPCI commits to that build, the 30% figure on the page and the 47% figure in PhonePe's transaction logs will keep moving in opposite directions.