International Payment Gateways in Nepal: Questions Before Integration

Header image: conceptual illustration.

Merchants serving customers in Nepal face a specific question: should they use an international gateway, a local Nepali gateway or wallet, or both? Nepal's payment system is overseen by Nepal Rastra Bank, and foreign-exchange rules affect how money can move in and out of the country. This guide lists the questions to answer before integration. It is not legal advice; confirm requirements with the provider and qualified local advisers.

Questions about customers

• How do your customers prefer to pay? Local wallets such as eSewa and Khalti are widely used domestically; international cards may not be available to everyone.
• Will customers pay in Nepali rupees, or in a foreign currency?

Questions for the gateway

1. Acceptance. Do you accept my business type and entity location? Get the answer in writing.
2. Methods. Which Nepali methods do you support for collection, and which for payouts?
3. Licensing and partners. Through which licensed local institution are Nepali payments processed? Ask for the name; don't assume.
4. Currency. In what currency is the customer charged, and in what currency am I settled? Who converts, and at what rate?
5. Settlement. Schedule, minimums, reserves, holiday effects.
6. Documentation. What documents do you need, and how long does review take?
7. Technical. Sandbox, server-side verification, signed callbacks, status query API.
8. Support. Hours in Nepal time, escalation contacts, outage notices.

Local options to compare against

Local wallets publish developer documentation: see eSewa's developer docs and Khalti's docs. Reading them tells you what a direct local integration involves, which helps you judge whether an international gateway's coverage is adequate. Our eSewa vs Khalti guide compares them for merchants.

Hypothetical scenario

*Invented for illustration.* A foreign e-learning company discovers that many of its Nepali visitors abandon checkout at the card form. It adds a local wallet through a gateway that supports Nepali methods, and keeps cards for customers who have them. Reconciliation now has two sources, so it maps both into one internal status model.

Red flags

• The provider cannot name the local institution processing payments.
• No written settlement terms.
• No server-side verification method in the documentation.

Why global gateways do not solve Nepal

Most international payment gateways are card-first. They were designed for markets where a Visa or Mastercard number is the default instrument, and their coverage in Nepal is either absent or limited to a small minority of cardholders. Nepal is a compact but fast-digitising market. Two wallets, eSewa and Khalti, carry most consumer volume, while connectIPS and Fonepay link the banking system for larger transfers.

Volumes are lower than the rest of the region, so operational discipline — clean reconciliation and predictable payouts — matters more than raw scale.

What an international gateway must actually provide

There are four separate problems hiding inside the phrase "accept payments in Nepal".

1. Local acceptance. The checkout must offer instruments customers hold, in NPR, with local-language conventions and mobile-first layouts.
2. Local collection. Funds have to land somewhere regulated inside the country before they can move anywhere else.
3. Reporting that survives an audit. Every payout to the merchant has to be traceable back to individual customer transactions.

Payment methods that matter in Nepal

Bank rails are covered through dedicated collection accounts with Nabil Bank, NIC Asia, Global IME and other local institutions, which is what makes larger ticket sizes practical. Coverage per market is listed on the countries hub.

Settlement out of NPR

Collections settle on T+1 in most cases. Money collected locally is aggregated, reconciled against transaction references, and then paid out to the merchant according to an agreed schedule and currency.

Compliance expectations for foreign merchants

Nepal Rastra Bank sets the framework that local acquirers and payment service providers operate under, and those obligations flow through to you as a merchant. Expect to provide:

• Certificate of incorporation and ownership structure for the operating entity
• Licences relevant to your vertical, where one is required
• A description of the service being sold and the customer journey
• AML and KYC policy documents, including how you handle sanctions screening
• Historical processing statements if you have them

Nepal Rastra Bank supervises payment service providers closely, and merchant categories are reviewed carefully, so onboarding evidence needs to be accurate from the start. Our compliance page sets out the standards we apply, and the KYC and AML policies describe the underlying process.

Integration model

A well-built international integration in Nepal looks the same regardless of vertical:

• One create-transaction call that returns a redirect or intent for the chosen method
• Signed webhooks for every state change, with retries and idempotency keys
• A reconciliation endpoint that can be replayed for any date range
• Separate credentials for sandbox and production

Full details are in the API documentation, and the general design principles are covered in our payment infrastructure overview.

Common mistakes

• Treating a wallet like a card. Bank holidays follow the Bikram Sambat calendar, so settlement calendars must be configured locally or payouts silently slip a day.
• Ignoring failure taxonomy. "Failed" is not a reason. Insufficient balance, limit exceeded, user cancelled and timeout each need a different retry or message.
• Under-provisioning payouts. Merchants often plan collections carefully and then discover they also need local disbursements, which requires separate capability and approvals.
• Skipping reconciliation until month one closes. Build it on day one; retrofitting it across thousands of transactions is painful.

Merchant benefits

• Local acceptance in NPR without incorporating in Nepal
• One API for eSewa, Khalti, connectIPS and bank rails
• Consolidated settlement with per-transaction reporting
• Routing across multiple local providers so a single outage does not stop revenue
• Underwriting that understands complex verticals rather than rejecting them by category

Related guides and solutions

• Nepal Payment Gateway
• High Risk Payment Solution Nepal
• Solutions overview
• Cross-Border Payment Solutions
• Payment Infrastructure
• High-Risk Merchant Payment Processing
• Countries hub

Frequently asked questions

Can a foreign company accept eSewa or Khalti?

That depends on the wallet's or gateway's onboarding policy. Ask them directly.

Who regulates payments in Nepal?

Nepal Rastra Bank, the central bank, oversees the payment system.

See also: cross-border payments Nepal and our Nepal payment gateway page.

Which payment methods should an international merchant launch with?

eSewa and Khalti cover the majority of consumer transactions, and bank transfers handle larger amounts. Launching with both wallet and bank coverage is normally worth the extra integration effort.

How long does settlement take?

Settlement typically runs on T+1 in most cases, with payout frequency agreed during onboarding based on volume and risk profile.

What documents are needed to onboard?

Incorporation documents, ownership details, any vertical-specific licence, AML and KYC policies, and a clear description of the product being sold. Processing history helps but is not mandatory.

Is a local bank account required?

No. Collections land in the partner's regulated local accounts and are settled onward to the merchant, which is what removes the need for the merchant to hold NPR accounts directly.

Sources

• Nepal Rastra Bank: https://www.nrb.org.np/
• eSewa Developer documentation: https://developer.esewa.com.np/
• Khalti documentation: https://docs.khalti.com/