Converting cash-on-delivery orders to prepaid

Converting a cash-on-delivery order to prepaid means persuading the customer to pay online before dispatch, usually by offering a small incentive. It is the only intervention that removes return-to-origin risk completely rather than reducing it, because a paid order cannot come back unaccepted in the same way.

It is also the one that costs you margin on purpose, which makes it the only RTO flow that needs arithmetic before you build it.

Why it works

Cash on delivery is the default in much of the world for a reason — it removes the buyer's risk. Razorpay, citing ET Prime Research, puts it at 60–65% of Indian ecommerce orders, and the pattern holds across Pakistan, Bangladesh, Egypt, Indonesia and Nigeria.

But the same feature that reassures the buyer is what exposes you: nothing has been committed, so declining at the door costs them nothing. GoKwik's own network data puts average RTO at 23.18%. Prepaid orders do not sit in that pool.

The trend is not uniform. Checkout.com's fourth annual MENA report found cash-on-delivery preference across the region halved from 41% to 20%, dropping as low as 10% in the UAE and Saudi Arabia — so in the Gulf this is a smaller problem than in South Asia.

The arithmetic

The question is what discount is worth offering, and it has an answer you can calculate from two numbers you already have: your RTO rate on cash-on-delivery orders, and what one RTO costs you.

Your COD RTO rate	Cost of one RTO	Expected loss per COD order	Discount worth offering
10%	10% of order value	1% of order value	Up to about 1%
20%	10% of order value	2%	Up to about 2%
25%	15% of order value	3.75%	Up to about 3–4%
35%	15% of order value	5.25%	Up to about 5%

The logic is simple: your expected loss per cash-on-delivery order is the RTO rate multiplied by the cost of an RTO. Any discount below that number is profitable if it converts, and any discount above it is you paying more to avoid the loss than the loss is worth.

What to offer instead of a discount

Money is the obvious lever and not always the best one. Several alternatives cost you less and convert respectably:

• Free delivery on prepaid. Costs you the shipping you were paying anyway, and reads as larger than an equivalent percentage.
• Faster dispatch. "Prepaid orders ship today" is true, costs nothing, and appeals to the impatient.
• A small free item at your cost rather than your retail price.
• Nothing at all. A meaningful share of customers will pay online simply because it is offered and convenient — test this before assuming an incentive is required.

That last one is worth testing first. If a plain "you can pay online here" converts at any reasonable rate, every one of those is a prepaid order you did not buy.

Where the offer goes

Inside the order confirmation conversation, immediately after the customer taps Confirm. Two reasons: the customer has just engaged, and their tap opened a 24-hour window in which everything you send is free text at no charge under Meta's pricing rules.

Sent as a separate message the next day, the same offer needs an approved template, is charged, and — because an offer is promotional — would be a marketing template, which cannot reach US numbers and is subject to per-user limits. Inside the window it is none of those things.

The payment link is yours, not ours

Be clear about the boundary. There is no in-chat payment step — a flow cannot take money. What it does is send a link generated by your payment provider, and the customer pays on their page.

Which provider depends on your market: UPI-based links through Razorpay or Cashfree in India, Easypaisa or JazzCash in Pakistan, Fawry in Egypt, Paystack or Flutterwave in Nigeria, mada or a BNPL option such as Tabby or Tamara in the Gulf. The flow is indifferent — it sends whatever link you give it.

If the link has to be generated per order, that is a job for the external API step, which is the one part of this needing a developer.

Ask once

A customer who has chosen cash on delivery and declined the switch has answered. Asking again the next day converts very little and reliably produces irritation — and because a follow-up offer is marketing, it is charged, capped and damaging to your quality rating if it annoys people.

One ask, in the conversation you were already having, is the whole play.

Measuring it honestly

1. Prepaid conversion rate — what share of confirmed COD orders switch.
2. Discount cost — total incentive given.
3. RTO avoided — converted orders multiplied by your COD RTO rate.
4. Net — RTO avoided minus discount cost. If that is negative, your incentive is too generous.

