Native Shopify Checkout or a Replacement COD Form?

There are two ways to take a COD order on Shopify. You can keep Shopify’s checkout and bolt verification onto it, or you can put your own form in front of it and create the order yourself once the customer has passed your checks. The decision gets argued as a conversion question. It is really a question about where order creation sits in your sequence, and that single structural difference drives almost everything else.

The actual difference

In both models the order ends up in Shopify, the customer ends up with a parcel, and the same checks can run. What changes is the order of operations.

With native checkout, Shopify collects the address and the payment choice on its own page, the order is created the moment the customer confirms, and anything you want to verify happens to an order that already exists. Verification becomes a post-order workflow: confirm, then dispatch or cancel.

With a replacement form, you collect the details on your own storefront, run your checks while the customer is still in front of you, and create the order only once it passes. Verification becomes a pre-order gate. Nothing unverified ever lands in your fulfilment queue.

Everything below follows from that. A pre-order gate is cleaner operationally and costs you whatever Shopify’s checkout was doing for you. A post-order workflow keeps Shopify’s checkout and leaves you managing a queue of orders that may or may not be real.

What you can actually do inside native checkout

This is where most comparisons go wrong, because the answer depends on your Shopify plan and the plan rules are specific. Worth reading Shopify’s own documentation rather than a summary of it, but the load-bearing facts as Shopify states them:

Checkout UI extensions are the supported way to add anything to checkout, and the useful steps are Plus-only. Shopify’s developer documentation for checkout UI extensions states that “Checkout UI extensions for the information, shipping, and payment steps are available only to stores on a Shopify Plus plan.” The information, shipping and payment steps are precisely where a phone field, an OTP prompt or a payment-method rule would have to live. If you are not on Plus, that route is closed, and no app can open it for you.

The old workaround is gone. Shopify’s help documentation states that “As of August 28, 2025, the additional scripts section in the Checkout settings is view-only.” Dropping custom JavaScript into checkout — the way a lot of early COD tooling worked — is no longer an option.

Extensions are sandboxed and cannot touch the page itself. Shopify’s documentation says extensions “run in an isolated sandbox” and “don’t have access to sensitive payment information or the checkout page itself.” So even on Plus you are placing blocks where Shopify allows blocks. You are not rebuilding the page. There are hard limits too: compiled extension bundles cannot exceed 64 KB, and merchants can add at most three extensions to the same block target.

Server-side validation has exactly one route. Shopify’s Cart and Checkout Validation Function API documentation states that “To validate a cart and checkout, server-side, you can only use the Cart and Checkout Validation Function API,” that you “can specify the checkout fields to target with the validation error message,” and that “You can activate a maximum of 25 validation functions on each store.” This is the mechanism that can genuinely stop a checkout from completing — useful for address and pincode rules.

And one detail worth circling. The same documentation lists where validation is supported and where it is not: supported for Checkout, Cart, B2B, Draft Order and Storefront, and not supported for POS, the Create Order API, Order Edit or Subscriptions. Orders created through the Create Order API do not pass through your validation functions. If you run a form, a CRM, a call centre or a marketplace sync that creates orders programmatically, your checkout-level rules are not protecting those orders. Many merchants assume a validation function is a store-wide rule. It is a checkout-path rule.

One more piece of recent housekeeping: Shopify’s help documentation notes that “August 26, 2026 was the deadline for stores on a non-Plus Shopify subscription plan to upgrade their existing Thank you and Order status pages to the new version of those pages.” That date has now passed, so if you were relying on legacy post-purchase page customisations for COD confirmation messaging, check what survived the upgrade.

What a replacement form buys, and what it costs

The appeal is straightforward. You own every field, every validation and every step order. You can ask for the phone number first and verify it before anything else happens. You can check pincode serviceability before the customer has invested effort. You can collapse the whole thing into one screen, which matters when most of your traffic arrives from an ad on a phone. And none of it depends on your Shopify plan.

The costs are real and usually underweighted.

You lose accelerated prepaid checkout. Shop Pay, saved addresses, wallet buttons and the one-tap paths your returning prepaid customers already use are properties of Shopify’s checkout. Routing a prepaid buyer through a COD form to re-type their address is a straightforward downgrade for your best customers.

You lose checkout analytics continuity. Shopify’s own checkout funnel reporting describes the native path. If half your orders go around it, your reports describe half your business, and the half they describe is not the half you are trying to fix.

Discounts, shipping rules and taxes become your problem. Anything Shopify’s checkout calculated for you now has to be calculated correctly on your form, and stay correct as your promotions change. This is the most common source of quiet revenue leakage after a switch: a stacking rule that behaves one way at native checkout and another way on the form.

