Card testing is one of the most structurally predictable fraud patterns in payments, and yet it continues to drain merchants and PSPs at scale. The basic mechanic has not changed in years: an attacker acquires a batch of stolen card numbers — purchased from a carding marketplace, extracted from a data breach, or generated algorithmically using BIN patterns — and needs to verify which ones are live before cashing out with a high-value purchase. The verification process is the card test: a sequence of small-value transactions designed to confirm authorization capability without triggering obvious fraud alerts.
The predictability of this attack pattern should make it straightforward to detect. In practice, it is not, because most velocity-based detection approaches are calibrated to catch tests on a single account or single card, not the distributed testing patterns that modern card testing operations use to stay below per-account alert thresholds.
How Modern Card Testing Operations Work
The unsophisticated card testing operation of a few years ago ran a batch of cards through a single merchant endpoint as fast as possible. That approach triggers obvious velocity alerts: one merchant, many failed authorizations, rapid succession. Most payment platforms caught this quickly.
Current card testing operations are more distributed. They use networks of compromised or throwaway accounts, spread transactions across multiple merchant endpoints, throttle the testing rate to stay below per-account velocity thresholds, and often use real consumer merchants — charitable donation pages, parking meters, streaming service trials — that have low per-transaction values and less sophisticated fraud monitoring.
The result is a card testing signal that is invisible when you look at any single account or any single merchant in isolation. The pattern only becomes visible when you aggregate across multiple accounts, across merchants, or across BIN ranges — and most fraud detection systems are not architected to do that aggregation in real time.
Velocity Clustering: What It Means and What It Catches
Velocity clustering is a detection approach that aggregates transaction events not by account but by shared attributes — same BIN, same device, same IP network, same merchant endpoint — and detects anomalous concentration of activity within those attribute clusters.
The signal is in the cluster density over time, not in the per-account velocity. A card testing operation that spreads 500 probe transactions across 500 different accounts will show up in BIN-level velocity clustering as a concentrated spike in authorization attempts against cards from a narrow BIN range within a short window. Individual accounts are each doing one transaction; the BIN cluster is doing 500.
Practically, BIN-level velocity clustering for card testing detection requires:
- Real-time BIN aggregation. Authorization events must be indexed by BIN prefix (typically 6-8 digits) and made available for fast range queries by time window. This is a different access pattern than per-account lookups and requires a separate aggregation layer optimized for range queries over the BIN space.
- Baseline establishment by BIN range. Not all BINs have the same normal authorization rate. Corporate cards, premium travel cards, and prepaid BINs have distinctive usage patterns. Alerting on absolute velocity rather than deviation from the BIN's own historical baseline produces excessive noise on high-activity BINs and misses attacks on low-activity BINs.
- Cross-merchant aggregation. The cluster analysis only works if transactions from multiple merchants are flowing through the same aggregation layer. This is structurally easier for PSPs (who see transactions across their entire merchant portfolio) than for individual merchants (who only see their own transactions).
Merchant Pattern Analysis: The Attacker's Target Selection Problem
Card testers do not pick target merchants randomly. They look for merchants that are likely to authorize small transactions without triggering strong fraud controls — low-value digital goods, donation forms, parking and transit micropayments, streaming trial sign-ups. These merchants share characteristics: low average transaction value, high authorization approval rates, and historically lower investment in fraud tooling because the per-transaction fraud cost has seemed low.
The irony is that these merchants bear disproportionate chargeback burden from card testing. The card test itself generates a small authorized transaction — often voided or captured and then refunded. The real loss comes when the tested-and-verified cards are used for high-value fraud elsewhere, and the cardholder disputes everything, including the small test transaction. The merchant who was used as a test vector ends up with chargeback exposure on transactions that were tiny individually but numerous in aggregate.
Merchant pattern analysis as a card testing detection signal looks at authorization event distribution across merchants within a PSP network to identify merchants being used disproportionately as test vectors. A merchant whose authorization pattern shows high failure rates, low average transaction values, and BIN diversity (many different BIN prefixes in a short window rather than a concentrated customer base) is a likely card testing target. Elevating the fraud scoring threshold for transactions touching these merchants protects both the merchant and the cardholder.
Authorization Response Code Analysis
Card testing generates a characteristic pattern in authorization response codes that is often underexploited as a detection signal. When an attacker runs a batch of stolen cards, many of them will return decline codes before any successful authorizations — Do Not Honor, Insufficient Funds, Card Reported Lost/Stolen, Invalid Card Number. The sequence of response codes across the probe batch tells you something about the quality of the card list and the method used to generate it.
A high ratio of Invalid Card Number declines followed by eventual successful authorizations is a signal of algorithmically generated BIN-based card number lists being iterated. A high ratio of Do Not Honor declines is more consistent with a breached card database where the issuer has already flagged some numbers. These patterns are useful not just for detecting that card testing is occurring, but for classifying the attack type and estimating the attacker's operational sophistication.
We use authorization response code sequence as a feature in our velocity clustering model. Accounts that show probe-pattern response code sequences — a mix of declines followed by successful authorizations — score higher than accounts that show random variation in response codes, even when absolute velocity is similar.
The CAPTCHA and Rate Limit Problem
A common first response to card testing detection is to add CAPTCHA or rate limiting to checkout flows. We are not dismissing these measures — they do reduce unsophisticated attack volume meaningfully. But they are not sufficient against the current threat model, for two reasons.
First, modern card testing operations bypass CAPTCHA through a combination of CAPTCHA-solving services and real human labor. The economics work because the value of a verified live card number is high enough to justify the cost of CAPTCHA solving at scale. If your primary card testing defense is a CAPTCHA, you are making the attack more expensive but not impossible.
Second, rate limiting calibrated to per-account or per-IP thresholds does not catch distributed testing operations that stay below those thresholds by design. You can rate-limit at levels that severely degrade the legitimate customer experience and still fail to catch a distributed testing operation that has been specifically engineered to stay under your limits.
CAPTCHA and rate limits are friction layers that stop casual attackers. Behavioral velocity clustering and BIN-level aggregation are signal layers that catch sophisticated attackers who have already solved the friction problem. Both matter; neither is sufficient alone.
What Effective Card Testing Detection Requires Operationally
Catching card testing attacks in real time requires aggregate visibility that individual merchants and most fraud tools do not have natively. A single-merchant fraud tool sees its own transactions only; the cross-merchant aggregation that surfaces BIN velocity spikes requires either a PSP-level view or a shared signal network across merchants.
This is one of the structural reasons why card testing remains a persistent problem despite being a well-understood attack pattern. The detection requires a view of the transaction stream that aligns with how attacks are distributed — across merchants, across accounts, across BIN ranges — and most organizations are instrumented to see fraud per-account rather than across these aggregate dimensions.
Building that aggregate view is the investment that actually reduces card testing exposure, not adding more rules to per-account velocity checks that sophisticated attackers already know to stay below.