Understanding COD Verification for Shopify Orders

Verification is the cheapest intervention in COD operations, because it is the only one that happens before you spend money. Once a parcel is packed and handed to a courier, every rupee of forward shipping is committed whether or not the customer ever intended to pay. A confirmation step sits in the gap between those two moments, and what you do with that gap largely determines your RTO rate.

What verification actually establishes

It is worth being precise about this, because merchants often expect verification to do more than it can. A confirmation step establishes two facts and no others.

That the phone number is real and monitored. A number that receives a message and responds belongs to someone who is reachable. That alone eliminates a category of failure — orders placed with mistyped or fabricated numbers, which the courier will never be able to call, and which are returned after two silent delivery attempts.

That the customer will spend ten seconds on the order. This is the intent signal, and it is weaker than it sounds but more useful than it looks. A customer who taps a confirmation link has not promised to pay. They have, however, done something — and the population that does something is measurably more likely to accept delivery than the population that ignores three messages.

What verification does not establish: that the address is deliverable, that the customer will have cash on the day, that they still want the product by the time it arrives, or that they are not a repeat refuser. Those need other controls. Treating verification as a complete answer to RTO is the most common way merchants end up disappointed with it.

Where it sits in the order

The useful window is after the order is created and before anyone picks stock for it. Earlier is not possible; later is pointless, because the cost you are trying to avoid has already been incurred.

That sounds obvious and is routinely got wrong. Brands that verify after generating a shipping label have already paid the handling cost. Brands that verify after pickup are confirming orders that are already moving. If your verification step runs on a batch at the end of the day while picking happens continuously through it, the two are not actually sequenced — they only look sequenced on a diagram.

The second consideration is that verification adds time, and time is itself an RTO cause. An order held two days awaiting confirmation is an order whose customer has had two extra days to change their mind, or to receive the same product from a faster competitor. The window has to be tight enough that the cure does not become the disease: hours, with a clear default action when the window closes, rather than an open-ended hold.

Choosing the channel

Nearly every COD app lists OTP verification. The channels behave very differently in practice, and the differences matter more than the feature list suggests.

SMS is universal and cheap, and in India it competes with a great deal of promotional traffic. Many customers do not read it. A low SMS response rate frequently means the message was never seen, not that the order was fake — which is exactly the misreading that causes merchants to cancel good orders.

WhatsApp generally performs best in the Indian market. The detail worth checking before you commit is whether the app uses the official WhatsApp Business API. Unofficial implementations are cheaper and carry a real risk of the number being blocked, which takes your primary verification channel down without notice and usually at the worst moment.

Automated voice calls reach customers who ignore text altogether. Fewer apps offer this, and it is disproportionately useful where your customer base skews older or less app-literate. It is also the channel most likely to be perceived as intrusive, so it works best as an escalation rather than a first contact.

The practical answer is a sequence rather than a single channel: try the highest-response channel first, escalate after a defined interval, and only treat an order as unconfirmed after the sequence is exhausted. Running one channel and reading silence as refusal will cost you genuine orders every single day.

Designing the message

A confirmation message has one job: make the required action obvious in the three seconds before the customer decides whether to engage.

Identify the order in terms the customer recognises — the product name, not just an order number. An order number means nothing to someone who placed the order on their phone an hour ago; “your order for the olive linen shirt” is instantly recognisable.

State the amount and the payment method plainly. Part of what you are confirming is that the customer understands they will be asked for cash on delivery, and how much. Surprise at the door is a refusal cause in its own right.

Ask for one action. A message that requests a reply, offers a link, and mentions a support number is three decisions, and three decisions is slower than one. Keep any additional options to a second line.

Do not ask for information you already hold. Requesting the customer re-enter their address or phone number reads as a security check rather than a courtesy, and it depresses response.

And say what happens if they do nothing. A customer who knows the order will be held is far more likely to act than one who assumes it is proceeding regardless.

Verifying everything stops working at scale

At low volume you can confirm every COD order and the cost is trivial. Past a few hundred a day two problems appear.

The first is messaging cost, which is the real expense in this category — the apps are mostly free to install, and the per-message charges are where the money goes. The second is friction applied where it is not needed: sending a verification request to a customer with three successful deliveries behind them adds work for your team, cost for you, and mild irritation for a person who has already proved they are good for it.

The answer is to route by risk rather than verify uniformly. Order value, pincode history, customer history, product category and acquisition source are all available to you, and some combination of them will separate the orders that need a confirmation from the ones that do not. Your operations team should be handling exceptions, not every order that arrives.

The most predictive input is your own refusal history. Numbers that have refused before, pincodes with chronic failure rates, the order-value band where your own refusals cluster. A blocklist built from your own data outperforms any generic risk score, and costs nothing beyond the discipline to maintain it.

What to measure

Response rate by channel. This tells you whether non-response means refusal or means your messages are not being seen. Without it, every other number here is uninterpretable.

RTO rate on confirmed versus unconfirmed orders. The payoff metric. Confirmed orders should come back noticeably less often. If they do not, your verification step is adding cost and delay without filtering anything, and something upstream is wrong.

Cancellation rate on unconfirmed orders. How many orders you are killing on non-response. Watch this alongside response rate: a low response rate and a high cancellation rate together mean you are destroying good orders because your messages are not landing.

Hours from order to confirmation. The delay verification is adding. Compare it against your RTO rate by dispatch-speed bucket to see whether the step is paying for the time it costs.

Cost per verified order. Total messaging spend divided by orders confirmed, at your real monthly volume. This is the number that decides whether universal verification or risk-based triage is right for you, and it is specific to your provider and your mix.

What this adds up to

Verification is a filter applied in the one window where filtering is cheap. It is not a judgement about the customer and it is not a complete RTO programme — it establishes reachability and a minimum of engagement, and those two facts are worth having before you commit a parcel.

Get the sequencing right, keep the window short, use more than one channel, and triage by your own data once volume makes universal verification wasteful. Then measure response rate before you measure anything else, because it is the number that tells you whether you are reading your own results correctly.

COD King runs the pre-dispatch layer of this — OTP and WhatsApp confirmation, rules by pincode and order value, and the order-level data to triage on. The sequencing and the window are operational decisions that stay yours.