This guide is for owners and managers in Nepal who want customers to pay on their website or app, whether that means a hotel taking deposits, a restaurant taking pre-orders, a school collecting fees or a shop selling online. It explains what “adding eSewa, Khalti and Fonepay” really involves, so you can plan the paperwork, brief a developer properly and avoid the mistakes that cost money later.

Three names, two different kinds of provider

eSewa, Khalti and Fonepay often get mentioned together, but they are not the same kind of company. Nepal Rastra Bank publishes a list of licensed payment companies. On that list, eSewa and Khalti are Payment Service Providers (wallets), and Fonepay is a Payment System Operator: a network that links banks and wallets.

In practice:

  • eSewa and Khalti each have a published developer integration. The customer leaves your site, pays in the wallet, and comes back to your site.
  • Fonepay is best known for the QR code at the counter, which customers scan with their mobile banking or wallet app. It also offers Checkout by Fonepay, which it describes as an online payment option for websites and mobile apps. The customer picks a partner bank or wallet and approves the payment there.

QR at the counter vs checkout on your website

These two solve different problems. It helps to decide which one you need before anyone writes code.

QR at the counter Checkout on your website or app
Where the customer is In front of you Anywhere, on their phone or laptop
What you need A merchant QR (static or dynamic) and a way to see payments arrive A merchant account with API credentials, plus development work
How you know they paid A notification in the provider’s business app or by SMS Your system confirms the payment with the provider’s server before it marks the order paid
Who matches payment to order Usually a person The software, automatically
Typical use Shops, restaurants, clinics, front desks Online orders, booking deposits, fee payments, subscriptions

Fonepay’s static QR is one code for everything. A dynamic QR is generated for each bill and can be linked to a point-of-sale system, so the amount is already filled in and the record is created automatically. If your counter staff type amounts in by hand and customers pay the wrong figure, a dynamic QR connected to your billing is often the first thing worth fixing.

Step 1: Merchant onboarding (the paperwork)

Nothing technical can go live until the business is approved as a merchant. Every provider sets its own requirements, and they change, so treat this as a general picture only:

  • eSewa lets you start merchant onboarding online or at its head office. Its published list for API integration asks for documents such as your business registration certificate and PAN/VAT certificate. What else it needs depends on your legal form: a sole proprietorship, a private limited company and an NGO are each asked for different documents.
  • Khalti asks you to sign up as a merchant, test in a sandbox account, then create a production account. Its documentation says you fill a KYC form to lift the transaction limit on a new account.
  • Fonepay merchants enrol through a Fonepay-linked bank or by self-registering. Fonepay lists documents including a business registration certificate (PAN/VAT), the proprietor’s citizenship copy and active bank account details.

Practical tip: start the onboarding at the same time as development, not after it. Approval and document back-and-forth usually take longer than the coding.

Fees vary by provider and by agreement; check each provider’s current merchant terms before you set your prices.

Step 2: What your developer needs from you

A good developer will ask for these. If they don’t, ask why.

  • Sandbox (test) access for each provider. eSewa publishes a test environment with a test merchant code, and Khalti offers a separate test merchant signup.
  • Production credentials issued to your business: the merchant code and secret key (eSewa), or the live keys from your Khalti merchant dashboard. Keep these on the server only, never inside a mobile app or in website code that runs in the browser.
  • The URLs customers return to after paying or cancelling (a success page and a failure page).
  • Your order rules: what happens to stock or a room booking while a payment is pending, and for how long.
  • Who has access to the merchant dashboards, for refunds and daily checks.

Step 3: How a proper web or in-app checkout works

The flow is similar for eSewa and Khalti:

  1. Your system creates the order with a unique reference and the exact amount.
  2. The customer is sent to the provider to pay.
  3. The provider sends the customer back to your return URL with a result.
  4. Your server checks the result directly with the provider before it marks anything as paid.

Step 4 is where most shortcuts cause losses. The page the customer lands on after paying proves nothing by itself.

  • eSewa signs its response. Its documentation tells merchants to verify that signature, and to use the status check API if no response arrives within five minutes.
  • Khalti tells merchants to use its lookup API for final validation. Only a status of Completed counts as success. Khalti also states that it is not accountable for losses caused by providing a service without checking the lookup status.

Details to get right:

  • Amount units. Khalti expects the amount in paisa, not rupees. Mixing these up gives you prices 100 times wrong.
  • Expiry. Khalti payment links expire, so an abandoned payment must not keep a room or item reserved forever.
  • Pending and unclear results. eSewa’s status API can return values such as PENDING, AMBIGUOUS or NOT_FOUND. Khalti’s lookup can return Pending, Expired or User canceled. Your system needs a rule for each one, not just “success” and “fail”.

Step 4: Test like a customer, then go live

Before switching to live keys, run these tests in the sandbox:

  • Successful payment: the order is marked paid exactly once
  • Customer cancels on the provider’s page
  • Customer closes the browser mid-payment, then the status check resolves it
  • Someone refreshes or re-opens the success page (it must not create a second order or confirmation)
  • Wrong or tampered amount in the return data (it must be rejected)
  • The same flow on a slow mobile connection
  • Refund handling, if you plan to offer refunds

Then run a small live payment with your own account before announcing anything.

Step 5: Reconciliation, the part everyone forgets

Getting money in is half the job. The other half is knowing, every day, which payments belong to which orders.

  • Store the provider’s transaction ID next to your own order reference for every payment.
  • Compare daily. Match your system’s paid orders against each provider’s merchant dashboard or statement. Look into anything that appears on only one side.
  • Separate counter and online payments in your records, so a counter QR payment is not mistaken for an online order.
  • Record refunds as their own entries, never as edits to the original payment.
  • Decide who owns the check, even if it takes only a few minutes a day.

Common pitfalls

  • Marking orders as paid from the redirect alone, without a server-side status check
  • Putting secret keys in a mobile app or in front-end code
  • Testing only the happy path
  • Leaving merchant onboarding until the website is “finished”
  • Offering three payment options when your customers mostly use one. Start with what they already use.
  • No written process for failed, pending or disputed payments

When to bring in help

If you only need a QR code at the counter, you probably don’t need a developer at all. Your bank or the provider can set you up. If you want payments inside your own website or mobile app, connected to your orders and records, that is the kind of systems and integrations work we do, and we are happy to talk it through.

Sources