Payment gateway integration in Nepal: eSewa, Khalti, Fonepay and connectIPS

If you're adding payments to a Nepali website or app, payment gateway integration in Nepal usually comes down to four rails: eSewa and Khalti (wallet gateways with sandboxes you can use straight away), Fonepay (an NRB-licensed payment system operator built around QR and hosted checkout) and connectIPS (an interbank network run by Nepal Clearing House Ltd, or NCHL). Each publishes its own developer documentation and test setup, and none of them is safe to integrate by trusting a browser redirect: you always need a server-side verification step. This guide walks through how each provider's docs describe integration, onboarding and verification, then compares them side by side.

If you're still scoping the whole build, our custom software development guide covers process, cost and choosing a partner.

How eSewa integration works (ePay v2)#

eSewa's current integration, ePay v2, is a redirect flow: your server builds a signed form and posts it to eSewa's hosted payment page (eSewa Developer Portal, accessed 18 September 2026).

• Your backend calculates amount, tax_amount and total_amount, and generates a transaction_uuid that is unique for every request (letters, numbers and hyphens only).
• You sign a set of fields, such as total_amount,transaction_uuid,product_code, with HMAC-SHA256, Base64-encode the result, and list the signed fields in signed_field_names.
• The form posts to a test endpoint (rc-epay.esewa.com.np/api/epay/main/v2/form) or the production one (epay.esewa.com.np/api/epay/main/v2/form), along with your success_url and failure_url.
• After payment, eSewa redirects the customer back with a Base64-encoded response that includes transaction_code, status, total_amount, transaction_uuid and its own signature, which you must verify rather than trust.
• For certainty, or if no response arrives within five minutes, you call eSewa's status-check API with your product_code, total_amount and transaction_uuid. It returns PENDING, COMPLETE, FULL_REFUND, PARTIAL_REFUND, AMBIGUOUS, NOT_FOUND or CANCELED.

Here is the signing step in TypeScript, using Node's built-in crypto module. The same function checks eSewa's response signature, using the field list the response sends in its own signed_field_names.

import { createHmac } from "node:crypto";

// eSewa ePay v2: Base64 HMAC-SHA256 over "field=value" pairs,
// joined with commas, in the order given by signed_field_names.
export function esewaSignature(
  values: Record<string, string>,
  signedFieldNames: string,
  secretKey: string,
): string {
  const message = signedFieldNames
    .split(",")
    .map((field) => `${field}=${values[field]}`)
    .join(",");
  return createHmac("sha256", secretKey).update(message).digest("base64");
}

const secretKey = process.env.ESEWA_SECRET_KEY;
if (!secretKey) throw new Error("ESEWA_SECRET_KEY is not set");

const signature = esewaSignature(
  { total_amount: "110", transaction_uuid: "241028", product_code: "EPAYTEST" },
  "total_amount,transaction_uuid,product_code",
  secretKey,
);

You can start building straight away, because eSewa's developer docs publish a test merchant secret key and test eSewa IDs. Production credentials come once you register as an eSewa merchant.

How Khalti integration works (ePayment / KPG-2)#

With Khalti's ePayment Gateway, your backend calls Khalti's API first, then redirects the customer to a Khalti-hosted payment page (Khalti Documentation, accessed 18 September 2026).

• You POST to /epayment/initiate/ (sandbox base dev.khalti.com/api/v2/, production khalti.com/api/v2/) with return_url, website_url, amount and purchase_order_id, sending your secret key in an Authorization: Key <secret key> header.
• The amount is in paisa, not rupees, and Khalti's docs say it should be greater than NPR 10, or 1,000 paisa (Khalti ePayment docs, accessed 18 September 2026).
• Khalti responds with a unique pidx and a payment_url, and you redirect the customer there.
• The customer returns to your return_url with the pidx and a status, which Khalti's docs say not to treat as final. Confirm the outcome by calling the Lookup API, /epayment/lookup/, with the pidx (Khalti Payment Verification API, accessed 18 September 2026).

Onboarding starts in Khalti's merchant dashboard (test-admin.khalti.com for the sandbox, admin.khalti.com for production), where the "Keys" section gives you separate test and live keys. The docs also publish test wallet IDs and a fixed OTP for sandbox payments.

How Fonepay integration works#

Fonepay says it is licensed by Nepal Rastra Bank as a "payment system operator", and lists Fonepay QR, the Fonepay Business App and a hosted Checkout by Fonepay among its merchant products (fonepay.com, accessed 18 September 2026). Separate production and test merchant portals, at login.fonepay.com and dev-merchant-login.fonepay.com, confirm a test environment (Fonepay merchant login; Fonepay test portal, both accessed 18 September 2026).

Because Fonepay's public website doesn't publish its full field-level integration spec, treat the following as how the web integration is commonly described in publicly available integration guides, rather than a spec we verified on an official Fonepay page:

• A redirect flow using a merchant code (PID), a payment mode (MD) and a merchant-assigned reference number (PRN) that identifies the order.
• Amount (AMT), currency (CRN, defaulting to NPR), a transaction date (DT) and optional reference fields (R1/R2).
• A return URL (RU), plus a Data Validation field (DV): an HMAC-SHA512 hash of the concatenated fields, computed with your merchant secret, which you recompute and compare on callback.

