Setting Up Online Payments in Nepal: Complete Guide

Accepting money online in Nepal is very achievable, but the options differ in who can use them, what paperwork they require, and how they are integrated. This is a practical overview of the choices and the mistakes that cost people money.

The main options

• eSewa — the most widely held digital wallet, and usually the first integration worth doing
• Khalti — a second wallet with broad reach, commonly offered alongside eSewa
• ConnectIPS — direct bank-to-bank transfer, useful for larger amounts where wallet limits bind
• Manual bank transfer — no integration at all, but it requires someone to reconcile payments by hand

For most small businesses the sensible starting point is one wallet plus a clearly presented bank transfer option. Adding every gateway at once multiplies the integration and reconciliation work without necessarily increasing sales.

What you need before you apply

A merchant account is issued to a registered business, not to an individual. Expect to provide business registration documents, tax registration, identification for the proprietors or directors, and bank account details in the business name. Applications are commonly delayed because the business name differs slightly across documents, so check that they match before submitting.

Verify on the server. Always.

This is the part that matters more than any other, and it is where homemade integrations go wrong. When a customer finishes paying, the gateway sends them back to your site, typically with parameters describing the result. That redirect arrives through the customer's browser, which means it can be modified.

Never mark an order paid because the browser said so. Your server must call the gateway's verification endpoint directly, using your secret credentials, and confirm the transaction reference, the status and the amount. Only then should the order change state. Treating the redirect as proof of payment allows an order to be completed without any money moving.

• Confirm the payment server to server, never from the browser callback alone
• Check that the amount charged matches the amount the order should cost
• Record the gateway's transaction reference against the order
• Make settlement idempotent, so a repeated callback cannot credit an order twice

Keep credentials out of the code

Merchant keys and secrets belong in environment variables on the server, never in the front-end bundle and never committed to a repository. Anything shipped to the browser should be assumed public. If a secret is ever committed by accident, rotate it rather than deleting the commit and hoping.

Plan for failures and refunds

Payments fail, connections drop mid-transaction, and customers occasionally pay twice. Decide in advance how a failed or duplicated payment is detected and resolved, and give staff a way to look up a transaction by reference. Handling this properly is the difference between an occasional inconvenience and a customer who does not come back.