UPI Native Intent Integration Guide for Merchants (2026)

Your checkout is losing customers the moment it asks them to type a UPI ID. That single friction point, a manual VPA entry field, is enough to push buyers away from an otherwise smooth purchase.

UPI Native Intent Integration eliminates that entirely, launching the customer’s preferred UPI app directly from your checkout with all payment details pre-filled.

And with NPCI formally deprecating the UPI Collect flow as of February 2026, this is no longer just an optimization. It is a compliance requirement.

Why UPI Native Intent Integration Matters Right Now

NPCI’s guidelines, effective February 2026, restrict manual VPA entry on mobile devices, making Intent compliance mandatory for mobile apps. If you are still running a Collect-based flow, your mobile checkout is already non-compliant.

The performance gap between the two flows is significant. Intent flows deliver 10-15% higher success rates, benchmarking 92-95%, by eliminating typing errors and notification latency.

The volume context makes this even more urgent. In August 2025, UPI processed over 20 billion transactions worth more than ₹24.85 lakh crore, reinforcing its role as India’s primary digital payment system.

According to NPCI data reported by Inc42, UPI processed transactions worth 299.76 Lakh Crore Indian Rupees in 2025, with person-to-merchant payments now representing the dominant share of transaction volume. Merchants who have not completed UPI Native Intent Integration are leaving conversion on the table at scale.

How UPI Native Intent Integration Actually Works

Before walking through the steps, it helps to understand the mechanics.

UPI Intent works by packaging payment details into a deep-link URI. Your app or web checkout constructs this URI with parameters like merchant VPA, amount, transaction reference, and currency.

That URI is then handed off to the operating system, which launches the user’s installed UPI app with every field already populated. The user only needs to enter their PIN.

There are two intent types:

• Specific Intent targets a known app directly. For example, routing to Google Pay using its package name com.google.android.apps.nbu.paisa.user. This gives you a more controlled experience but requires the user to have that specific app installed.
• Generic Intent presents an app picker showing all UPI-capable apps installed on the device. NPCI mandates that merchants support the generic intent in all cases, even if they also offer specific app options.

Step-by-Step UPI Native Intent Integration for Merchants

Step 1: Get Your Merchant Credentials in Order

Before writing a single line of code, you need your payment infrastructure confirmed.

You will need a registered merchant VPA (Virtual Payment Address) issued by your bank or payment service provider. This is the pa parameter in your intent URI. Alongside that, collect your merchant name, merchant category code (MCC), and the S2S callback URL where your payment processor will send transaction status notifications.

If you are onboarding with a payment aggregator like Razorpay, PayU, or Paytm, they issue a Merchant Key and Salt during onboarding. These are used to generate the checksum hash for API requests. Keep these server-side and never expose them in client code.

Step 2: Construct the UPI Intent URI

The URI structure is standardized by NPCI. Here is what a correctly formed UPI intent URI looks like:

upi://pay?pa=merchant@bank&pn=MerchantName&mc=1234&tr=TXN12345&tn=Order%20Payment&am=500.00&cu=INR

The parameters that matter:

Every transaction must use a unique tr value. Reusing transaction IDs causes reconciliation failures and can result in duplicate payment issues on the user side.

Step 3: Implement the Android Integration

Android handles UPI native intent integration through the standard Intent.ACTION_VIEW mechanism.

Declare UPI app queries in your AndroidManifest.xml (required for Android 11 and above):

<queries>

  <intent>

    <action android:name=”android.intent.action.VIEW” />

    <data android:scheme=”upi” />

  </intent>

</queries>

For a specific intent (targeting Google Pay as an example):

String GPAY_PACKAGE = “com.google.android.apps.nbu.paisa.user”;

Uri uri = new Uri.Builder()

  .scheme(“upi”)

  .authority(“pay”)

  .appendQueryParameter(“pa”, “merchant@bank”)

  .appendQueryParameter(“pn”, “Your Business Name”)

  .appendQueryParameter(“mc”, “5411”)

  .appendQueryParameter(“tr”, “TXN_UNIQUE_ID”)

  .appendQueryParameter(“am”, “500.00”)

  .appendQueryParameter(“cu”, “INR”)

  .build();

Intent intent = new Intent(Intent.ACTION_VIEW);

intent.setData(uri);

intent.setPackage(GPAY_PACKAGE);

startActivityForResult(intent, REQUEST_CODE);

For a generic intent (shows all installed UPI apps):

Intent genericIntent = new Intent(Intent.ACTION_VIEW);

genericIntent.setData(uri);

Intent chooser = Intent.createChooser(genericIntent, “Pay with”);

startActivityForResult(chooser, REQUEST_CODE);

You must implement the generic intent alongside any specific app integrations. NPCI requires it.

Step 4: Implement the iOS Integration

iOS requires upfront URL scheme declarations before you can open any UPI app.

Add to your Info.plist:

<key>LSApplicationQueriesSchemes</key>

<array>

  <string>upi</string>

  <string>phonepe</string>

  <string>tez</string>

  <string>paytm</string>

  <string>bhim</string>

  <string>amazonpay</string>

</array>

Without this declaration, canOpenURL will return false for all UPI apps and your intent launch will silently fail.

Launching the intent on iOS:

if let url = URL(string: “upi://pay?pa=merchant@bank&pn=YourBusiness&mc=5411&tr=TXN123&am=500.00&cu=INR”) {

  if UIApplication.shared.canOpenURL(url) {

    UIApplication.shared.open(url)

  } else {

    // Fallback: show QR code or alternate payment option

  }

}