You now maintain two order paths. Every future change — a new courier rule, a GST change, a new discount mechanic — has to be made and tested twice. For a small team this is the cost that compounds.

And, per the point above, validation functions do not cover API-created orders. If your form creates orders through the API, you cannot lean on checkout validation as a safety net. The checks have to be in the form.

The four questions that decide it

1. What plan are you on? If you are not on Shopify Plus, Shopify’s documentation closes off checkout UI extensions at the information, shipping and payment steps. You can still use validation functions to block a bad checkout, and you can still verify after the order exists. What you cannot do is add a field or an OTP step into those checkout steps. For a large share of Indian D2C brands this question answers the whole thing.

2. Can your operation hold an order? This is the question that actually matters and the one most people skip. If your pick-and-pack runs continuously and parcels leave within hours, a post-order verification workflow has to win a race it will sometimes lose — and an unverified parcel on a bike is an RTO in progress. If you batch dispatches once or twice a day, you have a natural confirmation window and post-order verification fits inside it at no cost. Pre-order gating is for operations that cannot hold.

3. What does your payment mix look like? If prepaid is a meaningful share of revenue, do not put every buyer through a COD form. The friction lands on customers who were never the problem. Either keep native checkout and verify afterwards, or split the paths — which is what most brands eventually do.

4. How wide is your catalogue? Single-product or narrow-range, ad-driven, low average order value: a form is a good fit, because there is little for a checkout to compute and every tap costs you. Wide catalogue with multi-item carts, bundle pricing and stacked discounts: the form has to reimplement a lot of Shopify’s arithmetic, and each reimplementation is a defect waiting to happen.

The hybrid most brands land on

Two buttons on the product page. “Buy now” goes to native checkout, with accelerated prepaid paths intact. “Order with COD” goes to your form, where the phone number is verified and the pincode checked before an order exists.

This puts each mechanism where it earns its keep: no friction for prepaid buyers, a hard gate on the orders that actually carry RTO risk. It is also the configuration that makes your prepaid-incentive messaging legible, because the two options are visibly different products rather than a single checkout with a radio button.

It is not free. You are running two funnels, so instrument both separately — a blended conversion rate across two paths will hide a problem in either one. Discount and shipping logic has to behave identically on both, and that needs an actual test, not an assumption. And your risk rules need to exist on both sides, because, again, checkout validation functions do not apply to orders created through the API.

Before you switch, instrument this

Most switches get evaluated on overall conversion rate, which is the one number guaranteed to be ambiguous. Baseline these instead, for at least a few weeks before you change anything:

Conversion split by payment method. Not blended. COD conversion and prepaid conversion move in opposite directions when you add a gate, and the blended figure can stay flat while your prepaid revenue quietly falls.

Time from order placed to dispatch. This tells you whether you have a confirmation window at all, and therefore whether post-order verification is viable.

RTO rate by order path. The whole point. Tag orders by which path created them from day one, or you will have no way to attribute the change.

Field-level abandonment on the form. If you build a form, you own its drop-off. Know which field loses people — usually it is the one that asks for something before the customer understands why.

Discount and shipping parity. Run the same five baskets through both paths and compare the totals to the paisa. Do this before launch and after every promotion change.

When each one is the wrong choice

A replacement form is the wrong choice if prepaid is most of your revenue, if your catalogue depends on multi-item carts and stacked discounts, if returning customers rely on accelerated checkout, or if you do not have the team to own a second order path through every future change. It is also wrong if your RTO problem turns out to be a dispatch-speed or address-quality problem, because a gate at checkout does nothing about either.

Native checkout is the wrong choice if you are not on Plus and you genuinely need field-level control inside the checkout steps, if your fulfilment cannot hold an order long enough to confirm it, or if you run a single-product ad funnel where the hosted checkout’s extra steps are measurably costing you orders.

Where COD King fits, and where it does not

COD King runs the replacement-form side of this: a COD order form with OTP verification and pincode and risk rules applied before the order is created, plus partial-advance collection on that form. It is built for the case where you need the gate in front of order creation and you are not on a plan that lets you put one inside Shopify’s checkout.

It is the wrong tool in a few cases, and they are worth saying plainly. If your RTO rate is already low and your constraint is acquisition, adding a verification step costs you orders and buys you nothing. If you are on Plus with developers and you want everything to stay inside native checkout, build it with checkout UI extensions and validation functions — that is what they are for, and it will be a better experience than any bolt-on. If your real problem is NDR handling and re-attempt coordination with couriers after dispatch, that is a different category of tool and a COD form will not touch it. And if prepaid is the bulk of your revenue, start with the prepaid conversion playbook instead; the checkout question can wait.

Shopify platform details in this article were taken from Shopify’s own developer and help documentation on 4 November 2026. Plan requirements and API support change; check the current documentation before you build against any of it.