Guide
6 min read

Avoiding Fake Orders in Cash-on-Delivery Sales

Phone verification, duplicate detection, systematic confirmation: the concrete filters to reduce fake cash-on-delivery orders.

A fake cash-on-delivery order costs the customer placing it nothing — and costs you twice the shipping price, both ways. Reducing this risk comes down to four simple filters, applied before shipping, not after the refusal.

What a fake order costs, precisely

Nothing is charged at the time of the order: the customer fills in a form, with no financial commitment. The parcel ships, the carrier attempts delivery, the buyer refuses or is unreachable, and the parcel comes back. You've paid for packaging, outbound shipping and the return, without a single dinar of revenue — and the product was tied up for a week, unsellable in the meantime.

This isn't an isolated incident: market estimates for Algeria put the COD refusal or return rate between 20 and 40%, depending on the product category. Part of this rate can be reduced with simple filters; another part is structural to COD and will never fully disappear — a buyer who has paid nothing always keeps the option of changing their mind at the door.

Two categories of fake orders stand out, and they're not handled the same way. The first is unintentional: a mistyped number, an incomplete address, a customer who genuinely intends to buy but whose order becomes unreachable for a technical reason. The second is deliberate: a competitor's test, an order placed by mistake or as a joke, or a repeated attempt to get a delivery with no intention of paying. This guide's filters target both, but with different responses — the first is fixed at data entry, the second is filtered through history.

Validate the phone number at data entry

The first, most basic filter: the phone field must validate the Algerian format (10 digits, a recognized mobile prefix) before the form is even submitted. An invalid or truncated number makes the confirmation call impossible and the order unreachable by construction — it systematically ends in a failed delivery.

This check happens on the form side, with no external service: a regular expression is enough to reject most typing errors before they enter your processing queue. Also refuse submission until wilaya and commune are selected from a dropdown list rather than typed as free text — a misspelled commune causes the shipping label creation to fail at dispatch time, well after the customer placed the order, which is the worst possible moment to discover the mistake.

Detect duplicates and suspicious patterns

Three signals, easy to automate even before the confirmation call:

  1. Same phone number, several orders close together. A customer who places the same order three times in ten minutes is more often a test or a double-click error than genuine multiple purchase intent.
  2. Same address, different phone numbers. A workaround signal: a customer already flagged who changes numbers generally keeps the same delivery address.
  3. Unusual quantity on an item with a high unit margin. An order of ten units of a product usually bought as a single unit deserves a check before shipping, not after.

A script that cross-references phone number and address across recent orders handles these three cases in a few milliseconds — the easiest part of filtering to fully automate, well before the step that needs a human on the phone. On a store receiving several dozen orders a day, this filter alone weeds out a significant share of accidental duplicates caused by a double-click on the order button or a poorly timed page refresh — a form usability issue more than a fraud attempt, but one that clogs the processing queue just the same if nothing catches it.

The phone confirmation call, the filter that pays off the most

This is the most well-documented lever in the Algerian market for reducing refusals: a gap of ten to fifteen percentage points in refusal rate is reported between stores that systematically confirm by phone before shipping and those that ship blind.

The principle stays simple: a short call, before printing the shipping label, to confirm the customer is expecting the parcel, at this address, for this amount. Three possible outcomes:

Call outcomeAction
Customer confirmsShip normally
Customer unreachable after several attemptsFollow-up SMS/WhatsApp, then cancel if no reply within 24-48h
Customer cancels or denies having orderedCancel immediately, do not ship

Never ship an unconfirmed order above a certain amount — the threshold depends on your margin, but the rule consistently protects the orders that are most costly to lose.

Building your own history of risky customers

Keep track, by phone number and by address, of the number of refused or returned orders. A customer who accumulates several consecutive refusals deserves different handling on the next order: a mandatory confirmation call before any processing, or a request for a partial deposit rather than full COD.

Don't permanently block after a single refusal — an isolated refusal happens to real customers for legitimate reasons (an unexpected absence, a one-off change of mind). It's recurrence that should trigger different handling, not the single incident.

A customer who has already changed numbers to place another order doesn't fully escape this tracking: also cross-check the delivery address, which generally stays the same even when the phone number changes. A history built on phone number alone misses this exact case; a history that cross-references number AND address catches it. This history stays specific to your store — there's no indication that a shared list of risky customers is currently exchanged between merchants by the carriers themselves, so don't count on it as an external signal: build your own.

What not to do

Two reflexes that seem logical but cost more than they save: requiring an online deposit for every order, which drops order volume among a customer base that's partly unbanked without actually eliminating the risk; and automating an outright rejection on the slightest weak signal, which eliminates as many real customers as actually fraudulent orders. Filtering exists to prioritize the confirmation call, not to replace human judgment on ambiguous cases.

One last point, often overlooked: measure it. Without tracking the refusal rate by product and by wilaya, there's no way to know whether your filters are working or whether you're simply losing real customers for nothing. A dashboard that shows this rate as orders come in is worth more than a general impression formed after a few memorable cases.

For the rest of the flow — choosing a carrier, calculating margin with the return rate factored in — see the guide on cash on delivery and the Yalidine integration guide if you're automating label creation. For setting up your store from scratch, the guide to starting an online store in Algeria covers platform choice and legal status.

Frequently asked questions

Should every suspicious order be rejected?

No. A filter that's too strict also rejects real customers who are in a hurry or distracted. The goal is to sort — call to confirm ambiguous cases rather than auto-cancel — not to eliminate every order that shows a weak signal.

Does the confirmation call slow down order processing too much?

A call generally takes less than a minute. Compared to the cost of a refused round-trip delivery, it's the most cost-effective control in the whole process — see the detailed calculation in the guide on cash on delivery.

Can duplicate detection be automated?

Yes, and it's the easiest part to fully automate: a script that compares phone number and address across recent orders flags duplicates within milliseconds, even before the confirmation call.

Can a customer already blocked place an order again with another number?

Yes, nothing technically prevents changing numbers. Also cross-check the delivery address: a customer who changes phone numbers generally keeps the same address, which lets you catch them despite the workaround.