Where should your Indian online store offer cash on delivery?

Offer cash on delivery only where your courier can collect, the basket can absorb failure costs and your business can fund the wait for payment. Start with confirmed delivery areas, recoverable products and manageable order values. Review customer history afterwards. A useful cash on delivery policy in India is selective, enforceable and measured by delivered-and-paid contribution—not orders placed.

Use three outcomes, with hard eligibility rules first

Give checkout, support and fulfilment one shared decision matrix. Apply delivery availability, product suitability and order-value limits before reviewing customer history. A loyal customer cannot override unavailable collection service. Separately, check whether total outstanding COD exposure leaves enough working capital for the next dispatch.

Choose delivery areas by courier service, not geography stereotypes

Maintain a PIN-code allowlist for each contracted courier and service. Shipping availability does not establish COD collection availability. Confirm collection limits, outward and return charges, delivery attempts, remittance timing and deductions from your agreement. These are merchant-specific terms, not facts established by Shopify’s shipping documentation. [2] Avoid blanket assumptions about metros, smaller towns or rural addresses.

For a new delivery group, cap both dispatch numbers and cash exposure. Set a review date and wait for enough completed deliveries, returns and remittances before expanding. Pause affected services during temporary disruption. If you change couriers, reassess the route rather than carrying over the previous courier’s approval automatically.

Set basket limits around contribution and recovery

Derive your minimum from the contribution left after product, fulfilment, collection and expected failure costs. Set your maximum around inventory exposure and available cash, not revenue ambition. There is no universal safe rupee threshold. Define the calculation precisely: for example, merchandise subtotal after discounts, excluding shipping. Check the final amount after every discount or basket change.

Assess personalised, perishable, bulky and fragile products by actual recovery loss. A durable standard item may return to sale; embroidery, spoilage or damage may destroy that option. State a mixed-basket rule: if any item is excluded, make the whole basket prepaid-only unless a tested alternative exists. Do not promise split payments or separate COD collections without operational support.

Verify customers without blaming them for courier failures

Give first-time customers a reasonable confirmation path, such as confirming their address, contact number and delivery intent. No history is not evidence of likely refusal. Review repeated attributable refusals, unresolved addresses and suspicious duplicate orders. Record the reason and provide a review route. Do not penalise customers for documented courier failures or failed attempts that never happened.

Keep delivery-risk assessment separate from card-fraud tools. Shopify describes its fraud analysis around verifiable online credit-card orders and chargeback risk. It is not a documented COD acceptance score. [4] A missing warning therefore does not establish that a customer will accept a parcel or that an address is usable.

Measure delivered contribution and the wait for cash

Return to origin, or RTO, means an undelivered shipment travels back to the merchant. In a simplified model where every dispatch ends as delivered-and-paid or RTO, expected contribution per COD dispatch = (1 − r)M − rL. Here, r is the RTO share, M is successful-delivery contribution and L is the loss on an RTO shipment.

Calculate M after product, fulfilment, collection, support and financing costs. Include outward and return freight, packaging, handling, unrecoverable product value and relevant financing costs in L. Count each cost once. Recoverable stock is not automatically a full product write-off. The model breaks even when r = M/(M + L); staying below that boundary is not a recommended operating target.

Track unresolved shipments, post-delivery returns and outstanding collections separately; the simple model omits these outcomes. Compare total incremental delivered-and-paid contribution against the prepaid alternative, including prepaid orders displaced by COD. Set a business-wide outstanding-COD limit covering funded stock and fulfilment, parcels in transit and collections awaiting remittance. Avoid double-counting the same exposure. Reserve cash for supplier and operating payments.

Hypothetical worked example: a home-textile merchant

Assume standard cushion covers can be inspected and resold, while personalised embroidered covers have negligible resale value. The courier confirms COD for established and new delivery groups, but the merchant has completed shipment records only for the established group. These are illustrative assumptions, not client results or claims about typical Indian delivery performance.

The same customer and PIN code can qualify for standard covers but not personalised ones. For the latter, unrecoverable production value increases L unless already included; never add it twice. Even profitable standard-cover dispatches must stop when the cash-exposure ceiling is reached. Successful delivery economics do not remove the need to pay suppliers before courier remittance arrives.

Enforce eligibility at checkout, then test it

On Shopify, COD is a manual payment method. Orders remain unpaid until payment is received and recorded. Additional details appear beside the payment method, while payment instructions appear after order completion. Shopify exempts manual payments from third-party transaction fees; this does not make courier collection free. [1] Reconcile carrier collections and bank receipts rather than treating a delivery scan as banked cash.

Shipping zones determine destinations and rates, not automatically COD eligibility. [2] Selective payment availability needs a compatible payment-customisation app and an eligible plan. Confirm that the chosen setup supports your actual conditions; Shopify’s documentation does not guarantee every app supports every rule. [3] For broader platform decisions, read Choose the store around the operation behind it.

• Test eligible, excluded and temporarily suspended PIN codes.
• Check amounts just below, at and above each threshold.
• Apply discounts and confirm the eligibility calculation updates.
• Test excluded products and mixed baskets.
• Test guests, confirmed new customers and reviewed repeat customers.
• Change the address and basket before payment; confirm rules run again.

Publish clear terms and review completed dispatch groups

Your customer policy should explain availability, threshold calculations, excluded products, mixed baskets, verified charges and confirmation requirements. When COD is unavailable, show a plain reason and a prepaid alternative, plus a support review route. This is an operational checklist, not legal boilerplate. Avoid vague rejection messages that leave customers guessing whether the restriction concerns their address, basket or delivery history.

1. Group dispatches by period, courier/service, delivery area and product type.
2. Count delivered-and-paid orders and RTOs; retain unresolved shipments separately.
3. Review refusal reasons, courier failures and stock awaiting inspection.
4. Calculate contribution, prepaid displacement and dispatch-to-bank time.
5. Reconcile unremitted collections against the exposure limit.
6. Expand profitable, cash-affordable groups; pause disrupted routes and revise loss-making rules.

Next, fill in the eligibility matrix using your carrier agreement and latest completed dispatch group. Assign one owner to maintain the rules and approve exceptions. If checkout cannot enforce them, resolve that gap before expansion. Softglimmer’s Shopify ecommerce development page outlines relevant implementation support; begin with the policy and acceptance tests, not an all-India COD switch.

Common COD policy questions

This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.