On this page · 12 sections
- What the cap is, and where it actually stands
- What actually breaks for a merchant
- Multi-PSP is an architecture decision, not a vendor decision
- The five things that make multi-PSP work
- What a routing configuration looks like
- The challenger apps are already changing the mix
- What to measure once it is live
- Sequencing the work before December
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. NPCI's rule capping any single third-party UPI application at 30% of transaction volume is currently scheduled to take effect on 31 December 2026, after NPCI pushed the deadline out by two years on 31 December 2024. The gap between the rule and reality is still wide. In May 2026 the two leading apps together held 79% of UPI volume, the first time that pair had fallen below 80% since NPCI began publishing per-application statistics, and the top three apps held 87%, down from 95.2% in January 2024. The system underneath is enormous: UPI processed 23.2 billion transactions worth ₹29.9 trillion in May 2026, averaging 737.79 million transactions a day, and it carries roughly 86% of India's digital transactions across 731 live banks and more than 839 million active users. For a merchant, the risk is not that your collections stop. It is that consumer payment behaviour gets rearranged inside a five-month window while your checkout assumes today's distribution. NPCI approved 20 new third-party application providers in 2024 alone, and newer apps have already taken measurable share: NPCI's own BHIM grew fivefold over two years to about 1%, while Navi and super.money together reached about 5.5% since launching two years ago. If your success rate, your fallback logic and your reconciliation are tuned to two apps and one payment service provider, that is the assumption to test before December.
What the cap is, and where it actually stands
NPCI introduced the rule in November 2020 to limit any single third-party application provider to 30% of total UPI transaction volume. The original deadline was 31 December 2022. It moved to 31 December 2024, and on 31 December 2024 NPCI extended it again by two years to 31 December 2026, citing operational challenges. That is the third extension.
The direction of travel is real but slow. The two leaders expanded from a combined 80% in 2021 to 86% by May 2024, then shed roughly 7 percentage points over the following two years to reach 79% in May 2026. To hit a hard 30% ceiling per app, the distribution has to change far more than that.
NPCI's approach has been to grow the challengers rather than only to throttle the incumbents. It has eased feature-parity rules so newer third-party application providers can get exclusive or early feature rollouts, granted 20 provider approvals in 2024, and invested in its own BHIM app. Several challengers are using RuPay credit cards linked to UPI, with rewards and interest-free periods, to buy volume.
A fourth extension is possible. Three have already happened, and NPCI has never enforced the cap. Plan for the behaviour change either way, because the challenger growth is happening regardless of whether the deadline holds.
What actually breaks for a merchant
The cap applies to consumer-facing third-party application providers, not to merchants. The mechanism that has been discussed for enforcement is that an app over the cap stops onboarding new customers. So the merchant-side effects are second order, and that is exactly why they get missed.
| What changes | Why it matters to your checkout | What to do about it |
|---|---|---|
| Payer app mix shifts toward newer apps | Success rates and failure codes are not uniform across apps and handles | Instrument success rate by payer handle, not just overall |
| New users land on challenger apps first | Your intent flow may be tested only against the incumbents | Test the full flow on the top five apps, including newer ones |
| More apps means more handle suffixes | Handle validation and allowlists silently reject valid VPAs | Stop hardcoding handle lists; validate server-side |
| Credit-on-UPI grows through challengers | RuPay credit card on UPI has different limits and decline behaviour | Handle credit-line decline codes distinctly from balance failures |
| Volume redistributes across PSP rails | A single acquiring PSP concentrates your downtime risk | Add a second PSP and route deliberately |
| Reward-driven app switching | Users abandon if their preferred app is not offered | Render the installed-app list dynamically rather than a fixed grid |
The two that cost the most money are the last two. A fixed three-icon app chooser and a single acquiring relationship both encode 2024's market into 2027's checkout.
Multi-PSP is an architecture decision, not a vendor decision
Adding a second payment service provider is usually described as commercial use. Treated that way, it produces two half-integrated rails and a reconciliation problem. Treated as an architecture decision, it produces a routing layer that also happens to give you use.
| Approach | What it gives you | What it costs | Fits |
|---|---|---|---|
| Single PSP | Simplest integration, one reconciliation file, one support path | Full exposure to one provider's downtime and success rate | Early-stage, low volume |
| Two PSPs, manual switch | A tested escape hatch | Switching is a deploy, so recovery takes hours | Mid-size with a stable base |
| Two PSPs, automatic routing | Failover in seconds, per-cohort success optimisation | An abstraction layer plus dual reconciliation | Anyone with meaningful UPI revenue |
| Payment orchestration platform | Routing, retries and reconciliation as a product | A third party in the critical path, plus fees | Multi-method, multi-geography |
| Direct PSP plus in-house router | Full control of routing rules and data | Real engineering ownership | High-volume marketplaces |
The decision usually turns on one number: what an hour of failed checkout costs you at peak. Multiply that by your worst provider incident in the last year and compare it against the build. The answer is rarely close for anyone doing meaningful volume.
The five things that make multi-PSP work
Most failed multi-PSP projects fail on the same details.
One internal payment identifier, many provider references. Generate your own order and attempt identifiers, and treat each provider's transaction reference as an attribute of an attempt, not as the key. Every downstream system, including refunds and support tooling, should read your identifier.
Idempotency on every write path. UPI callbacks arrive more than once, out of order, and sometimes after a timeout has already triggered a retry through the other provider. An idempotency key per attempt, enforced at the database with a unique constraint rather than in application code, is what stops a double capture.
Routing rules that are data, not code. Provider weights, cohort rules and circuit-breaker thresholds belong in configuration you can change without a deploy. During an incident the difference between a config flag and a release train is the entire value of the second provider.
Failure taxonomy normalised across providers. Each PSP returns its own decline reasons. Map them to your own taxonomy, separating payer-side failures such as insufficient balance or an expired collect request from bank or provider failures. Only the second group should trigger a reroute; retrying a payer-side failure on another rail wastes an attempt and annoys the customer.
Reconciliation before launch, not after. Two providers means two settlement files, two timing windows and two dispute processes. Build the matched, unmatched and duplicate reports before the second provider takes live traffic. Teams that defer this discover the gap during a festive peak.
What a routing configuration looks like
Keeping routing as data means a shape you can edit during an incident. The structure below is a worked illustration, not a vendor format, and the point is which decisions are externalised rather than the specific field names.
{
"version": 14,
"default_weights": { "psp_a": 70, "psp_b": 30 },
"cohort_overrides": [
{
"match": { "payer_handle_suffix": ["@newbank", "@challenger"] },
"weights": { "psp_a": 20, "psp_b": 80 },
"reason": "psp_b has better observed success on these handles"
},
{
"match": { "amount_paise_gte": 2500000 },
"weights": { "psp_a": 100, "psp_b": 0 },
"reason": "high-value attempts stay on the rail with the mature dispute process"
}
],
"circuit_breaker": {
"window_seconds": 120,
"min_attempts": 40,
"open_below_success_rate": 0.82,
"half_open_probe_share": 0.05,
"cooldown_seconds": 300
},
"reroute_on": ["RAIL_TIMEOUT", "PROVIDER_5XX", "BANK_UNAVAILABLE"],
"never_reroute_on": ["INSUFFICIENT_BALANCE", "PAYER_DECLINED", "COLLECT_EXPIRED"],
"max_attempts_per_order": 3
}
Four things in that block are the actual design decisions. The circuit breaker needs a minimum attempt count, or a quiet 2 a.m. window trips it on three failures. The half-open probe share is what lets a recovered provider earn traffic back without a human. The never_reroute_on list is the guard against burning attempts on payer-side failures. And the version number matters because you will want to correlate a success-rate change against the exact configuration that was live at the time.
Store the configuration where it is auditable. A file in version control that a service polls gives you review, history and rollback for free, which is more than most feature-flag setups provide for something that moves money.
The challenger apps are already changing the mix
The interesting number is not the incumbents' decline; it is where the volume went.
NPCI's own BHIM app grew about fivefold over two years to reach roughly 1% share, which is small in absolute terms but reflects deliberate investment by the network operator. Navi, backed by Sachin Bansal, and Flipkart's super.money together captured about 5.5% within two years of launching. WhatsApp Pay recorded sustained growth over the same period. The top three apps' combined share fell from 95.2% in January 2024 to 87% in May 2026, so roughly 8 percentage points of a 23-billion-transaction monthly market moved to challengers in about two and a half years.
NPCI is actively accelerating that. It approved 20 third-party application providers in 2024 alone, spanning fintech startups and large financial firms offering broking, lending, credit cards and investments, and it is easing feature-parity rules so newer apps can get exclusive or early feature rollouts. Several challengers lead with RuPay credit cards linked to UPI, bundling rewards and interest-free periods.
For checkout, credit-on-UPI is the part that changes engineering behaviour rather than just market share. A credit-line payment can decline for reasons that have nothing to do with the customer's bank balance, and treating those declines as generic failures produces the wrong retry, the wrong error message and a support ticket.
What to measure once it is live
Averages hide the failure. Instrument at the dimension where the change is happening.
| Metric | Cut it by | Why |
|---|---|---|
| Payment success rate | Payer app handle, PSP, bank, hour | App mix shift shows up here first |
| Time to callback | PSP, percentiles not mean | A slow rail is a failed rail at checkout |
| Decline reasons | Normalised taxonomy, PSP | Tells you whether rerouting would have helped |
| Reroute rate and reroute success | Rule, cohort | A reroute that also fails is a wasted attempt |
| Duplicate callback rate | PSP | Directly tests your idempotency |
| Unmatched settlement lines | PSP, ageing bucket | The earliest signal of reconciliation drift |
| Checkout abandonment at app selection | Device, app installed | Catches a fixed app grid excluding a user's app |
Baseline all of these now, before the app mix moves. Without a baseline you will not be able to tell a market shift from a regression in your own code.
Sequencing the work before December
| Phase | Work | Typical duration |
|---|---|---|
| 1 | Instrument success rate, decline codes and abandonment at the dimensions above | 1 to 2 weeks |
| 2 | Introduce the internal payment identifier and idempotent write paths | 2 to 3 weeks |
| 3 | Normalise the decline taxonomy and separate payer-side from rail-side failures | 1 to 2 weeks |
| 4 | Integrate the second PSP behind the routing abstraction, dark traffic only | 3 to 4 weeks |
| 5 | Build dual reconciliation and dispute handling | 2 to 3 weeks |
| 6 | Move a small live percentage, then externalise routing rules as configuration | 2 weeks |
| 7 | Load-test the failover path at festive peak volume | 1 week |
Durations are indicative for a team that already owns its checkout. The sequencing matters more than the estimate: instrumentation first, identifiers second, and the second provider only after the failure taxonomy exists, because otherwise you cannot decide what to reroute.
India-specific considerations
Three regulatory and operational threads run alongside this work.
Recurring payments sit under a separate regime. If you take subscriptions or instalments over UPI, the e-mandate rules govern the notification and debit flow independently of which app the customer uses, and the engineering steps are set out in our RBI e-mandate directions engineering checklist.
API limits are a real constraint at peak. UPI's per-endpoint rate limits shape how aggressively you can poll for status and how retries should back off; the architecture implications are covered in our note on UPI and NPCI API rate limits, and the commercial view for brands is in what the UPI shake-up means for D2C merchants.
Payment telemetry is personal data. Payer handles, device signals and cohort attributes used for routing are personal data under the Digital Personal Data Protection Act 2023, so a routing layer that stores payer identifiers needs a retention rule and a purpose limitation from day one, not retrofitted later. The engineering controls are in our DPDP Act engineering playbook for Indian startups.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based technology consultancy founded in 2021, CMMI Level 5 assessed, MSME certified and ISO 27001:2022 certified, with senior-led engineering teams building fintech, ecommerce and marketplace products for Indian and global businesses. On this problem we do the unglamorous parts properly: instrumenting success rate and decline codes at the payer-handle level so you have a baseline, introducing internal payment identifiers and database-enforced idempotency, normalising decline taxonomies across providers, and building the dual reconciliation reports before a second rail takes live traffic. We design payment systems aligned with NPCI and RBI requirements and with Digital Personal Data Protection Act 2023 obligations, and we work as an extension of your team rather than a replacement for it. Typical engagements start with a two-week checkout and reconciliation audit, then move into a phased build. If you want your UPI checkout assessed before the December window, talk to our team, or read more about our fintech and payments app development work.
References
- Outlook Business, PhonePe, Google Pay combined UPI market share drops below 80% for first time, 17 June 2026.
- MediaNama, NPCI extends UPI market share cap deadline to 2026, January 2025.
- Business Today, NPCI extends 30% UPI market share cap deadline on third-party apps to December 2026, 31 December 2024.
- Inc42, NPCI extends deadline for 30% market cap on UPI apps till 2026, accessed 6 August 2026.
- ANI, UPI hits new high in May 2026 with 23.2 billion transactions worth Rs 29.9 trillion, NPCI data shows, 2 June 2026.
- Press Information Bureau, UPI completes 10 years, emerges as world's largest real-time payments platform, accessed 6 August 2026.
- The Print, NPCI extends market cap deadline for UPI apps for another two years till 2026, accessed 6 August 2026.
- Drishti IAS, NPCI extends market cap deadline for UPI apps, accessed 6 August 2026.
- India TV, UPI market cap deadline extended to 2026: NPCI, 2 January 2025.
- Yahoo Finance, India extends UPI market share cap deadline, accessed 6 August 2026.
- Business Standard, PhonePe clocks record 8.1 bn UPI transactions in January, shows NPCI data, accessed 6 August 2026.
- The Startup Spectrum, NPCI extends deadline for 30% market cap on UPI app providers to December 2026, accessed 6 August 2026.
Last updated: 6 August 2026.
