Building an online store in Nepal.

Before any platform conversation, three local realities shape every decision that follows. Getting these wrong is how a technically competent store fails commercially.

Cash on delivery is not an edge case

In most Nepali categories, cash on delivery is the majority payment method, not a fallback. That has consequences well beyond a checkout option. It means you carry the cost of delivery on orders that get refused at the door, so your returns rate is a logistics problem rather than a customer-service one. It means order confirmation by phone before dispatch is standard practice, not poor service. And it means your margin model has to survive a refusal rate that in some categories reaches one order in five.

Wallets, not cards

eSewa, Khalti, IME Pay, and Fonepay together account for far more digital transactions than card payments do. Building a checkout that leads with a card form and buries the wallets is a straightforward way to lose conversions. Lead with what people use.

Addresses are descriptive, not structured

A Nepali delivery address is frequently a landmark and a phone number rather than a house number and a postcode. A checkout that demands a rigid structured address, or validates a postcode, will simply fail. Take a free-text address field, require a phone number, and make the landmark field prominent, because that is the field the rider will actually use.

There are four realistic routes, and the correct one depends far more on your catalogue size and payment needs than on anybody’s technology preference.

If you are already selling and the manual process is the bottleneck, that is the moment a real store pays for itself. For most businesses at that stage WooCommerce is the pragmatic choice, and it stops being the right one at roughly the point where you have a few thousand products, several thousand daily visitors, or logic that no plugin models.

Each gateway is its own small project: a merchant application, a sandbox, a signature scheme, and a set of failure cases to handle. Budget for them individually rather than as one line item called “payments”.

• eSewa. The widest consumer reach in Nepal. Merchant registration requires business registration documents and a PAN or VAT certificate. Integration is a redirect flow with a hashed signature, plus a verification call you must make server-side before you treat an order as paid.
• Khalti. Strong with younger urban customers and a noticeably better developer experience. Similar documentation requirements, a cleaner API, and a proper sandbox.
• Fonepay. Reaches customers through their own bank apps rather than a separate wallet, which broadens who can pay you. Onboarding usually goes through your bank.
• Connect IPS. Direct bank transfer, useful for higher-value orders where wallet limits become a constraint.
• International cards. Realistically this means Stripe or PayPal through a foreign entity, or a local acquirer with materially higher fees. If you sell to the diaspora, this is worth the trouble; if you do not, it usually is not.

The two mistakes that cost real money

First: trusting the browser. Every gateway returns the customer to your site with a success parameter, and every one of those parameters can be forged by hand. An order must only be marked paid after your server has independently verified the transaction with the gateway’s verification endpoint. This is the single most common security defect we find in Nepali stores, and it is trivially exploitable.

Second: not handling the abandoned middle. A customer who reaches the wallet, pays, and loses connectivity before returning must still end up with an order. Reconcile against the gateway on a schedule and alert on mismatches, because otherwise the customer has paid and you have no record of it.

Fulfilment is where Nepali e-commerce is actually won or lost, and it is mostly not a software problem. What software can do is stop it becoming a mess.

• Inside Kathmandu Valley, same-day or next-day delivery through a local courier or your own riders is achievable and is a genuine competitive advantage. Say so on the product page, not just at checkout.
• Outside the Valley, set expectations explicitly by region. A stated three to five days that you meet beats a promised two days that you miss.
• Zone your shipping rates by district rather than charging one flat national rate. A flat rate either loses money on distant orders or overcharges local ones.
• Give every order a status the customer can see without messaging you. Most support volume in this market is people asking where their parcel is.
• Send SMS rather than relying on email. Order confirmation, dispatch, and out-for-delivery messages by SMS or Viber cut your support load substantially.
• Build the cash-on-delivery reconciliation into the admin from the start: what the courier collected, what they remitted, and what is outstanding. Retrofitting this onto a live store is miserable.

This is the highest-leverage page type on the site and usually the most neglected. Two changes outperform almost anything else you could do: real photographs, and answering the objection.

• Photograph the actual product, from several angles, including one shot with something familiar beside it for scale. Manufacturer stock photos read as reselling, and in a market with real counterfeit anxiety that costs you the sale.
• Write the specification out fully. Dimensions, material, warranty, what is in the box, whether it needs an adapter. Every unanswered question is a reason to close the tab.
• Put the delivery estimate and the return policy on the product page, not three clicks away in a footer link.
• Show the price in NPR including any VAT, and state delivery cost before checkout. Surprise charges at the final step are the largest single cause of abandonment.
• Use structured data. Product markup with price, availability, and reviews gets you rich results in Google Shopping surfaces, and almost nobody in this market does it.
• Collect and display reviews, even a handful. In a low-trust market social proof does more work than any amount of design.

Work through this on a real phone, on mobile data, with a real card and a real wallet, before you announce anything.

1. 1Place a complete order through every payment method you offer, including cash on delivery, and confirm the order appears correctly in the admin.
2. 2Deliberately fail a payment and confirm the customer sees a sensible message and no order is created.
3. 3Confirm that server-side verification, not the redirect parameter, is what marks an order paid. Try forging the success URL and confirm it does nothing.
4. 4Check the store on a mid-range Android phone on 4G. Product listing pages with many images are where stores get slow.
5. 5Confirm order confirmation SMS and email both actually arrive, from an address that is not flagged as spam.
6. 6Set stock levels and test what happens when something sells out mid-checkout.
7. 7Enable HTTPS everywhere and confirm there are no mixed-content warnings on any page including checkout.
8. 8Add Product and Organization structured data, submit the sitemap in Search Console, and confirm product pages are indexable while cart and checkout are not.
9. 9Set up Google Analytics e-commerce tracking before launch, not after. Retroactive data does not exist.
10. 10Write the returns and privacy pages properly. They are a trust signal as much as a legal requirement.

Add to any of these the annual running cost, which for e-commerce is meaningfully higher than for a brochure site: real hosting rather than shared, maintenance that includes retesting payment flows when a gateway changes, and per-transaction gateway fees of roughly two to three and a half percent.