COD fee as a shipping rate vs a line item: the honest trade-off
Updated · ACOD (E-TRADE PARTNER)
There are two ways a Shopify app can charge a Cash on Delivery fee: inside a shipping rate, or as an added line item in the cart. Neither is “correct” — the shipping-rate model is cleaner at checkout and bulletproof with refunds and taxes, while the line-item model shows the fee as its own row in orders and accounting exports. We build ACOD, which uses the shipping-rate model; here is the genuinely balanced version of the trade-off, including when the other approach fits better.
Why the fee can't just be a fee
Shopify's checkout has no native concept of a payment-method surcharge. An app that wants to charge extra for COD has to smuggle the fee into something checkout *does* understand: either the shipping line (a dedicated COD shipping rate whose price is the fee) or a cart line (a fee “product” added to the order, usually via a cart transform). Every COD fee app on the App Store uses one of these two mechanisms — and each inherits real side effects from its host.
The two models side by side
| Shipping-rate fee (ACOD's model) | Line-item fee | |
|---|---|---|
| What the customer sees | A shipping option: “Cash on Delivery (+₹99)” at the shipping step | An extra product row: “COD fee — ₹99” in cart and checkout |
| Where it appears in the order | Inside the shipping line, merged with shipping cost | As its own line item — visible in order details, invoices, and exports |
| Taxes | Taxed as shipping, per your store's shipping-tax setting — automatic | Taxed as a product; the fee product's tax settings must be configured correctly or the fee is mis-taxed |
| Refunds & cancellations | Nothing extra to do — the fee refunds with shipping like any normal order | The fee line must be refunded/removed like a product; partial refunds get fiddly |
| Discount codes | Immune — product discounts can't touch a shipping rate (free-shipping codes can, by design) | “X% off everything” discounts can accidentally discount the fee itself unless excluded |
| Catalog side effects | None — no fee product exists | A fee “product” lives in your catalog: it can leak into collections, feeds, search, and inventory reports if not carefully hidden |
| Conversion feel | Fee reads as part of delivery cost — familiar, low-friction | Fee reads as an added charge in the cart — more visible, and more likely to be questioned |
| Accounting exports | Fee is inside the shipping total — needs a report filter (e.g. by shipping-rate name) to isolate | Fee is a separate row — trivially visible in every export and accounting integration |
The real complaints, both directions
The main criticism of the shipping-rate model — and we hear it in our own support chat, and have seen it in a 1-star review of ours — is that customers perceive the fee as a shipping charge (“why is shipping ₹99 when you promised free shipping?”) and that bookkeepers can't see the fee as a distinct row. Both are legitimate. The fixes: name the rate unambiguously (“Cash on Delivery fee”, not just “COD”), and isolate fee revenue in reports by filtering on the rate name.
The line-item model earns the opposite complaints: fee products that get discounted by storewide codes, appear in Google Shopping feeds, break bundle apps, survive in the cart after the customer switches to prepaid, or need manual cleanup on refunds. One competitor in this category has public 1-star reviews specifically about its fee implementation creating duplicate shipping methods and unremovable charges — the failure modes are real on both sides, they're just different failure modes.
How to choose
- Choose the shipping-rate model if you want the lowest-friction checkout, correct taxes and refunds with zero maintenance, different fees per shipping zone, and — the capability that requires this model — linking the COD payment method to specific shipping rates, including multiple pay-on-delivery options with different fees.
- Choose a line-item app if your accounting workflow strictly requires the fee as a separate order line and you're prepared to maintain the fee product's tax, discount-exclusion, and feed-exclusion settings.
Whichever model you pick, pick it consciously — most “the app is broken” frustration in this category is actually a mismatch between the model the app uses and what the merchant expected the fee to look like afterwards.
ACOD: the shipping-rate model, done properly
Fee per zone, linked payment method, clean taxes and refunds, no fee products in your catalog — and we'll tell you honestly if your use case needs the other model.
Install ACOD on Shopify — 7-day free trialFrequently asked questions
›Why does my COD fee show up as shipping?
Your app uses the shipping-rate model: the fee is the price of a dedicated COD shipping rate. That's by design — it keeps taxes and refunds automatic. Rename the rate to something like “Cash on Delivery fee” if customers mistake it for a delivery charge.
›Can a COD fee be a separate line item on the invoice?
Only with an app that uses the line-item (cart transform) model, which adds a fee product to the order. ACOD deliberately doesn't — the trade-off is explained on this page. If a separate invoice row is a hard requirement, a line-item app fits your case better.
›Which model handles refunds better?
The shipping-rate model — the fee sits in the shipping line, so standard refund flows handle it with no extra steps. Line-item fees must be refunded like products, which adds a manual step and a common source of errors.
›Do discount codes apply to the COD fee?
Under the shipping-rate model, product discount codes can't touch the fee (only free-shipping codes can, by design). Under the line-item model, storewide percentage discounts can hit the fee product unless it's explicitly excluded.