UPI's 50 balance-checks-a-day cap: engineering your app around NPCI OC-215 in 2026

Summary. The National Payments Corporation of India (NPCI) issued its UPI API Security Guidelines, numbered OC-215/2025-26, on 21 May 2025, with enforcement from 1 August 2025. The rules put hard daily ceilings on the high-volume APIs that fintech apps lean on: 50 balance checks per user per day per app, 25 linked-account views per day, and only 3 transaction-status checks per payment, each spaced at least 90 seconds apart. AutoPay mandates now run only inside fixed windows, and every system-initiated call must be queued and rate-limited. This is not a small tuning change. UPI processed 22.72 billion transactions worth ₹28.92 lakh crore in June 2026 alone, about 757 million payments a day, and the caps exist to keep that volume from collapsing the rails. For builders, the caps break any app that polls for balances or hammers status endpoints, and non-compliance risks penalties, API throttling, or suspension of new-customer onboarding. Under the Digital Personal Data Protection Act, 2023, weak safeguards on the same flows can draw fines up to ₹250 crore. This guide covers what OC-215 limits and how to re-architect around each cap.

If your UPI integration was built to fetch a fresh balance on every screen open, or to poll a status endpoint every two seconds until a payment settles, it now breaks in production. The fix is not a bigger quota. It is an architecture that treats these calls as scarce and moves work to caching, webhooks and scheduling. Here is the whole rule set and the engineering response to each part.

The caps, in one place

OC-215 separates customer-initiated calls, which a person actively triggers, from system-initiated calls, which your backend fires on its own. The daily ceilings, drawn from NPCI's guidelines as documented in the OC-215 compliance breakdown and reporting on the August 2025 UPI rules, are the ones that reshape app design.

Each app counts independently, so a user with three UPI apps gets 50 balance checks on each, but your app only owns its own 50. The guideline's intent is blunt: every system-initiated API must be "queued and rate-limited to avoid overload." Background calls that used to be free are now the first thing to cut.

Why NPCI drew the line here

The rationale is scale. UPI's 22.72 billion transactions in June 2026 sit on top of a much larger pile of non-payment API calls, balance refreshes, account-list fetches, status polls and key fetches, many fired automatically rather than by a person. NPCI's decongestion push targets exactly that automated traffic, which added load without adding payments. The guidelines were notified on 21 May 2025 with a 31 July 2025 compliance deadline, and by 31 August 2025 every Payment Service Provider had to file an undertaking that its system-initiated APIs are queued and rate-limited. The direction is one many payment networks are moving toward: treat non-transactional API traffic as a cost to be governed, not a free convenience.

Architecture 1: cache balances, do not fetch them

A 50-per-day balance ceiling is generous for a human tapping "check balance" and impossible for an app that refreshes the balance on every home-screen render. The design change is to stop treating balance as live data.

Cache the last known balance with the timestamp of the last successful enquiry, and show it with a clear "as of" label. Refresh only on a genuine customer action, never on a screen load or a background timer. After a payment, update the cached balance from the transaction result rather than firing a fresh enquiry.

            on home_screen_open:
    show cached_balance with "as of {last_checked}"    # no API call

on user_taps_refresh:
    if balance_checks_today < 50 and now - last_checked > 60s:
        balance = upi.balance_enquiry()                 # customer-initiated
        cache(balance, now); balance_checks_today += 1
    else:
        show cached_balance, "refreshed a moment ago"    # soft-block
          

The soft-block matters. When a user hits the ceiling, show the cached figure and a friendly note rather than an error, so a legitimate person is never told the payment app is broken. The same discipline applies to the linked-account list, capped at 25 per day: fetch it once at onboarding, cache it, and refresh only when the user explicitly adds or removes an account.

Architecture 2: replace status polling with webhooks and backoff

The 3-checks-per-transaction limit, with a mandatory 90-second gap, ends the common pattern of polling a status endpoint every couple of seconds until a payment resolves. Three checks over roughly five minutes is not enough to poll your way to certainty, and that is deliberate.

Move to callbacks. Rely on the PSP's or bank's webhook to tell you when a payment settles, and treat the 3 status checks as a fallback for the rare case where the callback is late, not as the primary mechanism. When you do check, respect the interval and use exponential backoff.

            on payment_initiated:
    register_webhook(txn_id)          # primary: push, not poll
    schedule_status_check(txn_id, after=90s)

on status_check(txn_id):
    if checks[txn_id] >= 3: mark_pending_manual_review(txn_id); return
    status = upi.transaction_status(txn_id)
    checks[txn_id] += 1
    if status == "pending":
        schedule_status_check(txn_id, after=90s * (checks[txn_id] + 1))  # backoff
          

For payments still unresolved after 3 checks, route to a reconciliation job that settles against the bank's end-of-day file rather than continuing to poll. This is also better engineering: webhook-driven settlement is cheaper and lower-latency than polling ever was. The pattern mirrors the event-driven approach we describe for account aggregator integration.

Architecture 3: schedule AutoPay into the allowed windows

Recurring mandates, subscriptions, loan EMIs and utility bills, no longer execute whenever your scheduler fires. NPCI restricts AutoPay execution to fixed non-peak windows and caps each mandate at 4 attempts, one original plus 3 retries.

