Web Development
2026-10-15 · 11 min read
Sapun Lamichhane
Founder & CEO of Arcetis
A Nepal-facing e-commerce or booking site that only accepts international cards loses the majority of potential customers before checkout even begins. eSewa and Khalti between them cover most of the digital wallet usage in the country, with eSewa generally having the longer track record and broader merchant network, and Khalti strong particularly among younger, mobile-first users. Most serious Nepali websites that sell anything online eventually integrate both, plus card payments as a secondary option for customers who have them. Digital wallet adoption has kept climbing year over year as more Nepalis get comfortable transacting online for everything from mobile top-ups to grocery delivery, which only increases the cost of skipping these integrations.
This is less a preference than a conversion-rate issue: offering a payment method a customer does not have or trust is functionally the same as not offering checkout at all.
This is particularly true for mobile-first sectors like food delivery, ticketing, and small e-commerce, where a customer abandoning checkout because their preferred payment method is missing almost never results in them switching to a different method - they simply leave and buy from a competitor who already supports it.
“The hardest part of Nepali payment integration is not the code - it is reconciling what the gateway says happened with what your own database says happened.”
Getting started requires a formal merchant account with eSewa, which means submitting business registration documents (PAN or VAT), bank account details, and a description of what is being sold - this approval step alone commonly takes anywhere from a few days to several weeks, so it needs to be started well before a launch date, not the week before. Development happens first against a sandbox/test environment before the account is approved for production.
On the technical side, the integration pattern is: the website redirects the customer to eSewa's checkout page with the transaction details (amount, a unique transaction reference, product identifiers), the customer completes payment on eSewa's side, and eSewa redirects back to the website with a signed response. That signature must be verified using the secret key - every serious bug in eSewa integrations seen in practice traces back to skipping or getting this verification step wrong.
It is also worth planning for eSewa's API versioning - the exact field names and endpoint structure have changed between versions over the gateway's history, and documentation available publicly does not always reflect the most current production behavior. A development team integrating eSewa for the first time should confirm the current API version and test thoroughly in sandbox before assuming any older code sample or tutorial still applies exactly as written.
Khalti's merchant onboarding and developer flow follows a broadly similar shape - business verification, sandbox testing, then production keys - with its own API conventions and its own checkout widget (Khalti Payment Gateway, commonly referred to as KPG) that can be embedded directly on a page rather than always requiring a full redirect, which tends to feel smoother on mobile.
Settlement timelines (how long it takes for collected payments to actually reach the business's bank account) vary and are worth confirming directly with current merchant terms rather than assuming, since both gateways have adjusted these over time; a business planning cash flow around online sales needs this number early, not after the first settlement surprises them.
Businesses selling through both a website and a mobile app sometimes need to integrate both Khalti's web checkout and its app-based SDK separately, since the two are not automatically interchangeable, which adds a bit of extra development time that is easy to underestimate when scoping a project that needs to work across both platforms.
The single most common and most dangerous mistake is trusting the browser-side "success" redirect as proof that payment happened, without a server-to-server verification call back to the gateway to confirm the transaction status and amount independently. Without that check, a customer could in theory manipulate the client-side flow and appear to have paid when they have not - this is a real fraud vector, not a theoretical one.
Beyond that: not explicitly handling "pending" and "failed" states (treating everything as either success or silence), not protecting against the same transaction being processed twice if a customer refreshes the callback page, and not testing the refund flow until the first real refund request arrives, by which point a customer is already frustrated. All of these are solvable, but only if they are planned for during development rather than discovered in production.
Logging every gateway callback and webhook payload, even ones that appear to be duplicates or edge cases, also pays off later - when a customer disputes a payment weeks after the fact, having the original raw response from the gateway on file is often the only way to resolve the disagreement definitively, rather than relying on memory or an incomplete order record.
Payment gateway integration is usually part of the broader e-commerce or custom website build rather than a separate line item, and it is one of the reasons e-commerce sites in Nepal run higher than a basic brochure site - typically NPR 1,00,000-5,00,000+ depending on complexity, against roughly NPR 30,000-1,20,000 for a basic informational site. Both eSewa and Khalti also take a transaction commission on each payment processed, which is a cost of doing business worth factoring into product pricing, separate from any development cost.
Arcetis has built this kind of integration as part of custom web development work for Nepali clients, and the standing practice is to always verify transactions server-side regardless of how the frontend behaves - not because any particular client requested it, but because it is the only version of this that is actually safe to ship. This is treated as a non-negotiable baseline on every project, not an optional upgrade a client has to specifically ask for and pay extra toward.
Businesses should also budget time, not just money, for the back-and-forth that merchant approval sometimes requires - incomplete documentation or a mismatch between the registered business name and the bank account name are common reasons an application gets sent back for correction, and building in a buffer of a couple of weeks before a planned launch avoids this becoming a last-minute crisis.
eSewa generally has the broader and longer-established merchant network, while Khalti has a strong, younger mobile-first user base. Most serious e-commerce or booking sites end up integrating both rather than picking one, since each captures a meaningfully different slice of customers.
It varies, but commonly ranges from a few days to a few weeks depending on how complete the submitted business documents are. Starting the merchant application well before a planned launch date avoids it becoming the bottleneck.
Yes. The redirect alone is not proof of payment - it can be manipulated client-side. A server-to-server call back to the gateway to independently confirm the transaction status and amount is the only reliable way to mark an order as paid.