Payment Fraud Detection

A single transaction rarely looks fraudulent in isolation. Real fraud detection combines velocity checks (how many attempts, how fast), device/behavioral signals, and risk scoring to catch patterns a single approve/decline check would miss.

Velocity checks (how many card attempts from one device/IP in a short window) catch card-testing attacks that a single-transaction risk score alone would miss

Risk scoring combines many weak signals (new device, mismatched billing/shipping country, unusually large first-time order) into one decision, rather than relying on any single hard rule

Manual review queues exist for the ambiguous middle ground — scores too risky to auto-approve, not risky enough to auto-decline — where a human's judgment adds real value

Overly aggressive fraud rules cost real revenue by declining legitimate customers, so fraud systems are tuned as a false-positive/false-negative tradeoff, not toward 'block everything suspicious'

Hands-on demo

Score a transaction

Combine a few weak signals and see how the risk score — not any single rule — decides the outcome.

Order amount $80

Try it yourself

Try it yourself — run a scenario below, then flip this and replay it to see what changes.

Card Testing Attack Detected

An attacker runs small transactions across many stolen card numbers to find which ones still work.

Want this flow explained in detail as it plays?

checkout.flowground.dev

Checkout

Amount$1.00

Card•••• 1

Attacker

App

Fraud Engine

A tiny amount, designed to slip under typical fraud thresholds while confirming the card is still valid.

Selected hop

Attacker submits a $1.00 charge using stolen card #1

Attacker

The malicious actor attempting to exploit this flow.

App

The application's backend — enforces business rules and decides what every request is allowed to do.

What happens here

A tiny amount, designed to slip under typical fraud thresholds while confirming the card is still valid.