Partial Payment on Shopify COD Orders

Cash on delivery is a free option. The customer takes it at checkout, decides at the door whether to exercise it, and you carry the forward shipping, the return shipping and the tied-up capital either way.

Partial payment is the cheapest available way to change that, and the interesting thing about it is that it does not work the way most merchants assume.

It is behavioural, not financial

The instinct is to think of partial payment as reducing exposure. If the customer pays 15% up front, you are 15% less exposed on a rejected parcel.

That is true and it is not the point. Fifteen percent of a small order is a small sum, and it barely dents the cost of a failed delivery — you still pay both shipping legs and the handling.

What it actually changes is the customer's relationship to the order. Someone who has paid nothing has deferred a decision. Someone who has paid anything, however little, has made one. The behavioural difference at the door is large relative to the amount collected, which is why token amounts work nearly as well as substantial ones.

Understanding this matters practically, because it tells you not to reach for a large percentage. The goal is to create a decision point, not to insure the order.

Why it beats blocking

Blanket COD blocking is what merchants reach for first, and it is usually the more expensive intervention.

Blocking removes the order and all its revenue. In a market where COD is a majority payment method, that is not a marginal adjustment — it is removing most of your demand to solve a problem that exists in a minority of it.

Partial payment keeps the order, keeps the customer, and changes the economics. The customer who would have accepted the parcel still buys. The customer who was never going to accept it now either commits or does not order, and both outcomes are better than a rejected parcel.

The last two rows are worth noting together. OTP verification and partial payment address different causes — verification removes uncontactable buyers, partial payment removes uncommitted ones — so they compound rather than overlap.

Setting the amount

Two failure modes bracket the decision.

Too little and it does not read as a commitment. A trivial sum feels like a fee rather than a decision, and it produces the conversion cost without the behavioural benefit.

Too much and the customer reasons they may as well prepay in full. At that point you have not built a partial payment mechanism, you have built a worse prepaid checkout with an extra step.

Between those, the specific number matters less than merchants expect. Both fixed amounts and percentages work. Percentages scale better across a wide price range, which matters if your catalogue spans very different values — a fixed amount that is meaningful on a small order is negligible on a large one, and large orders are where RTO hurts most.

Apply it where the risk is

The most common implementation error is applying partial payment to every COD order.

RTO risk is not uniformly distributed. It concentrates by cart value, by geography, and by customer history. Applying friction uniformly costs you conversion on the orders that were never a problem.

The threshold should come from your own numbers. Export delivery outcomes, compute RTO rate by cart value band and by pincode, and let that decide where the rule applies. Almost every merchant who does this finds the problem concentrated far more narrowly than assumed — which means the rule can be narrower, and cost far less revenue, than a blanket policy.

Explaining it to the customer

This is where implementations fail on execution rather than on logic.

A partial payment requirement that appears without explanation reads as a trick. The same requirement, explained in one line, reads as reasonable — and the explanation that works is straightforward rather than defensive.

Say what is being charged now and what is due on delivery, in numbers, before the customer commits. Say why, briefly, without a paragraph of justification. And make the balance due unmistakable on the confirmation and in the delivery message, because a customer who does not have the right cash at the door produces exactly the failed delivery you were preventing.

That last point is easy to miss. Partial payment changes the amount due on delivery, and a customer expecting to pay the full price who is asked for a different figure is a customer who may refuse the parcel over confusion rather than intent.

Measuring it honestly

The metric merchants use is conversion rate, and it is the wrong one. Conversion will fall. That is the mechanism working.

The number that matters is delivered revenue net of RTO cost, per visitor. That captures both sides — the orders you did not take and the parcels you did not send back — and it is the only figure that tells you whether the intervention helped.

A reasonable evaluation:

1. Baseline first. RTO rate and delivered contribution margin, by cart value band and pincode, before changing anything.
2. Introduce the rule narrowly, on the highest-risk segment only.
3. Hold it long enough to clear the noise — weeks, not days, since RTO is only visible after the delivery cycle completes.
4. Compare delivered margin, not order count.
5. Widen or narrow based on what the data shows, rather than on how the order count feels.

Reconciliation, refunds and the operational detail

Partial payment splits one order across two payment events, and that has consequences downstream that are easy to overlook when the mechanism is being evaluated purely as a conversion lever.

Reconciliation. The prepaid portion settles through your online payment provider; the balance arrives as cash to your courier or your counter. Those are two different reconciliation paths with different timings, and your finance process needs to expect that. An order is not fully settled until both halves land, and the gap can be days.

Refunds are the awkward case. A customer who cancels after prepaying is owed the prepaid amount back, and that refund runs through the online provider while nothing was ever collected on the balance. Decide in advance what your policy is — refund in full, refund less a processing cost, or hold as credit — and state it before the customer pays rather than discovering it during a dispute.

Partial delivery. If an order ships in more than one parcel, or part of it is unavailable, the amount due at the door changes and the prepaid portion no longer maps cleanly to what arrived. This is the most common source of genuine confusion, and the answer is usually to avoid splitting partial-payment orders across shipments where you can.

Accounting treatment. The prepaid amount is received before the sale completes, which may need handling differently from a straightforward payment depending on how your books are kept. Worth a conversation with whoever maintains them before launch rather than at year end.

Where it fits with everything else

Partial payment is one intervention among several, and the order to implement them in is fairly consistent.

OTP verification first. Broadest impact, lowest revenue cost, and it addresses the largest single bucket — orders placed with a number that was never reachable.

Partial payment second, above a threshold your data supports.

Targeted risk rules third, for the specific pincodes and patterns measurement exposed.

Pre-dispatch confirmation throughout. A message that lets a buyer cancel before dispatch converts a future RTO into a cancellation, which costs you only the picking.

For the full RTO picture and the cost arithmetic behind it, see checkout and payments. Payment method selection for Indian stores is covered in the same archive.