UPI India: QR, VPA and limits
1) What is UPI
Unified Payments Interface (UPI) is India's national payment bus, operated by NPCI. It provides 24/7 instant transfers between bank accounts and fintech applications (PSPs). For the user and merchant, UPI is a single layer of addressing (VPA), confirmation (2FA) and clearing, on top of which P2P and P2M scenarios are built.
Key principles:- Interoperability: any UPI application ↔ any bank/account.
- Addressing without details: VPA of the form 'name @ handle' instead of IFSC/account.
- Instantaneity and finality: translation is confirmed immediately; returns - a separate operation.
- Low costs for merchant: regulation according to MDR/schemes reduces the cost of collection.
2) Ecosystem participants
NPCI (scheme/switch): routing, rules, certification.
PSP banks and non-bank PSP (Front-End Apps): client applications (PhonePe, Google Pay, Paytm, etc.), SDK/APIs for merchants.
Acquirer/Issuer: Merchant Acquiring Bank and Payer Issuing Bank.
Merchant PSP: UPI acceptance provider for business (SDK, QR, Intent, reconciliation).
3) Identifiers: VPA and details
VPA (Virtual Payment Address) is the main UPI identifier: 'user @ psphandle' or 'merchantname @ acquirer'.
Features:- Linked to a UPI bank account/node.
- Can be personal (P2P) or merchant (P2M) with business details included.
- Supports collect request, invoices and metadata (orderId, purpose, MCC).
4) QR payments: static vs dynamic
Static QR
Contains VPA/handle merchant, sometimes fixed fields (MCC, name).
The amount is entered by the payer manually (suitable for cafes/small retail).
Pros: simplicity, printing once. Cons: risks of incorrect amount, weaker analytics.
Dynamic QR (per-order)
Generated for each check: includes amount, orderId, purpose field, optional discounts, prop tags.
The payer → scanned application opens a fixed-amount invoice.
Pros: fewer errors, easier reconciliation, loyalty and anti-corruption evidence.
Intent & Deep-Link Flow
Instead of scanning, the merchant application launches the UPI client at the deeplink/Intent URI, transferring the amount and metadata.
Convenient in e-commerce/applications, allows you to build an even UX without a camera.
5) Typical payment flows
P2P (pull/push): transfer between users via VPA/phone/QR.
P2M (push) - The buyer initiates a payment (scan/pay).
Collect Request (pull for merchant): the merchant issues a request, the buyer confirms in his UPI application.
AutoPay (e-mandate): subscription with pre-authorization of the limit and frequency, debit is initiated by mandate without manual confirmation of each operation (up to the limit).
6) UPI limits: How they work
Limits are determined by the rules of the scheme, RBI/NPCI policies, issuing banks and sometimes by the merchant category. They can vary in participants, risk profile and channel.
Main types of limits:1. Per-transaction cap: "typical" value for most retail scenarios - up to ~₹1,00,000 (1 lakh) per payment; for individual above/below categories.
2. Per-day cap: limit on the total volume/number of transactions on the payment application/bank.
3. Category limits: For certain MCCs (e.g. investment, education/medicine, tickets, utilities), elevated/separate thresholds may apply.
4. New recipients/risk timeouts: reduced one-time limits and shutter speed are possible when transferring to a new VPA for the first time.
5. UPI Lite (offline micropayments): wallet on device/bank for small offline payments; limits are lower than normal UPI and are set separately (per-txn and daily).
6. AutoPay (e-mandate): the limit on automatic debits without re-authentication is fixed in the mandate; for different categories - different thresholds.
7. Scenario/channel: intents/QR can have their own validations (anti-abuse, velocity).
7) Security and authentication
2FA: confirmation in UPI application (PIN/biometrics) + link to device/SIM slot/account.
Device binding: anti-fraud at the PSP application level.
Real-time risk policies: velocity check, sanctions/fraudulent templates, beneficial name display.
UPI Lite and offline: microlimits + delayed posting to the core to reduce risks.
8) Rates and Fees (MDR)
For UPI, the retail segment historically has minimum MDRs or zero commissions for merchants in base cases. Exceptions to categories/tools are possible (for example, UPI-linked wallets, corporate solutions, PSP add-on services). When calculating unit economics, consider:- subscription/SDK fee for UPI acquiring,
- fee for additional services (dynamic QR, reconciliation API, annotations, reports),
- support costs, disputes and returns.
9) Returns, Partial Returns and Disputes (ODR)
Chargeback is absent in the card sense. The return is a new credit transaction from the merchant to the payer, with reference to the original transaction.
Partial refund is supported (by amount).
ODR (Online Dispute Resolution): standard online claim resolution process - statuses, SLA, reason for refusal, evidence (payment log, check, bill of lading).
Timing: depends on bank/PSP; put in support regulations.
10) Merchant Integration: Options
1. Static UPI QR: minimum development; good for POS/SMB.
2. Dynamic UPI QR: server generates custom QR; Better reconciliation of amount/order.
3. Intent/Deep Link: mobile UX without camera; web checkout → Open UPI Application.
4. Collect (request-to-pay): merchant initiates an "account," the client confirms.
5. SDK/JS/Native: ready-made PSP modules for Android/iOS/web with status processing.
- Payment payload generation (VPA/amount/tags)
- Colback end point for successful/unsuccessful payment,
- reconciliation by TID/RRN/UTR,
- manual/automatic refund,
- monitoring SLA PSP/banks.
11) Reconciliation and reporting (UTR, statuses)
UTR (Unique Transaction Reference) - unique calculation identifier in bank rail; save it for all operations.
In PSP reports: initial parameters (VPA, amount, orderId), statuses (initiated, pending, success, failure), late updates, returns.
Daily auto-recon and periodic full-recon (vault with bank/PSP) are required.
12) Offline and smartphone-free availability
UPI Lite (offline micropayments): for small amounts; transactions are confirmed without a network request, posting later.
UPI 123PAY/IVR/feature-phone: payment by number/IVR menu.
Tap-and-Pay (NFC-UPI): contactless scenarios where supported.
13) Crossborder (UPI Global)
UPI is gradually integrating with foreign rails/country partnerships (e.g. scanning Indian UPI-QR by tourists or Indians abroad in partner networks). Support and limits vary by country/partner pair and issuing bank.
14) Risks, AML/KYC, compliance
KYC levels at PSP/banks affect limits.
AML/sanctions: recipient/destination filters, anomaly monitoring.
Fraud case: refunds are impossible without the consent of the merchant → strict verification of the order is required (dynamic QR, check, geo/device).
Industry legal regime: restrictions apply for individual verticals (MCC categories, licensing, geoblock in states/UTs). Plan with lawyers for local acceptance of UPI for your type of business.
15) UX design and best-practices
Error surface: clearly show the timer, instructions and how to repeat the payment.
Idempotency: 'orderId' + idempotency key for safe repeats.
Fallback: if Intent hasn't opened, suggest QR and "copy VPA/amount."
Interface limits: warn of excess and offer split checks where allowed.
Reliability: Retrays exponentially for status, webhooks + pull-API.
Transparency: check with UTR, amount, date/time, VPA merchant, support contact.
16) Integration checklist (P2M)
1. Get Merchant VPA/handle from PSP.
2. Select channel: static/dynamic QR, Intent, Collect.
3. Implement payload generation and secure sausages.
4. Enable reconciliation by UTR/OrderId (daily + full).
5. Set up returns (partial/full), logs and ODR.
6. Enter anti-fraud rules (velocity, new recipients, high-risk MCC backlight).
7. UI/UX: hints, errors, repetition, displaying limits.
8. Establish monitoring of SLA PSP/banks, alerts and reporting.
9. Conduct end-to-end tests with real UPI clients.
10. Regularly update limits/rules (by bank/category).
17) Limit card (design guidelines)
Per-txn (retail): landmark up to ~₹1,00,000.
Per-day: total daily threshold by bank/application; is set locally.
UPI Lite: Substantially lower than normal UPI (micropayments).
AutoPay (e-mandate): limit per transaction without repeated 2FA - by mandate/category.
New beneficiaries: reduced one-time limits and/or delays.
Categories with increased ceilings: depend on MCC/bank rules (example: education/medicine/tickets/investment scenarios - as agreed).
18) Comparison of QR strategies for merchant
19) What to consider iGaming/high-risk verticals
Check whether the category is valid at the PSP/bank and corresponds to the local law.
Expect reduced limits and extended KYC/ODR requirement.
Consider alternative rails for deposit/withdrawal and strict traffic segmentation.
20) Architectural notes
UPI-Gateway as a microservice:- endpoints: `createPaymentIntent`, `generateDynamicQR`, `refund`, `reconcile`, `webhook`.
- idempotency through keys and the dedupe table.
- event bus for statuses and accounting.
- observability: metrics (success/failures/latency), tracing, alerts.
- security: HMAC signatures of webhooks, allowlist IP PSP, secret rotation.
Summary for production
Bet on dynamic QR and/or Intent.
Do not hardcode limits - config + update by banks/PSP.
Include UTR reconciliation, partial returns, and ODR flow.
Cover UX with failure scenarios, replays, and transparent checks.
Review limits and category policies regularly with the PSP.