UPI is a single rail with several entry points, and treating them as interchangeable is how checkouts leak. The method you choose decides who initiates, how long the customer waits, and how much of the flow you control. Here is what separates them.
Intent: the customer taps, their app opens
An intent flow hands payment details straight to the customer's UPI app, usually by deep link on mobile. The app opens pre-filled and the customer only approves.
- Smoothest option on a phone: nothing to type and no waiting for a request to arrive.
- The natural fit for in-app checkout and mobile web.
- Does not apply on desktop, where there is no app to hand off to.
- You lose the customer to another app briefly, so the return journey needs designing.
Designing the hand-off and the return
The weak point of an intent flow is not the payment, it is the moment the customer comes back. Your page has been in the background, may have been evicted from memory, and the customer has no idea whether anything happened.
- Persist the order state before the hand-off, so a reloaded page can recover it.
- Show a definite waiting state on return rather than the original pay button, which invites a second payment.
- Poll for status on return instead of trusting any parameter the app passed back.
- Offer a fallback after a reasonable interval — a collect request or a QR — rather than leaving the customer stuck.
- Never mark the order paid from a client-side signal.
When the app chooser hurts
A customer with several UPI apps installed gets a chooser, which is an extra decision at the worst moment. Where your flow knows or can remember which app they used last, deep-linking directly to it removes a step — and where it does not, showing the common apps as explicit buttons is usually better than a generic 'Pay by UPI'.
Collect requests: you ask, they approve
A collect request is initiated by you and pushed to the customer's UPI app as a pending approval. It works regardless of the device they are browsing on, which makes it the usual choice on desktop and for invoicing.
The trade-off is waiting. The request has to reach the app, the customer has to notice it, and they have to act before it expires. Each of those is somewhere a payment can quietly stall.
What the waiting screen should say
- That a request was sent, and to which UPI ID — so the customer can tell whether it went to the right place.
- Where to find it: 'open your UPI app and check pending requests' is more useful than a spinner.
- How long they have, counting down, so the deadline is concrete.
- A way out: resend, switch to a QR, or change the UPI ID if they typed it wrong.
The last point matters more than the others combined. A mistyped UPI ID with no way to correct it is a dead checkout, and it is one of the more common ways collect requests fail.
Static QR: print once, collect indefinitely
A static QR encodes your identifier but not an amount. The customer scans and types what they owe. It costs nothing per transaction to display and needs no integration at the point of sale, which suits counters and stalls.
Because the amount is customer-entered, reconciliation is harder: you cannot match on an expected value and you depend on the payer to reference the right thing. For a shop that is fine. For invoice collection it usually is not.
Where static QR genuinely wins
- Zero marginal cost: one printed sticker serves an unlimited number of transactions.
- No hardware, no power, no connectivity at the point of sale.
- It survives a dead phone battery on the merchant's side, which a screen-based code does not.
- It works for a queue, because several customers can scan the same code at once.
The failure mode to plan for is the wrong amount. A customer typing 500 instead of 5,000 produces a settled payment that is short, and you find out at reconciliation rather than at the counter.
Dynamic QR: the amount travels with the code
A dynamic QR is generated per transaction and carries both the amount and a reference. It removes the two weaknesses of a static code — wrong amounts and unmatchable credits — at the cost of needing something to generate it.
- The customer cannot mistype the amount, because they never type it.
- The reference comes back with the payment, so reconciliation is a lookup rather than a guess.
- It works on a screen at a counter, on an invoice, or embedded in a checkout page.
- It can expire, which a printed sticker cannot.
- It needs a system at the point of sale, which a printed sticker does not.
Where the customer is remote rather than present, a payment link does the same job through a different channel — the comparison is in payment links versus dynamic QR.
Recurring collections and mandates
Everything above assumes a one-off payment where the customer is present to approve. Subscriptions and instalments need a different mechanism, because asking for approval every cycle guarantees churn through inattention rather than intent.
A mandate is approved once and then permits collection on a schedule within agreed limits. The design questions are different from a one-off collection.
- The approved amount is usually a ceiling rather than a fixed figure, so variable billing within the cap is possible.
- Customers are notified before a debit, which means your billing run has to be predictable rather than opportunistic.
- A mandate can be revoked by the customer at any time, so a failed collection is not necessarily an error — it may be a cancellation you have not recorded.
- Mandate setup is a conversion step of its own and deserves the same attention as checkout.
Choosing
| Context | Method | Main reason |
|---|---|---|
| Mobile checkout | Intent, collect as fallback | No typing; fewest steps to approval |
| Desktop checkout | Collect request or dynamic QR | No app on the device to hand off to |
| Counter, small varying amounts | Static QR | Zero marginal cost and no hardware |
| Counter, exact amounts | Dynamic QR | Removes wrong-amount errors entirely |
| Invoices | Dynamic QR or payment link | Amount and reference travel with the request |
| Delivery collection | Dynamic QR | Amount known at the door, customer present |
| Subscriptions | Mandate | Avoids asking for approval every cycle |
Where checkouts actually leak
Conversion work on UPI checkouts usually starts with the payment method and should start with the three places customers are lost regardless of method. Fixing those is cheaper than optimising anything downstream of them.
| Leak | What it looks like | Fix |
|---|---|---|
| Entering the UPI ID | Typos, abandonment at the field | Offer intent or QR so nothing is typed |
| The pending wait | Customers leave during an unexplained delay | Explain what was sent, where, and for how long |
| The return journey | Order never confirmed although payment succeeded | Poll server-side; never depend on the redirect |
| The retry | Second payment after an apparent failure | Show status before offering to pay again |
| Expiry with no recovery | Request dies silently | Offer a fresh request rather than an error |
The fourth row produces the complaints that cost the most to resolve. A customer who paid, saw a failure, and paid again now has two debits and a strong opinion. Checking status before re-offering payment prevents it entirely.
The status check before the retry
- Never render a retry button from a client-side timeoutA timeout in the browser says nothing about whether the payment settled. It is the single most common cause of duplicate payment in UPI checkouts.
- Query the server for the current state firstIf it has settled, show success. If it is pending, say so and keep waiting. Only an actual terminal failure justifies offering a retry.
- Make the retry a new requestA fresh reference, so a late settlement of the original does not collide with the retry.
- Detect and refund the doubleIf both settle, you want to know within minutes rather than at month end, which means reconciling on the reference rather than on the amount.
Frequently asked questions
Which UPI method converts best on mobile?
Intent, in most cases, because the customer's app opens pre-filled and there is nothing to type or wait for. Keep a collect request available as a fallback for cases where the hand-off does not complete.
Why do collect requests stall so often?
They depend on the request reaching the customer's app and the customer noticing and acting before expiry. Each step is a place the payment can pause, which is why the pending state needs real design rather than a spinner.
Is a static QR good enough for invoicing?
Usually not. Without an amount or reference encoded, you cannot match the credit to the invoice automatically. A dynamic QR or payment link carrying both removes the ambiguity.
What happens if a customer pays the wrong amount on a static QR?
The payment settles short or over and you discover it at reconciliation rather than at the counter. It is the main reason to prefer a dynamic code wherever the exact amount is known.
How should recurring UPI collections work?
Through a mandate approved once, which permits collection on a schedule within an agreed ceiling. Asking for approval every cycle produces churn through inattention rather than intent.
Can I rely on the customer returning to my page to confirm payment?
No. The return journey is unreliable and easily faked. Confirm from a server-side signal — a webhook with a verified signature, backed by a status poll for anything still outstanding.
What should the checkout do if the customer mistypes their UPI ID?
Let them correct it and resend. A collect request sent to the wrong ID with no way to change it is a dead checkout, and it is one of the more common ways this method fails.
