How to collect payment for an event in Nepal

Selling a ticket is the easy part. Getting the money, reconciling it, and proving to an attendee that their payment arrived is where most Nepali events lose time.

Here is how payment actually works for an event in Nepal, and what to set up before you open registration.

Fonepay is the default, and it is two different things

Almost everyone reaches for Fonepay, but it is worth being precise: there are two distinct routes, and they suit different people.

The QR. You show a code, the payer opens whichever banking app they already have, scans, and pays. This works on a laptop, on a printed sheet at a desk, and on a second phone. It is the route that needs no assumptions about the payer's device.

The mobile-banking hand-off. Instead of showing a code, you hand the payer straight into their own bank's app with the amount already loaded. On Eventio360 this covers 21 banking apps today. It is faster than scanning — but the link only resolves on the phone that has the app installed. On a desktop it opens nothing.

That distinction matters for your checkout. A payer on a phone wants the bank list. A payer on a laptop wants the QR. Offering only one of them costs you completed payments, which is why both are separate choices at checkout rather than one button that guesses.

Delegates paying from abroad

A Nepali bank rail does not help someone registering from Delhi or Dubai. PayPal covers them, and it accepts cards without the payer needing a PayPal account.

The thing most organisers miss is currency. If your conference has a local delegate rate and an international rate, those are genuinely different prices in different currencies — not one price converted at whatever rate a page happened to load. Price each ticket type in its own currency and the problem disappears.

The part that actually bites: reconciliation

Every organiser eventually gets the same message. *"I paid, I have the receipt, my ticket has not arrived."*

What makes that answerable is recording every payment attempt against the booking, not only the successful ones. When a payer says money left their account, you need to be able to look up what was issued, when, for how much, and what the gateway said about it. If your system only stores completed payments, that conversation ends with you refunding someone out of goodwill because you cannot tell.

Three practical rules:

• Never mark a booking paid from the browser. A page that says "payment complete" is reporting what the payer's phone thinks. Confirm against a signed reply from the gateway.
• Keep every reference you issue. If a payer pays a QR from ten minutes ago rather than the one on screen, you still need to find it.
• A timeout is not a failure. Gateways answer "no record" for payments that are simply still in flight. Treating that as failed is how you tell someone their payment bounced when it did not.

What to set up before registration opens

1. Your own merchant account. Money that lands directly in your bank is money you do not have to claim back from anybody. See why that matters.
2. Both Fonepay routes, so phone and desktop payers each get the one that works for them.
3. PayPal, if a single delegate might register from outside Nepal.
4. A test payment of Rs 1, through every method, on a real device — not a sandbox. Sandbox credentials and live credentials fail in different ways, and the failure you care about only shows up on the live one.

That last step is the one people skip, and it is the one that catches the misconfiguration before four hundred delegates do.