How do you collect UPI payments for events without a gateway?

Last checked 10 September 2026

A traveller paying your own UPI ID or scanning your own QR costs you nothing, because no gateway sits in the path and there is no percentage to pay. What it costs instead is reconciliation: somebody has to open each screenshot, read the amount, the reference number, the timestamp, the payee ID and the status word, and match all five against your own bank or UPI app statement before a seat is held. Do that with a fixed checklist rather than a glance, because the four things that get past a glance are an old screenshot resent, a payment made to a similar-looking UPI ID, a pending state read as success, and an amount short by a fee. The honest trade is that a manual UPI payment has no chargeback protection and no dispute process, so verification before the seat moves is the only control you have.

Most Indian trip and event organisers already collect UPI this way. You post the QR, the traveller pays, they send a screenshot on WhatsApp, you say confirmed. It is the cheapest way to get paid in the country and nobody is going to talk you out of it. The part worth fixing is what happens after the screenshot arrives, because that is where seats get double-sold and half-paid people get on buses.

What the screenshot is actually worth

A screenshot is a picture of a claim about a payment, taken on a device you do not control, in an app anyone can edit a copy of. The proof is the line in your own bank statement or your own UPI app history. The screenshot earns its keep as the pointer that lets you find that line quickly.

That sounds pedantic until the first time somebody sends you a genuine screenshot of a genuine payment they made to somebody else, or their own payment from last month. Both happen more often through carelessness than through fraud, and both cost you the same seat.

So no seat moves from held to confirmed until somebody has matched the screenshot against your own statement. The checklist below does that in under a minute.

The checklist for verifying a UPI payment screenshot

Run these in order. Steps 1 to 5 are read off the image itself and take about fifteen seconds. Step 6 is the one that actually decides it, and skipping it makes the first five decorative.

1. Amount. Read the digits rather than recognising the shape of a number you see forty times a week. Check it against what this traveller owes right now, which for a deposit is the deposit and not the full price. Note anything short, however small, before you look at anything else.
2. Reference number. Every completed UPI payment carries a transaction reference, shown in the payment details of the payer's app and often labelled UPI transaction ID, UTR or RRN. If the screenshot does not show one, it is not a receipt, and you should ask for the one from the payment details screen rather than the celebration screen.
3. Timestamp. Read the date as well as the time. An old screenshot resent looks identical to a new one except here, and phone screenshots carry the payment's own timestamp inside the receipt, not just the file date.
4. Payee. Check the UPI ID or name the money went to, character by character, against your own. This is the step people skim, and it is the one a lookalike ID is designed to survive.
5. Status word. Look for the word, not the tick. Completed, Successful and Paid are settled. Pending, Processing, Initiated, In progress and Awaiting confirmation are not, and a pending payment can still fail hours later.
6. Match it against your own record. Open your bank app, your UPI app history or your statement, and find the credit. Search by the reference number if your bank lets you, otherwise by amount and time window. You are looking for one credit, of that amount, at that time, with that reference. If you cannot find it, the payment did not reach you, whatever the picture says.
7. Record it against the booking. Write the reference number next to the traveller's name in whatever list you keep. A payment recorded only as a message in a thread has to be verified again by the next person who wonders.

The four things that get past a glance

Two of these are dishonest and two are ordinary human error. They fail the same way, so it is not worth guessing which one you are looking at.

The edited screenshot exists as well, and it is rarer than the four above because it takes effort. It fails at step 6 like everything else does.

QR, payment link or collect request

There are three ways to ask, and they are not equivalent. A QR code, printed on a poster or pasted into a chat, is the push flow: the traveller scans, their app opens with your details filled in, and they approve. A payment link from your own bank does the same thing through a URL. Both are fine and both are what the volume is moving to.

A collect request is the pull version. You enter the traveller's UPI ID, a request appears inside their app, and they approve it with their UPI PIN. Nothing is debited until they do. It is the flow operators reach for when chasing a balance, and it is the one to stop building on.

A single static QR for the whole business is the easiest to set up and the hardest to reconcile, because every payment arrives looking the same and nothing in the credit tells you which trip it was for. If you keep one QR, you are choosing to do the matching by hand, which is workable at ten bookings a week and painful at fifty.

Deposits, balances and the reminder nobody sends

