Nepal's Payment Gateways, Compared for Developers

All five move money from a Nepali customer to a Nepali business. The technical differences are smaller than the vendor pages suggest. The decision that matters is which one your customer already has installed, because a gateway your buyer has never heard of adds a signup step in the middle of your checkout.

Wallets against bank rails

eSewa, Khalti and IME Pay are wallets. The customer holds a balance or a linked account and approves a payment inside an app or a hosted page. They are quick for small and medium purchases and they carry limits.

Connect IPS and Fonepay sit closer to the banking system. The customer authorises from their bank account, which suits larger amounts and feels more familiar to an older or more corporate buyer.

That split, rather than any API detail, is what should shape your checkout. A store selling clothes needs wallets. A business collecting a deposit on a vehicle needs a bank rail. A store doing both needs one of each.

What integration actually looks like

Every one of them follows the same pattern: you construct a signed request, redirect the customer, and verify the outcome from your server. The differences are in the details of the signature, the shape of the callback, and how much the sandbox resembles production.

Write a thin adapter per gateway behind one interface with two operations, start and verify, rather than a single class that branches. When one provider changes its verification response, you want to edit one file rather than reason about shared code.

Store the provider's own transaction reference against every order from the first day. Reconciliation at month end is trivial with it and painful without it.

The questions to ask before you commit

Technical documentation quality varies, and so does support responsiveness. Both matter more over three years than the feature list does. Before choosing, get answers to these in writing.

• What is the settlement period, and to which account?
• What are the per-transaction and daily limits for a customer?
• How is a refund processed, and is it an API call or a support ticket?
• What does the sandbox not simulate?
• Who do we contact when a payment is stuck, and what is their response time?

The refund question catches people out most often. Several providers handle refunds through a manual process, which means your order model needs a refund-pending state and your support team needs a runbook.

What to build regardless of choice

Three things protect you whichever gateway you pick.

Server-side verification, always. Never mark an order paid because the browser reached your success page.

An idempotency key per payment attempt, so a customer who refreshes does not create a second charge or a second order.

A reconciliation view in your admin that lists orders whose payment state is uncertain. Every gateway produces some, and finding them by hand in a database is not a process anyone sustains.

A sensible default

For a typical Nepali online store, start with one wallet and one bank option, verify both properly, and add a third only if you can point at customers asking for it. Two well-handled gateways convert better than four half-finished ones, and they cost far less to keep working.