Payment Gateways in Nepal: What Integration Actually Involves

Every online seller in Nepal asks which payment gateway to integrate. It is the wrong first question. The right one is what share of your orders will be paid online at all — because for most sellers here, the answer is still a minority, and cash on delivery remains the default.

That shapes everything about how you build the payment side.

Design for COD first

If most of your orders arrive as cash on delivery, then your payment problem is not a gateway problem. It is a reconciliation problem: money collected by a courier, days after the order, in amounts that may not match the invoice, arriving in a batch settlement.

Practically your store needs:

• COD as a first-class payment method, not an afterthought
• An order state for “delivered, cash collected by courier, not yet remitted”
• Reconciliation of courier settlements against orders, so you can prove what you are owed
• A separate record of what was actually collected, which is not always the order total

Sellers who treat COD as “unpaid until someone marks it paid” end up with a spreadsheet reconciling courier remittances by hand. We wrote about the courier’s side of the same problem in cash on delivery reconciliation for courier companies in Nepal; the merchant’s side is the mirror image.

What the online options are

The domestic landscape breaks into a few categories, and the details — fees, settlement periods, onboarding requirements — change, so confirm current terms directly with each provider rather than trusting any published summary including this one.

Wallets (eSewa, Khalti and others) are the most-used online method. Users have a balance, the checkout redirects to the wallet to authorise, and the wallet confirms back to your server. Onboarding requires a registered business.

Fonepay connects to bank accounts and mobile banking, and its QR standard is very widely accepted — relevant for in-person as well as online.

ConnectIPS handles direct bank transfers, useful for larger-value transactions where wallet limits bite.

Card processing, domestic and international, involves a bank or an acquirer and has more onboarding requirements than the wallets.

Most sellers end up with one or two wallets plus COD. Adding more has diminishing returns and each one is a permanent maintenance obligation.

What the integration actually involves

All of these follow broadly the same shape, and the same things go wrong:

A redirect or a widget. The customer leaves your checkout to authorise and comes back. That round trip is where orders get lost — a customer who closes the tab mid-payment leaves you with an ambiguous order.

A server-to-server verification. Never trust the browser redirect alone. The callback the customer’s browser makes can be forged or simply not happen; the authoritative confirmation is your server asking the provider’s API whether that transaction reference actually succeeded and for how much. Verify the amount too — not just that a payment happened.

Idempotency. Callbacks arrive more than once. A customer refreshes, the provider retries, a network hiccup causes a duplicate. If your handler is not idempotent you will mark orders paid twice, or worse, ship twice.

Reconciliation against settlement. The provider settles in batches to your bank, net of fees, on their schedule. Your system needs to match its own record of successful transactions against what actually arrived. Discrepancies are usually fees or timing, occasionally something real.

The failure cases to build for

These are not edge cases. They happen weekly at any volume:

• Payment succeeded, callback never arrived. The customer’s money is gone and your order says unpaid. You need a reconciliation job that polls pending transactions against the provider and resolves them, plus a way for support staff to check a reference manually.
• Customer abandoned mid-payment. Order sits in “pending payment”. Needs a timeout and a clear state, or your order list fills with ghosts.
• Double submission. Two payments for one order. Needs detection and a refund path.
• Amount mismatch. Paid amount differs from order total. Should never auto-fulfil.

A store that handles only the happy path will generate a steady stream of support cases that all look like “the customer says they paid”.

Refunds

Worth confirming before you integrate, not after: does the provider support programmatic refunds, or is it a manual process through their dashboard? Partial refunds? What is the timeline for the money reaching the customer?

For COD orders, “refund” means something different again — you are returning money you received in a batch settlement, usually by wallet transfer or bank transfer, and your system needs to record it against the original order regardless.

Testing

Every provider has a sandbox. Use it, and specifically test the paths that are not success: cancelled payment, timeout, duplicate callback, wrong amount. Most integrations are tested only on success and then meet reality in production.

Also verify behaviour on a real phone on mobile data. Wallet redirects into apps behave differently on mobile than in a desktop browser, and mobile is where most of your customers are.

Which to pick

For most sellers starting out: COD plus one major wallet. Add the second wallet when customers ask for it by name. Add bank transfer when average order value is high enough that wallet limits are a real constraint. Add cards when you are selling internationally.

Each integration you add is code that has to keep working, so add them because a customer segment needs them, not for completeness.

We build eCommerce platforms for sellers in Nepal with local payment integration, COD reconciliation and courier connectivity built in rather than added later. If your payment reconciliation is a monthly spreadsheet, talk to us.