,

UPI Payment: What It Is and How to Accept It via API

·

UPI is India’s real-time bank-to-bank payment system, used for most digital transactions in the country. Here’s what UPI is, how the Collect, Intent, and QR flows work, and what integrating it actually requires.

UPI processed 24.51 billion transactions worth ₹29.82 trillion in August 2026 alone, up 22% year-on-year, with 791 million transactions running through it on an average day (Business Standard, Sept 2026). If your product touches India, UPI payment support isn’t optional. Here’s what UPI is, how it actually works under the hood, and what accepting it requires from your stack.

What is UPI?

UPI (Unified Payments Interface) is a real-time payment system built by the National Payments Corporation of India (NPCI) that moves money directly between bank accounts. Instead of a card number, a UPI transaction routes through a virtual payment address (VPA), a human-readable identifier like name@bank that maps to the customer’s linked account. There’s no card network in the flow, no card PAN data to secure, and settlement is typically instant rather than batched.

The scale is the reason this matters outside India too. India accounts for roughly 49% of global real-time payment volume, close to one in every two instant payments worldwide (CoinLaw, 2026). NPCI and the Indian government are targeting 1 billion UPI transactions per day by FY2026-27, which would put annual volume at roughly 300-350 billion transactions at current growth rates.

How UPI payments work

A customer links a bank account to a UPI app (Google Pay, PhonePe, Paytm, or their bank’s own app) and gets a VPA. To pay, they authorize a transfer using that VPA, and the underlying bank-to-bank movement happens in real time over NPCI’s rails, no separate settlement batch, no card authorization hold.

Three apps dominate the buyer-facing side: PhonePe and Google Pay together handle roughly 87.93% of UPI transaction volume, with PhonePe alone at about 10.48 billion transactions and Google Pay at 7.41 billion (Oxigen Wallet, 2026). That concentration matters for integration testing. Your checkout flow needs to work cleanly across a small number of dominant apps, not a long tail of niche ones.

UPI started as a domestic Indian rail, but it isn’t anymore. As of 2026, UPI is live in nine countries through bilateral link-ups run by NPCI International Payments Ltd (NIPL): India, Singapore, UAE, Bhutan, Nepal, Sri Lanka, France, Mauritius, Qatar, and Cambodia (Vajiram & Ravi, 2026). In Singapore, that link-up runs through PayNow; in the UAE, through Mashreq Bank’s NeoPay/AANI network; in France, through the Lyra network. The underlying transaction is still Indian-bank-account-to-recipient, but the acceptance surface now extends beyond India’s borders.

UPI payment flows: Collect, Intent, and QR

UPI isn’t one API flow, it’s three, and they have different latency and failure characteristics:

  • Collect: your server sends a payment request to the payer’s UPI app. The customer sees the request, reviews the amount, and approves or declines it from their app. This is server-initiated and works well for scheduled or recurring-style requests where the payer isn’t actively in your checkout.
  • Intent: a deep link opens the customer’s UPI app directly with the amount pre-filled, and they approve from there. This is client-side and requires handling app-specific URI schemes, since each UPI app registers its own deep-link handler.
  • QR: a scannable code encodes the payment details. Common at in-person checkout and on some web flows where a customer scans with their phone’s UPI app instead of tapping through a redirect.

Each flow has a distinct request/response shape, its own timeout behavior, and its own status-polling pattern. Treating them as interchangeable options on the same API call is the most common mistake in a first UPI integration (Cashfree, 2026, cross-referenced against PayU, Paytm, and Pine Labs UPI documentation).

Why UPI matters for businesses selling into India

As of May 2025, UPI’s transaction value in India ran at roughly 12 times the combined value of all card transactions (PaymentsJournal). “We’ll support cards in India” is not a strategy that reaches most Indian customers. If cards are your only accepted method in that market, you’re building for a small slice of the payment volume that’s actually happening there.

The good news for teams outside India: you don’t need an Indian legal entity to accept UPI payments. Under the RBI’s Payment Aggregator-Cross Border (PA-CB) framework, consolidated in the RBI Regulation of Payment Aggregators Directions, 2025, an RBI-licensed cross-border payment aggregator can onboard foreign merchants directly and settle offshore (Eximpe, 2026). That’s different from operating as a PSP or Third-Party Application Provider (TPAP) yourself, connecting directly to NPCI, which does require an Indian entity and a sponsor bank relationship. Most businesses accepting UPI payments only need the former.

UPI vs. cards, wallets, and net banking

UPI’s account-to-account model changes more than just the checkout button. The key differences from card payments sit in three areas:

Dimension UPI Card payments
Routing Account-to-account via VPA Card network (Visa/Mastercard)
Card data No card PAN Card PAN required
PCI DSS scope No scope implication Scope applies
Settlement Real-time; no batch cycle Batched (T+1 or T+2 typically)

Transaction limits are also a live variable, not a fixed constant. NPCI’s standard per-transaction cap is ₹1 lakh (100,000 rupees) for most person-to-merchant payments. Effective September 15, 2026, select high-value categories, insurance, investments, education, travel, and government payments, were raised to a ₹5 lakh per-transaction cap, with up to ₹10 lakh allowed daily for those categories (The United Indian, 2026). Individual banks and UPI apps can still enforce limits below the NPCI ceiling, so treat the published cap as a maximum, not a guarantee.

Integrating UPI: technical requirements and payment flow