Almost nobody pays ₹18,000 for a Spiti trip in one tap, so the money arrives in two pieces and the second piece is the one that goes missing. On manual UPI the split costs you nothing, because there is no percentage and no per-transaction fee to pay twice. What it costs is a second round of the checklist above, a fortnight later, against a booking you have half forgotten.

The WhatsApp reminder for a balance due is not hard to write. It is hard to remember to send, and harder to send to exactly the right eleven people. The version that works is a list you can filter to whoever has paid a deposit and not the balance, so the reminder goes out from a record rather than from memory. Keep the trip name, the amount outstanding and the date in it, because half the replies you get to a bare reminder are asking for those three things.

A booking that holds a deposit now and the balance later is one record with two payments against it, which is also what makes the second verification quick: you already know what is owed. If the deposit and the balance live as two unrelated screenshots in two different threads, you will be doing arithmetic on the morning of departure.

What you give up by not using a gateway

Be clear-eyed about this before you commit a season to it. There is no chargeback protection on a manual UPI payment and no dispute process to escalate into, in either direction. If a traveller claims they paid and did not, you have your statement and nothing else. If you cancel a departure, the refund goes back out as your own transfer, on your own initiative, at whatever speed you manage.

You also have no automatic record. A gateway hands you a reconciled list of who paid what, which is most of the value people think they are buying with the percentage. Collecting UPI yourself means you are the reconciliation, and the honest comparison is not free against 2%, it is free-plus-your-evenings against 2%. The arithmetic on what a gateway actually charges is in which payment gateway should an Indian tour operator use.

Most operators run both. Manual UPI for the deposits and for travellers who prefer it, a gateway for anyone who wants a card or whom you would rather not chase.

Turning the thread into a queue

The reason this breaks at volume is not the payments. It is that the record of a payment lives in a chat, and chats have no state. Nothing in a WhatsApp thread knows whether that screenshot was checked, by whom, or whether the seat behind it is now held, and two people working the same inbox on a Friday evening will confirm the same last place twice.

The fix is to give the proof somewhere to sit. On Thrivia the traveller picks a departure, uploads the payment proof at checkout, and the booking waits in a pending state against a real seat while somebody runs the checklist. Accepting or rejecting it is what moves the seat, so there is one place the answer lives. The Instagram and WhatsApp enquiries that come before any of that arrive in the same inbox, for the same reason.

The rest of the season then reads off that record instead of being rebuilt from it. The accepted bookings are the guest list, and at the trailhead the same record is what the QR check-in scans. Whoever still owes a balance is a filter on that list rather than a second sheet you keep in step by hand, which is what makes the reminder easy to send to exactly the right eleven people. When a departure is cancelled, the refund follows the policy tier the booking was sold under, which is a duller conversation in October than trying to recall what you promised in March.

None of that touches the money. Thrivia has no payouts and no settlement, so a manual UPI payment goes from the traveller's bank to yours exactly as it does today, at the same cost of nothing.

Who checked the screenshot, and when you find out nobody did

Two of you run this between you. One WhatsApp number that both of you have open, one bank login that sits with whoever set up the account, and a QR in the phone gallery. Verification is not a job either of you was given, it is something both of you do when you happen to be holding the phone, and for a season or two that is fine and free.

Switching costs you an argument you have not had yet: which of you accepts payments, and what the other one does when a screenshot lands while they are the only one online. The setup itself is an evening of typing in trips, prices and dates. The habit is the expensive part, because replying confirmed from your own phone takes two seconds and opening the booking takes twenty. At under ten bookings a week, two people and one checklist is genuinely enough, and this is a monthly subscription either way.

What to change on Monday

1. Ask for the payment details screen, not the confirmation animation. Say it in the message with the QR and you will get the reference number most of the time without asking twice.
2. Put the trip name and the exact amount in the payment request, so a short payment is obvious rather than arguable.
3. Keep one list of who has paid what, with the reference number next to the name, and treat it as the record. The chat is where the conversation happens, not where the answer lives.
4. Check your own statement once a day rather than once per screenshot, and clear the whole day's pending payments in one pass.
5. Decide who accepts payments before the season starts. Two people accepting from the same inbox is how a departure gets oversold.

More on the booking side of this in booking software for tour operators and, if you are collecting payments from an Instagram bio rather than a site, in linktree for tour operators.