UPI Deep Linking: upi://pay Explained (India)

A UPI payment link is a `upi://pay` URL that opens an Indian UPI app with the payee, amount, currency and note prefilled; the customer still approves with a UPI PIN (product explanation checked 8 Aug 2026). Dvaarik can send the link during a call, WhatsApp chat or Instagram conversation and record the next workflow step.

A UPI payment link is a URL that starts with `upi://pay`. When a customer taps it on an Indian smartphone, their UPI app opens with the payee, amount, and note already filled in. The customer still approves the payment using their UPI PIN. The money moves bank-to-bank through UPI, usually within seconds.

Deep linking means a link opens an app directly into a specific action instead of opening a normal web page. In this case, the deep link tells Google Pay, PhonePe, Paytm, BHIM, or another UPI app: open the payment screen with these details. A basic direct link can include `pa` for UPI ID, `pn` for payee name, `am` for amount, `tn` for note, and `cu=INR` for currency. You can test this with the free UPI payment link generator.

A UPI deep link is a URL with the scheme `upi:` and the host `pay`, carrying the payment details as query parameters. Nothing is hosted; the string itself is the instruction.

``` upi://pay?pa=name@bank&pn=Business%20Name&am=100.00&cu=INR&tn=Booking%20A123 ```

Two practical rules. Everything must be URL-encoded — a business name with a space becomes `Business%20Name`, and an unencoded `&` inside a note will silently truncate every parameter after it, which is the single most common way a hand-built link breaks. And amounts should carry two decimal places; `100` and `100.00` are both usually accepted, but the second form is what you will see in working examples.

If you would rather not assemble this by hand, our UPI payment link generator builds and encodes it for you in the browser, and nothing you type is sent anywhere.

The subject described in this section: This distinction causes more confusion than any parameter, because both get described as "sending a payment link" and they behave very differently.

Intent flow is what a `upi://pay` deep link triggers. The payer taps it, their UPI app opens with your details pre-filled, and they approve the payment. The money moves because the payer pushed it. Nothing was requested from their bank; you simply handed them a pre-addressed instruction.

Collect request is the opposite direction. You — usually through a payment provider — send a request to the payer's VPA, and a notification appears in their app asking them to approve a pull. The payer did not initiate anything.

The practical differences matter:

• Trust. Intent flow starts with the customer's own tap, so it feels like paying. Collect requests arrive unprompted, which is the same shape as a very common fraud pattern, so a lot of Indian users have learned to decline them.
• Expiry. A collect request has a validity window. An intent link does not expire; it is just a string.
• Who can send it. Anyone can build an intent link. Collect requests generally require a PSP or gateway relationship.
• Confirmation. A collect request flows through the provider who sent it, so they can tell you what happened. An intent link tells you nothing — you look at your bank app.

For a small business collecting a booking deposit inside a WhatsApp conversation, intent flow is almost always the right one. It is free, it is instant, and it does not resemble a scam.

A UPI QR code is not a separate technology. In the common case it encodes the same payment string a deep link carries, so the QR and the link are two presentations of one instruction — one for a camera, one for a tap.

That has a useful consequence: the same generated string solves both your desktop and mobile problems. A `upi://` link needs a UPI app on the same device, so on a laptop it does nothing. Render that identical string as a QR code on screen and the customer scans it with the phone that has their UPI app. Nothing else changes.

Where this matters in practice:

• In-person counters want a QR — static on a card for open-amount payments, or generated per-bill with the amount filled in.
• WhatsApp and SMS want the tappable link, because the customer is already on the phone that will pay.
• Desktop web wants the QR, or a link the customer can send to themselves.
• Printed material wants a static QR with no amount, because you cannot reprint it per customer.

A static QR without an amount also removes a whole class of error: the customer types what the bill actually was, and you are not chasing a link that was generated for the wrong figure.

The subject described in this section: This is the most common support question, and the honest answer is that behaviour is not perfectly uniform across UPI apps and has shifted over time.

Things that vary in practice:

