eSewa vs Khalti vs Fonepay for Merchants

Most "eSewa vs Khalti vs Fonepay" comparisons are written for customers - which app is nicer to pay with. This one is written for the person who has to reconcile them. When you are the merchant, the question is not which app has the prettiest screen; it is which rail lets you prove where every rupee went. On that measure the three are genuinely different, and this is an honest look at how.

They are not the same kind of thing

Before comparing, get the categories straight, because they change everything downstream:

• eSewa - a wallet. Payments pool in a merchant wallet and settle to your bank in batches, net of fees.
• Khalti - also a wallet, but the most developer-transparent of the three, with a documented lookup and refund API.
• Fonepay - not a wallet at all. It is an interbank QR network; money routes toward your bank account rather than pooling in a Fonepay balance.

That single distinction - pooled wallet vs. direct-to-bank - shapes how you reconcile each one. Wallets need report-to-settlement matching; Fonepay needs report-to-bank-statement matching. All the rules live under Nepal Rastra Bank's payments framework at nrb.org.np.

Data access

This is where the rails diverge most for a merchant who cares about proof.

• Khalti is the strongest. A per-payment lookup keyed to a pidx, a transaction list for any period, and per-transaction fee data. You can pull an authoritative status for any single payment and a full ledger for the day. See the Khalti business guide.
• eSewa gives you a solid transaction/wallet report and a server-side status check, but the settlement itself arrives as a lump with the fee already baked in - you decompose it yourself. See the eSewa merchant guide.
• Fonepay gives you the business app and a merchant report, but because settlement is a bank event, much of your data access is really about reading the bank statement well - especially with static QR, where the payment carries no order reference.

Refunds

• Khalti documents a refund API, full and partial, keyed to the original payment. You can issue and track refunds programmatically. The catch is that refunds often net against a future settlement rather than appearing as their own line - explained in why a Khalti refund reduces your next settlement.
• eSewa supports refunds, but the tracking is less turnkey, and refunds can likewise reduce a settlement rather than reverse cleanly.
• Fonepay refunds are essentially a bank-side reversal or a fresh transfer back, since the money already sits in your bank. There is no wallet balance to reverse.

Webhooks and confirmation

• Khalti favours a server-side lookup as the source of truth - you confirm status by calling the lookup with the pidx rather than trusting the browser redirect.
• eSewa uses a signed redirect response plus a server-side status-check endpoint you should always re-verify against.
• Fonepay confirmation for QR is closer to real-time notification in the business app, with the bank credit as the final proof.

Across all three, the same rule holds: never mark an order paid on the browser redirect alone. Always confirm server-side. This one habit removes most payment disputes.

Fees

All three charge a percentage-style service fee, and the headline rate is less important than what you are actually charged. Khalti's per-transaction fee reporting lets you compute your true effective rate; eSewa bakes the fee into the settlement so you infer it; Fonepay charges may show up as a reduction in the bank credit. Over thousands of transactions the gap between assumed and actual fees is real money. We break the numbers down in payment gateway fees in Nepal, compared.

Settlement behaviour, side by side

• eSewa - payments pool in the wallet, settle in batches net of fees, timing can split a payment into the next batch. You decompose the lump.
• Khalti - similar pooling and batching, but with far better data to reconstruct the batch from. Refund netting is well documented.
• Fonepay - settles toward your bank directly, often batched by your acquiring bank's cycle, so your reconciliation anchor is the bank statement, not a provider payout report.

So which should a merchant use

The honest answer is most Nepali merchants end up running all three, because customers expect all three. So the real question is not which to pick, but how to reconcile a mix. And a mix is harder than any single rail:

• Wallet payouts (eSewa, Khalti) must be matched report-to-settlement.
• Fonepay must be matched report-to-bank-statement.
• Refunds net across time on the wallets.
• Fees hide in different places on each rail.

Doing this across three rails, every evening, in one spreadsheet, is where the errors creep in. If you want the conceptual foundation, what is payment reconciliation and what is a daily close are the two to read next.

Where RakamHQ fits

RakamHQ was built for exactly the multi-rail reality. It ingests eSewa, Khalti, and Fonepay reports alongside your bank statement, applies the right matching logic to each rail, tracks refunds through netting, and reconciles everything into a single proven daily close - so no matter which rail a customer chose, every rupee traces back to a source row.

Frequently asked

Which Nepali rail has the best data access for merchants?

Khalti is currently the clearest, with a per-payment lookup, a transaction list, and per-transaction fee data. eSewa is workable but more manual, and Fonepay depends on how your bank reports credits.

How are eSewa, Khalti and Fonepay fundamentally different?

eSewa and Khalti are wallets where payments pool and settle in batches. Fonepay is an interbank QR network that routes money directly toward your bank account, so it has no pooled balance.

How should merchants confirm a payment across these rails?

Never rely on the browser redirect. Confirm server-side: a lookup call on Khalti, a status check on eSewa, and the bank credit plus business-app notification on Fonepay.

Do I have to pick just one rail?

Most Nepali merchants run all three because customers expect all three. The real challenge is reconciling a mix, where wallet payouts, direct-to-bank credits, refunds and fees all behave differently.

Keep reading

Payment Gateway Fees in Nepal Compared

Read

What Is Payment Reconciliation?

Read

connectIPS Explained for Businesses

Read