Building e-commerce for a market that pays in cash
Most e-commerce tutorials assume the card clears before you ship. In Nepal it usually does not. That one assumption changes the whole system.
Open any e-commerce tutorial and the happy path is the same: customer adds to cart, card is charged, order is confirmed, warehouse ships. Payment precedes fulfilment, and the platform's entire risk model rests on that ordering.
Now invert it. In Nepal, cash on delivery is not a niche option, it is the default. The customer pays the courier at the door, days after the order was placed. Everything downstream of that single change has to be designed differently.
We hit this properly while building NepCase, a phone case retailer shipping to all seven provinces.
Your order state machine grows a new failure mode
With card payment, an order is either paid or it does not exist. With cash on delivery, an order can be placed, dispatched, out for delivery, and then refused at the door. The stock was committed, the courier was paid, and no money arrived.
That means:
- Inventory must be reserved on order, not on payment, or you oversell.
- It must be released automatically when a delivery is refused, or your stock counts drift until someone reconciles by hand.
- Refusal rate is a real metric. It belongs on a dashboard next to revenue, because it is revenue.
None of that exists in the standard tutorial, because the standard tutorial never has to model a customer changing their mind while holding the box.
Address quality is the actual hard problem
A card payment validates itself. An address does not.
Large parts of Nepal do not have the kind of structured postal addressing that address-autocomplete APIs assume. What you get instead is a landmark: "near the pipal tree, third house past the school." That is genuinely useful to a local courier and completely useless to a validation library.
So we stopped trying to validate addresses into a schema and started capturing what actually helps delivery. Free text, a phone number that is unambiguously reachable, and province and district as the only structured fields that matter for routing.
The phone number does more work than the address. It is how the courier resolves the last hundred metres.
Delivery cost is a product surface, not a shipping setting
Shipping to Kathmandu is not the same as shipping to Sudurpashchim. If you flatten that into one national rate you either lose money on distance or overcharge the customers hardest to reach.
We surfaced free nationwide delivery as a deliberate positioning choice, with the cost modelled into pricing rather than bolted on at checkout. That is a business decision the software has to support cleanly, not a config value.
What holds up on a bad connection
Product photography for phone cases is the whole sell, and photographs are heavy. On mobile data outside the valley, a beautiful gallery that takes eight seconds to appear is a lost sale.
The unglamorous work is what pays: aggressive image compression, correct dimensions rather than CSS-scaled originals, lazy loading below the fold, and a catalogue that filters client-side once loaded rather than round-tripping for every filter change.
The lesson generalises
Every market has an assumption baked so deep into the standard tooling that nobody writes it down. For Western e-commerce it is that payment precedes fulfilment. For Nepal it does not.
Find the assumption, and you find the work that actually has to be done.
Building something like this?
We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.