• Whether a pre-filled amount is editable. Some apps present your `am` value locked; others let the payer change it. If your workflow assumes an exact figure, verify the amount received rather than trusting the link.
• Which app opens. On Android, a `upi://` intent with several UPI apps installed usually produces a chooser. Some phones remember a default, which is why your test on your own handset may not match a customer's.
• App-specific schemes. Individual apps also register their own schemes, so you will see links built for one app in particular. Those are more fragile — they fail outright for anyone who uses a different app. Prefer the generic `upi://pay` unless you have a specific reason not to.
• iOS behaviour. URL-scheme handling differs from Android's intent system, and a link tapped inside an in-app browser may not hand off to a payment app at all. A link that works from the SMS app can fail from inside a social app's browser.
• Unencoded characters. A stray `&`, `#` or space in the note silently drops parameters. It is not an app bug; the URL genuinely ended early.

None of this makes deep links unreliable — hundreds of millions of payments run on them. It means you should test rather than assume, which is the next section.

Five minutes here prevents the failure mode where a customer says "it's not working" and you have no idea which part broke.

1. Open it on your own phone and stop at the confirmation screen. Do not pay. Check that the payee name and VPA shown are yours and are spelled the way customers expect.
2. Check the amount and the note carried through. If the note is truncated, you have an encoding problem — usually a space or an `&`.
3. Try it from a second app. If you use one UPI app, ask a colleague on a different one to open the same link and confirm the screen looks right.
4. Try it from inside WhatsApp, not just from your browser. In-app browsers are where hand-off most often fails, and WhatsApp is where you will actually send it.
5. Send ₹1 to yourself once. The end-to-end test is the only one that proves the VPA resolves and the credit lands where you expect, with your note attached.
6. Then render it as a QR and scan that too, if you plan to use it at a counter.

Do this once per VPA, not per link. Once the pattern works, the generator produces the same shape every time.

Deep links are free and instant, which makes it tempting to use them for everything. They are genuinely the wrong choice in a few cases, and knowing which saves you a painful month.

When you need automatic confirmation. Nothing calls your system back. If your process requires knowing the payment landed without a human checking, you need a gateway.

When volume outgrows manual reconciliation. At a handful of deposits a day, matching credits by note is fine. At fifty a day it is somebody's job, and that person costs more than gateway fees.

When you need refunds with an audit trail. You can always send money back, but a deep link leaves no linked record tying the refund to the original payment.

When the payer is not on their phone. Desktop checkout works better through a hosted page than through a QR the customer has to scan mid-flow.

When you need to charge repeatedly. Recurring collection is a mandate problem, not a link problem.

The honest summary is that a deep link is excellent at one job — getting a specific amount paid by a specific person during a conversation — and mediocre at everything a payments stack normally does. Most small businesses should use it for deposits and a gateway for anything that needs reconciliation. Where this fits into an actual booking flow, with the link sent mid-conversation and the slot released if payment does not arrive, is covered on our payments feature page.

Direct UPI is excellent when the business owner can verify payment or when the AI workflow records a UTR. Razorpay is better when the booking should confirm automatically through a webhook.

Salons: collect a small deposit before locking a high-value service. Clinics: collect appointment advances when allowed by the clinic's policy. Restaurants: collect party-booking advances before blocking tables. Gyms and studios: collect trial-class or enrollment deposits. Real estate: collect paid site-visit or consultation fees only when appropriate and clearly explained. The point is not to charge everyone; it is to create commitment where no-shows are expensive.

A payment link does not solve anything by itself. A business still has to send it at the right moment, verify payment, confirm the booking, send a reminder, and follow up if the customer does not pay. That is where Dvaarik's Payments Agent fits: it sends the payment link during a call, WhatsApp chat, Instagram DM, or website chat, then keeps the conversation moving.

Check the UPI ID, payee name, amount, customer name, service, booking date, refund/cancellation rule, and verification process. For direct UPI links, ask the customer to share the payment screenshot or UTR if your workflow does not auto-confirm. For automated payment flows, prefer a gateway path with webhooks and clear settlement records.

If you only need a one-off link, use the UPI payment link generator. If you want the AI to send payment links inside conversations, start with payment collection, WhatsApp automation, or the AI receptionist India page. For the short definition, see the UPI payment link glossary.