Digital Payments in Nepal: What to Integrate and in What Order

Nepali customers pay in more ways than customers in most markets, and the mix shifts by age, city and order value. A shop that only takes cards will lose most of its orders. A shop that builds every integration at once will spend three months on plumbing before it has proved anyone wants the product. The order you add methods in matters more than the total number, and the failure handling matters more than either.

What Nepali customers actually pay with

Wallets and QR dominate everyday consumer transactions, especially under a few thousand rupees. Bank rails handle larger amounts and anything business to business. Cards are mostly for customers abroad. Cash on delivery persists because it substitutes for trust a new seller has not earned yet.

• eSewa and Khalti. The two wallets most customers already have installed, with web checkout, in-app payment and QR. If you integrate one thing, integrate one of these.
• IMEPay. Smaller share than the two above but worth adding once you are past the first version, particularly outside the Kathmandu Valley where remittance-linked usage is stronger.
• connectIPS. Direct bank account debit, operated through the national payments infrastructure. Better than a wallet for larger amounts because it is not constrained by a wallet balance, and the natural choice for invoices, fees and B2B.
• Mobile banking apps and QR. Most banks now have their own app and support interoperable QR. For an in-person or hybrid business, a printed QR is often the highest-volume rail you will ever have and costs nothing to build.
• Cards. Domestic debit cards are a minority of online orders. Foreign-issued cards matter if you sell to the diaspora or abroad, and that is a different setup entirely.
• Cash on delivery. Still a large share of physical goods orders from unfamiliar sellers.

Integrate one wallet first, and finish it properly

Pick the wallet your customers actually use, integrate it end to end, and do not touch a second one until the first has taken real money for a month. End to end means the money arrives in the merchant account, the order is marked paid by your server rather than by the browser, a failed payment leaves a clean recoverable order, and refunds have a tested path. Most teams stop at "the happy path works" and discover the rest on a busy Friday.

Add connectIPS or a plain bank transfer with manual confirmation next, because that combination covers almost everything the wallets miss and the manual version costs a day of work. A named account, a clear reference field, and an internal page where somebody marks the payment received is a legitimate first version. We build this pattern into most ecommerce and web builds, and the sequencing is covered further in our guide to running an ecommerce site in Nepal.

Cards, and selling to customers outside Nepal

Accepting foreign-issued cards is a commercial and banking question before it is a technical one. It normally requires an acquiring arrangement, and the terms, eligibility and settlement currency differ by bank and by what you sell. Do not design a checkout around international cards until your bank has confirmed in writing what you can accept, in which currencies, and how the funds settle. Teams regularly build first and discover the constraint afterwards.

If your buyers are largely abroad, be honest about whether you are running a Nepali shop that occasionally sells overseas or an export business that happens to be built here. The second one has different structure, different reconciliation and different tax handling, and it is worth resolving before the code is written. The same question comes up when selling services rather than goods to overseas clients.

The redirect that dies on mobile data

This is the single biggest cause of lost orders in Nepali checkouts, and almost nobody tests for it. The flow looks like this: the customer is on a mid-range Android phone on mobile data, taps pay, gets redirected to the wallet app or a bank page, switches to SMS for an OTP, and the browser is killed in the background because the phone is short of memory. The money leaves their account. They come back to a dead tab, or to your site showing an unpaid order. From their side you have taken their money and given them nothing.

Design for that specific sequence rather than treating it as an edge case.

• Never mark an order paid from the browser redirect. Verify server side against the provider before anything changes state.
• Take the provider's server-to-server callback as the primary signal, and treat the browser return as a convenience only.
• Make the handler idempotent. Duplicate callbacks are normal, not a bug, and a non-idempotent handler will double-fulfil an order eventually.
• Add a scheduled reconciliation job that queries the provider for any order still pending after a few minutes and resolves it without human involvement.
• Put a "I have paid, check again" button on the pending screen that runs a live verification. It is twenty lines of code and it removes a support conversation per day.
• Send the order confirmation from the server on verified payment, not from the success page, so the customer gets it even if their browser never came back.

Test all of this on a real mid-range Android phone on mobile data, with the browser backgrounded, not in a desktop emulator on office wifi. Before a campaign, test it under load as well, because payment callbacks queue like anything else and a checkout that works at five orders an hour can behave differently at five hundred. Our note on load testing before a campaign covers how to do that without a large budget.

Fees: understand the shape, negotiate the number

Published rates move and are negotiable at volume, so treat any percentage you read online as unreliable and get your own in writing in the merchant agreement. What is stable is the shape of the pricing, and that is what you should design around.

• A per-transaction charge, usually a percentage, sometimes with a flat component, and often different per method rather than one blended rate.
• Settlement on a delay rather than instantly. Ask for the settlement cycle in days and whether it changes at weekends or over Dashain and Tihar.
• Refunds that may not return the original fee, and may take longer than the customer expects.
• Cross-border card payments carrying additional components: interchange, cross-border and currency conversion, plus chargeback exposure that domestic wallets do not have.
• Cash on delivery costing a courier collection fee plus the return rate, which is the real number and is usually the larger one.
• Minimums, monthly charges or setup fees for some merchant accounts. Ask explicitly rather than assuming zero.

Model this against your average order value before choosing methods. A percentage that is trivial on a Rs 8,000 order is not trivial on a Rs 400 one, and for low-value orders a QR that settles directly to a bank account can be cheaper than anything you integrate.

Cash on delivery is a returns policy, not a payment method

Treat it as a credit decision. You pay to ship, you may pay to ship back, and you carry the goods in the meantime. Reduce the exposure rather than banning it: confirm high-value orders by phone or Viber before dispatch, cap the order value that can be paid on delivery for a first-time customer, keep a simple record of numbers that have refused delivery before, and offer a small discount for paying up front so the customer chooses the cheaper rail themselves.

Reconciliation is the permanent cost, not the integration

The integration takes days. Matching settlements against orders, chasing refunds, and dealing with payments that arrived with no order attached is a weekly job forever. Build the small internal tools before you need them rather than after the first bad month.

• Store the provider transaction reference on the order, always. Support conversations should be a lookup, not a guess.
• Keep an unmatched payments page listing money received with no order, and let a non-technical person attach one to an order without opening the database.
• Reconcile the provider's settlement report against your own totals weekly, per method, and investigate any gap the same week.
• Log every payment attempt, including the failures. The failure rate per method is the number that tells you which integration is quietly costing you orders.

That last page is worth building deliberately. The pattern is the same as any other internal dashboard people actually use: one screen, the exceptions only, and an action button next to each row.

Publish your refund timeline in plain language

Settlement is not instant and refunds are slower still, so say so on the site, in the number of working days it genuinely takes, with Dashain and Tihar noted as exceptions. One honest paragraph prevents more support load than any feature you could build around it, and a customer who was told to expect seven working days does not open a complaint on day three.