--- title: Card testing enumeration attacks explained (and the controls to stop them) date: 2026-09-30T11:30:00+01:00 author: Rosalie Rogers canonical_url: "https://www.ravelin.com/blog/card-testing-enumeration-prevention" section: Blog --- Blog /[Fraud analytics](/resources?search=&category%5B0%5D=134547#resourceContainer "Go to Fraud analytics"), [Payments & payment fraud](/resources?search=&category%5B0%5D=189241#resourceContainer "Go to Payments & payment fraud"), [Ravelin University](/resources?search=&category%5B0%5D=257999#resourceContainer "Go to Ravelin University") # Card testing enumeration attacks explained (and the controls to stop them) This is how fraudsters turn payment authorization into intelligence on stolen cards, often with the help of automation and AI. 30 September 2026 ![Card testing enumeration attacks explained (and the controls to stop them)](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_blogSmall/515-Card-Testing-Feature-885x505.webp) 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](https://www.ravelin.com/insights/online-payment-fraud), and which controls help merchants detect, analyze and mitigate attacks without creating unnecessary friction for customers. ## **Why it’s important to prevent card testing** 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](https://www.ravelin.com/blog/visa-vamp-changes-chargeback-disputes) 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*](https://pages.ravelin.com/fraud-trends-report-2026-ecommerce) 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*](https://pages.ravelin.com/global-payments-report-2026-authentication), 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](https://www.ravelin.com/blog/visa-vamp-changes-chargeback-disputes) 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. ## What is card testing? 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. ### Why card testing can be tricky to prevent For fraud and payments teams, the challenge is twofold: 1. 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. 2. The response has to be precise, because blunt controls create the friction and churn merchants are trying to avoid. ### **Why fraudsters use low-value transactions** Several small payments let attackers test more cards with less exposure than medium or high value payments. They are also [exempt from any SCA](https://www.ravelin.com/blog/sca-transaction-optimization-guide-exemptions) 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. ## Common targets for card testing Card testing affects any online merchant that accepts card payments, but **fraudsters often look for payment flows with low fulfillment friction**. Common targets include: - [digital goods](https://www.ravelin.com/sector/fraud-prevention-for-digital-goods-subscriptions) - subscriptions - [marketplaces](https://www.ravelin.com/sector/fraud-prevention-for-online-marketplaces) - 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. ## Card testing vs enumeration vs scripted payment fraud 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. ### Types of card testing attacks PatternMain goalTypical signalsImpact on merchantValidation attackTo validate existing card details through payment attemptsLow-value attempts, repeated payment behavior, unusual velocity, issuer response patterns, linked accounts or devicesHigher declines, chargeback exposure, authorization pressure, operational workload, card network scrutinyPAN enumeration / BIN attackTo discover valid card details through repeated testing or guessingHigh 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 ratesScripted payment fraudTo make fraudulent purchases at scale, including card testingSuccessful orders, repeated baskets, resale-friendly goods, rapid fulfillment, linked accounts, devices, or payment methodsDirect 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](https://www.ravelin.com/blog/how-to-prevent-chargebacks-ecommerce). ### **Real stolen data in card testing** 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](https://www.ravelin.com/blog/connect-ravelin-graph-database-network-analysis-link-analysis). 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. ## How do card testing attacks work? 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](https://www.ravelin.com/insights/account-takeover-fraud), 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 - email - 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. ## Signs that fraudsters are card testing on your online shop 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: #### **1. Changes in fraud and network decline rates** 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](https://www.ravelin.com/blog/marketing-push-ecommerce-fraud), but a more substantial rise that cannot be explained by normal fluctuations should invite closer scrutiny. #### **2. Spikes by BIN, card, or shared identifier** 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](https://www.ravelin.com/insights/machine-learning-for-fraud-detection) 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. #### **3. Unusual velocity and thin identities** 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](https://www.ravelin.com/blog/ecommerce-burner-account-fraud) 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. ### **Why low authorization rates aren’t enough** 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](https://corporate.visa.com/content/dam/VCOM/corporate/solutions/documents/visa-perc-biannual-report-spring-2025.pdf), 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. ## Prevention and mitigation controls for card testing 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.** #### **Step 1: Detect the attack** 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](https://www.ravelin.com/blog/ai-fraud-detection-with-ml-and-nlp) identifies such attacks at scale, flagging anomalies and suspicious behavior over time. #### **Step 2: Identify the pattern fast** 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](https://www.ravelin.com/insights/link-analysis-and-graph-database-for-fraud-detection) helps gauge whether ordinary-looking payment attempts share enough in common to indicate card testing. #### **Step 3: Mitigate quickly** 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](https://www.ravelin.com/blog/reduce-false-positives-fraud) 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](https://www.ravelin.com/blog/success-of-fraud-prevention-tools) means weighing thwarted attacks against authorization rates, false positives, and the customer experience. Ravelin’s [online payment fraud detection](https://www.ravelin.com/solutions/online-payment-fraud) 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. ![rules testing on ravelin](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/Test-rules.png)#### **Step 4: Improve detection quality** 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](https://www.ravelin.com/blog/feature-engineering-at-ravelin) 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. #### **Step 5: Close the loop** With the attack contained, card testing traffic should feed back into future detection. [Our guide to AI fraud detection with ML and NLP](https://www.ravelin.com/blog/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 Logo](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/ravelin-symbol-logo-transparent.webp) ## Payment fraud detection, done better Ravelin's CNP solution detects anomalous behavior across the entire shopping journey. [Discover our payment fraud solution ](https://www.ravelin.com/solutions/payment-fraud-prevention) ## What to do during an active enumeration attack 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](https://www.ravelin.com/blog/connect-ravelin-graph-database-network-analysis-link-analysis) 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](https://www.mastercard.com/content/dam/mccom/shared/business/intelligence-insights-ai/pdf/Digital-Payment-Security-Principles-Dec-22-2025.pdf) 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**. ## How to prevent card testing 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. ![Ravelin Logo](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/ravelin-symbol-logo-transparent.webp) ## Accept more payments with confidence Detect fraud along the entire customer journey with confidence with our AI-native solution. [Discover our payment fraud solution ](https://www.ravelin.com/solutions/payment-fraud-prevention) ## Frequently Asked Questions **What is a card testing attack?** 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. **How does a card testing attack work?** 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](https://www.ravelin.com/blog/visa-vamp-changes-chargeback-disputes). **If cards are tested with such low value purchases, why should merchants prevent card testing?** 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. **Why do fraudsters test cards?** 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. **What fraud signals and signs indicate card testing?** Common signs of card testing include: - changes in fraud or network decline rates - unusual authorization patterns - repeated attempts with the same BIN or card - abnormal payment velocity - thin profile accounts attempting similar payments **Are PAN enumeration attacks the same as BIN attacks?** 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. ## Author ![Rosalie Rogers](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_avatarSmall/287252/rosalie.webp) Rosalie RogersData Science Manager A Mathematics graduate from the University of Bath, Rosalie Rogers boasts a background that reveals an undeniable, infectious passion for data: “I’ve… [More from this author](https://www.ravelin.com/author/rosalie-rogers) ## Related content [Blog / Fraud trends ### Online Retail Fraud Trends 2026: New global report Refund abuse just outranked traditional forms of first-party abuse in terms of its negative impact on retailers – while 78% say fraud has stifled their growth to some extent. ![1669287463716 2023 12 07 164059 ybjd](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/196785/1669287463716_2023-12-07-164059_ybjd.webp)Nikoleta Dimitriou,Senior Content Manager](https://www.ravelin.com/blog/online-retail-fraud-trends-2026) [Blog / 3DS & SCA ### What's the difference between 3D Secure 1, 2 and 2.3? Strong Customer Authentication is required in more and more countries around the world. Here’s a quick explanation of the key differences between the 3D Secure versions. ![Catherine Jones](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/76597/kit-photo.webp)Catherine Jones,Product Director ![James hogan](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/274718/james-hogan.webp)James Hogan,Senior Product Manager – Payments Engineering](https://www.ravelin.com/blog/whats-the-difference-between-3d-secure-1-and-2) [Blog / Fraud analytics ### Burner account detection requires continuous behavioral monitoring and network analysis Today we explore ecommerce burner accounts and why it's important for merchants to home in on and ban them before they do harm. ![Unnamed 3](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/265422/unnamed-3.webp)Nelda Biltauere,Senior Fraud and Payments Researcher](https://www.ravelin.com/blog/ecommerce-burner-account-fraud)