How do I sell tickets for a bhajan sandhya or kirtan night?

Last checked 20 September 2026

A samiti, a temple committee or a host putting on a bhajan sandhya, a kirtan night, a kavi sammelan, a mata ki chowki or a garba evening has the same money question behind all of them, which is whether a platform takes a cut of a collection meant to pay for the event itself. Thrivia has a manual payment mode where the attendee pays the committee's own UPI ID and uploads the payment screenshot against their own pass. The 4.9% handling fee is computed only on a gateway order and is simply never computed on a manual one, so the money goes from the attendee's bank to the trustee's account with no platform percentage anywhere in the path. The screenshot does not land in a WhatsApp group: it is capped at 5 MB, accepted only as JPEG, PNG or WebP, converted to WebP, and stored on a private prefix with no public read, and whoever checks it opens a signed link that stops working after an hour. Approving or rejecting that payment needs the finance permission, which the check-in role deliberately does not hold, so the volunteer scanning passes at the gate cannot decide that money arrived.

A bhajan sandhya, a kirtan night, a satsang, a jagran, a mata ki chowki, a kavi sammelan and a garba evening are not one kind of event to the people who attend them. To the people who organise them they are almost exactly the same problem. Somebody puts up a poster with a QR, money starts arriving into an account, a WhatsApp group fills with screenshots, and on the night a volunteer stands at a gate with a printed list that stopped being accurate on Thursday.

Most of the writing on this subject is aimed at the person buying a pass. This is written for the committee, because the committee is the one carrying the money question.

The collection is the event's budget, so a percentage lands differently here

A samiti collecting ₹300 a head for a kirtan night is not running a margin. The pass money is the tent, the sound system, the singers' honorarium and the prasad, and it has usually been budgeted to the rupee by people who will answer for it at a meeting. Handing five percent of it to a ticketing platform is not a cost of doing business, it is a line somebody has to justify to a trustee who was going to buy chairs with it.

That is why the default across this entire calendar is a QR code of the treasurer's UPI on the poster. It costs nothing, and nobody is going to argue a committee out of it. The part worth fixing is everything that happens after the payment, which is where the list, the gate and the accounting all come apart.

Manual mode pays the committee's own UPI, and the handling fee never reaches it

Thrivia runs two payment modes on an event. In gateway mode the attendee pays through a hosted gateway checkout and a 4.9% handling fee is charged, inclusive of its own tax, on the tax-inclusive subtotal. In manual mode the attendee pays your own UPI ID directly and uploads the payment screenshot.

The mechanism is worth stating exactly, because it is not a discount and not a waiver. The pricing engine computes the handling fee inside a branch that only runs when the payment mode is gateway. On a manual order the branch is not entered, the fee is zero, and there is nothing on the attendee's side to add it to and nothing on the committee's side to deduct it from. The payment itself is written with a gateway name of manual, which is the flag the rest of the system reads to mean that the host collected this money and Thrivia only ever looked at the proof of it. Nothing in the product holds it, releases it or settles it, because it was never in the path.

So a ₹300 pass paid this way credits ₹300 to the account on the poster. What you buy is the record, not the rails. The mechanics of taking UPI this way, and the checklist for reading a payment screenshot properly, are in collecting UPI payments for events, which this page does not repeat.

What happens to the screenshot after somebody uploads it

This is the part of manual collection that nobody thinks about until it has already gone wrong. A UPI screenshot carries the payer's name, their bank, part of an account or handle, an amount and a reference number. In the ordinary version of this, that image ends up in a group of forty volunteers, in the photo gallery of every phone in the group, and in whatever cloud those forty phones back up to.

The upload path here is narrow on purpose:

• 5 MB is the ceiling and JPEG, PNG and WebP are the only types accepted. Anything else is refused at the door rather than stored and dealt with later.
• Every accepted image is re-encoded to WebP and sized down to fit within 1200 by 1600, so what is stored is a normalised image rather than whatever the payer's phone produced.
• It is stored on a private prefix with no public read access. There is no URL anyone can guess or forward.
• The verification queue is handed a signed link that expires, by default after an hour, never the stored object. A link that leaks out of your committee is a link that has already stopped working.

The practical effect for a samiti is that payment proofs stop being forty copies of a stranger's bank details sitting in forty photo galleries. They become one copy that one person opens to decide one booking.

The volunteer at the gate cannot approve a payment

Committees run on volunteers, and volunteer access is usually all or nothing. The person who scans passes at the gate on Saturday is in the same WhatsApp group as the person who signs cheques, which means in practice that eleven people can confirm a seat and nobody can say afterwards which of them did.

