Merchant Payment Solutions Nepal: What to Build, Buy and Monitor

Separating the layers

Merchants in Nepal usually buy one product but need five capabilities:

1. Acceptance — presenting eSewa and Khalti and bank transfer options and initiating transactions.
2. Ledger — a durable record of every attempt, state change and amount.
3. Settlement — moving collected funds to the merchant on a schedule.
4. Payouts — sending money back out to customers, partners or suppliers.
5. Monitoring — knowing within minutes when any of the above degrades.

Buying only acceptance and assuming the rest is included is the single most common planning error. Travel, education, digital subscriptions and remittance-adjacent services drive much of the online payment demand.

Payment methods that matter in Nepal

Your method mix should follow your customer profile, not an industry average. Look at where your traffic actually comes from and what ticket sizes you expect.

• eSewa — supported through PayEurasia's Nepal acceptance stack with reference data returned on every transaction.
• Khalti — supported through PayEurasia's Nepal acceptance stack with reference data returned on every transaction.
• connectIPS — supported through PayEurasia's Nepal acceptance stack with reference data returned on every transaction.
• Fonepay — supported through PayEurasia's Nepal acceptance stack with reference data returned on every transaction.

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.

Onboarding: what underwriting will ask

Onboarding in Nepal is document-driven. Preparing the pack in advance typically cuts days off go-live:

• Company registration and ownership chain up to beneficial owners
• Director identification documents
• Website or app walkthrough showing the actual purchase flow
• Terms, refund policy and privacy policy that match what the site says
• Any licence required for your vertical
• Bank statements or processing history where available

Our merchant onboarding page lists the current requirements, and compliance explains the standards behind them.

Refunds, reversals and disputes

Nepal Rastra Bank supervises payment service providers closely, and merchant categories are reviewed carefully, so onboarding evidence needs to be accurate from the start. Design for this explicitly:

• Store the rail reference for every successful collection so a refund can be matched
• Decide whether partial refunds are supported per method before you promise them to customers
• Keep an evidence trail — timestamps, IP, device, delivery confirmation — for every disputed transaction
• Reconcile refunds into the same ledger as collections rather than tracking them separately

Our refund policy shows the structure we recommend merchants mirror.

Monitoring and operations

A payment stack in production needs a small number of alerts that actually fire:

• Approval rate per method dropping below a rolling baseline
• Webhook delivery failures exceeding a threshold
• Settlement not received within the expected window
• Unusual concentration of a single customer, device or amount

Anything more elaborate tends to get ignored. The point is to know before your customers tell you. Our status page reflects the same principle on the provider side.

Build versus buy

Keep in-house: your order model, your customer communications, your fraud rules that depend on product knowledge, and your accounting integration.

Buy: local acceptance, rail connectivity, redundancy across upstream providers, settlement, and compliance infrastructure. These require licences and relationships that are impractical to reproduce for a single merchant.

Merchant benefits

• Acceptance, payouts and reporting under one contract in Nepal
• Settlement on T+1 in most cases with line-level statements
• Underwriting that handles regulated and complex verticals
• Operational monitoring and escalation paths
• Coverage extendable to the rest of South Asia through the same integration

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

Talk to our team

If you are evaluating acceptance in Nepal, the fastest way to get a useful answer is to share your vertical, expected monthly volume and required payout frequency. Our team can confirm which rails are available to your business, what documentation underwriting will ask for, and how quickly you can go live. Start with merchant onboarding or contact us directly.

Frequently asked questions

What is a merchant payment solution?

It is the combination of acceptance, ledger, settlement, payouts and monitoring that lets a business take money reliably. In Nepal that means wallet and bank rail coverage plus a settlement path that works for your entity.

How long does merchant onboarding take in Nepal?

With a complete document pack, onboarding typically moves in days rather than weeks. Missing licences, unclear ownership or a website that does not match the stated business are the usual causes of delay.

Can I accept and pay out through the same provider?

Yes. Collections and local disbursements can run through one integration and one reconciled ledger, though payouts are underwritten separately.

Are refunds supported on wallet payments?

Refund handling depends on the specific method. Store the rail reference on every collection so refunds can be matched, and confirm partial refund support per method before advertising it.

Do I need different providers for each South Asian market?

Not necessarily. One integration can cover Bangladesh, India, Pakistan, Nepal, which is simpler to operate than four separate local contracts.