Partial COD for Indian Online Stores: How It Works in CS-Cart

How Partial COD works in CS-Cart: an advance paid online at checkout, the balance on delivery, advance rules by product, category, vendor and store, and refunds for refused deliveries.

Cash on delivery is still how a large share of Indian shoppers expect to pay, and every online store that offers it, whether on CS-Cart (sometimes written CS Cart) or any other platform, carries the same risk: a customer who has paid nothing can refuse the parcel at the door. Partial COD reduces that risk without taking COD away. This guide explains how Partial COD works, how the advance is set, how refunds are handled, and how we build it as a CS-Cart add-on.

The COD problem for Indian stores

Offering COD wins orders from customers who do not want to pay online for a seller they have not bought from before. The cost shows up later. When a COD parcel is refused, the order returns to the seller as an RTO (Return to Origin), and the store pays for shipping both ways on a sale that never completed — one of the most expensive outcomes in Indian e-commerce. The product has been packed, shipped and returned, and nothing has been collected.

Full prepayment avoids that risk, but it is not always realistic. For B2B orders and for high-ticket B2C purchases, full prepayment is uncommon: buyers expect to see the goods before handing over the whole amount. Stores that insist on it lose those buyers; stores that offer plain COD carry the refusal risk on every order.

What Partial COD is

Partial COD, often shortened to PPCOD (Partially Prepaid Cash on Delivery), sits between the two. The customer pays part of the order online at checkout, the advance, and pays the remaining balance in cash on delivery.

The advance changes the customer's position. A buyer who would never prepay the full amount can still complete the purchase, and the advance gives the store a stronger signal that the customer intends to accept the parcel. COD stays available as an option.

We build Partial COD as a CS-Cart add-on. The rest of this guide walks through how it works, using the add-on we build as the example. See the Partial COD add-on for CS-Cart for a summary of the capability.

Setting the advance percentage

A single advance percentage for the whole store rarely fits. A store selling both expensive and everyday products needs different terms for each. In the add-on, the advance percentage is configurable at four levels:

Product: a percentage for one specific product
Category: a percentage for every product in a category
Vendor: a percentage for a marketplace vendor's products
Global: the store-wide default

When more than one rule matches a cart, a priority order decides which one applies, and the most specific rule wins. The order is product, then category, then vendor, then global. A product rule overrides all the others; without one, the category rule applies; without a category rule, the vendor rule applies; and without a vendor rule, the global default is used.

For example, a store might set a 20% default advance, 30% for one high-return category like electronics, and 0% for low-value items. A product in the electronics category would then need a 30% advance, unless that product had its own rule, which would take priority. These figures are an illustration only; every store chooses its own.

Taking the advance: Juspay

The advance is collected online at checkout. In the add-on we build, the gateway is Juspay: the customer pays the advance through Juspay, and refunds of the advance go back through Juspay.

The same pattern works with other payment gateways — the advance is collected at checkout via the gateway's standard payment flow, and refunds route back through the same gateway. Connecting a different gateway is integration work on the payment side; the advance rules and order handling stay the same. Our payment gateway and ERP integration services cover that work.

The balance collected on delivery is handled outside CS-Cart by the logistics process. The add-on records what was paid online and what remains pending, without taking over the courier's cash collection.

Refunds: two different paths

A Partial COD order can need a refund in two situations, and the add-on treats them differently.

Refused delivery. If the customer refuses the parcel, the courier's RTO webhook triggers the refund path for the advance. Because the trigger comes from the courier's own event, a refused parcel does not depend on someone remembering to issue a refund. This works alongside our courier and aggregator integrations; see our multi-carrier shipping integrations for CS-Cart for how tracking and COD remittance are handled on the shipping side.

Refund after delivery. If the order is delivered and the customer later asks for a refund, the accounts team processes it manually and records a new entry that flags the PPCOD order as manually refunded. The order then shows how its money moved, even when the refund happened outside the automatic path.

Order statuses: a flag, not a new status

A tempting way to build Partial COD is to add new order statuses such as "advance paid" or "balance pending". That touches every part of the store that reads order statuses: emails, reports, shipping and other add-ons.

The add-on avoids that. Partial COD orders keep the standard order statuses and carry a PPCOD flag instead. The order state machine stays intact for non-PPCOD orders, so prepaid and regular COD orders behave exactly as they did before the add-on was installed.

The flag is where the admin sees the difference. It appears in the admin order list, so the team can see at a glance which orders have a balance due, and the order details page shows the advance amount, the pending amount and the related PPCOD fields together.

Multi-Vendor and Ultimate

The add-on works on both CS-Cart Multi-Vendor and CS-Cart Ultimate. On a marketplace, the vendor level of the advance rules lets each vendor's products carry different terms, without a rule for every product.

Multi-Vendor also splits a checkout with products from several vendors into a parent order and one child order per vendor, and any payment logic has to work correctly at the child-order level. Our page on building CS-Cart addons explains how we design for parent and child orders.

Before you build it: a checklist

Set the default advance. Decide the global percentage that applies when no other rule matches.
List the exceptions. Which categories, vendors or products need a different advance, and remember that the most specific rule wins.
Write the refund policy for both paths. What happens to the advance on a refused delivery, and how a refund after delivery is approved and recorded.
Agree how the COD amount reaches the courier. The balance is collected outside CS-Cart, so the logistics process needs to know the pending amount on each order.
Check the courier's RTO events. The refund path for refused deliveries depends on the courier or aggregator sending an RTO webhook.
Test on staging. Place orders that hit each level of the advance rules, then run both refund paths before going live.

If your checkout needs other changes alongside Partial COD, such as payment methods shown by cart contents or extra checkout fields, our CS-Cart checkout customization service covers that work. Add-ons start from $1,500, scoped per store.

Common questions

What is Partial COD?

A payment method where the customer pays an advance online at checkout and the remaining balance in cash on delivery.

How is the advance percentage decided?

By rules at four levels. The priority is product, then category, then vendor, then the global default, and the most specific matching rule wins.

What happens to the advance if the customer refuses the parcel?

The courier's RTO webhook triggers the refund path, and the advance is refunded through the same gateway that collected it.

Does Partial COD add new order statuses?

No. Partial COD orders keep the standard statuses and carry a PPCOD flag, so regular orders are unaffected.

Does it work with CS-Cart Multi-Vendor?

Yes. The add-on works on both Multi-Vendor and Ultimate, and the advance can be set per vendor.

SysNova Technologies, H NO 152 Muradgarhi, YEIDA Development Area, Gautam Buddh Nagar, 203209
Phone: +91 9793760210
Email: sales@sysnovatech.com