If you want long-term retainers Partnership and pricing

Ecommerce

Cash on delivery is a software problem, not a payment option

Hands check a returned courier parcel against a printed remittance report on a store packing table.

Your store takes GCash, Maya and cards, and the Messenger inbox still fills with the same question: may COD ba? So you switch it on. For a fortnight it looks like the easiest decision of the year.

Then the first parcel comes back refused. Then the remittance lands as one figure for forty parcels and nobody can match it to orders. Then a customer orders the last two units, never answers the phone, and the stock sits in a courier hub in Davao while the site shows it as sold. None of this is a payment problem. It is what happens when a store built for paid orders is asked to run unpaid ones.

An unpaid order is a different thing

When someone pays through GCash, Maya, PayMongo or a bank transfer, the order exists because money arrived. The store confirms the payment, takes the stock, prints the waybill and moves on.

A COD order exists because someone typed an address and a mobile number. Nothing has been confirmed. You are extending credit to a stranger on the strength of a Messenger profile, and the money, if it comes, arrives weeks later from the courier rather than from the customer.

So the order needs states a paid-only store never has. Placed but not confirmed. Confirmed and waiting to ship. Dispatched and unpaid. Delivered and awaiting remittance. Refused. Returned. Remitted. The order statuses a store platform ships with were written for paid orders, and the gap gets filled with a spreadsheet, a group chat and one person who remembers.

The first of those states is where bogus buyers live: the order placed as a joke, the address that does not exist, the number that rings out. The defence is a confirmation step before anything is packed, by SMS or Messenger, plus a record of numbers and addresses that have refused before. That is not a payment feature. It is an order queue with a person working it and rules the software has to enforce.

Stock has to survive a refusal

With a paid order, stock leaves the shelf when the payment clears. With COD, the question is when to reserve stock and when to give it back.

Reserve at ordering and a refused parcel takes a unit out of circulation for the whole round trip: Metro Manila to a barangay in Leyte, two delivery attempts, the return leg, then a bin in the stockroom until someone checks the box. On the last units of something you are running ads for, that is a lost sale on stock you still own. Do not reserve, and two COD orders for the last unit both get confirmed, one ships, and the other becomes an apology in Messenger.

The workable answer is a third stock state between available and sold: reserved for an unpaid order, with release rules. Released when the confirmation call fails. Released when the parcel is marked refused. Held for inspection when it comes back, then restocked or written off. Each of those is a decision the system either makes for you or leaves to whoever notices.

The money comes from the courier, not the customer

A GCash payment is one order, one amount, one timestamp. A COD remittance is a batch. The courier, whether that is J&T, LBC, Ninja Van or Flash Express, collects cash at dozens of doorsteps, deducts its COD fee and the shipping on each parcel, sometimes adds a return fee for the ones that came back, and sends the net figure to your bank account with a report attached.

Matching that report is the work nobody budgets for. Every line has to match a waybill, every waybill an order, and the gaps have to be explained: a parcel marked delivered on the tracking page but missing from the remittance, an amount below the order total because the rider accepted less, a refused parcel that appears only as a deduction.

It also forces a question your accountant will ask eventually: when is a COD order paid? Not when tracking says delivered, because a remittance can arrive short, late or not at all. It is paid when the batch lands and the waybill is matched. That date drives your sales figures and your receipting: an order receipted at dispatch that comes back refused needs a cancellation your BIR-registered invoicing can record, not a deleted row. The software using that date every time is what keeps the books honest.

On Lazada or Shopee the marketplace collects the cash and settles your balance. On your own store there is no marketplace in the middle. You are the marketplace, and the reconciliation is yours.

Who should still offer it

Nothing above is an argument against deciding to offer cash on delivery. The buyer asking for it keeps nothing in a wallet, or will not put a card into a site they found yesterday, and will still pay a rider they can see. The question is whether your product, your delivery area and your team can carry the model.

COD works when the parcel is cheap to lose: low-ticket goods, stock that holds its value on the return trip, delivery inside Metro Manila or on the same island, where the round trip is days rather than weeks. It works when someone confirms orders before they ship and someone matches remittances every week, and both of those are jobs, not favours.

It works badly for expensive items, where one refused parcel ties up more capital than the margin on the ten that got through. It works badly for made-to-order, perishable or personalised goods, because a refused cake is not stock, it is waste. It works badly for bulky items, because the shipping fee is gone on refusal and the return fee arrives on top. And it works badly for a business with nobody to work the queue.

Between all and nothing there is a set of rules. COD only within a delivery radius. COD only for customers with a completed order behind them. COD capped at an order value. COD with a small reservation fee through GCash or Maya, deducted from what the rider collects. Every one of those has to be enforced by the store, at checkout and in the order queue, or it is a policy on a Facebook post that nobody follows.

Before you switch it on

Four pieces of homework come first.

  1. Write down every state a COD order can be in, from placed to remitted or returned, with a name against each saying who moves it on.
  2. Decide when stock is reserved and when it is released, then check whether your store does that or a person does.
  3. Pick the date on which a COD order counts as paid, and get your accountant to agree with it.
  4. Take one month of courier remittance reports and match them to orders by hand. That is the job you are signing up for every month.

Then decide whether to offer it, to whom, and under what rules. Whatever you land on, the store has to enforce it. If the answer lives in a spreadsheet, you have not offered COD. You have given your team a second job.


Ready when you are

Tell us what you are building and we will tell you honestly how we would approach it.