n8n Order Fraud Detection: Score Every Order Before You Ship

A high-value order lands at 2am, ships to a freight-forwarder address, pays by card, and the phone number is one digit short of valid. Three weeks later it's a chargeback. The merchant eats the goods and the fee. Most stores find out when the bank does, not before.

n8n order fraud detection flips that timing. Instead of reviewing payments by hand or trusting a single opaque risk label, you score every order the second it lands, get a ship-or-hold verdict with a reason, and gate the risky ones before a courier ever touches them. The scoring runs in your own n8n instance, against rules you control.

The pages ranking for this term don't actually solve it. Shopify's own fraud analysis docs admit the score only covers "online credit card orders" and never explain the rules. The Greip + Shopify integration page is a marketing gateway with no workflow, no COD handling, and no ship/hold logic. Nobody ships a portable, rules-transparent triage flow. That's the gap.

What an order fraud workflow can automate

Fraud screening is a chain of small checks, and the expensive one is the decision to fulfil:

• Score every new Shopify or WooCommerce order the moment it arrives.
• Check a self-serve blocklist of known-bad emails and phone numbers.
• Flag high-value, mismatched-country, disposable-email, and bad-phone signals.
• Catch fake cash-on-delivery orders with a confirmation link before fulfilment.
• Write a plain-English verdict explaining ship, review, or hold.
• Alert the owner on Telegram with a one-glance recommendation.
• Log every order and decision to Google Sheets for a full audit trail.

That's not a fraud button. It's a gate that runs before money and goods move.

Why a single risk score isn't enough

Here's the stance worth defending: trusting one platform's risk label is how stores get burned on the orders that label was never built to see. Shopify's machine-learned score is decent on card fraud and blind to everything else. It doesn't run on WooCommerce. It says nothing about COD, which is where a fake name and a throwaway number cost you the product and the return shipping.

A real triage flow scores signals you can read and weight. High order value relative to your average. A billing country that doesn't match the shipping country. A disposable-email domain. A phone that fails a format check. A buyer already on your blocklist. Each adds points; the total picks the verdict. When something flags, you see why, not just a color.

The COD case needs its own gate. Card fraud you can sometimes recover through the processor. A COD order shipped to a fake address is a pure loss, so the workflow emails a confirmation link first and only releases fulfilment when the customer clicks. Different fraud, different gate.

The order fraud pipeline

New order (Shopify/WooCommerce webhook)
        │
   Normalize fields (one shape for both platforms)
        │
   Pull blocklist from Google Sheets
        │
   Score rules in a Code node → risk total + reasons
        │
   AI verdict summary (plain English)
        │
   IF risk total ≥ hold threshold? ── yes ──► hold + Telegram alert
        │ no
   COD order? ── yes ──► confirmation email, wait for click
        │ no
   Ship + log decision to Google Sheets

The verdict exists before any fulfilment step. That ordering is the whole point.

Step-by-step breakdown

1. Trigger on the new order

A n8n-nodes-base.webhook node catches the order-created event from Shopify or WooCommerce. Both platforms POST order JSON, but the field names differ, so the next step normalizes them. The Webhook node's default response is fine here; the scoring happens after the response returns, so the store isn't waiting on you.

2. Normalize both platforms into one shape

A n8n-nodes-base.code v2 node with jsCode maps Shopify and WooCommerce payloads into a single object: email, phone, total, billing_country, shipping_country, payment_method, line_items. Now every downstream rule reads the same field regardless of source. Write the platform-specific mapping once and the rest of the workflow stays platform-agnostic.

3. Score the fraud signals

The same Code node (or a second one) runs the rules. Each signal adds to a running total:

let score = 0;
const reasons = [];
if (blocklist.includes(o.email)) { score += 100; reasons.push('blocklisted email'); }
if (o.total > HIGH_VALUE) { score += 25; reasons.push('high order value'); }
if (o.billing_country !== o.shipping_country) { score += 20; reasons.push('country mismatch'); }
if (DISPOSABLE.test(o.email)) { score += 30; reasons.push('disposable email'); }
if (!/^\+?\d{7,15}$/.test(o.phone)) { score += 15; reasons.push('invalid phone'); }
return [{ json: { ...o, score, reasons } }];

Keep the thresholds in a Config Set node so you tune weights without editing code. The reasons array is what makes the verdict explainable.

4. Write the plain-English verdict

The @n8n/n8n-nodes-langchain.openAi v2.1 node takes the score and reasons and writes a one-line recommendation a human reads in two seconds. Its output lands at $json.output[0].content[0].text. Don't skip the parse step if you ask for structured fields back; the model returns text and the next node expects an object, so a n8n-nodes-base.code v2 node converts it. The AI isn't deciding the verdict here, it's explaining the score the rules already produced.

5. Route, confirm, and log

An n8n-nodes-base.if v2 node compares the score against the hold threshold. Above it, the order routes to a Telegram alert and waits for a human. Below it, a second IF checks the payment method: COD orders get a confirmation email first, card orders pass straight through. Every order, every verdict, and every reason appends to Google Sheets so the decision is auditable a month later when the chargeback would have hit.

Implementation patterns

Pattern 1 — The transparent rules engine. Keep every threshold in one Config Set node (n8n-nodes-base.set v3.4) and reference it with ={{ $('Config').first().json.highValue }}. When a clean order keeps landing in review, you adjust one number, not the workflow graph.

Config (Set) → Code (score) → IF (verdict)
   weights         reasons        threshold

Pattern 2 — The COD confirmation gate. For cash-on-delivery, email a unique confirmation link and pause fulfilment until the click arrives. A fake address never confirms, so it never ships.

COD order → confirmation email → wait for click → release fulfilment

Pattern 3 — The owned blocklist. Pull a Google Sheets tab of known-bad emails and phones at the top of every run. When a fraud attempt slips through, you add the contact once and every future order checks against it automatically. You own this list, not a vendor.

n8n nodes you'll use most

Getting started

1. Stand up the workflow on self-hosted n8n so the order data and blocklist stay on your instance.
2. Add the Webhook node and register it as the order-created destination in Shopify or WooCommerce.
3. Write the normalize-and-score Code node for your platform's payload shape.
4. Put your fraud thresholds in a Config Set node and start conservative.
5. Wire the IF verdict gate, the COD confirmation email, and the Telegram alert.
6. Append every decision to Google Sheets, then watch the log for a week and tune weights.
7. Skip the build below if you'd rather start from a tested flow.

Where this fits in your store

Fraud triage is one gate in a larger order flow. Once an order clears the risk check, it hands off to fulfilment and, if something goes wrong later, to returns. The same explainable-rules pattern that scores fraud also drives gated returns automation, where a blind auto-refund is the mirror-image mistake to a blind auto-ship. Stores running the full pipeline usually pair this with order fulfilment automation so the clean 80 percent ships untouched while the risky minority waits for a human.

A store that scores orders before it ships them stops finding out about fraud from the bank. For the broader picture, see how this connects to ecommerce workflow automation across the whole order lifecycle, and pair it with the Stripe Failed Payment Recovery flow to catch revenue leaking on the payment side too.