NV-002
Android only
Navi — With transaction note
No tn set, so this is the same payload as the plain control.
Why
Profile P02 is defined by tn, and neither your UPI profile nor this run supplies one — so comparing P02 against P01 would be comparing a method against itself and reading the noise as a finding. Set tn on the profile first, or run P01 and know what you measured.
pa — A payment needs a payee address. Nothing can be launched without pa.
Addressing one named app from a browser needs an Android intent URI, and you are not on Android. There is no iOS equivalent for this app.
What would unblock it
Open the lab on an Android phone, or use the Generic UPI (GN) group here.
Parameters
pa
tr
LAB4QHW3V999KEV
am
2.00
cu
INR
Advanced details
- Launch
- Scheme
- intent:// (Android only)
- Profile
- P02 — P01 + tn
- Platform
- Android
- Browser
- Android: Chrome or any browser that follows intent: URIs. iOS: Safari, only where the app registers a scheme.
- Docs
- No public UPI deep-link specification. (npci spec)
- Reference
- LAB4QHW3V999KEV
- Registry
- 1.0.0
Whether a note is displayed, truncated, stripped or rejected. Note length limits differ sharply between apps.
Expected
Navi opens on its payment confirmation screen showing the payee and ₹2.00. Whether a note is displayed, truncated, stripped or rejected. Note length limits differ sharply between apps.
Limitations
- A browser cannot tell you whether an app is installed. "App did not open" and "app is not installed" look identical from here; AN-004 in the Android harness is what separates them.
- Not runnable on iOS at all through this method.
Prerequisites
- A saved UPI profile with a payee address.
- On iOS: not addressable — Navi publishes no URI scheme the lab is willing to claim. Use the Generic UPI group (GN) on iPhone.
- On Android: Navi installed (com.naviapp).
Notes
- Navi publishes no URI scheme the lab is willing to claim, so it cannot be addressed directly from a non-Android browser.
How the lab runs it
Android: an intent:// URI naming com.naviapp, with no browser_fallback_url so a failure to open stays visible. iOS: not implemented, because no scheme exists to implement.