Most of what gets called COD cart abandonment in India isn't abandonment at the payment step at all. It's a customer on a 4G connection who tapped "Buy Now", waited 3 seconds for a cart drawer, scrolled past a pin-code field that didn't work, typed a 10-digit phone number, then discovered a ₹49 COD fee at the payment step. Each of those is a separate, fixable thing. Lumping them into one number called "checkout abandonment" is why most stores never fix any of them.
We've rebuilt enough Indian and GCC checkouts to say this with some confidence: the COD-specific frictions cost more than the generic ones. Trust badges and exit-intent popups get all the attention. Pin-code serviceability, fee disclosure timing and OTP flows are where the money is.
Where COD cart abandonment in India actually happens
Shopify gives you a checkout funnel report — sessions that reached checkout, added contact info, added shipping, added payment, completed. Pull it for mobile only, over 30 days. Then pull the same for desktop. On a typical Indian D2C store the mobile drop between "reached checkout" and "contact info" is the biggest single leak, and it has almost nothing to do with the payment methods you offer.
That step is where the customer types a phone number and an address. On a 5.5-inch screen. Possibly with an OTP app interrupting. If you only look at the payment-step drop-off, you're auditing the last 20% of the problem.
Friction 1: the cart nobody waited for
A cart drawer that fires three app scripts before it renders will lose people who had their thumb on the button. We see this constantly on stores running an upsell app, a reviews app, a WhatsApp widget and a currency switcher, all loading synchronously. Largest Contentful Paint on the product page sits at 3.2–3.8s on a throttled mobile profile, and the cart interaction feels worse than the number suggests because it happens after the main thread is already busy.
Get the PDP LCP under 2s and the cart open in under 400ms. That usually means deferring anything that isn't the buy button, killing one or two apps outright, and serving product images at the size they're actually displayed. Our Shopify speed optimization work starts with an app-script audit before anyone touches Liquid, because trimming 400KB of third-party JS beats any amount of image tuning. If you want to see where you stand before committing to work, SwiftStore scans the store, fixes the mechanical issues and tracks the score so you know whether a change helped or a new app quietly undid it.
Frictions 2 and 3: pin-code uncertainty and the late fee
Two of the most expensive COD frictions are both disclosure problems.
The first: a customer in a tier-3 town doesn't know whether you deliver to them, or whether COD is available there, until they've filled in the entire address. Your 3PL knows. Delhivery, Shiprocket, Bluedart, XpressBees all expose serviceability by pin code. Put that check on the product page, above the buy button, and have it return three things — deliverable yes/no, COD available yes/no, and an ETA date range. Not "3–5 business days". A date. "Arrives 12–14 Feb, COD available."
The second: the COD fee. If you charge ₹49 or ₹79 for cash on delivery and the customer meets it for the first time on the payment step, you have engineered a moment of resentment at the exact point you need trust. Show it on the PDP next to the pin-code result and again in the cart. The customers who were going to bail on the fee will bail earlier and cheaper, and the ones who accept it won't feel ambushed.
Implementing this cleanly on Shopify is where plans start to matter. Native payment customization and delivery customization Functions — hiding COD above a cart value, above a weight, or outside a pin-code list — are Shopify Plus features. On Basic or Grow you're doing it with an app, or with a line-item surcharge, which is uglier and interacts badly with discount codes. That's a genuine reason to look at Plus, and one of the few we'll argue for on merit. Most of the others are not worth the jump until you're well past ₹1 crore a month.
Friction 4: OTP steps that fail quietly
Phone verification before order placement is the standard answer to fake COD orders. It works. It also does not reduce abandonment — it relocates it. You are trading order volume for order quality, and that's a defensible trade, but only if you know the exchange rate.
Where OTP flows leak:
- SMS doesn't arrive because the DLT template isn't approved for the header being used, or the operator throttles it during a festive traffic spike. The customer waits 40 seconds, taps resend, waits again, closes the tab.
- The OTP field doesn't accept a paste, or doesn't auto-read the code, so the customer has to leave the browser, open Messages, memorise six digits and come back. Mobile browsers restore tabs unreliably. Some of those people never come back.
- There's no fallback. If SMS fails, offer WhatsApp or a voice call. If both fail, let the order through and verify after.
- The step fires before the customer has committed to anything, so it reads as a login wall.
Our default now is to verify after the order is placed, over WhatsApp, with a one-tap confirm. You capture the order, then filter. The RTO reduction is comparable and the checkout stays one screen. If you're going to do OTP pre-order anyway, at minimum test resend timing and paste behaviour on a real mid-range Android, not on your laptop's device emulator.
Frictions 5 and 6: the address form and the payment screen
Shopify's one-page checkout is good. The things bolted onto it usually aren't. Two specifics we fix on nearly every build:
Autofill. Custom address fields, reordered inputs and third-party address widgets break browser autofill and Google's address prefill. A returning customer who could have filled the form with one tap now types 60 characters. Check that every field has the correct autocomplete attribute and that the pin code populates city and state. Also check the phone field: if it strips the leading zero some customers type, or rejects a +91 prefix, you've just invented an error message.
Payment method order. If 65% of your orders are COD, COD should not be the fourth option below UPI, cards, netbanking and three wallets. Sort by actual usage and collapse the rest behind "other methods". And put the COD fee inline next to the COD label, in rupees, with the total already recalculated. A customer who has to do arithmetic in the checkout is a customer thinking about whether to bother.
Razorpay's Magic Checkout is worth evaluating if your address quality is poor and you want prefilled addresses and a shorter COD path. The trade-off is real: you hand a chunk of the checkout experience and its analytics to a third party, and your ability to customise it is limited by their roadmap rather than yours. We've shipped it where it fit and pulled it out where it didn't.
Friction 7: COD rules that fire too late
This one is a straightforward engineering failure and we still see it weekly. The store hides COD for carts over ₹5,000, or for a specific pin-code list, or for a pre-order SKU. Fine. But the rule evaluates at the payment step, after the customer has typed their name, phone, address and landmark. They reach payment, COD is gone, no explanation. That's not a policy problem, it's a sequencing problem.
Evaluate eligibility as early as you can know the answer. Cart value is known in the cart, so say it in the cart: "COD not available on orders above ₹5,000." Pin code is known the moment they enter it. SKU-level exclusions belong on the product page. If a developer tells you this can't be surfaced before checkout, they mean it's inconvenient, not impossible.
Friction 8: the prepaid discount, usually priced wrong
Everyone offers one. Very few have checked the maths. Here's the calculation with numbers you can swap for your own.
Say you do 5,000 orders a month, 70% COD, so 3,500 COD orders. AOV ₹1,200. Your RTO rate on COD is 18%. Cost of an RTO: ₹65 forward freight, ₹65 reverse, ₹40 handling and repack — ₹170. COD remittance fee 1.5% of order value, so ₹18 per COD order.
You offer 5% off for prepaid. That's ₹60 per order. Assume it converts 15% of your COD orders to prepaid: 525 orders.
- Cost of the discount: 525 × ₹60 = ₹31,500
- RTOs avoided: 525 × 18% = 94.5 orders, at ₹170 = ₹16,065
- Remittance fees avoided: 525 × ₹18 = ₹9,450
- Total saved: ₹25,515
You paid ₹31,500 to save ₹25,515. That discount loses about ₹6,000 a month, before you count the customers who would have paid prepaid anyway and just took the money. Run it at 3% (₹36) and the cost drops to ₹18,900 against the same ₹25,515 — now it works, with roughly ₹6,600 of margin and a real cash-flow benefit from money arriving today instead of in 12 days.
The point isn't that 3% is the right number. It's that the right number falls out of your RTO rate, your freight cost and your remittance fee, and it's often lower than the 5–10% stores reach for by default. If your RTO is 30% rather than 18%, a 5% discount is comfortably profitable. Check, don't copy.
The order we fix these in
Speed first, because everything else is measured through it and because a slow store makes every other test noisy. Then disclosure — pin code, ETA, COD fee, eligibility rules, all moved as early in the journey as the information exists. Then the form itself: autofill, phone validation, payment method ordering. OTP last, because it's the one where you're deliberately accepting friction and you want a clean baseline before you add it.
Instrument each change separately. If you ship four fixes in one release and conversion moves 0.6 points, you've learned nothing about which one to do again on the next store.
If you want a second pair of eyes on where your mobile COD funnel is leaking, our free audit covers the checkout path, the app-script load and the serviceability flow, and tells you which of the eight above is actually costing you money on your store rather than in general.