Fraud Prevention

CardNexus has a layered Trust & Safety system that captures behavioral signals at checkout, computes risk indicators across the order lifecycle, and surfaces them to the admin team for review. This page covers how it all works — from raw data collection through to Discord alerts.

Architecture Overview

The fraud prevention system has four layers that build on each other:

Data Collection

Transaction: Buyer Context

When a buyer initiates checkout, we capture device and location data from the request and store it on the transaction:

Transaction: Stripe Risk Data

After payment succeeds, the checkout.session.completed webhook populates the stripeRisk object from the Stripe charge:

User Profile

We track the most recent device snapshot on the user profile, updated on high-value actions (checkout, listing creation, login):

• lastIp — most recent IP address
• lastUserAgent — most recent browser user agent
• lastCountry — most recent detected country

These are lightweight fields for quick buyer-seller comparison at order assessment time.

Risk Indicators

Each risk indicator has a code, severity (info / warning / critical), a human-readable message, optional data, and a detectedAt timestamp.

Severity Levels

The order risk level is the highest severity across all its indicators. The transaction risk level is the highest across all its orders.

Full Indicator Catalog

Order Creation Detectors

These run when a transaction completes (all orders in the transaction assessed together):

Status Transition Detectors

These run when an order reaches a fund-releasable status (completed, resolved_no_refund, resolved_partial_refund):

Tracking Detectors

These run when the order.delivered event fires (tracking confirms delivery):

Background Job Detectors

Assessment Flow

When Assessment Runs

Risk assessment is triggered by domain events — not called synchronously from API handlers:

Batch Context Fetching

The assessTransactionOrders method is optimized for multi-order transactions. It batch-fetches:

1. All orders in the transaction
2. All distinct sellers (with createdAt, lastIp, lastCountry)
3. The buyer (with createdAt)
4. Buyer’s completed purchase count
5. Per-seller: completed sales count, card fingerprints from past purchases
6. Per-order: earliest listing creation date, recent order count for the buyer-seller pair

This data is assembled into an OrderCreationContext object passed to each detector — detectors themselves never hit the database.

Catch-Up Cron

A background job runs every 15 minutes to catch any orders that were missed by the real-time subscriber (e.g., due to temporary failures or deployments):

// Finds orders older than 10 minutes that were never assessed
const unprocessed = await OrderModel.find({
    riskAssessedAt: null,
    createdAt: { $lt: tenMinutesAgo },
})

It groups the unprocessed orders by transaction and runs assessTransactionOrders for each, with a try/catch per transaction so one failure doesn’t block others.

Indicator Persistence

When detectors produce indicators, persistIndicators handles storage:

• With indicators: Appends to Order.riskIndicators via $push, computes the new riskLevel (highest severity), sets riskUpdatedAt and riskAssessedAt, then emits an order.risk_updated event.
• Without indicators: Still sets riskAssessedAt so the catch-up cron knows this order was processed.

After all orders in a transaction are assessed, the transaction’s riskLevel is updated to the highest across all its orders.

Fund Release Safeguards

Beyond detection, the system also enforces a hard minimum hold period on funds:

payoutEligibleAt = max(calculated, createdAt + 7 days)

No matter how fast an order progresses through its lifecycle, funds cannot be released before 7 calendar days from order creation (FUND_RELEASE_HARD_MINIMUM_DAYS = 7). This prevents rapid fund extraction through colluding accounts.

Admins can also extend the hold period on suspicious orders via the admin panel (reason required for audit trail). There is no action to shorten — we never accelerate release below the minimums.

See Fund Management for the full fund release flow.

Admin UI

Order List

The order list page has risk-related columns and filters:

• Risk Level column — colored badge (info/warning/critical)
• Risk Level filter — filter by severity
• Review Status filter — needs_review / reviewed / all

Order Detail: Risk Indicators Card

When an order has risk indicators, a dedicated card appears showing:

• Overall risk level badge with color-coded border (amber for warning, red for critical)
• Each indicator with severity icon, code, message, and detection timestamp
• Tooltips with exact timestamps on hover
• “Mark as Reviewed” / “Unmark Reviewed” button

Review Workflow

The review workflow is timestamp-based — no complex state machine:

• Needs review = has indicators AND (riskReviewedAt is null OR riskUpdatedAt > riskReviewedAt)
• Reviewed = riskReviewedAt >= riskUpdatedAt

This means if an order is reviewed at WARNING level and a CRITICAL indicator fires later, it surfaces again as “needs review” automatically.

Discord Alerts

Critical indicators trigger real-time Discord notifications via the existing webhook integration. The DiscordRiskAlertHandler subscribes to order.risk_updated events and sends an alert embed when any of these codes are detected:

• SAME_IP — buyer and seller share an IP
• SAME_CARD — buyer used seller’s card
• TRACKING_PREDATES_ORDER — recycled tracking number
• INSTANT_COMPLETION — order completed in under 24 hours

The alert includes the order number (linked to admin panel), risk level, critical indicator codes, and buyer/seller usernames.

Stripe Radar Configuration

The system relies on Stripe Radar being configured with these rules (Stripe Dashboard > Radar > Rules):

EU transactions already require 3DS under PSD2/SCA. The rule for score ≥ 65 targets NA transactions specifically.

Code Locations