Launching an Online Store in Nepal: The Technical Checklist

eCommerce6 min read

The things that get skipped before launch and cost money afterwards — from phone validation at checkout to what happens when a payment callback never arrives.

Most online stores in Nepal launch working. They also launch with the same set of gaps, and each gap becomes a recurring cost that nobody attributes back to the launch.

This is the list worth going through before you turn a store on, based on what breaks first.

Checkout

Phone number is mandatory and validated. In this market the phone number is the delivery mechanism, not a nice-to-have. Validate the format at entry. An order with a bad number is a return waiting to happen.

District or zone is a selector, not free text. Free-text addresses cannot be routed, cannot be priced by zone, and cannot be handed to a courier API without a person cleaning them.

There is a landmark field. Customers will describe their location by landmark whatever your form looks like. Give it a field so it arrives structured instead of jammed into the street line.

Guest checkout works. Forcing account creation before a first purchase costs orders, and in a COD market where trust is the barrier, it costs more than usual.

COD is a proper payment method. Not “other”. It needs its own order state and its own reconciliation path.

Payments

Server-side verification on every transaction. Never mark an order paid on the strength of a browser redirect. Ask the provider’s API whether that reference succeeded, and for how much.

Callback handling is idempotent. Duplicates will arrive. Handle them.

Pending payments time out. Otherwise the order list fills with abandoned attempts nobody can interpret.

There is a reconciliation job. Something that periodically checks pending transactions against the provider and resolves the ones where the callback never arrived. Without it, support staff resolve these by hand forever.

More on all of this in payment gateways in Nepal.

Stock

One stock pool across every channel. Website, marketplace, physical counter. Overselling because two channels each thought they had the last unit is the most avoidable customer complaint there is.

Stock decrements at the right moment. On order, or on payment, or on dispatch — pick one deliberately. Each has different failure modes and the wrong choice for your business shows up as either overselling or phantom stockouts.

There is a plan for out-of-stock. Hide, show as unavailable, or accept backorder. Silently allowing a purchase of something you cannot ship is the worst option and the most common default.

Delivery

Shipping rules are configured, not hard-coded. Zone pricing, weight bands and free-shipping thresholds change. They should be data.

Courier integration exists, or the manual path is deliberate. Manual entry is fine at low volume as long as you know the threshold at which it stops being fine. See connecting your online store to a courier in Nepal.

Customers get a tracking link. By SMS. Most delivery-related support contact disappears when customers can check for themselves.

Content and SEO

Every product page has a unique title and description. Templated titles that differ only by product name compete with each other and rank for nothing.

Product images are compressed and sized. The single largest cause of slow stores. A 4MB photograph on a product listing page multiplied by twenty products is a page nobody on mobile data will wait for.

Structured data on product pages. Product schema with price and availability is what makes rich results possible.

Canonical URLs are set, especially with variants and filters. Faceted navigation generates enormous numbers of near-duplicate URLs. Without canonicals, that is what gets crawled instead of your actual products.

robots.txt and a sitemap exist and are correct. Cheap, and routinely wrong.

Return and refund policy is published and specific. Vague policies generate disputes.

Terms and privacy policy exist. Also frequently required by payment providers during onboarding.

Contact details are real and visible. A phone number and a physical address do more for conversion in this market than any design change. Buyers are checking whether you are a real business.

Delivery timeframes are stated honestly. Under-promising costs a few orders; over-promising costs reviews.

Operational readiness

Someone owns the order queue, with defined hours and a defined response time.

There is a process for a failed delivery. Who calls, how many attempts, and when it becomes a return. Decide before it happens, not during.

Order confirmation SMS goes out immediately. It reassures the customer and it validates the phone number — a bounce tells you the order is at risk before you have shipped anything.

Analytics is installed and configured before launch, not after. You cannot analyse traffic you did not measure.

Before you turn it on

Place five real orders yourself, on a phone, on mobile data, in a district you do not ship to often. Pay one by each method. Cancel one mid-payment. Let one fail delivery deliberately.

Almost everything on this list that is broken will surface in those five orders, and finding it then costs nothing.

We build eCommerce software for sellers in Nepal with payment reconciliation, courier integration and shared stock built in rather than added under pressure later. If you are preparing to launch, talk to us.

Read next

Stay Updated with the Latest Tech