Detecting e-commerce order fraud with AI in n8n

A spike in orders on a Friday night should be good news. It's markedly less so when half of them come from accounts created within the hour, with a shipping address that differs from the billing address and a payment method tested across several orders in a row — the classic pattern of stolen-card fraud or card testing ahead of fraudulent use elsewhere. Manual review of every order doesn't scale past a few dozen a day, and overly strict filtering rejects legitimate customers just as fast as it blocks fraudsters. n8n lets you build a risk-scoring pipeline that runs on every order, before shipping, without depending on a single black-box tool.

The signals to combine before any scoring

A reliable system never relies on a single indicator: it combines several weak signals, each unremarkable on its own but revealing once stacked together.

• Billing/shipping address mismatch, and a shipping country different from the card's country or the connecting IP's country.
• Velocity: several orders within minutes from the same IP, the same device, or variants of the same email, using different payment methods (the classic signature of card testing).
• Cart inconsistency: an unusually high-value order on an account with no history, or a cart made up entirely of high-resale-value items (electronics, gift cards) — a profile very different from an ordinary cart.
• A brand-new account paired with an urgent express-shipping order, a combination that leaves little time for after-the-fact verification.
• A disposable or generic-domain email paired with a high order amount, while the bulk of your customer base uses stable professional or personal email addresses.

None of these signals alone is enough to flag fraud — a legitimate customer might well place an urgent order to a shipping address other than their own (a gift, a move). It's the combination and the weighting that make the difference, exactly the principle already detailed in our guide to AI-based churn risk scoring: several weak signals, a composite score, an action threshold rather than a binary rule.

Building the pipeline in n8n

The workflow starts at the most useful moment: right after the order is created, before shipping, never after.

1. Trigger on your platform's "new order" webhook (Shopify, WooCommerce, or Stripe for a direct payment) — see our guide to securing n8n webhooks to validate the request signature before any processing, a must-have as soon as a workflow can trigger an automatic hold.
2. HTTP Request node to an IP geolocation service (free up to a certain volume with most providers) to compare the IP's country, the shipping country, and the card's associated country.
3. Code node that computes velocity signals by querying that customer's, that IP's, or that device's recent orders — stored in a dedicated Supabase table, following our guide to connecting n8n + Supabase.
4. An LLM node with a Structured Output Parser that receives the full set of raw signals (geographic mismatches, velocity, account age, cart composition) and returns structured JSON: a risk score from 0 to 100, a short natural-language explanation, and a recommendation ("let through," "hold," "priority manual review"). Natural-language reasoning has a concrete advantage over an opaque score: the person working the review queue immediately understands why an order was flagged, without having to decode internal rules.
5. An IF/Switch node routing on the recommendation, following the principles in our conditional routing guide.

On the reliability of this kind of scoring, a 2025 systematic literature review published in the journal Computers by Baisholan, Dietz, Gnatyuk, Turdalyuly, Matson, and Baisholanova, "A Systematic Review of Machine Learning in Credit Card Fraud Detection Under Original Class Imbalance" (see on Google Scholar), makes a point that's easy to forget: fraud remains, by nature, a rare event relative to total order volume, and a large share of published studies artificially rebalance their dataset before evaluating their model — which inflates the reported accuracy compared to real production conditions. An earlier study by Isangediok and Gajamannage, presented at the IEEE International Conference on Big Data 2022 ("Fraud Detection Using Optimized Machine Learning Tools Under Imbalance Classes," see on Google Scholar), points the same way, comparing logistic regression, decision trees, random forest, and XGBoost specifically under this class-imbalance constraint. The practical takeaway for this workflow: never set an automatic-block threshold on the confidence displayed by the LLM or a composite score alone — calibrate it over a few weeks of your own orders, with a human validating false positives and false negatives before ramping up automation.

Hold, don't reject

Once scoring is in place, the temptation is to automatically cancel any order above a threshold. That's almost always a mistake: an automatic rejection on a legitimate customer costs an immediate sale and often the customer relationship long-term, while an order put on hold with a Slack or email notification to the team only delays shipping by a few hours.

• Low risk: the order goes straight to fulfillment, no intervention needed.
• Medium risk: the order is held, a notification goes to the review channel with the score, the LLM's explanation, and a link to the customer record — following the same prioritization principle as our guide to AI-based security alert triage, applied here to a different kind of event.
• High risk with confirmed repeat offense (the same payment method already tied to confirmed fraud): automatic block, the only case where full automation is justified, since the signal is no longer probabilistic but an already-established fact.

Closing the loop with disputes

A risk score that never learns from its mistakes loses value over time. Every confirmed chargeback received via Stripe should flow automatically into the at-risk orders table, reusing the logic detailed in our guide to handling Stripe disputes and chargebacks with AI: the payment method, IP address, and email tied to that chargeback become watchlist entries consulted at step 3 of the pipeline, without waiting for a manual model re-evaluation. It's a simple reinforcement, grounded in confirmed facts rather than predictions, that improves scoring far faster than a full retrain.

Hardening it for production

• Deduplication: a customer who edits their cart before final payment can trigger multiple order webhooks. A deduplication key on the order ID, following the principle in our guide to duplicate webhook deliveries, prevents scoring — and thus holding — the same order twice.
• Geolocation service or LLM outage: the workflow should never silently block an order because a third-party service didn't respond. A dedicated Error Workflow routes the order to manual review by default as soon as a step fails, rather than leaving it on hold indefinitely.
• Audit trail: every automated decision (score, recommendation, action taken) should be logged with a timestamp, following our guide to a GDPR audit trail with Supabase — useful if a wrongly blocked customer disputes the decision, and to adjust thresholds later based on real data rather than a gut feeling.

To place this workflow within a broader e-commerce automation setup — stock sync, order management, returns — our complete n8n guide for e-commerce covers the full chain around this anti-fraud checkpoint.

Where to go from here

This same mechanism — combining several weak signals, having an LLM evaluate them into structured output, then routing to a risk-calibrated action — is at the core of the Inbox AI Pack (€79), which applies the same triage-and-scoring principle to a mailbox. For the traceability and decision-logging side, essential as soon as a customer order gets held based on a score, the Compliance & Audit Pack (€149) provides a ready-made timestamped audit trail. All three packs, bundled in the FlowKit Complete Bundle (€269 instead of €347 bought separately), cover the full chain, from sorting incoming orders to documenting every decision.