UPI and payments for Indian apps: what product teams need to know

Why payments design matters for Indian products

For most consumer and many business apps in India, the checkout is where design, engineering and regulation meet. Users expect to pay by UPI in a few taps, card payments must follow Reserve Bank of India (RBI) rules on storage and authentication, and the business usually depends on a regulated payment aggregator to move the money. Getting the architecture right early avoids rework, failed audits and lost orders.

This guide explains the building blocks and the rules a product team should understand before integrating payments. It is a technical overview, not legal advice; your payment partner and legal adviser should confirm what applies to your business.

UPI in brief

Unified Payments Interface (UPI) is run by the National Payments Corporation of India (NPCI). NPCI describes UPI as a system that lets users add multiple bank accounts, from any participating bank, to a single UPI app, combining fund transfers and merchant payments in one place. The pilot was launched on 11 April 2016 by Dr Raghuram G. Rajan, then Governor of the RBI.

The features NPCI highlights include:

immediate money transfer through a mobile device, 24 hours a day, 365 days a year;
one app for several bank accounts;
a virtual payment address (the UPI ID), so payers do not need to share account numbers, IFSC codes or card details;
two-factor authentication;
QR-code and intent-based payments, for both person-to-person and merchant payments;
grievance redressal directly from the app.

The participants

Every UPI transaction involves several parties. NPCI lists them as the UPI app, the payer’s payment service provider (PSP), the remitter bank, the payee’s PSP, the beneficiary bank, and the users and merchants themselves. For a business accepting payments, the practical point is that you rarely connect to UPI directly. You integrate with a bank or a payment aggregator, which handles the connection to the payee PSP and settles funds to your account.

Scale

UPI is now the default for everyday digital payments in India. NPCI’s monthly statistics for September 2026 show 24,068.38 million transactions worth ₹29,37,396.67 crore, with 756 banks live on UPI.

How an app typically accepts UPI

There are three common patterns, and most apps support more than one.

Intent flow (mobile). Your app or mobile site hands the payment request to a UPI app installed on the phone. The user approves the payment in that app and returns to yours.
QR code. The checkout displays a dynamic QR code containing the amount and a reference. This suits desktop web, in-store screens and invoices.
UPI ID entry. The user types their UPI ID and approves the request in their UPI app.

Whatever the flow, the same engineering rules apply:

Never trust the client. A redirect or callback from the user’s device is not proof of payment. Confirm the final status server-to-server with your payment provider, through a signed webhook, a status API or both.
Make order creation idempotent. Network drops and repeated taps happen. Use a unique order reference so a retried request cannot create a second charge or a duplicate order.
Handle pending states. Some payments take time to resolve. Show a clear “processing” state, poll or wait for the webhook, and reconcile anything left unresolved.
Reconcile daily. Match your orders against the provider’s settlement reports and investigate any mismatch.

Payment aggregators: the RBI framework

Most online businesses accept payments through a payment aggregator (PA), which collects funds from customers on behalf of many merchants and settles them on. The RBI consolidated its rules in the Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025, issued on 15 September 2025 and effective immediately unless a provision says otherwise.

Three categories

The Directions define three types of payment aggregator:

PA-P (Physical): the acceptance device and the payment instrument are physically present in close proximity, as at a shop counter.
PA-O (Online): they are not in close proximity, as in e-commerce and in-app payments.
PA-CB (Cross Border): aggregation of cross-border payments for current account transactions through e-commerce, with inward and outward sub-categories.

What it means for merchants and builders

For most product teams, the obligations sit with the aggregator, but several shape your integration and onboarding:

Merchant due diligence. PAs must carry out customer due diligence on their merchants in line with the RBI’s KYC rules, with a simplified process for small merchants below set turnover limits. Expect to provide business documents and website or app details during onboarding.
Escrow and settlement. Non-bank PAs must hold merchants’ funds in a separate escrow account. Settlement timelines are set out in the PA-merchant agreement, which must state them transparently.
No card storage on merchant systems. Annexure 1 of the Directions states that customer card credentials shall not be stored in the database or server accessed by the merchant.
Authorised partners. Non-bank PAs need RBI authorisation and must meet a minimum net worth of ₹15 crore at application, rising to ₹25 crore by the end of the third financial year after authorisation. Check that your provider is authorised for the category you need.

Card-on-file tokenisation

Before tokenisation, many apps stored card numbers to offer “saved cards”. The RBI ended that practice.

In its September 2021 circular on card-on-file tokenisation, the RBI allowed card details to be replaced by a token that is unique to the combination of card, token requestor and merchant. Tokenising a card requires the customer’s explicit consent, validated through an additional factor of authentication (AFA) by the card issuer, and merchants must give cardholders an option to de-register a token. For tracking and reconciliation, entities may keep only limited data: the last four digits of the card number and the card issuer’s name.

The RBI’s July 2022 circular confirmed that all entities other than card issuers and card networks had to purge stored card-on-file data before 1 October 2022. For guest checkout, as an interim measure, it allowed the merchant or its PA to hold card data for at most T+4 days, or until settlement if earlier, solely for settlement.

In practice: never store full card numbers, expiry dates or CVVs in your systems. Use your PA’s tokenisation and hosted payment fields or SDK, so card data goes directly to the provider and never touches your servers or logs.

Authentication rules from April 2026

The RBI issued the Authentication Mechanisms for Digital Payment Transactions Directions on 25 September 2025, with compliance required by 1 April 2026 unless a specific direction says otherwise. According to the RBI’s press release:

the minimum remains two-factor authentication;
issuers may add risk-based checks beyond that minimum;
the framework encourages new authentication factors that use technological advances;
it does not require SMS-based OTP to be discontinued;
card issuers must validate an additional factor for non-recurring cross-border card-not-present transactions when the overseas merchant or acquirer requests it.

For app teams, the practical effect is that authentication is handled by the issuer and the payment provider. Your checkout should support whatever challenge the issuer presents, handle failures and timeouts gracefully, and avoid building custom flows that bypass the provider’s authentication.

Where payment data may be stored

The RBI’s 2018 directive on the storage of payment system data requires that the entire payment data of authorised payment systems be stored in systems located only in India. The RBI’s FAQ makes clear that this extends to service providers, intermediaries, payment gateways and third-party vendors engaged by authorised entities. Covered data includes customer details, payment credentials and transaction data. If processing takes place abroad, the data must be deleted there and brought back to India within one business day or 24 hours of processing, whichever is earlier.

If your app handles payment data itself, rather than only through your PA, choose hosting, logging, analytics and backup services with this in mind.

A build checklist for payment features

Architecture

Integrate through an RBI-authorised PA or bank appropriate to your category.
Keep card data out of your systems entirely: use hosted fields, SDKs and tokens.
Verify every payment server-side through signed webhooks or status APIs.
Make order creation and payment capture idempotent.

Operations

Reconcile orders against settlement reports every day.
Monitor success rates, failures and pending payments by payment method.
Keep payment logs free of sensitive data, and know where every log and backup is stored.

User experience

Offer intent, QR and UPI ID options suited to the device.
Show clear states for success, failure and pending, with a reference the user can quote.
Make refunds and their timelines visible.

Governance

Keep copies of your PA agreement and settlement terms.
Track RBI and NPCI circulars through your provider, and review the integration when rules change.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.