How do you verify a UPI payment screenshot?

Last checked 20 September 2026

You cannot verify a UPI payment screenshot by looking at it. The image carries no signature, no issuer and nothing a bank would recognise, so every field on it is a claim typed by whoever sent it. The one field that does any work is the transaction reference, the UTR or RRN, because it is the handle you use to find the credit in your own bank or UPI app statement. Ask for that reference as text rather than as part of the picture, search your own record for it, and treat the payment as real only when a credit of that exact amount, at that time, with that reference, appears on your side. Everything else on the receipt, including the tick and the green, is decoration that a phone can produce in thirty seconds. Thrivia runs this as a queue rather than a chat thread: the payer uploads proof at checkout, the booking sits in a verify state holding the seat, and you approve or reject it against the reference.

Someone has sent you an image of a payment and is waiting for you to say yes. This page is about that one decision. If you are still working out how to take UPI in the first place, how to split a deposit from a balance, or how to chase what is outstanding, the wider version of the job is in how to collect UPI payments for events without a gateway.

A screenshot carries nothing a bank would recognise

A payment receipt in a UPI app is a screen the app drew from data it received. A screenshot of that screen is a bitmap. Nothing travels with it: no signature from the bank, no issuer, no way for you to ask anyone whether the picture is a true record of anything. Every pixel arrived from a device you do not control, through a chat app that will happily forward an image from 2024 with today's timestamp on the message.

Which means the question is never whether the screenshot looks real. Convincing ones are free. The question is whether a matching credit exists on your side, and the only field on the image that helps you answer it is the transaction reference.

The UTR is the part that does the work

Every completed UPI payment carries a transaction reference. UPI apps label it inconsistently, as UTR, RRN, UPI transaction ID or just transaction ID, and it lives on the payment details screen rather than on the animated confirmation screen most people screenshot. Kotak Mahindra Bank's explainer describes UTR as a unique identifier attached to a transfer so it can be traced, and lists bank statements, internet banking history, the mobile app, SMS and email confirmations as the places you can find one.

That reference is useful to you for one reason. You can paste it into your own bank app or UPI history and either find the credit or not find it. Nothing else on the receipt is searchable. An amount is searchable but ambiguous, because three people paid you ₹8,500 on Tuesday.

So ask for the reference as text, in the message, alongside the image. A number you can copy is a number you can search and a number you can compare against every reference you have already accepted. A number that exists only as pixels inside a screenshot has to be retyped by hand, and it gets retyped wrong often enough that people stop bothering.

What a forged or reused screenshot actually looks like

There is a small industry of apps that generate UPI receipt screens to order. You type a name, a VPA, an amount and a time, and you get an image that matches your bank's layout closely enough to survive a glance on a small screen in poor light. Nobody needs image-editing skills for this.

The tells people look for are unreliable and getting worse. Font mismatches, a wrong shade of green, a status bar that shows a different battery level from the rest of the conversation, an aspect ratio that does not match any phone the sender owns. Each of these catches the lazy version and none of them catches the current one, so a forensic read of the image is time you spend to arrive at the same uncertainty you started with.

The reused screenshot is more common than the forged one and just as expensive. A real receipt for a real payment, sent again for a second booking. A real receipt for a payment made to somebody else. A screenshot of a screenshot, forwarded from a friend who paid for a different trip. Every field on these is genuine, which is exactly why inspecting fields cannot catch them.

All four fail the same way. The reference either appears in your statement, once, attached to a credit of the right amount at the right time, or it does not.

Why the same reference turns up twice

Once you are storing references as text rather than as images, one check becomes free that was previously impossible: has this reference been submitted before, against any other booking. On Thrivia the reference is normalised and compared against what is already on file when the proof is submitted, and a repeat is flagged for the person reviewing rather than being refused outright, because the honest explanations are real. Somebody resubmits after a failed upload. Somebody pastes the wrong line from their history. A second traveller on the same booking sends the payer's receipt again.

Flagging rather than blocking is the right default for a reason you can reproduce by hand. A hard block on a duplicate reference turns every clumsy resubmission into a support conversation, and the organiser then works around the block, which is worse than not having it. A flag costs a glance and never strands anyone.

A payee-only QR lets the payer choose the amount

This is the mechanical reason short payments look so normal. A static QR pasted into a chat or printed on a poster encodes a payee and no amount. The payer's app opens with an empty amount field and they type the figure themselves, which means an underpayment travels through exactly the same flow as a correct payment and produces exactly the same successful receipt. There is nothing wrong on the screenshot. The wrong number is the one they typed.