iOS does not support a native app picker the way Android does. If no UPI app handles the scheme, you need a fallback. A dynamic QR code is the cleanest option and keeps the transaction within your native checkout.

Step 5: Handle the Server-to-Server Callback

This is where most merchants make mistakes that cost them reconciliation headaches.

When the user completes payment in their UPI app, the PSP app returns control to your app with a response. On Android, this comes through onActivityResult. But this response is not your final confirmation. The user’s device response can be spoofed or incomplete.

Always verify payment status server-side. Your backend must call the Transaction Status API provided by your payment processor using the original transaction ID. Only treat a payment as confirmed after receiving a server-side status of SUCCESS.

The S2S callback from your processor will arrive at the URL you registered during onboarding. Your server should:

1. Validate the checksum hash on the incoming notification
2. Match the Order ID and Amount against your database records
3. Update the order status only after validation passes
4. Return a 200 response to the processor to acknowledge receipt

Skipping server-side validation and trusting only the app callback is a fraud vector. Do not skip it.

Step 6: Build a Fallback Flow

Not every user has a UPI app installed. Not every device will respond to an intent correctly. You need fallbacks.

The standard fallback hierarchy looks like this:

• Mobile (UPI app installed): Native intent launches directly
• Mobile (no UPI app): Deep link to Play Store or App Store for a specific PSP
• Desktop or web checkout: Display a dynamic QR code

For web-based checkouts, Chrome on Android supports intent-based deep links using the Chrome intent scheme:

intent://upi/pay?pa=merchant@bank&am=500.00&cu=INR#Intent;scheme=upi;package=com.google.android.apps.nbu.paisa.user;S.browser_fallback_url=https://play.google.com/store/apps/details?id=…;end;

This launches the app if installed, and redirects to the Play Store if not, without breaking the checkout flow.

Step 7: Test Before Going Live

Testing UPI Native Intent Integration requires real PSP apps on physical devices. Emulators do not have UPI apps installed and will not give you accurate results.

Run through these scenarios before launch:

• Successful payment via specific intent (Google Pay, PhonePe)
• Successful payment via generic intent (user picks app from chooser)
• Payment cancellation (user dismisses the UPI app)
• Network timeout during payment
• App not installed on device (fallback trigger)
• Duplicate transaction attempt (same tr value)

Verify each scenario produces the correct order status in your backend. Cancellations and timeouts should not mark orders as failed until you confirm the status via the Transaction Status API.

Common Integration Errors to Fix Before Launch

• Hardcoding the transaction ID. Every transaction must have a unique tr value. Using a fixed ID causes payment failures and breaks reconciliation entirely.
• Skipping the generic intent. NPCI requires it. Specific app integrations alone are not sufficient for compliance.
• Missing <queries> declaration on Android 11+. Without it, your app cannot detect installed UPI apps and the intent launch silently fails.
• Trusting the client-side callback as final. The response from onActivityResult is not authoritative. Server-side confirmation via the Transaction Status API is mandatory.
• No fallback for web or desktop users. A native intent launched from a desktop browser goes nowhere. Always detect the device context and serve a QR code on non-mobile sessions.

What Happens After Integration

Once Integration is live, you can start using UPI intent for mobile checkouts. However, ongoing monitoring matters more than most merchants expect.

Track your transaction success rate by intent type separately, specific versus generic. If one PSP app shows a higher failure rate, that is a signal to investigate whether the package name, URI parameters, or callback handling needs adjustment.

Watch your refund rate closely in the first 30 days post-launch. A spike in refunds often points to an amount mismatch between what the user saw and what was charged, usually caused by a misconfigured am parameter or incorrect currency handling.

For merchants processing higher volumes, payment infrastructure and dispute management become increasingly interconnected. 

Understanding low-risk vs high-risk payment processing also becomes relevant as you scale, particularly if you operate across digital goods categories where UPI transaction disputes carry a different risk profile than standard retail.

Work with Specialists Who Understand Payment Infrastructure

UPI Native Intent Integration is a technical step, but it sits within a broader payment infrastructure that needs to be solid, especially if you operate at scale or across high-risk merchant categories.

Setting up the right merchant account structure, managing dispute risk, and staying compliant with NPCI and card network rules all connect back to how your payment stack is built.

At EMS Global, we work with merchants to build payment setups that account for compliance, conversion, and dispute risk from day one. If you are scaling your UPI infrastructure or need guidance on your overall payment account structure, speak with our team.

FAQs

• What is UPI Native Intent Integration?

It is a method where your app or web checkout constructs a UPI deep-link URI and hands it off to the operating system, which launches the user’s preferred UPI app with payment details pre-filled. The user only confirms with their PIN.

• Is UPI Collect still supported?

NPCI deprecated UPI Collect effective February 2026. It is no longer compliant for mobile transactions. Merchants still running Collect flows should migrate to Intent immediately.

• Does UPI Native Intent Integration work on iOS?

Yes, but it requires LSApplicationQueriesSchemes declared in Info.plist and a fallback for cases where no UPI app is installed. The experience is less seamless than Android due to the lack of a native app picker.

• What is the difference between specific and generic intent?

Specific intent targets a named UPI app by package name. Generic intent lets the OS present all installed UPI-capable apps to the user. NPCI mandates that merchants support generic intent regardless of whether they also integrate specific app flows.

• How do I confirm payment status securely?

Always use your payment processor’s Transaction Status API from your backend after receiving the app callback. Do not treat the client-side response as final.