UPI Intent App-Launch Fallback for Mobile Checkout

UPI Intent can make mobile checkout fast because the customer chooses a compatible payer app and returns after authorizing payment. The fragile part is app navigation: an app may not be installed, an in-app browser may restrict the handoff, the operating system may show no handler, or the customer may cancel before authorization.

NPCI lists Intent and QR among UPI merchant integration modes. The checkout still owns the experience around those modes, including fallback and final verification. Source: NPCI UPI FAQ.

Treat App Launch as Navigation

Do not interpret a button tap, page blur, visibility change, or return URL as payment success. These signals only describe what happened to the browser. The payer can return after cancelling, choosing the wrong account, encountering a limit, or completing payment while confirmation is still delayed.

Use explicit customer states:

State	Customer message
Ready	“Choose a UPI app to continue”
Launch requested	“Opening your UPI app…”
Returned, unresolved	“Checking payment for this order”
Verified	“Payment verified”
Launch unavailable	“We could not open a UPI app on this device”

Only the verified state should trigger fulfilment.

Preserve One Payment Attempt

Create the order on your backend before displaying the Intent action. Store client_txn_id, expected amount, gateway order ID, creation time, and current state. When an app does not open, keep that record and offer recovery against it.

Disable repeated taps while the launch request is active, but provide a visible “Try another way” action after a short UI wait. Do not generate a new transaction ID on every tap. If the original attempt expires according to your actual payment contract, close it through the backend state machine before creating a replacement.

The Dynamic UPI QR API guide explains the server-owned order pattern.

Build a Fallback Ladder

Use a predictable order of options:

1. Let the customer choose another compatible UPI app.
2. Explain how to open the checkout in the system browser when the current container blocks the handoff.
3. Offer a cross-device QR where your checkout supports it and another device is practical.
4. Provide a safe payment-link or support path tied to the same order.
5. Allow the customer to return later using a non-secret order-status link.

Do not expose the merchant API key, webhook secret, provider credentials, or a reusable internal admin link in any fallback. Avoid instructions that ask the customer to share a UPI PIN or OTP.

Verify After the Customer Returns

When the page becomes active, show pending and ask your backend for the known order state. The backend may already have processed a signed event; otherwise it can use an authenticated status check under a bounded recovery policy.

Compare the stored reference and amount before accepting success. Do not immediately show another pay button while the first result is unknown. The payment-state page guide covers late confirmation and safe retry behavior.

Test and Measure Recovery

Test these conditions on real devices:

• Compatible app installed and payment completed
• Compatible app installed but customer cancels
• No app can handle the Intent
• App opens slowly
• Customer returns before backend confirmation
• Current in-app browser blocks external navigation
• Network drops after order creation
• Repeated taps occur before the UI updates

Measure launch requests, successful returns, verified payments, fallback selected, time to verification, and unresolved orders by device category. Do not treat app-open rate as conversion. The useful outcome is a verified payment on the original order with no increase in duplicate attempts.

Record each failed launch with a small, privacy-safe category: no compatible handler, navigation blocked, customer cancelled, page resumed unresolved, or unknown. Pair the category with checkout version and device class, not a complete user-agent fingerprint or customer identity. This tells the product team whether to improve instructions, prioritize system-browser recovery, or investigate a release defect.

Keep support wording consistent with the UI. “The app did not open” must never become “the payment failed” unless authenticated evidence says so. When support sees the same order reference and launch category, it can guide the customer without creating another attempt.