Team seats here are separated along exactly that line. Verifying or rejecting a manual payment is gated on the finance permission. The check-in seat holds the guest list and the right to admit people and nothing else, and among the team roles only the full-access one holds finance. A co-host with a check-in role does not hold it either, which was a deliberate narrowing rather than an omission: marking a payment as received mints a ledger entry stamped with whoever approved it, and that is not a door action however close to the door it happens.

Reading the pending queue is a weaker act and sits on a weaker permission, so you can give a volunteer sight of what is waiting without giving them the power to clear it. The useful consequence is that you can hand out gate access freely on the night of a jagran, to people you have met that week, without also handing out the ability to say that ₹2,000 arrived.

Free entry, and the contribution that is not a fixed price

A large share of this calendar is not ticketed at all. Entry to a satsang or a bhajan sandhya is open, and money is collected in a box by the door or handed to somebody near the stage. The box has one property that makes it hard to plan around, which is that it tells you nothing until you count it, and by then the event is over.

The shape that fits is a free ticket type that admits anyone, alongside a contribution ticket where the payer enters a whole-rupee amount themselves. That amount has a floor you set on the event, which defaults to ₹100, and the engine takes the higher of your floor and the ticket's own price, so you cannot accidentally leave it open at zero. A contribution order carries exactly one contribution ticket, in quantity one, and nothing is added on top of what the payer chose.

What this gives a committee before the night rather than after it is a running number. You know on Wednesday what has come in and roughly how many are coming, which is the difference between ordering prasad for four hundred and ordering it for whoever turns up.

Passes, sittings and the gate

Garba is the case where the calendar's shape shows up most clearly, because a garba pass booking is rarely for one evening. Nine nights sold as nine separate things, plus a season pass, plus a couples rate, is four products and a capacity ceiling that differs on a Saturday. Each night is its own dated occurrence with its own capacity and its own tiers, so the Saturday selling out does not close the Tuesday, and a season pass is a tier rather than a promise somebody remembers at the gate.

Kavi sammelan ticket booking has the opposite shape and the same machinery. One sitting, one hall, seat categories that matter because the front rows are the ones people pay for, and an audience that books late. What both need at the door is the same thing: a QR per ticket rather than per booking, so a family of five arriving in two cars is two arrivals rather than an argument.

A pass already scanned comes back as already checked in, with the time it was first used, which is what stops one screenshot of one QR being forwarded around a colony and used four times. The second person at the gate is not quietly admitted and not shown a hard error either; the volunteer sees when the pass was used and by then knows to ask. The mobile scanner keeps a queue on the device when the hall has no usable signal, which at a temple ground or a community hall basement is most of the time, and replays those scans when signal returns without double-counting anyone. Load the guest list while you still have signal, because the app can replay what it took offline but cannot fetch a list it has never seen.

The general event side of this, including several gates running at once and what the large consumer platforms charge, is covered in ticketing software for event organisers.

The poster QR, the group and the register

The way almost every committee in the country runs this is genuinely fine for a hundred people and one night. A QR on the poster, a WhatsApp group of volunteers, screenshots arriving at all hours, one person keeping a register, and a printed list at the gate. It is free, everyone already knows how to do it, and no software is going to be worth its price against it at that size. It gives way at four hundred people, at nine nights, and at the point where more than two people are answering the same group.

The expensive part of moving is not the software. It is the meeting where the committee decides which two people hold the finance seat, because that conversation has been avoided for years by the group chat doing the deciding. The typing itself is an evening: the nights, the tiers, the prices and the UPI ID.

Planning around the calendar rather than one festival

Committees that only set this up for one festival end up setting it up again every time, because the calendar does not stop. A samiti that ran nine nights of garba is running a kirtan night in a month and a jagran after that, usually with the same volunteers, the same hall and the same UPI ID.

The dates move each year with the lunar calendar, so the practical rule is to check an actual panchang rather than last year's poster. Kartik Purnima in 2026 falls on Tuesday, 24 November for New Delhi, with the Purnima tithi running from 11:42 pm on 23 November to 8:23 pm on 24 November, which is the sort of overnight boundary that decides whether a jagran is sold as one night or two. Set the event up once with the tiers and the UPI ID you will reuse, and the next one on the calendar is a copy and a set of new dates rather than another round of posters and screenshots.

Where this does not help

• Cash at the gate. Nothing records it. If most of your collection is cash on the night, most of your collection stays outside any of this.
• Money that arrives without a booking. A devotee who transfers to the account without ever opening the pass page is invisible here, because a manual payment becomes a record only when the payer uploads proof against their own booking. Nothing reads your bank account.
• Payouts and splits. Thrivia does not move money on your behalf, so settling with the singers, the sound contractor and the caterer stays your treasurer's job.
• A published price in another currency. A relative abroad can pay on their card, but the pass is priced in rupees and their bank converts it.
• Email as a channel. There are no campaigns and no newsletters, which matters if your samiti's announcement list is an email list rather than a WhatsApp broadcast.