Card-Testing Attacks: How Velocity Features Catch a Burst of Small Charges

The attack that hides in small numbers

Someone has a list of stolen card numbers — many incomplete, some already dead. They run small charges to find which ones still work and aren't blocked yet. A validated card is then sold on or used for a real purchase somewhere else. Card-testing attack detection is hard for one reason: each individual charge looks unremarkable, so the signal isn't in the transaction, it's in the pattern.

Why it's small and fast

A one-dollar authorization, or a charge against a donation form or a low-value digital good. Hundreds in minutes. The attacker doesn't care about any single charge succeeding — the point is throughput, sorting live cards from dead ones as quickly as possible.

Why per-transaction models miss it

Score that one-dollar charge on its own and everything is fine: small amount, plausible merchant, no obvious anomaly. A model that only ever sees one transaction at a time has nothing to flag. The anomaly only exists across the burst.

Velocity features

The features that catch it are counts over short rolling windows, keyed by entity:

• Authorization attempts per card in the last 1, 10, and 60 minutes.
• Distinct card numbers seen from one device or IP in a short window.
• Decline rate spiking for a specific merchant or BIN range.

Freshness is the whole game

A velocity feature refreshed from a nightly batch table has missed the entire attack — the burst is over in minutes. This is the concrete reason a fraud pipeline needs a streaming feature store rather than batch aggregates. On our fraud-scoring project the velocity and behavioural features are computed continuously from the live event stream, specifically so a card-testing run is visible while it's happening, not the next morning.

What to do when you detect it

Don't just decline the one charge. Rate-limit the card, device, and IP for a cooldown period, alert the affected merchant, and — if the pattern is strong — add a challenge step. Blocking a single transaction while the script keeps running against the next card accomplishes little.

The merchant-side tells

If you run the checkout rather than the fraud engine, a testing run shows up as: a sudden spike in low-value or zero-value authorizations, a jump in the decline rate, a wave of card numbers never seen before, and often a cluster on one payment method or one product (a cheap digital good, a donation field). Any one of these in isolation is noise; two or three together within a short window is the pattern.

A response, end to end

Detection is only the first step. The full loop: flag the burst, rate-limit the card, device, and IP for a cooldown, notify the affected merchant so they can watch their own authorization rate, optionally insert a challenge step for the flagged entities, and feed the labelled burst back into the next retraining pass so the model sees this attack shape. Declining the individual charges while the script moves to the next card is the version that doesn't work.

Where this stops being right

• Legitimate bursts exist. A flash sale, a subscription billing run, a popular product drop all look like velocity spikes. Whitelist known patterns and known merchant behaviours.
• Very low-volume merchants may not generate enough traffic to tune short-window thresholds meaningfully.
• The attack adapts. A defence tuned to one-dollar charges gets evaded by zero-dollar auth checks or by spreading attempts over hours. Monitor the shape, not one fixed rule.

FAQ

Is card testing our problem or the card network's? Both. You absorb the chargebacks and the processing cost, and a testing spike drags down your authorization rate and your standing with the acquirer.

What's the fastest signal? Attempts-per-entity in a short window — minutes — not anything about the individual transaction.

Does 3-D Secure stop it? It raises the attacker's cost but adds friction for real customers, and testers adapt by targeting flows where it isn't enforced. Velocity detection is the lower-friction first line, with a challenge reserved for entities that already look suspicious.

ISTRALLEN builds fraud pipelines with streaming velocity features that surface a card-testing run while it's in progress; see AI for Fintech.