eSewa and Khalti: Payment Options for Merchants in Nepal

Header image: conceptual illustration.

eSewa and Khalti are widely used digital wallets in Nepal, and both publish developer documentation for merchants: eSewa developer docs and Khalti docs. Payment systems in Nepal are overseen by Nepal Rastra Bank. This guide compares them on what matters to a merchant's operations, and lists what to confirm directly.

Integration model

Both wallets document an online checkout in which the customer is sent to the wallet to authorise and then returned to the merchant, followed by a server-side check of the payment. Read the current documentation for the exact parameters, signing and verification calls — they change between API versions, so pin the version you integrate.

What to verify for both

1. Merchant onboarding. Eligibility for your business type and entity; documents; whether a foreign company can be onboarded.
2. Sandbox credentials and test accounts.
3. Secret keys kept server-side.
4. Server-side verification/lookup after the customer returns, before marking paid.
5. Amount units. Confirm whether amounts are in rupees or paisa for each API.
6. Callbacks and retries.
7. Refunds — API or manual, timing.
8. Reports with unique transaction IDs and itemised fees.
9. Settlement schedule and bank.

Operational comparison worksheet

• Documentation clarity (your developer's view) — eSewa: ? Khalti: ?
• Verification endpoint tested — eSewa: ? Khalti: ?
• Refund process — eSewa: ? Khalti: ?
• Settlement schedule — eSewa: ? Khalti: ?
• Support response during pilot — eSewa: ? Khalti: ?
• Checkout completion (your pilot) — eSewa: ? Khalti: ?

Hypothetical pilot

*Invented.* A merchant integrates both. In testing, a developer notices that one API expects amounts in paisa; a unit test now checks every amount conversion. During the pilot, completion is similar for both, so both stay at checkout.

Reconciliation tips

• Store wallet transaction IDs with your order ID.
• Map both wallets' statuses to one internal status model.
• Daily match of paid orders, wallet reports and settlement.

Why the comparison matters

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. A merchant deciding between eSewa and Khalti is really deciding how much of the addressable customer base to reach on day one.

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

Side-by-side

Maturity

eSewa: The longest-established Nepali wallet with a wide user base

Khalti: Newer, with strong adoption among digital-first users

Flow

eSewa: Wallet authorisation with callback confirmation

Khalti: Wallet authorisation with callback confirmation

Limits

eSewa: Bounded by wallet KYC tiers

Khalti: Bounded by wallet KYC tiers

Best for

eSewa: Widest single-wallet coverage

Khalti: Incremental reach and redundancy

Operational differences that surface later

Feature tables rarely capture what actually costs you money in production:

• Confirmation behaviour. Callback timing under load differs between providers, so a single global timeout is usually wrong for at least one of them.
• Failure taxonomy. Reason codes are not identical; map them to your own canonical set rather than displaying raw upstream strings to customers.
• Reference formats. Store each rail's reference separately so reconciliation and refunds stay unambiguous.
• Downtime patterns. Independent providers rarely degrade at the same moment, which is why running both is a resilience decision as much as a coverage one.

Bank holidays follow the Bikram Sambat calendar, so settlement calendars must be configured locally or payouts silently slip a day.

Verdict

Support both, and add connectIPS or Fonepay bank transfer for amounts above wallet tiers. In a market this size the marginal integration effort is small relative to the conversion gained.

What to do at checkout

1. Show both options with recognisable branding rather than a generic "wallet" button.
2. Route by amount where limits differ, before the customer hits a failure.
3. Keep a bank transfer option visible for higher-value orders.
4. Log method selection so you can measure real preference in your own traffic.

Merchant benefits

• eSewa and Khalti through a single Nepal integration
• Automatic failover when one provider degrades
• Unified reconciliation across both rails
• Settlement on T+1 in most cases

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

Do I need both wallets?

If your customers use both, offering both usually reduces abandoned checkouts.

Can I mark an order paid from the return URL?

Only after calling the wallet's verification or lookup endpoint server-side.

Related: eSewa merchant guide, Khalti merchant guide, Nepal payment gateway page.

Should I integrate eSewa or Khalti first?

Support both, and add connectIPS or Fonepay bank transfer for amounts above wallet tiers. In a market this size the marginal integration effort is small relative to the conversion gained.

Does supporting both increase costs?

Marginally in integration effort, but the additional coverage and the resilience gained when one provider degrades normally outweigh it.

How do I handle amounts above wallet limits?

Route them to a bank rail. Detect the limit before submission so the customer sees the right option instead of a failure.

How is settlement handled across both methods?

Both settle into the same reconciled ledger with per-transaction references, on T+1 in most cases.

Sources

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