A UPI intent can carry the amount. The upi://pay URL takes an am field alongside the payee, and when it is present the payer's app renders the amount as a fixed field instead of an empty one. Thrivia generates the QR per booking from that intent, with am set to the exact payable total, so the manual flow no longer depends on a host having uploaded a QR image that encodes a payee and nothing else.

Be precise about what that buys. It closes the careless hole and not the deliberate one, since nothing stops a payer opening their app and sending any figure they like to a VPA they already know. The amount on the receipt still has to be checked against what is owed. What changes is that the common case, a traveller typing 8000 instead of 8500 at eleven at night, stops happening.

Who is allowed to say yes

Verification is a money decision, and it tends to get handed to whoever is nearest the phone. Accepting a payment that never arrived and admitting someone at a gate are different acts with different consequences, so they should not be the same permission.

On Thrivia the verify and reject endpoints sit behind a capability called finance:manage, and the team roles are sets of capabilities rather than ranks on a ladder. The check-in role holds two capabilities, reading the guest list and admitting, and nothing else, so the person at the gate structurally cannot approve a payment. The operations role holds events, CRM and guest-list access and deliberately holds no finance capability at all, so a senior operations person cannot approve one either. Among the assignable roles, full access is the only one that carries finance:manage.

Running this without software means picking the same boundary yourself and writing it down before the season starts. Who opens the bank app, who is allowed to reply confirmed, and what the other people do when a screenshot lands at eleven at night and the one person who can check it is asleep.

How long an unverified payment should wait

A payment nobody has looked at holds a seat, and a seat held indefinitely by an unreviewed screenshot is the same thing as an oversold departure arriving late. So there has to be a deadline, and somebody has to enforce it.

Thrivia gives the host 48 hours from the moment the proof is submitted. A job runs hourly and cancels manual payments still unverified past that window, declines the booking behind them and emails the traveller that it expired. Cancelling the payment is what releases the seat, because capacity only counts manual payments still in a processing state.

One exception is written into that job and is worth borrowing as a principle. A traveller whose proof is sitting in the queue has already paid out of their own account, and a manual UPI payment has no automated refund path, so cancelling their booking on a schedule forfeits money that is genuinely gone from their side. The job therefore skips accounts locked out for non-payment of their own subscription rather than expiring the attendees of a host who is currently unable to verify anything. The deadline exists to protect the seat, and it stops short of punishing the person who paid.

Where the image should live once you have it

A payment proof shows somebody's name, their bank, their VPA and how much money they have moved. It is not a poster. Forwarding it through a group chat so a colleague can check it copies all of that onto every phone in the group.

Thrivia accepts JPEG, PNG and WebP up to 5 MB, re-encodes the image to WebP on the way in, and stores it under a private prefix with no public read. The verification queue is handed a presigned link that expires in an hour by default rather than the stored object itself, so an old link in someone's browser history stops working on its own.

The re-encode has a consequence to be honest about. What is stored is a viewing copy rather than the original bytes, so nobody is going to run pixel forensics on it later. That is an acceptable loss given that pixel forensics was never going to settle anything. The statement settles it.

Who checked it, and how you find out nobody did

The usual setup is one shared WhatsApp number, one bank login belonging to whoever opened the account, and a QR in the camera roll. Nobody was given verification as a job, so it happens when someone is holding the phone. That works at eight bookings a week and fails in a specific order.

None of this moves your money. A manual UPI payment goes from the traveller's bank to yours the way it does today, at the same cost of nothing, because the 4.9% handling fee applies to gateway-mode bookings and manual mode is priced without it.

What to ask for, in the message with the QR

1. The transaction reference as text. Say the words UTR or transaction ID, and say it is on the payment details screen rather than the confirmation animation. Asking in the same message as the QR gets it first time in most cases.
2. The exact amount, stated by you. If the payer is typing the figure, the figure needs to be unambiguous and in writing, so a short payment is arguable by nobody.
3. The screenshot as well. It is a fast way to spot a pending status and a wrong payee before you go looking in your statement, and it is the record you keep of what the payer believed they sent.
4. Nothing else. Bank account numbers and card details have no role in confirming a UPI payment, and asking for them creates an obligation to protect them.

Then find the credit. If your bank lets you search by reference, that is a five-second check, and the whole of the rest of this page exists because most people skip it.