An ecommerce development company in Delhi that knows what breaks here
Storefronts built for an Indian buyer fail in specific, predictable ways — a checkout that treats UPI as an alternative, a COD flow with no RTO model, GST that falls apart the moment you ship to Haryana. We build for those first.
- UPI-first checkout
- COD modelled on RTO
- GST at invoice level
Checkout, in the order Indian buyers actually pay
UPI is the default here, not a fallback. On most storefronts we take over, UPI sits below cards in the checkout because the theme was written for a market where that made sense — and the drop-off at the payment step is the single largest leak on the site. We put UPI first, with the intent flow on mobile and a QR on desktop, and card payments second.
Card storage has to follow RBI's tokenisation rules, so saved cards work through network tokens rather than a PAN sitting in your database. If you are on a gateway that still lets you store raw card data, that is a liability rather than a feature, and it is usually the first thing we change.
Cash on delivery is a fulfilment path, not a toggle
COD is still a real share of consumer orders in and around Delhi, and it behaves nothing like a prepaid order. Return-to-origin eats margin quietly: the courier charges both legs, the stock comes back late, and the order looks like revenue in the dashboard until it does not.
We model COD properly — an order value ceiling, pin-code level eligibility rather than a blanket on/off, an OTP or WhatsApp confirmation step on higher-value carts, and RTO reporting that sits next to the revenue number rather than three clicks away. For NCR pin codes the serviceability picture is good; the moment you sell outside it, the difference between what Delhivery, Bluedart, Shiprocket and Xpressbees will actually deliver to becomes something the storefront has to know before the customer reaches payment.
GST that survives an interstate order
A Delhi seller shipping within Delhi charges CGST and SGST. The same order going to Gurugram or Noida is interstate and becomes IGST, and the invoice has to say so. Getting this wrong is not a cosmetic bug — it surfaces at filing, months later, on hundreds of orders at once.
So place-of-supply logic goes in at the invoice layer, not as a display rule. Above the e-invoicing turnover threshold the IRN and QR code have to be generated and stored against the order. HSN codes belong on the product record rather than in a spreadsheet somebody maintains separately. None of this is difficult; it is just usually left until after launch, and it is far more expensive there.
The catalogue problems particular to Delhi sellers
A lot of ecommerce work in this city starts from a wholesale catalogue rather than a retail one. Apparel and hosiery exporters around Gandhi Nagar, homeware and handicraft houses, industrial suppliers in Naraina — the product data lives in a printed rate list or an agent's head, with sizes, MOQs and customer-specific pricing that no consumer template expects.
That shapes the build. Customer-group pricing has to be real rather than a discount code. Bulk and break-pack quantities need to coexist. Buyers who have ordered on trade terms for twenty years will not fill in a consumer checkout, so the storefront usually needs a quote path alongside the buy path. This is the most common ecommerce brief we get in Delhi and it is nothing like building a D2C store.
Working with us on it
We are in Bali Nagar, West Delhi, so kick-offs, catalogue workshops and launch days happen in person — for a wholesale catalogue that matters, because the pricing rules are usually easier to extract across a table than over a call. Everything between those runs remotely, with a preview link from day three.
What people ask us
All three, and the choice follows the catalogue. A clean consumer catalogue usually belongs on Shopify. A wholesale catalogue with customer-specific pricing and MOQs often does not, and forcing it there costs more in apps and workarounds than a custom build would have. We tell you which case you are in during the framing week.
Yes, and we usually do. UPI first with the intent flow on mobile and a QR on desktop, cards second through a gateway that supports RBI-compliant tokenisation. The ordering alone tends to move completion rates more than most checkout redesigns.
As a real fulfilment path — order value ceilings, pin-code level eligibility, confirmation on higher-value carts, and RTO reported next to revenue rather than buried. Pretending COD is just another payment button is how margin disappears without anyone noticing.
That is exactly where most storefronts break. Place-of-supply logic goes in at the invoice layer, so a Delhi-to-Delhi order is CGST plus SGST and a Delhi-to-Gurugram order is IGST, with e-invoicing IRN and QR generated above the turnover threshold.
It is most of what we do here. Customer-group pricing, MOQs, break-pack quantities and a quote path alongside the buy path are all normal requirements for Delhi trade sellers, and they are the reason a consumer template usually will not fit.
No — the payment, COD and GST work applies anywhere in India. Being in Delhi or NCR just means the kick-off and catalogue sessions happen in person at our office in Bali Nagar or yours.
Want a second opinion before you spend the budget?
Half an hour with a senior engineer. No slides, and no sales call pretending to be something else.