API security for UPI, PSPs, and payment companies is no longer a one-time checkbox. Between the NPCI API guidelines and the RBI authentication rules, it is now a continuous, audited discipline. This guide breaks down what you must implement, and by when.
TL;DR
API security for UPI and payment companies is now driven by the NPCI UPI API Security Guidelines and the RBI authentication rules. The core requirements are rate limiting on every UPI API, separating customer-initiated from system-initiated calls, two-factor authentication with a dynamic factor from April 2026, end-to-end encryption, input and output validation, and annual CERT-In empanelled audits. Non-compliance can mean throttling, penalties, or suspension from the UPI network.
On this page
Why API security for UPI changed
As UPI grew to more than fifteen billion transactions a month, its APIs came under real strain from bots, automated scripts, and poorly configured background jobs. In response, the National Payments Corporation of India issued the UPI API Security Guidelines, and the RBI tightened authentication for all digital payments. Together they turned API security for UPI, PSPs, and payment companies from a one-time review into a continuous, governed function that runs across the whole software lifecycle: inventory, design, deployment, monitoring, and audit. For any PSP bank, acquiring bank, or UPI app provider, this is now a live obligation with hard deadlines.
The six core controls
The rules are detailed, but strong API security comes down to a recognisable set of controls that every PSP and payment company needs to have working and evidenced.
In practice that means enforcing rate limits and a transactions-per-second cap on every core API, classifying each call as customer-initiated or system-initiated and treating them differently, implementing two-factor authentication with at least one dynamic factor, encrypting data end to end with AES, TLS, and PKI, validating all input and output while keeping APIs documented, and passing an annual CERT-In empanelled audit with quarterly self-attestations. A structured VAPT programme across your APIs is usually the fastest way to prove these controls hold.
Governing API call behaviour
At the centre of the NPCI guidelines is a simple principle with strict mechanics: not all API calls are equal. Getting this classification right is the core of the discipline in day-to-day operations.
Customer-initiated calls, real actions a user takes, are prioritised, especially during peak load, but even they carry limits, such as balance-enquiry APIs restricted to a set number per customer per day and a capped number of status checks per transaction. System-initiated calls, background and automated requests, must be queued and rate-limited so they cannot overload the network, and certain list APIs are confined to non-peak hours. PSPs had to submit a formal undertaking confirming that every system-initiated API is queued and rate-limited. This behavioural governance is what keeps UPI stable at scale.
The two-factor authentication mandate
A second major change reshapes how payment flows are built. Under the RBI authentication rules, from April 2026 every domestic digital payment, including UPI, must use two authentication factors from different categories, with at least one dynamic factor unique to the transaction.
In practice a static factor like a UPI PIN or a registered device is no longer sufficient on its own, it must be paired with a dynamic factor such as a one-time password or a biometric. SMS one-time passwords are still allowed, but not as the only factor, and small-value contactless payments are exempted. For PSPs and payment companies, this means building secure two-factor flows into the API layer itself, part of a complete approach rather than a bolt-on.
Audit and evidence
The guidelines close the loop with mandatory assurance. Annual CERT-In empanelled audits of API systems are required, and PSPs file quarterly self-attestations detailing their controls, incidents, and remediation. Because the difference between a scan and a real assessment matters here, it is worth understanding how a scan differs from a penetration test, our guide on VAPT versus vulnerability scanning explains why an automated scan alone will not satisfy an audit of your UPI APIs. Strong evidence, findings tracked to closure and confirmed by retest, is what turns compliance from a claim into something you can prove.
The lean-team path to API security for UPI
Meeting all of this, rate-limit and call-governance posture, two-factor flows, encryption, ongoing API testing, and audit-ready evidence, is a heavy lift for a lean PSP or payment company without a large security function. Assembling it from separate tools and consultants is slow and hard to keep current. The efficient path is one platform that runs the testing and organises the evidence together.
Get API security for UPI right, and audit-ready.
Osto is the one-stop cybersecurity and compliance platform built for fast-moving startups and lean payment teams. Test your APIs, harden authentication and encryption, and keep audit-ready evidence, on one platform. No security team required.
Book a Demo →Frequently asked questions
What is API security for UPI?
It is the set of controls the NPCI and RBI require for UPI APIs: rate limiting, separating customer-initiated from system-initiated calls, two-factor authentication, encryption, input and output validation, and annual CERT-In empanelled audits. It applies to PSP banks, acquiring banks, and UPI app providers.
Who must comply with the NPCI UPI API guidelines?
All Payment Service Provider banks, acquiring banks, third-party app providers, and UPI app providers. PSPs were required to submit an undertaking confirming that every system-initiated API is queued and rate-limited.
What are the UPI API rate limits?
NPCI caps transactions per second and limits high-frequency APIs, for example balance-enquiry calls restricted per customer per day and a limited number of status checks per transaction, with certain list APIs confined to non-peak hours. System-initiated calls must be queued and throttled.
What is the two-factor authentication rule for UPI?
From April 2026, every domestic digital payment including UPI must use two authentication factors from different categories, with at least one dynamic factor unique to the transaction. A UPI PIN alone is not sufficient, and SMS one-time passwords cannot be the only factor.
Is a CERT-In audit required for UPI APIs?
Yes. Annual CERT-In empanelled audits of API systems are mandatory, alongside quarterly self-attestations of controls, incidents, and remediation. Reports and evidence must be kept current.
What happens if a PSP does not comply?
Non-compliance can result in throttling of APIs, financial penalties, or suspension from the UPI network. Because these guidelines are enforceable rather than advisory, API security for UPI is a business-critical obligation for any payment company.