Accepting UPI requires a connection to a PSP, gateway, or aggregator that already holds NPCI certification as a PSP or TPAP, since building that certification yourself means the Indian-entity and sponsor-bank path described above. From there, a working integration needs to:

  • Support all three flows (Collect, Intent, QR), since your merchant base or checkout context will need different ones depending on whether the customer is on mobile web, in an app, or at an in-person terminal.
  • Validate VPAs before submitting a payment request, since a malformed or nonexistent VPA fails at the bank level, not gracefully in your application.
  • Poll or listen for asynchronous status updates. A UPI Collect request isn’t a synchronous approve/decline the way a card authorization often reads, it waits on the customer to act on their end.
  • Handle per-app quirks. CIMB-style bank-level requirements exist in other bank-redirect rails, and UPI apps have their own version of this: deep-link handling, timeout windows, and error message formats aren’t fully standardized across PhonePe, Google Pay, and Paytm even though they sit on the same underlying rail.

Integration challenges developers hit in practice

Every top-ranking UPI integration guide (Cashfree, Razorpay, PayU, Paytm) documents Collect, Intent, and QR from inside that specific PSP’s own API surface. The underlying UPI protocol is the same rail regardless of which PSP you go through, but the request shapes, webhook formats, and status-polling patterns those guides describe aren’t portable between providers. Build against one PSP’s UPI implementation, and you’ve built something that doesn’t move if you switch providers later.

NPCI’s rule changes compound this. The September 2026 category-specific limit increase described above is a live example: a hardcoded limit check written before that change would silently reject legitimate high-value transactions in the newly-raised categories, the kind of rail-specific rule drift that a direct, single-PSP integration absorbs one change at a time, with no upstream layer catching it for you.

And if you’ve already integrated card processing, wallets, or other local payment methods through one or more PSPs elsewhere, adding UPI usually means a fourth or fifth parallel, PSP-specific build rather than an extension of what you already have. Each rail you add this way multiplies the surface area you maintain: separate webhook formats, separate error handling, separate credentials to rotate.

Accepting UPI through a payment orchestration platform

UPI is one of the payment methods already connected in Orchestra’s network, so adding it doesn’t mean starting a standalone integration project. It’s one more provider routed through the same payment library and API you’re already using for other rails, and new PSP or payment-method connections are added to Orchestra’s network at no additional cost.

That matters most if you’re not adding UPI in isolation. A business selling into multiple markets is usually looking at the infrastructure cost of supporting each local rail separately, and the maintenance burden of running several PSP-specific integrations in parallel is exactly what compounds as you add UPI, then the next market’s dominant local method, then the one after that. Orchestra’s model is built to add a new connection without a multi-week integration project for each one, and cross-border settlement questions that come up alongside a UPI rollout are covered separately in our cross-border payments FAQ.

To be direct about what this does and doesn’t mean: Orchestra doesn’t operate as a UPI PSP or TPAP itself, and this isn’t a claim that Orchestra is NPCI-certified. It routes UPI transactions to the PSPs in its network that hold that certification, the same pattern used for other local, certification-gated rails. The value is in not building and maintaining that connection yourself, not in Orchestra replacing the licensed party in the chain.

Frequently Asked Questions

What does UPI stand for?

UPI stands for Unified Payments Interface, a real-time payment system built by the National Payments Corporation of India (NPCI) that lets users move money directly between bank accounts using a mobile app.

Is UPI only available in India?

UPI originated as India’s domestic bank-to-bank payment rail and still requires an Indian bank account on the sending side. As of 2026, NPCI has extended UPI acceptance to nine countries through bilateral link-ups: India, Singapore, UAE, Bhutan, Nepal, Sri Lanka, France, Mauritius, and Qatar and Cambodia. The core transaction volume, though, is still domestic Indian payments.

How is UPI different from a card payment?

UPI moves funds directly between bank accounts in real time using a virtual payment address (VPA) instead of a card number. There’s no card network involved, no card PAN data to secure, and settlement is typically instant rather than running through a card-style batch cycle.

What are the UPI transaction limits?

NPCI’s standard per-transaction cap is ₹1 lakh (100,000 rupees) for most person-to-merchant UPI payments. Effective September 15, 2026, select high-value categories, insurance, investments, education, travel, and government payments, were raised to a ₹5 lakh per-transaction cap, with up to ₹10 lakh allowed daily for those categories. Individual banks and apps can still enforce limits below the NPCI ceiling.

What’s the difference between UPI Collect, Intent, and QR?

Collect sends a payment request to the payer’s UPI app for approval. Intent deep-links directly into a UPI app with the amount pre-filled, used for app-to-app checkout. QR displays a scannable code encoding the payment details, common at in-person checkout and some online flows. Each is a distinct API flow with its own request shape and timing, not interchangeable options on the same request.

Do foreign merchants need an Indian entity to accept UPI?

Not to accept payments. Under the RBI’s Payment Aggregator-Cross Border (PA-CB) framework, an RBI-licensed cross-border payment aggregator can onboard foreign merchants and settle offshore without the merchant setting up an Indian entity. Operating as a PSP or Third-Party Application Provider (TPAP) yourself, connecting directly to NPCI, is a different case and does typically require an Indian entity and an NPCI-approved sponsor bank.

How do I add UPI to a checkout that already supports other payment methods?

Through a PSP or orchestration platform that already holds NPCI PSP/TPAP certification and routes UPI transactions on your behalf, rather than pursuing that certification and building the Collect, Intent, and QR flows yourself. That keeps UPI as one more connected provider in your existing setup instead of a separate, parallel integration.

More recent articles