Blog / Fraud analytics, Payments & payment fraud, Ravelin University
This is how fraudsters turn payment authorization into intelligence on stolen cards, often with the help of automation and AI.
30 September 2026
At first glance, card testing and enumeration attacks don’t always look like major card-not-present fraud events.
But behind these seemingly harmless, low-value payments is one goal: to find out which stolen card details work before they are resold or used to commit fraud – often against the same merchant.
This guide explains how card testing works, how it differs from PAN enumeration and other forms of online payment fraud, and which controls help merchants detect, analyze and mitigate attacks without creating unnecessary friction for customers.
Despite the low value of payment involved, good reasons to prevent card testing for merchants and PSPs include:
Merchants can see lower authorization rates from issuing banks on legitimate traffic following attacks
Authorization rates are a key metric which merchants use to choose PSPs
Visa’s enumeration ratio can lead to fines for acquirers and for merchants, per the VAMP monitoring program
Card testing often starts with a low-value purchase such as a donation, subscription trial, account top-up, or digital purchase. But, with the help of readily available tools, scripting, as well as AI, card testing and enumeration increase exponentially, and can become a major issue for merchants.
Friction was cited by 29% of merchants as the primary obstacle to more effective fraud prevention in Ravelin’s Global Fraud Trends 2026 report – the most of any factor.
At the same time, frictionless rates have dropped in 76% of the countries covered by our Global Payments Report 2026, as issuers, schemes and regulators raise the bar for authentication and put more pressure on merchants.
Meanwhile, card schemes monitor card testing closely, penalizing merchants who leave it unchecked with programs such as Visa's VAMP and Mastercard's upcoming GMAP. Although the financial loss may seem minimal, the enumeration ratio calculated by Visa takes into account the number of attempts as well.
Merchants who don’t keep enumeration attacks under control may find themselves paying higher fees for all card payments, or even banned from using certain card schemes.
Card testing refers to the automated use of online payment flows to check whether stolen card details work, by attempting low-value transactions to see if they go through.
Fraudsters aren’t usually interested in this transaction itself. Instead, they are looking for feedback – a way to tell which cards can still be used for more profitable, more complex, schemes.
Note here that card testing describes the activity of checking card details itself. This can range from brute-force attacks to AI-powered automation and scripts. If the transaction is small in nature and the intention is to check which cards work, it qualifies as card testing.
An authorization attempt can show whether the issuer approved or declined the payment, whether authentication was requested, or whether the response suggested a problem with the card number, expiry date, CVV, or account status.
For fraud and payments teams, the challenge is twofold:
Card testing and enumeration attacks don’t always look the same, especially as criminals move from high-decline guessing attacks to less obvious attacks using real stolen card details.
The response has to be precise, because blunt controls create the friction and churn merchants are trying to avoid.
Several small payments let attackers test more cards with less exposure than medium or high value payments. They are also exempt from any SCA multi-step authentication requirements as "low-value", even per the EU's strict PSD2 regulation.
These purchases blend into normal checkout traffic more easily than large purchases, particularly if attempts are spread across different accounts, devices, or payment methods.
Card testing affects any online merchant that accepts card payments, but fraudsters often look for payment flows with low fulfillment friction.
Common targets include:
subscriptions
gift cards
donations
account top-ups
low-value ecommerce items
Such flows enable the attacker to test quickly, observe the payment response, and move on quickly without waiting for physical delivery.
Low-friction environments are always easier to test fraud on, more widely.
Strictly speaking, card testing, PAN enumeration, and scripted payment fraud are very closely related attacks, but they describe different attacker goals.
Card testing usually starts with card details already in the fraudster’s possession.
Primary account number (PAN) enumeration, on the other hand, is a more specific form of card testing where fraudsters test or guess card numbers, expiry dates, and CVVs to discover valid credentials.
Either way, it is the feedback from these attempts that helps fraudsters figure out correct card details.
Meanwhile, scripted payment fraud refers to the use of automation to make purchases at scale. Although card testing can be scripted, not all scripted payment fraud is card testing.
| Pattern | Main goal | Typical signals | Impact on merchant |
|---|---|---|---|
| Validation attack | To validate existing card details through payment attempts | Low-value attempts, repeated payment behavior, unusual velocity, issuer response patterns, linked accounts or devices | Higher declines, chargeback exposure, authorization pressure, operational workload, card network scrutiny |
| PAN enumeration / BIN attack | To discover valid card details through repeated testing or guessing | High attempt volume, low authorization rates, expiry or CVV guessing patterns, concentrated activity around a Bank Identification Number (BIN) | Card network, issuer, acquirer, and/or processor scrutiny, higher payment processing costs, lower approval rates |
| Scripted payment fraud | To make fraudulent purchases at scale, including card testing | Successful orders, repeated baskets, resale-friendly goods, rapid fulfillment, linked accounts, devices, or payment methods | Direct fraud loss, chargebacks, inventory loss, customer support pressure |
Card testing is sometimes mentioned alongside carding and BIN attacks, but these terms don’t always describe the same behavior.
Carding usually refers to the broader criminal use of stolen card details. The term BIN attack describes testing the first 6 to 8 digits that identify the card network and the specific issuing bank, while PAN enumeration typically includes testing the entire 16- to 19-digit string.
Note that in the case of PAN enumeration, cybercriminals target sites that don’t require a CVV, and potentially brute-force the cards’ CVV in a separate step.
When validated cards are used for fraudulent purchases, card testing contributes to the wider challenge of preventing chargebacks and disputes in ecommerce.
Older enumeration-style attacks often involved large volumes of guessed or generated card details. Many invalid combinations fail in this scenario, which creates low authorization rates and obvious spikes in declined transactions for the merchant.
Fraudsters are also testing real, stolen card data. These card details are more likely to be valid (unless/until the consumer freezes or cancels their card, or the card expires), so more attempts pass authorization compared to attacks where the details are guessed.
It's important for detection to move beyond looking at decline rate alone, with fraud teams now needing to compare authorization patterns with a suite of different factors.
These include BIN concentration, device reuse, new account behavior, velocity checks, issuer response codes, and linked activity. By examining the behavior of a shopper account – and considering it in comparison to acceptable and typical behavior – merchants can prevent card testing with accuracy.
Card testing attacks vary by merchant, payment flow, and attacker sophistication, but many follow the same basic sequence: Fraudsters obtain card data, run automated payment attempts, read the issuer response, and retain the cards that work.
1. Acquire or buy card data: A card testing attack usually starts with card details the fraudster wants to validate. These often come from phishing-related data breaches that involve social engineering and account takeover, but they may also be sourced via criminal marketplaces.
2. Automate checkout or payment attempts: Once fraudsters have the card data, they use scripts, bots or AI to submit payment attempts at scale through checkout pages, payment forms, or account update flows.
3. Vary traffic to avoid detection: Card testing rarely involves the same card, account, and device making the same request again and again. Instead, attackers try to mask that repetition across the identifiers merchants use to detect abuse, such as:
IP address
device fingerprint
account
session behavior
transaction timing
The overarching goal for fraudsters is to stop each attempt from having too many obvious shared data points with the last attempt.
4. Learn from issuer responses: Attackers then receive feedback. The issuer may approve the payment, decline it, request authentication, or return a response that points to an invalid card number, expiry date, CVV, or account status. Those responses help attackers judge the quality of the card data. A failed attempt may show that the card details are unusable, or that one detail is wrong while the card itself may still have value.
5. Keep the cards that work: The cards that receive a favorable response can then be sold or used elsewhere, with failures likely discarded. Partial failures, like an incorrect expiry date or CVV, may be retested with variations or tried in another payment flow.
Card testing doesn’t always announce itself with a flood of failed payments. As we noted earlier, some attacks cause visible decline spikes while others survive undetected for longer.
Nevertheless, here are some of the most obvious signs:
A fraud decline rate measures how often a merchant’s fraud controls block or reject payment attempts. A network decline rate is the share of payment attempts declined through the card network, usually because the issuer does not approve the transaction.
Both fraud and network decline rates can rise during card testing. Fraud controls reject traffic that matches risk patterns, and issuers decline card details that are invalid, expired, blocked, or inconsistent with the customer profile.
The key question is whether either rate has moved outside the merchant’s normal range.
A small increase may be expected during seasonal peaks or during marketing campaigns, but a more substantial rise that cannot be explained by normal fluctuations should invite closer scrutiny.
Card testing can also create clusters that would be easy to miss at transaction level but stand out when grouped by BIN, expiration date, card, device, IP address, account, or payment method.
Machine learning is particularly strong in flagging such anomalies in the data. Fraud teams may see:
more attempts from the same BIN
repeated attempts against the same card
several accounts or devices linked to similar payment attempts
These clusters may suggest that the attacker is testing related card details or reusing the same infrastructure. And the stronger the pattern, the less each transaction should be viewed in isolation.
Velocity is the speed and frequency of activity. In card testing, it may present as:
too many payment attempts from the same account
too many cards tried on one device
too many low-value attempts with similar characteristics
Thin identities (sometimes called thin files) are accounts or customer profiles with limited merchant-side history. They tend to be recently created accounts that are associated with sparse behavioral data and repeated, low-value payment attempts.
Burner accounts are also of relevance, as they can be set up specifically to be used later thus avoiding any obvious fraud rules associated with activity from newly registered accounts.
Low authorization rates can be symptomatic of enumeration activity because guessed or generated card details fail at high volume. In those attacks, the merchant may see a sharp rise in declines.
Newer verification-style attacks are harder to spot.
When fraudsters use real stolen card data, more attempts pass authorization and move further through the payment flow. As a result, the pattern may only become clear when fraud teams consider activity across cards, accounts, devices, and issuer responses.
Visa’s Spring 2025 Biannual Threats Report found that enumerated transactions increased by 22% over the prior six-month period, while enumerated PANs increased by 8% over the same period.
These numbers reinforce the need for fraud teams to assess decline data in the context of the surrounding payment behavior.
Card testing mitigation requires both speed and precision. Slow responses give attackers more time to validate stolen cards, while heavy-handed controls block legitimate customers along with the attack traffic.
An effective response follows the same basic sequence: detect the change, identify the pattern, contain the activity, improve the data behind detection, and feed what the team learns back into future controls.
To detect the attack, start with the payment and fraud signals that move first:
authorization rates
fraud declines
network declines
payment attempt volume
issuer response codes
payment velocity
Breaking payment and fraud data down by BIN, merchant ID, product flow, and payment method can show where card testing activity has started to concentrate.
If attempts cluster around one of these points, teams can investigate before the attack spreads.
Real-time AI fraud prevention identifies such attacks at scale, flagging anomalies and suspicious behavior over time.
Once a possible attack has been detected, it’s important to compare the suspicious activity with normal payment behavior for this specific merchant's good customers.
Comparisons should occur within the appropriate traffic segment.
For example, online card-not-present traffic shouldn’t be treated the same as card-present activity, and a spike in one payment flow shouldn’t drive controls across every customer journey.
In addition, link analysis for fraud detection helps gauge whether ordinary-looking payment attempts share enough in common to indicate card testing.
Mitigation should then be targeted to the pattern identified. That might mean velocity controls, BIN or device-based rules, account restrictions, stronger authentication, bot controls, or temporary risk threshold changes.
Where possible, test new rules in simulation or listen mode before they go live. This shows fraud teams what each rule would block and helps reduce false positives during an active attack.
Once the risk has been contained, teams should review and normalize any temporary thresholds. Measuring the success of fraud prevention tools means weighing thwarted attacks against authorization rates, false positives, and the customer experience.
Ravelin’s online payment fraud detection brings behavior monitoring, machine learning, granular rules, and graph networks together so that merchants can make those decisions with more context than a single transaction review permits.
Card testing often exposes gaps in data coverage. If key fields are missing, inconsistent, or unavailable, there is less evidence to separate fraudulent and legitimate sources of traffic.
The priority isn’t just to collect more data; teams need high-signal fields captured consistently across MIDs, payment flows, regions, and PSP integrations. Otherwise, the same attack could look different depending on where it enters the business.
Ravelin’s work on selecting and engineering ML features for fraud detection shows why the quality, consistency, and relevance of those inputs matter as much as the volume of data collected.
To that end, teams must prioritize:
BIN and MID aggregations
issuer response codes
account age
device data (fingerprint, browser and session behavior)
repeated expiry-date patterns
card-age-style features where available.
With the attack contained, card testing traffic should feed back into future detection. Our guide to AI fraud detection with ML and NLP explains how machine learning analyzes fraud patterns to improve future detection.
Teams should also capture the response while the relevant details are still fresh. An incident review should explain how the attack was identified, which controls were applied, and when controls were relaxed. Reviews should also record any handoffs between fraud, payments, engineering, support, and PSP or acquirer teams.
The next card testing attack may not follow the same pattern, but a documented response gives the company a stronger starting point, enabling fraud prevention to catch it more readily next time.
Ravelin's CNP solution detects anomalous behavior across the entire shopping journey.
During an active enumeration attack, teams need to confirm the scope quickly before they tighten controls.
Metrics show where the attack is concentrated, while transaction samples help clarify which BINs, payment flows, issuers, or merchant IDs are involved.
A sophisticated graph network link analysis tool such as Ravelin's Connect works on several levels – one of which is to enable quick defenses during an attack, providing visual context and speedy actioning.
Connect also supercharges the investigative layer by revealing the hidden relationships between users and how fraudulent accounts, devices, cards, and transactions are linked.
Once the scope is understood, make sure your response should focus on the affected segment. Controls applied too widely can create approval-rate pressure and unnecessary customer friction, especially when the attack is limited to one segment and not the payment environment itself.
The response also needs close monitoring. Teams must observe whether the attack shifts after controls go live, and whether controls create false positives, customer complaints, or decline pressure. These areas are critical, with 55% of consumers indicating they would abandon a purchase because of friction.
Exact thresholds depend on merchant size, volume, market, and payment setup.
Smaller merchants may manage one checkout flow or MID.
For enterprise merchants, managing enumeration fraud requires visibility across multiple brands, MIDs, regions, and payment service providers.
The same response discipline applies to card testing and enumeration attacks: Confirm the scope, focus controls on the affected segment, watch for changes in behavior, and incorporate any insights to improve the next response.
Card testing prevention requires layered ecommerce fraud detection, a fast response, and enough checkout data to discern likely attack traffic from legitimate payment behavior.
The aim is to recognize the early warning signs of a coordinated attack. Many teams only discover card testing once the signs are obvious but with the correct solutions in place, it’s much easier to see when payment behavior moves outside its expected range and investigate proactively.
That critical context helps teams respond with more precision. Instead of applying broad controls across the whole checkout, merchants can narrow their focus to only the affected segment, adjust thresholds as needed, and continually improve detection as new attack patterns emerge.
Detect fraud along the entire customer journey with confidence with our AI-native solution.
A card testing attack occurs when fraudsters use an online payment flow to check whether card details are valid.
The payment is usually of low value because the transaction is only a test. What matters is whether the issuer approves, declines, or requests authentication.
Fraudsters obtain card details, submit automated payment attempts through checkout or another payment flow, and read the issuer response.
Approved payments, authentication requests, and certain decline patterns help them decide which cards are worth keeping. Attackers often rotate accounts, devices, emails, or IP addresses to make the attempts harder to connect.
Bear in mind, however, that the two terms are often used interchangeably, especially with Visa introducing the “enumeration rate” in recent VAMP monitoring program updates.
The consequences of letting card testing happen on your ecommerce website go beyond obvious financial losses. Higher chargeback rates can get you in trouble with card schemes such as Visa and Mastercard, resulting in higher fees paid by you for each transaction. For PSPs, higher authorization rates are always appreciated.
Fraudsters card-test because unverified card details have uncertain value. A favorable issuer response tells them which cards are more likely to work, making those details easier to sell, monetize, or successfully use in a later fraud attempt.
In that sense, this testing payment is less of a purchase and more a validation step.
Common signs of card testing include:
There's a subtle difference, based on the fact that a BIN attack focuses on the first 6 to 8 digits of a card (which identify the card network and issuing bank) while a PAN enumeration attack typically involves the entire number. However, be advised that the two terms are sometimes interchangeably in our industry.
Rosalie Rogers Data Science Manager
