Fraud Scoring

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €20–35/month

Generated from docs/plan/paid/fraud-scoring/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merged from duplicate proposals: “Advanced fraud scoring and payment risk”, “Fraud Detection & Risk Scoring”, “Fraud Scoring”

A paid module that scores orders as high/medium/low risk at checkout and flags risky orders for manual review before fulfillment. The system learns from historical chargebacks, reviews IP reputation, and detects velocity abuse (10 orders from same IP in 5 minutes). Merchants set review thresholds and receive email alerts for flagged orders.

The problem

A merchant processes 100 orders daily; 5% are fraud. Currently, they discover fraud after chargeback (60–90 days), losing revenue plus chargeback fees (€25–$100 per dispute). They need automated flagging so they can review high-risk orders before fulfillment, blocking fraud before it costs them.

What it does

• Score order at checkout: analyze IP reputation (via third-party DB), payment method history, velocity (5 orders in 5 min = suspicious), customer email domain
• Risk factors: shipping address ≠ billing address, new customer, high-value order, known-fraud IP, email domain recently registered, velocity abuse
• Assign risk_score (0–100) and risk_level (‘low’, ‘medium’, ‘high’) to every order
• Configurable thresholds in admin: flag for manual review if score > X (default: 70)
• Flag orders: order.flagged_for_review = true, order.review_reason = [‘high_velocity’, ‘new_customer’, ‘high_value’]
• Email alert to shop owner/fraud team when order is flagged
• Manual review UI in admin: list of flagged orders with risk breakdown, one-click ‘approve’ or ‘cancel’ action
• Audit trail: log who reviewed order, when, and decision (approve/cancel) with reason

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Automatic order cancellation or hold (merchant always makes final decision; system flags, not auto-blocks)
• Chargeback prediction (requires historical chargeback data as training; too many unknowns)
• Payment-method tokenization or 3D Secure enforcement (payment processor owns this; we do not store card data)
• Refund automation (merchant initiates refund; we do not auto-reverse payments)

Data model

Add fraud_score table: { id, order_id, risk_score, risk_level, risk_factors (JSON array), flagged_at, reviewed_at, reviewed_by_user_id, review_decision, review_reason }. Add order.fraud_review_required (BOOLEAN). Schema migration: new table, safe.

API

• POST /checkout/score-order — internal; called by checkout flow before order.create
• GET /admin/orders?flagged=true — list orders requiring review
• GET /admin/orders/:id/fraud-review — read fraud score and risk factors
• PUT /admin/orders/:id/fraud-review — update review_decision and review_reason (approve/cancel)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Add ‘Fraud Review’ dashboard in Commerce > Orders. Tab: ‘Flagged for Review’ with count. Table: order_id, customer_email, risk_score (color bar), risk_factors (tags), timestamp. Click row to see risk breakdown. Quick actions: ‘Approve & Proceed’, ‘Cancel Order’, ‘Block IP’. Show threshold setting: ‘Flag orders with score > 70’ (adjustable slider).

The seam — why this is paid

Paid module owns the fraud-scoring algorithm, IP reputation database subscription, and support burden for false positives. Core owns the order data model and review audit trail. Merchants cannot access this without the paid subscription (not a core feature that merchants can build themselves).

Reduces fraud losses and chargeback costs. Low-value or digital-only sellers may not need this. Support commitment justified by risk reduction ROI.

Dependencies

• Order system (must exist to score orders)
• Checkout flow (must call scoring before order creation)
• Email system (to alert on flagged orders)
• Third-party IP reputation database (must be available; cost is borne by module)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• An order with shipping_address ≠ billing_address AND from a new customer receives risk_score >= 60
• If 10 orders are placed from the same IP in 5 minutes, all 10 receive ‘high_velocity’ in risk_factors
• Admin sets threshold to 75; an order with risk_score = 74 is not flagged, risk_score = 76 is flagged
• Approving a flagged order sets review_decision = ‘approved’, order proceeds to fulfillment
• Canceling a flagged order sets review_decision = ‘canceled’, order status = ‘canceled’, refund is queued
• Email alert to shop owner includes order_id, risk_score, and risk_factors as bullet points

Risks

If IP reputation data is not updated frequently (stale data = many false positives). If threshold is too low, staff spends all day reviewing legitimate orders (tuning burden). If reviewing order does not update order status (e.g., ‘reviewing’ status is never checked at fulfillment), fraudsters still get their orders shipped. If fraud_score is computed but never enforced (merchant sees flag but doesn’t act), value is zero.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.