Prepaid Conversion Is a CRO Problem, Not a Logistics One

Prepaid share sits on the ops dashboard, which is why almost nobody tests it. It is a conversion outcome of where you ask, what you offer and how much risk the customer is carrying and the usual fix, discounting the prepaid option, buys the number by giving away the margin.

Who Owns Prepaid Share at Your Company?

Ask three people and you will get three answers.

Operations owns the number, because prepaid share drives RTO, working capital and reverse logistics cost. Marketing owns the funnel but reports on conversion rate, where prepaid share does not appear. Finance sees the margin consequence a quarter later.

Nobody owns the moment the customer chooses.

That gap has a specific consequence: prepaid share almost never enters the experimentation roadmap. It gets discussed in ops reviews, targeted in quarterly plans, and addressed with a discount but it is rarely treated as something you form a hypothesis about and test.

Across the D2C brands we work with, the pattern is consistent. Teams running structured CRO programmes have tested product page layouts, checkout form length and trust badge placement. Very few have ever run a controlled test on payment method selection, despite it being one of the highest-leverage decisions in the funnel.

Prepaid Is a Conversion Decision, Not a Payment Preference

The framing matters, because "payment preference" implies something fixed about the customer and "conversion decision" implies something you can influence.

At the moment of choosing, a first-time buyer is weighing three things:

Risk of the product. Will it arrive, will it match the photos, will it fit. COD removes that risk entirely they pay only if something physically arrives.

Risk of the brand. Do I trust this store with my money before I have anything in return. Weaker for established brands, severe for a first purchase from a name they met through an ad an hour ago.

Friction of the payment itself. Entering card details or completing a UPI handoff is more work than tapping a button. On a patchy connection, it is also more likely to fail.

COD solves all three in one tap. That is why it wins by default, and why a discount only addresses a fourth consideration, price while leaving the first three untouched.

Which tells you where the real levers are.

The Discount Lever and What It Really Costs

The default advice in this category is to incentivise prepaid with a discount. It works, which is why it is the default.

The problem is what it buys you. A prepaid discount converts two populations:

• Customers who would have chosen COD and are genuinely shifted by the incentive, real value

• Customers who were going to pay prepaid anyway and now pay less, pure margin give-away

You cannot separate them from a dashboard. You can only separate them with a controlled test.

The margin maths is unforgiving. A prepaid discount in the mid-single-digit percentage range, applied to every prepaid order, has to be funded by the RTO savings on the orders it actually shifted. If your prepaid share was already meaningful before the discount, a large share of the discount is subsidising behaviour you already had.

Worth noting that prepaid adoption is moving on its own. GoKwik reported that prepaid orders crossed COD during a Valentine's Day sale period, surpassing 55% of orders. Sale periods skew prepaid, but the direction is real — which means some of the lift a discount appears to produce is a trend you would have captured anyway.

The Levers That Are Actually CRO

Six things that move prepaid share without buying it.

Where in the flow you ask. Payment method presented at the first step, before address entry, produces a different answer than the same choice presented after the customer has invested five minutes. Sunk cost works in your favour later in the flow.

Default state. Whether COD is pre-selected, listed first, or requires an active choice. Default effects in checkout are well documented and routinely under-tested.

Risk reversal at the payment step. Return policy, exchange window and support contact placed at the moment of payment rather than in a footer. This addresses the product-risk concern directly, which a discount does not. Our post on trust signals that actually improve ecommerce conversions covers placement.

Trust placement specific to first-time buyers. Review count, delivery guarantee and brand credibility shown to new visitors and suppressed for returning customers who do not need them.

Partial-COD and token-amount framing. Asking for a small prepaid token with the balance on delivery splits the difference on brand risk. The framing of that amount and whether it is positioned as a confirmation rather than a payment is testable.

Delivery-speed differentiation. Faster dispatch on prepaid orders is a genuine operational difference you can offer without discounting. It converts a margin give-away into a service benefit.

Each of these is a hypothesis. None requires a price change.

How to Run the Test Properly

Here is a worked design you can adapt.

Hypothesis

Observation: COD is pre-selected at checkout, and prepaid requires an active change. First-time buyers select COD at a materially higher rate than returning customers.

Change: Present payment method as an unselected choice with prepaid listed first and a delivery-speed benefit attached, COD available without friction.

Expected impact: Prepaid share of completed orders rises, with no meaningful fall in checkout completion.

Split

Fifty-fifty at checkout entry, running to a pre-calculated sample size. Do not restrict to new users only, you need the returning-customer segment as a control on whether the change helps or harms people who were already going to pay.

What you measure

What invalidates it

• Checkout completion falls beyond your guardrail threshold, even if prepaid share rises

• The test runs through a sale period, where payment behaviour shifts independently

• Prepaid share rises but RTO-adjusted revenue per session does not

That last one is the discipline most programmes skip. A variant that lifts prepaid share while reducing total delivered orders has moved a number, not improved the business.

The measurement trap

COD and prepaid are two funnels with different intent, and a blended conversion rate will hide a winning variant.

Here is how that plays out. Imagine a variant that successfully shifts mix toward prepaid. Prepaid checkout completion is typically lower than COD completion paying is a bigger ask than tapping confirm. So your blended completion rate falls.

Per 100 checkout starts, the control might complete 60 orders weighted toward COD. The variant completes 57, weighted toward prepaid. On a blended view the variant lost three points and gets killed.

Now apply RTO. COD returns at a multiple of the prepaid rate frequently three to four times higher. The variant's 57 orders survive delivery at a materially better rate than the control's 60. On delivered orders, the variant wins.

A blended conversion rate would have ended that test as a loss. You need completion rate split by payment method, and a delivered-order view, or you will systematically reject the variants that are actually working.

Two further complications worth planning around. Third-party one-click checkouts replace your native flow, which means your GA4 events may not carry payment method at all unless you have deliberately instrumented it and without that dimension, none of the above analysis is possible. And if your purchase events are unreliable to begin with, the test result is unreadable regardless of design. Our post on cart abandonment as a UX or tracking problem covers how to tell the difference.

The Metric That Stops You Optimising the Wrong Thing

Prepaid share on its own is gameable. Make COD sufficiently awkward and the number rises while total orders fall.

Pair it with two others:

RTO-adjusted revenue per session. Revenue from orders that were actually delivered and kept, divided by sessions. This is the number that catches a variant winning on prepaid share and losing on delivered volume. Our post on RTO as a measurement problem covers how to build the delivered-order view this requires.

Contribution margin per order. Revenue minus COGS, shipping, payment processing, discount and reverse-logistics cost. This is where a prepaid discount shows its true cost a variant can improve prepaid share and RTO while reducing margin per order to the point where the trade is not worth making.

Three metrics, read together. Any one alone will mislead you.

Where to Start

If prepaid share has never been tested at your brand:

1. Instrument payment method as a dimension. Pass it on checkout and purchase events and register it as a custom dimension. Without this, nothing else on this list is measurable.

2. Establish the split baseline. Checkout completion rate, RTO rate and revenue per session, separately for COD and prepaid, over a clean period with no sale.

3. Test default state first. It is the cheapest change with the clearest mechanism, and it does not touch price.

4. Hold the discount in reserve. If the flow and trust levers are exhausted and prepaid share is still below where it needs to be, then discount knowing what it costs because you have the contribution margin view.

Prepaid share is not something operations inherits from customer behaviour. It is produced by decisions in your checkout flow, and those decisions are testable.

Want prepaid share on your testing roadmap rather than your ops dashboard? Talk to FunnelFreaks about a CRO Program, we design and run the tests, and measure them against delivered orders rather than placed ones.