Checkout friction in Indian ecommerce, in the order it loses orders

The standard checkout advice assumes a buyer with a saved card, a postal address that fits three fields, and a courier that reaches every door. An Indian buyer on a phone has a UPI app, an address that includes a landmark and no house number, and a pincode your courier may or may not serve. A checkout that ignores those facts loses the order, and it loses it quietly. The buyer does not complain. They close the tab.

We have rebuilt checkouts for stores selling everything from toys on rental to rugged electronics, and the points of loss repeat. They are listed here in the order we have seen them cost orders, most frequent first.

COD is a decision the buyer makes before the payment step

A buyer who intends to pay on delivery decides that on the product page. If the store never says whether COD exists, they arrive at payment with one question and leave the moment the answer is no. If COD sits below three prepaid options with a fee added on the last screen, the fee reads as a penalty and the order is abandoned at the point of highest effort.

State the COD position early and state it plainly. "Cash on delivery available" or "Prepaid only" on the product page, next to the delivery estimate. Where you charge a COD fee, show the two totals side by side on the payment step, COD and prepaid, so the buyer sees a choice and not a surcharge. One option is to make prepaid cheaper by a small fixed amount instead of making COD dearer; the arithmetic is identical and the framing is not.

Whether to offer COD at all is a cost question. An RTO on a COD order costs you outbound shipping, return shipping, and the days the unit was out of stock. Work out what one return costs and what fraction of COD orders come back before you set the fee. The COD and RTO Cost Calculator does that sum from your own numbers.

UPI is the default prepaid path, so it cannot be the fourth tab

On a phone, the prepaid buyer wants to tap a button, land in their UPI app, approve, and come back. A payment page that opens on card number, expiry and CVV, with UPI under a tab labelled "Other methods", has asked that buyer to do work they did not expect. Some will find it. Some will type a card. Some will leave.

Put UPI first on mobile. Use the intent flow, where tapping a button hands off to whichever UPI app is installed, ahead of the collect flow where the buyer types a VPA and waits for a request that may land in a different app or arrive after they have given up. On desktop, where there is no app to hand off to, show a QR code the buyer scans from their phone, and poll for the payment status so the page confirms on its own.

Two things break this even when UPI is placed correctly: a timeout tuned for card payments, too short for a buyer who has to unlock a second app, and a return URL that loses the cart when the browser reloads on the way back. Test both on a real phone, not in a desktop emulator.

A pincode check at checkout is a serviceability check three pages too late

The buyer has chosen a size, added to cart, entered their name and phone, typed their address, and then the checkout says the pincode is not serviceable. Everything before that message was wasted, and the buyer knows it. Revealing it after payment, as a cancellation and refund, is worse.

Ask for the pincode on the product page. One field, six digits, one answer: deliverable or not, and if deliverable, the expected date and whether COD is available there. Remember it in a cookie so the buyer types it once. The same lookup then pre-fills the checkout, and the checkout's own check becomes a confirmation, not a surprise.

The lookup needs a real serviceability table behind it, built from your courier partners' pincode lists and refreshed when they change. A check that answers yes to everything converts a lost order into a cancelled one. Where you ship on your own rate card, the Shipping Cost Calculator gives the per-zone cost the pincode answer should quote.

Indian addresses do not fit a form designed for house numbers

A typical address reads: "Flat 302, Shanti Apartments, behind the SBI branch, Sector 12, Noida." There is no house number on a street. The locating information is a building name and a landmark. A form with "Address line 1", "Address line 2", "City", "State" and "ZIP" forces the buyer to guess where the landmark goes, and validation that rejects a line without a digit rejects a correct address.

Structure the form around how the address is written and how the courier reads it. The fields that work are shown below, in the order the buyer thinks of them:

Pincode          6 digits, entered first, auto-fills city and state
Flat / House     "Flat 302" or "H.No. 14" or "2nd floor", free text
Building / Area  "Shanti Apartments, Sector 12", free text
Landmark         "Behind SBI branch", optional but its own field
City, State      pre-filled from pincode, editable
Phone            10 digits, the field the courier will use

Pincode first fills city and state, triggers the serviceability check, and removes two fields the buyer would otherwise type. The landmark gets its own field because couriers use it, and a landmark buried in address line 2 gets truncated on the label. Do not validate any free-text field for format. A minimum length is the only check that helps.

OTP verification interrupts whatever step it sits on

Stores ask for an OTP on the phone number for two reasons that hold up: it cuts fake COD orders and it confirms the number the courier will call. The problem is where it lands. An OTP demanded before the buyer has seen the cart total, or one that appears between the payment button and the payment page, breaks momentum at the worst possible point. On a phone the buyer leaves the browser to read the SMS, and a page that has reset itself when they return has lost the order.

Verify once, when the number is entered, and never again in the session. Use the Web OTP API so a supporting browser reads the SMS and fills the code without an app switch. Keep every filled field when the page regains focus. For prepaid orders, consider skipping OTP altogether, since the payment proves the buyer is real; reserve it for COD, where the risk exists.

Test the checkout the way the buyer meets it

1. Open the store on a mid-range Android phone over mobile data, not on your office wifi.
2. Pick a product, enter a pincode you know is not served, and note how many screens pass before the store tells you.
3. Enter a real address with a landmark and no house number, and see whether the form accepts it without a fight.
4. Pay with UPI through the app switch, and confirm the cart survives the return to the browser.
5. Place a COD order and count every OTP, fee and confirmation step between the payment button and the order page.

Run those five steps after every checkout change. Analytics reports each of these failures as a drop between two funnel steps, with no explanation attached.

Why do Indian ecommerce checkouts lose orders at the payment step?

Because the buyer reaches payment without the answers they needed earlier: whether COD is offered, whether their pincode is served, and whether UPI is available. Fix it by stating COD terms and checking the pincode on the product page, placing UPI first on mobile, building the address form around landmarks, and verifying the phone number once.