Your mandate scheduler has to become window-aware. Queue mandates due during a blackout and release them at the next allowed window, spread the load rather than firing every mandate at 9:31 PM, and count attempts against the 4-try ceiling so a failing mandate does not retry forever. Build the retry ladder to fit inside the allowed windows, and surface a clear failure to the user after the fourth attempt rather than silently dropping the mandate. Teams that also handle merchant-side UPI flows should read this alongside our note on UPI's 2026 transaction caps for fintech builders.

Architecture 4: separate customer calls from system calls

The deepest change in OC-215 is architectural, not numeric: your backend must distinguish customer-initiated from system-initiated API calls and govern them differently. NPCI requires per-second rate limiting on all core APIs, exponential backoff on retries, and dropping of excessive or redundant requests. It also restricts non-customer-initiated calls, fetching account lists, validating payment addresses, fetching encryption keys, auto-updating merchant lists, during peak load.

Practically, that means an internal API gateway in front of your UPI calls that tags each request with its trigger, applies a token-bucket rate limiter per user and per API, and prioritizes genuine customer actions over background jobs. Positive security is the model NPCI expects: allow only documented, in-sequence flows and block out-of-spec or out-of-sequence calls. Every UPI endpoint should have a published OpenAPI spec, and requests that deviate from it should be rejected at the gateway before they reach the rails. This is the same API-governance posture we build in API integration and modernization work.

The other regulated APIs you cannot ignore

Three more APIs carry specific rules that catch teams off guard.

The List Verified Merchants API is now limited to one call per day, must return at least 1,000 merchants in a single batch, and should run only in non-peak hours. If your app refreshes a merchant directory, switch to a daily batch sync, not on-demand lookups.

The Penny Drop API, used to validate that a bank account belongs to the person claiming it, is regulated under both NPCI rules and the DPDP Act. You must obtain explicit customer consent before the call, use a dedicated UPI ID tagged with Merchant Category Code 7413, and avoid storing or transmitting personal data outside approved boundaries.

The ValCust API, used for validation in IPO PAN checks and remittance onboarding, is flagged high-risk: moderated invocation speed, limited retries, approved flows only, and every call auditable. Treat it as a privileged path with its own logging.

Compliance is continuous, and DPDP overlaps

OC-215 is not a one-time certification. NPCI expects ongoing API discovery so no shadow or deprecated endpoints exist, published specs before any API goes live, continuous scanning, encrypted transport with masking of fields like PAN, account number and mobile, and audit trails reviewed by CERT-In empanelled assessors. Non-compliance can bring penalties, API restrictions, or suspension of new-customer onboarding.

The DPDP overlap is real and expensive. The same UPI flows carry personal and financial data, and the Digital Personal Data Protection Act, 2023 expects reasonable security safeguards, with penalties up to ₹250 crore for failing to implement them. Consent, data masking and boundary controls on APIs like Penny Drop satisfy both regimes at once, which is why our DPDP engineering playbook treats API governance and data protection as one project rather than two.

India-specific rollout posture

For an Indian fintech, the sensible sequence is to instrument first. Before changing behaviour, add per-API, per-user counters so you can see how close you already run to the 50, 25 and 3 ceilings; most teams are surprised by how much of their traffic is background refresh. Then cut the automated calls, move status handling to webhooks, and make the AutoPay scheduler window-aware. Ship the customer-versus-system tagging at the gateway last, because it is the largest change and benefits from the visibility the counters give you.

The caps also interact with the wider UPI roadmap. NPCI is layering agentic payments on top of the same rails, which we cover in our look at the Unified Agent Protocol for agentic UPI, and an app that already separates customer from system calls is far better placed for that shift. Building the governance now pays twice.

FAQ

How eCorpIT can help

eCorpIT builds and re-architects UPI and payment apps to run inside NPCI's OC-215 caps without breaking the user experience. Our senior engineering teams instrument existing integrations to find where they breach the 50, 25 and 3 ceilings, move status handling to webhooks, make AutoPay schedulers window-aware, and put a customer-versus-system API gateway in front of the rails, with DPDP-aligned consent and data handling built in. If you are building or fixing a UPI app for the 2026 rules, contact us to scope the work.

References

1. NPCI UPI API Security Guidelines (OC-215/2025-26) explained — Indusface.

1. UPI new rules from August 2025, explained — Ujjivan Small Finance Bank.

1. NPCI tightens UPI API rules to boost resilience and fraud controls — IBS Intelligence.

1. NPCI guidelines on UPI and API usage — Mondaq.

1. UPI clocks 22.72 billion transactions worth 28.92 lakh crore in June 2026 — Entrackr.

1. NPCI UPI product statistics — National Payments Corporation of India.

1. UPI transactions rise 23% to over 22 billion in June — IBEF.

1. Indian fintech enters 2026 as AI and compliance take center stage — Entrepreneur India.

1. NPCI UPI circulars — National Payments Corporation of India.

1. UPI transaction new rules: a complete guide for businesses — Pine Labs.

_Last updated: 19 July 2026._