Card testing has always been a numbers game, but the game has gotten more patient. The high-velocity, same-merchant card testing attacks that were easy to catch with simple velocity rules are still happening, but the pattern that causes more damage in 2025 looks nothing like that. Modern card testing operations are slow, distributed, and multi-merchant. They are designed specifically to evade the detection methods built to stop the old pattern.
Understanding how current card testing actually works is the prerequisite for understanding why the detection approach needs to be different.
The Old Pattern and Why It Was Easy to Catch
Classical card testing looked like this: a batch of stolen card numbers, typically from a dump file or BIN attack, would be tested against a single merchant or a small set of merchants in rapid succession. The tester needed to validate which cards were live, which had sufficient funds, and which bypassed AVS checks. Speed was the objective because the window before the card was canceled was short.
This pattern was detectable with a straightforward velocity rule: more than N transactions from the same IP address or device to the same merchant within a short time window triggers a flag. The concentrated attack surface made detection relatively easy. Even a moderately sensitive rule would catch it.
The detection pressure from those rules is exactly what produced the current evolved pattern.
Distributed Low-Velocity Card Testing
The current pattern distributes the testing load in a way that stays below the velocity thresholds of any individual merchant or any single detection rule. Instead of 200 test transactions at one merchant in 10 minutes, a distributed card testing operation might run 3 to 5 test transactions at each of 40 to 60 merchants over 24 to 48 hours.
At any individual merchant, this looks like a small number of authorization attempts from a new account. The per-merchant velocity is low. The transaction amounts are micro-transactions, often $0.01 to $1.99, which fall below alert thresholds and below amounts that cardholders are likely to notice in their statement. The device and IP characteristics are varied, using proxy infrastructure to avoid IP-based velocity rules.
The signal that reveals this pattern is not visible at the individual merchant level. It requires cross-merchant or cross-platform visibility: the same card number appearing at many merchants in a short window, each with a small transaction, is the card testing signature. But most merchants and many payment platforms do not have that cross-merchant visibility. They see only their own transaction stream.
BIN-Range Sequencing vs Enumeration
A related but distinct attack type is BIN enumeration, where the attacker does not have a list of known stolen card numbers but instead iterates through valid BIN ranges systematically, generating plausible card numbers and testing them against a payment acceptance endpoint to find live cards.
Modern enumeration attacks have adapted to bypass bot detection. Instead of running from a single IP with regular timing intervals, they use distributed residential proxy networks, vary request timing with human-like irregularity, and rotate through browser fingerprints. Against payment platforms that rely primarily on device fingerprinting and IP velocity for bot detection, these techniques are effective at avoiding flags.
The characteristic signature of BIN enumeration is the pattern in the card numbers themselves: clusters of attempts within a small number range, high decline rates (because most generated numbers are not active cards), and a small number of authorizations interspersed among many declines. The decline-to-authorization ratio in BIN enumeration is typically very high, often 50:1 or worse, compared to a normal merchant who should have a 95% or better authorization rate on genuine customers.
Monitoring authorization rate by source is therefore a useful detection signal. A sharp decline in authorization rate on transactions from a specific channel, geography, or device cluster, without a corresponding business explanation, often indicates enumeration activity even if no individual card number triggers a velocity rule.
The Wallet Funding Vector
Digital wallet platforms face a specific card testing variant worth addressing separately. The wallet funding flow, adding a card to a digital wallet account, is an attractive testing target because it involves a card authorization that may have lower friction than a typical purchase flow and because a successfully added card can be used for subsequent transactions.
Card testing through wallet funding typically follows a pattern: an account is created, a card is added, a small test transaction is authorized, the account is abandoned if the card is live and that card number is now validated. The information value is in the authorization result, not in retaining the wallet account.
The signals that identify this pattern at the wallet platform level: high ratio of card additions to subsequent wallet transactions (most organic users add a card and then use it; card-testing accounts add a card and stop), authorization-to-abandonment sequences where a card is successfully added and then the account shows no further activity, and multiple accounts with similar creation characteristics adding cards in the same BIN range within a short window.
Why Velocity Rules Alone Are Insufficient
Card testing has specifically adapted to evade velocity rules. That is not a coincidence: it is the direct result of the detection pressure that velocity rules create. The attackers observed which patterns got flagged and adjusted their operation accordingly.
This creates a specific limitation in rule-based card testing detection: rules are transparent. A rule that flags "more than 3 failed authorizations from the same device in 1 hour" teaches the attacker to stay under 3 failed authorizations per device per hour. The rule creates the operational constraint that shapes the evolved attack pattern. Once the rule is public knowledge or inferrable from the platform's responses, the attack adapts around it.
Detection that depends on cross-transaction patterns that the attacker cannot observe or predict is more durable. The card number appearing at many merchants is a pattern the attacker cannot eliminate without reducing the scale of their testing operation; the economics of the attack require testing at scale. The decline rate signature of enumeration is inherent to the enumeration process itself. These patterns are more resistant to adaptation because they are not byproducts of arbitrary rule thresholds; they are structural properties of the attack itself.
Detection Investment Priorities
For platforms that want to improve card testing detection without false-positiving on legitimate low-value transactions, the investment priorities in rough order are: cross-channel signal sharing (if you are part of a network that allows card-number-level shared intelligence, that is the highest-leverage investment because it makes the distributed cross-merchant pattern visible), decline rate monitoring by source segment (immediate visibility into enumeration patterns), account lifecycle velocity combined with behavioral signals for wallet funding flows (catches the add-and-abandon pattern), and behavioral consistency scoring for the checkout session (catches bot-like interaction patterns in the authorization flow regardless of velocity).
What is unlikely to improve card testing detection significantly: adding more velocity rules with lower thresholds (attackers adapt), tightening AVS requirements (the evolved attack pattern often already meets AVS, since the attacker has the full card data), or IP geolocation blocking (distributed proxy infrastructure renders this largely ineffective against professional operations).
