Skip to content
<Rojit />
10 min read· August 1, 2026

Payment Gateway Integration in Nepal: eSewa, Khalti, ConnectIPS & International

How to integrate payment gateways in Nepal — eSewa, Khalti, ConnectIPS, FonePay — plus Stripe and PayPal for international customers, and how NRB rules shape online payment integration.

Written by Rojit Pokharel — Full-Stack Web Developer & System Architect, Kathmandu, Nepal

PaymentseSewaKhaltiE-commerceNepalLaravel
Payment Gateway Integration in Nepal: eSewa, Khalti, ConnectIPS & International
$

Accepting online payments in Nepal is no longer a luxury — it is table stakes for any serious e-commerce or booking business. But integrating Nepali payment gateways is different from wiring up Stripe. This guide explains the landscape, the NRB rules that shape it, and how to pick the right gateway for your product.

The Nepali payment landscape

Nepal's digital payment ecosystem is small but active. Four gateways dominate e-commerce checkout:

GatewayBest forType
eSewaWallet payments, wide merchant baseDigital wallet
KhaltiWallet + card, developer-friendly docsDigital wallet
ConnectIPSBank-account direct transfersBank transfer
FonePayQR + wallet, growingDigital wallet
Stripe/PayPal (international)Foreign customers / USDCard

For a domestic customer base, your checkout will usually need eSewa or Khalti first, and ConnectIPS for users who prefer direct bank transfers.

The NRB factor you must understand

Nepal Rastra Bank (NRB) regulates payment service providers. The practical consequences for developers and business owners:

  • Payment providers must be licensed by NRB — use only licensed gateways for real money.
  • Settlement is not instant. Funds typically reach your bank account on T+1 or T+2 days. Plan your reconciliation accordingly.
  • You are responsible for matching transactions between your database and the gateway's ledger — implement idempotency keys and webhooks carefully.
  • Merchant onboarding requires business documents (PAN, company registration) — gateways approve merchants, not developers.
Integration basics (the patterns are the same)

Whatever gateway you choose, the flow is nearly identical:

  1. 01Create a merchant account and get API keys (public + secret).
  2. 02Build an order in your backend, then request a payment initiation from the gateway.
  3. 03Redirect the customer to the gateway's hosted page (or open their app via deep link).
  4. 04Receive the verification callback (webhook or redirect with signed params).
  5. 05Verify the signature server-side before trusting it — never trust the frontend.
  6. 06Update the order status and reconcile with the settlement report.

Signed callback example (pseudo-flow)

php
// 1. Initiate payment from server
$payment = $gateway->initiate([
    'amount'   => $order->total,
    'ref_id'   => $order->uuid,   // your idempotency key
    'callback' => route('payment.verify'),
]);

// 2. Redirect customer
return redirect($payment->payment_url);

// 3. Verify callback signature BEFORE updating the order
if ($gateway->verifySignature($request)) {
    $order->markAsPaid($request->transaction_id);
}

The single most important rule: always verify the callback signature on the server and make sure the amount and ref_id match your order. Otherwise you leave the door open for forged callbacks.

Choosing the right gateway
  • Selling goods to Nepali customers? Start with eSewa + Khalti. High wallet adoption.
  • B2B or high-value invoices? Add ConnectIPS so customers can pay directly from their bank account.
  • Selling to foreigners or in USD? Stripe or PayPal, with a pricing strategy that accounts for fees and currency conversion.
  • Restaurant or physical store? FonePay QR codes at the counter pair well with a web checkout.

Watch the fees

Gateway fees in Nepal typically range from 1% to 3% per transaction, sometimes with a minimum per transaction. Compare total cost (setup + per-transaction + settlement) rather than just headline rates.

Common mistakes I see in production
  1. 01Trusting the frontend callback. Always verify server-side.
  2. 02No idempotency. A customer double-clicking "Pay" can create two orders.
  3. 03Ignoring webhooks. Redirect-based callbacks are lost if the browser closes — implement webhooks for reliable updates.
  4. 04Forgetting reconciliation. Settlement files differ from your DB totals; build a daily reconciliation job early.
  5. 05Storing secrets in the frontend. Merchant secret keys must live on the server only.
Beyond checkout: payments as a feature

In my agency work, payment logic rarely stays a simple "pay for order" step. I've built:

  • Multi-currency booking engines with departure-based fare rules and partial payments.
  • Automated invoicing that generates sequential invoice numbers and triggers payment reminders.
  • Vendor earnings dashboards that aggregate payouts from marketplace orders.

Each of these adds moving parts — which is exactly why a payment-savvy developer saves you far more than the invoice suggests.

Getting help

If you are planning a store or platform with Nepali payments, I've integrated eSewa, Khalti, ConnectIPS, and international gateways across production systems. Contact me and I can help you pick the right stack and avoid the expensive mistakes above.

Building a product like this?

I build production web applications end-to-end — custom code, real-time systems, and deployments. Let's discuss your project.

Get in Touch