Confirm the exact field names and onboarding steps with Fonepay merchant support before you build against this pattern.

How connectIPS integration works#

connectIPS is an interbank payment network operated by NCHL, not a wallet. Its documentation describes how a merchant's site or app integrates with the "connectIPS Core Module" through a documented Merchant Interface (connectIPS Gateway Introduction, accessed 18 September 2026).

• Your backend builds a token string describing the transaction (merchant ID, app ID, transaction ID, date, currency, amount in paisa and reference fields), computes a SHA-256 digest of it, signs that with SHA256withRSA using your merchant private key (a .pfx certificate file), and Base64-encodes the result before redirecting the customer (Merchant Interface Description, accessed 18 September 2026).
• To confirm payment status, your server calls the REST Payment Validation API, authenticated with HTTP Basic Auth using your app ID, with a JSON body containing your merchant ID, app ID, reference ID, transaction amount and token (Payment Validation API, accessed 18 September 2026).

Onboarding runs through your own bank, with supporting documents, rather than a self-serve sign-up. That means more paperwork up front than a wallet gateway, but your checkout connects directly to customers' bank accounts.

Inventure integrated connectIPS payments for Book Me World (bookmeworld.com), a React, Node.js and MongoDB platform for online booking and ticketing for clubs, lounges, pubs and theatre events in Nepal.

Comparing payment gateway integration Nepal options: eSewa vs Khalti vs Fonepay vs connectIPS#

None of the four is strictly better than the others. They solve different problems, and a checkout can offer more than one.

As a rough starting point, eSewa or Khalti are a reasonable default, because you can build against their sandboxes straight away. Add Fonepay if a meaningful share of your customers pay with its QR network, and connectIPS when your customers' banking habits or transaction values justify the extra bank-mediated onboarding.

Security practices these providers' own docs point to#

Every provider above builds a server-side verification step or a signature check into its flow. Four practices follow from that, whichever gateways you use:

• Verify every payment server-side. A success_url, failure_url, return_url or any other browser redirect is a hint to update your UI, not proof of payment. Confirm the outcome with the provider's own API (eSewa's status check, Khalti's Lookup API or connectIPS's Payment Validation API) before you mark an order paid.
• Use your own reference as an idempotency key. Check your unique order or transaction reference (an eSewa transaction_uuid, a Khalti purchase_order_id, a Fonepay PRN or a connectIPS reference ID) before fulfilling an order, so a repeated callback, a retried request or a customer pressing refresh can't charge or ship the same order twice.
• Recompute signatures yourself. Never accept a status field at face value. Recompute the HMAC or signature server-side with your own secret, and only proceed if it matches exactly.
• Never trust client redirects. This matters most when the redirect looks successful: a manipulated or replayed redirect must never convince your backend that an unpaid order was paid.

Keep test and production credentials clearly separated too. Each provider separates them, whether as keys, portals or certificates, and letting a staging deployment reach a production endpoint is an easy way to mix real and test transactions.

Payment endpoints deserve the same scrutiny as login endpoints. Our web application security checklist based on the OWASP Top 10 covers the fundamentals, and our security and DevSecOps service applies them to platforms in production.

Reconciliation: matching gateway records to your own#

Verification confirms a single payment; reconciliation confirms your books match reality over time. In practice, that means:

• Pulling each gateway's daily settlement report or statement and matching it, transaction by transaction, against your own order records.
• Flagging mismatches, such as a payment the gateway shows but you don't, a different amount, or a status that changed later, for manual review.
• Handling partial refunds and chargebacks explicitly in your data model, since a "paid" order isn't necessarily settled for good.
• Keeping an audit trail per transaction: the raw callback, the verification response and the reconciliation outcome, so a dispute months later doesn't come down to guesswork.
• Tracking "paid" and "settled" as different moments, because each gateway moves funds to your bank account on its own schedule.

International card payments from Nepal, at a high level#

Nepal Rastra Bank (NRB) regulates foreign-currency card payments, and the rules apply in both directions.

Outward, a Nepali individual or business paying with an international card generally works within NRB-set allowances rather than open access: individuals get a limited annual allowance, while IT and software businesses, especially those earning foreign currency through exports, can obtain larger annual limits (reported by Common Law Chambers, citing NRB's unified circular, accessed 18 September 2026). The limits change, so confirm any figure with NRB directly rather than relying on this post.

Inward, a Nepali merchant accepting international Visa or Mastercard payments is generally on a separate track from eSewa, Khalti, Fonepay and connectIPS, which are built mainly around Nepali wallets, bank transfers and domestic cards. The commonly reported pattern is to partner with an NRB-licensed commercial bank that holds a card-scheme acquiring licence, and foreign payment providers generally reach Nepali merchants through locally licensed partners rather than directly (reported by PayAtlas' Nepal payments overview, accessed 18 September 2026).

This section is general information, not financial or legal advice. Confirm your specific limits and licensing requirements with NRB or a licensed bank before relying on them.

What to do next#

If you're scoping a build that needs Nepali payments, such as a booking platform, a marketplace or an internal tool that reconciles transactions automatically, our API integrations service covers this kind of gateway work, from the redirect flow to server-side verification and reconciliation. It's also worth reading how the cost to build a web app breaks down, since payment integration is usually one line item among several.