The upi://pay deep-link format that lets a QR code open any UPI app (GPay, PhonePe, Paytm, BHIM) with the payee VPA, name, amount, and note pre-filled for instant settlement.
UPI intent is the deep-link mechanism behind India's Unified Payments Interface QR codes: a upi://pay URL whose query parameters carry everything a payment needs. A typical intent looks like:
upi://pay?pa=merchant@upi&pn=Example%20Store&am=250.00&cu=INR&tn=Order%201234
When scanned, the phone offers the installed UPI apps; the chosen app opens with the payee, amount, and note pre-filled, and the user authorizes with their UPI PIN. Settlement is effectively instant and works across all participating banks and apps — the interoperability that made UPI the world's highest-volume real-time payment rail.
Parameter anatomy
The core parameters are pa (payee address — the Virtual Payment Address like name@bank), pn (payee name shown to the payer), am (amount in rupees), cu (currency, INR), and tn (transaction note or reference). Optional parameters cover merchant codes, sub-merchant details, and callback URLs for transaction status. The VPA is the key abstraction: it decouples the payment identity from the underlying bank account, so merchants can print one QR code without exposing account numbers, and can rotate or revoke VPAs without reprinting if the printed code sits behind a managed mapping.
Static print versus dynamic intent
UPI QR codes appear in two deployments. Static printed codes (the stickers on shop counters) usually encode a fixed VPA with no amount — the customer enters the amount at payment time. Dynamic intents generated per transaction include the exact amount and a unique reference, enabling automated reconciliation: the merchant's system matches the callback or statement entry against the order. Dynamic codes are also single-purpose — each encodes one expected payment — which simplifies fraud monitoring.
Collect requests versus intents
Do not confuse a upi://pay intent (a push: the payer initiates and authorizes) with a UPI collect request (a pull: the payee requests and the payer approves in-app). QR codes overwhelmingly encode intents, because the scan-to-pay flow is payer-initiated. Collect flows belong inside apps, not on printed codes.
Security and verification
The payer's app displays the payee name (pn) resolved against the VPA before the PIN screen — this is the verification moment, and users should be taught to check it, since a sticker-swap attack (pasting an attacker's QR over a merchant's) is the classic UPI QR fraud. From the merchant side, verify settlement through bank statements or the app's transaction history, not merely the customer's "payment successful" screen, which can be faked. For QR generation, always URL-encode parameter values, keep the amount to two decimals, and test the scan across at least two UPI apps before mass printing.
Diagram description: Annotated upi://pay URL with pa, pn, am, cu, and tn parameters labeled, mapped onto a UPI app payment screen showing the verified payee name before the PIN prompt.