Andrew Veal
← All case studies

Case Study · eCommerce Operations · 2022

The fraud gate: turning a growth blocker into a review queue

DRAFT — core write-up complete; final narrative being refined.
StackShopify · Celigo · NetSuite · 3PL
Built witheCommerce team + IT
Result>$100K saved in year one

The problem

Fraudulent orders were shipping. Not "suspicious" orders — orders the card networks would eventually decline, meaning the money was never coming. And because nothing stopped them at the door, the business paid twice: once for the goods, once for the pick, pack, and freight to send them away. Then the chargeback landed and the revenue evaporated.

The eCommerce team could see it happening. What they didn't have was a mechanism — no place in the order flow where a human could intervene between "order placed" and "order shipped."

Comparison of a fraudulent order caught before fulfillment costing nothing versus one that ships and loses goods, fulfillment spend, and revenue to chargeback

The part that made this urgent wasn't the P&L line. Payment processors watch chargeback ratios, and a merchant that can't contain them gets dropped — or never gets approved for the volume it's trying to grow into. So this wasn't only leaking margin. It was a ceiling on how big the business was allowed to get.

Finding the leverage point

The signal already existed. Shopify was scoring incoming orders for risk — anomalies like an unusually large order placed far from where that card had last been used. Nobody was doing anything with it, because by the time an order reached the ERP and routed to the 3PL, that context had dropped on the floor.

So the fix wasn't buying a fraud tool. It was making an existing signal survive the trip across three systems and land somewhere a person could act on it. That meant tracing the Shopify order as it moved through the Celigo integration into NetSuite, then reworking the sales-order process so a flagged order couldn't quietly continue to fulfillment.

What I built

I modified the NetSuite order process so flagged orders dropped into a saved search that functioned as a review queue — and, critically, held fulfillment release until a human cleared them.

Order flow diagram showing Shopify orders passing through Celigo into NetSuite, where flagged orders divert into a review queue for the eCommerce team before either cancellation or release to the 3PL

The judgment call: why nothing auto-cancels

The obvious design is to cancel anything flagged. It's also wrong.

Sometimes a large order placed hundreds of miles from the cardholder's usual location is exactly what it looks like — and sometimes it's someone buying for friends and family while travelling. That's not a fraudster. That's an enthusiastic customer placing one of the best orders you'll get all month, and auto-cancelling it burns real revenue and a real relationship in the name of risk management.

So the queue routes to people, not to a rule. The team reviews the order, reaches out to the customer where it matters, and then makes one of two deliberate calls: cancel it as confirmed fraud, or flip a flag on the sales order that releases it to the 3PL for normal fulfillment. The system narrows the field; a human makes the decision.

Why it took more than a config change

The solve sat at the intersection of four things that usually live with four different people: how Shopify scores orders, how our integration pattern moved data through Celigo, how the NetSuite sales-order process actually released fulfillment, and what the eCommerce team could realistically operate day to day. I worked the design with the eCommerce team so the queue fit their workflow rather than adding to it, and with IT to deploy it into a live order flow without interrupting orders that were fine.

The result