Point four is the one to watch. It is entirely possible to run a prepaid conversion programme that converts well and loses money, because the discount exceeded the expected loss it was preventing. Method is in measuring whether your automation works.

Where this sits among the RTO fixes

Last. Confirmation, address verification and delivery-day notices all reduce RTO without costing margin, so they should be running before you start paying customers to change payment method. The full sequence is in reducing RTO with WhatsApp.

Who to offer it to

Not everyone. A blanket offer discounts orders that were never at risk, which is the fastest way to make the programme lose money.

Customer	Offer it?	Why
First order, cash on delivery	Yes	Highest RTO risk, no history to judge by
High-value cash-on-delivery order	Yes	Most expensive failure
Delivery area with poor success rates	Yes	Risk is concentrated
Repeat customer who always accepts	No	You would be discounting a safe order
Already prepaid	No	Nothing to convert

That fourth row is the discipline most stores skip. Your reliable repeat customers are the ones most likely to take a discount, and the least likely to have needed one.

What to say

Lead with the benefit to them, not the risk to you. "Pay now and we'll cover delivery — or keep cash on delivery, either is fine" gives a real choice and does not imply you distrust them. "Prepaid orders are prioritised" is honest if true.

What fails is anything that sounds like suspicion. Customers in cash-on-delivery markets choose it because it removes their risk, and a message that reads as pressure to give that up converts badly and damages the relationship.

Tag the outcome

Whichever way they answer, write it back onto the order so your operations can see it: "prepaid pending" while you wait for payment, "prepaid" once it clears, "cod confirmed" otherwise. Without that, nobody downstream knows which parcels are paid for.

A prepaid-pending order also needs a rule for what happens if payment never arrives. The simplest workable answer is that it reverts to cash on delivery after a few hours rather than sitting unshipped — decide it before you launch.

Regional payment rails

The flow sends whatever link you give it, but the link matters for conversion and it is market-specific:

• India — UPI-based links, usually via Razorpay or Cashfree.
• Pakistan — Easypaisa, JazzCash, or a Raast transfer.
• Egypt — Fawry, which also allows cash payment at a counter, a useful middle ground.
• Nigeria — Paystack or Flutterwave; bank transfer remains the trust-restoring default.
• The Gulf — mada, plus buy-now-pay-later options such as Tabby or Tamara, which convert well where a discount does not.

Fawry deserves a mention as a pattern worth copying: it lets a customer pay before dispatch without a card, which captures people who would otherwise have had no prepaid option at all.

What this does not solve

A prepaid order can still be refused, returned or disputed. What changes is that you are holding the money while that happens, so the failure mode is a refund rather than a total loss — materially better, but not the same as risk-free.

And it does nothing for the orders that never convert, which will be most of them. Prepaid conversion is a margin play on a slice of your volume, not a replacement for the confirmation and address flows that protect the rest.

Test the plain offer first

Before deciding what discount to give, run the version with no incentive at all for a fortnight. Some share of customers will pay online simply because it is offered, convenient and instant — and every one of those is a prepaid order that cost you nothing.

That number is your baseline. A discount is only worth what it converts above the baseline, which is a much smaller figure than the total prepaid conversion rate and the one that should be compared against your expected RTO loss.

Where it fits in the conversation

After the confirmation, not before it. Asking someone to change payment method before they have confirmed they want the order at all is two decisions in one message, and it reduces both.

Confirm first, then offer. The tap that confirms opens the free window, so the offer costs nothing to send, per Meta's pricing documentation — and a customer who has just actively confirmed is measurably more engaged than one who has not.

Do not let it delay dispatch

A prepaid-pending order that sits unshipped while you wait for a payment that never arrives is worse than a cash-on-delivery order that shipped on time. Set a short window — a few hours — after which the order reverts to cash on delivery and ships normally.

Say so in the message. "Pay within the next couple of hours and we'll cover delivery, otherwise it goes out as normal" is honest, creates a real reason to act, and removes the operational ambiguity.