E‑commerce Fraud Detection: Real‑Time Rules + ML with Webhooks

Fraud hurts revenue, trust, and margins. This guide outlines a production‑grade fraud detection pipeline combining deterministic rules with ML scoring, wired together via webhooks and queues for real‑time decisions.

What Is Real‑Time Fraud Detection?

A streaming pipeline that evaluates each order in seconds using:

• Webhooks from checkout/payment
• Rules engine for hard prevents/flags
• ML score for borderline cases
• Queue + worker for async enrichment
• Case management for manual review

Unlike offline batch analysis, real‑time decisions prevent bad orders before fulfillment.

Reference Architecture

• Checkout → Webhook (order.created)
• Normalize → Rules → Enrich (device/IP) → ML score
• Decision: Approve / Review / Decline
• Notify ops; store decision + features for retraining

Core Rules (Deterministic)

1. Velocity Controls

N orders in M minutes per card, email, IP, or device; escalate to review when near threshold.

2. BIN / Country Mismatch

Flag when card BIN country differs from IP or shipping destination beyond tolerance.

3. High‑Risk Email Signals

Disposable domains, newly created mailboxes, and mismatched name–email patterns.

4. Shipping vs. Billing Distance

Decline or review when distance exceeds a configured threshold (e.g., >1,000 km).

5. Blacklists and Prior Incidents

Block known bad cards, emails, addresses, and device fingerprints; decay entries with time.

Rules act first; only uncertain cases hit ML.

ML Scoring (Pragmatic)

• Start with gradient boosting or logistic regression
• Features: velocity, geo mismatch, device fingerprint, history
• Thresholds: score >= 0.8 → decline, 0.5–0.8 → review, <0.5 → approve

Data Enrichment

• IP reputation (AbuseIPDB)
• Email validation
• Device fingerprint
• Historical buyer risk

Workflow in Practice

1. Receive Event via Webhook

Normalize the order payload and attach a requestId for tracing.

2. Evaluate Rules First

If any hard rule triggers, decline immediately and notify with the reason code.

3. Enrich and Score

Fetch IP/device/email enrichments, then compute an ML risk score for borderline cases.

4. Decide and Route

Approve, decline, or send to manual review; persist features and decision for audits.

Best Practices

• Keep rules versioned and auditable
• Log features & decision for every order
• Rate‑limit providers and cache enrichments
• Periodically retrain models; watch drift
• Provide a reviewer UI with quick actions

Deployment Considerations

• Ensure sub‑second rule evaluation; keep enrichment async with timeouts
• Use DLQ for timeouts/errors; don’t block the checkout
• Track false positives/negatives; iterate thresholds

Real‑World Impact

• 30–60% lower chargebacks with layered rules + ML
• Faster order processing; fewer manual reviews

Related Reading

• All articles on architecture
• n8n Webhook Best Practices

Next Steps

1. Define initial rule set and thresholds
2. Implement webhooks + rules engine; log decisions
3. Add enrichment + baseline ML model