Card Testing and Enumeration Attacks: How They Work and How to Stop Them

Card testing is not a sophisticated attack. It does not require technical depth, insider access, or custom malware. It requires purchased card data (widely available on carding forums for $1–15 per record), scripted automation, and a merchant endpoint with insufficient rate limiting. The economics are straightforward: a validated card sells for $5–50; an unvalidated card data record costs $1–5. The fraudster’s job is to run enough test authorisations to sort the active cards from the inactive ones.

The merchant is the testing service. The costs — authorisation fees, elevated fraud ratios, VAMP exposure, potential chargeback exposure from follow-on fraud — fall entirely on the merchant. Understanding the attack is the first step to making it economically unviable against your endpoint.

How Card Testing Works: The Attack Anatomy

Step 1: Data acquisition. Card data is purchased from carding markets — underground marketplaces that sell card details (PAN, expiry, CVV, sometimes billing address and cardholder name) in bulk. Data comes from payment card breaches, phishing, skimming, or dark web aggregation. At scale, attackers purchase hundreds of thousands of records.

Step 2: Credential organisation. Card data is grouped by BIN (Bank Identification Number — the first 6–8 digits, identifying the issuing bank and card type). Different BINs have different fraud detection sensitivities, different issuer authorisation models, and different market value post-validation. Attackers optimise which BINs to test first based on expected market value.

Step 3: Script deployment. Automated scripts — typically headless browser automation, custom HTTP clients, or commercial carding tools available in underground markets — are configured to submit transaction attempts to the target merchant’s checkout. The attack is typically parameterised: transaction amount (small amounts trigger less friction), transaction frequency (calibrated to stay below obvious velocity thresholds), and source IP rotation (using proxy networks or residential proxy services to obscure attack origin).

Step 4: Testing. The script submits authorisation requests — either small purchase transactions or $0 card-not-present authorisations where the PSP supports them. The response code determines card status: 00 Approved = valid and active; 05 Do Not Honour = potentially blocked but might be risk-based; 54 Expired = expired; 41/43 Lost/Stolen = blocked. The approved cards are identified and recorded.

Step 5: Monetisation. Validated cards are either sold on carding markets at a premium, used directly for purchase fraud by the attacker, or rented to other fraud operators. The merchant may see follow-on fraud from the same cards tested — purchases made with confirmed-valid credentials — as a second wave of exposure.

Why Your Endpoint Is Targeted

Merchants are selected for card testing based on several characteristics:

Low friction checkout: Merchants without CAPTCHA, bot detection, or strict rate limiting are easy targets. Attackers map merchant endpoints for friction signatures — if a checkout accepts authorisation attempts at high velocity from a single IP without challenge, it is a viable testing endpoint.

Predictable authorisation response codes: Merchants whose PSP returns detailed decline codes (beyond a generic decline) help attackers understand why a card failed. A response that distinguishes 54 Expired from 51 Insufficient Funds from 05 Do Not Honour gives the attacker enriched data about the card.

Small minimum transaction amounts: Merchants that support $0.50 or $1.00 transactions (donation platforms, tip platforms, charity checkouts) are disproportionately targeted because the testing cost is low and the transaction amount attracts less fraud scrutiny from the issuer.

Low fraud detection investment: Merchants without active fraud screening, device fingerprinting, or velocity-based blocking are easier to run sustained attacks against.

The Cost Structure for Merchants

Card testing attacks create cost across multiple categories:

Authorisation fees: Every authorisation request — whether approved or declined — incurs a per-authorisation fee from the PSP. At $0.05 per authorisation and 100,000 test attempts in a day, the authorisation cost is $5,000. At $0.10 per auth (common in some pricing structures), $10,000 — for a single attack day.

VAMP ratio contamination: Under Visa’s VAMP programme, enumeration-flagged transactions count in the VAMP ratio. An attack generating 50,000 flagged transactions in a month where you process 500,000 total transactions adds 10 percentage points to the VAMP ratio — far above the 0.9% monitoring threshold. This is often the most serious consequence: a card testing attack can push an otherwise compliant merchant into VAMP monitoring without a single successful fraud transaction.

Follow-on fraud chargebacks: After validation, some attackers use the tested cards at the same merchant. The authorised fraudulent purchases generate chargebacks when cardholders dispute them. At $15–$30 per chargeback plus the lost transaction value, follow-on fraud from a large testing event adds thousands more in direct costs.

Acquirer risk review: Elevated declined-to-approved ratios and sudden spikes in attempted transactions trigger automated acquirer risk flags. The result is often an account review inquiry, required fraud reporting, and in severe cases, temporary holds on settlement. The operational disruption is disproportionate to the attack volume.

The Defence Stack

Card testing defence is layered — no single control is sufficient against a determined attacker with residential proxy infrastructure and calibrated velocity.

Layer 1: Rate Limiting

The most fundamental control. Limit the number of authorisation attempts:

• Per IP address per hour (5–10 failed attempts before requiring CAPTCHA or blocking)
• Per card number per day (2–3 attempts before hard blocking)
• Per session or device fingerprint (similar limits)

Calibrate rate limits against your legitimate traffic patterns. High-conversion checkout flows with frequent returns by the same customer require different thresholds than single-purchase e-commerce. Too aggressive and you create friction for legitimate customers; too loose and you remain a viable testing endpoint.

Layer 2: CAPTCHA and Bot Detection

CAPTCHA on payment forms adds friction for scripted attacks. The challenge is balancing fraud prevention against checkout abandonment — CAPTCHA on the payment step adds 3–8% abandonment in most data. The optimised approach: invisible CAPTCHA (using browser signals without a visible challenge) for low-risk sessions, visible challenge for high-risk signals.

Bot detection services (Cloudflare Bot Management, DataDome, PerimeterX, Google reCAPTCHA v3) can distinguish browser automation from human interaction at the session level. These operate on signals like mouse movement patterns, keystroke timing, browser attribute consistency, and TLS fingerprint. Commercial carding tools increasingly mimic human behaviour — newer models of bot detection correlate across multiple signals.

Layer 3: Payment-Level Velocity Controls

Within the payment stack, fraud tooling applies velocity rules at the card/BIN level:

• Flag authorisation attempts from cards in known-compromised BIN ranges
• Block IP addresses associated with proxy infrastructure (commercial proxy intelligence from services like IPQualityScore or IPinfo)
• Apply step-up authentication (3DS2) on sessions with high-risk velocity signals
• Hard-block card numbers that have been declined multiple times across the network (shared decline intelligence from fraud tools that operate across multiple merchants)

Stripe Radar, Kount, Sift, and Riskified all provide velocity-based controls with some degree of cross-merchant signal sharing — the latter is important because card testing infrastructure used against one merchant often appears at others.

Layer 4: Minimum Transaction Floors

For merchants whose product allows it, implementing a minimum transaction value above which authorisations are processed reduces the economic viability of low-value testing. A minimum $5 or $10 transaction floor significantly increases the cost of each test authorisation and reduces the attacker’s margin on testing. This is not applicable to all merchants (subscription billing, donations, pay-what-you-want models cannot implement floors) but for transaction-type agnostic checkouts, it is a simple deterrent.

Layer 5: Response Code Normalisation

Returning generic decline messages rather than specific decline codes removes one data point attackers use to enrich their card data. A generic “card declined — please try another payment method” response, regardless of the underlying decline code (54 Expired, 51 Insufficient Funds, 41 Lost), gives the attacker less information about why the card failed. PSP configuration or checkout-layer normalisation handles this.

Layer 6: Network-Level Enumeration Detection

For merchants with significant card testing history, adding a network-intelligence layer — services that correlate attack patterns across merchants and block known-bad IP ranges, device fingerprints, and BIN sequences proactively — provides coverage against attacks that appear below merchant-level velocity thresholds because they are spread across multiple merchants simultaneously.

Incident Response

When a card testing attack is detected mid-flight:

1. Quantify before blocking. Understand the attack volume, source characteristics, and targeted BINs before taking action. Blocking prematurely without understanding the attack may not stop it — attackers on proxy infrastructure will simply rotate.

2. Engage PSP fraud team. Most PSPs have an active fraud response team that can apply network-level blocking against known attack signatures faster than merchant-level controls alone.

3. Apply temporary velocity hardening. Tighten rate limits below normal thresholds, enable CAPTCHA globally, and apply stricter session-level controls for the duration of the attack.

4. Document for VAMP purposes. If the attack is generating VAMP ratio exposure, document the attack start date, volume, and remediation actions taken. Acquirers and Visa accept documented attack events as context in VAMP remediation discussions — demonstrating the ratio spike was externally caused and remediated, not ongoing operational failure.

5. Post-incident review of defence gaps. Every card testing event reveals a specific gap in the defence stack. Post-incident, identify what allowed the attack to generate the volume it did and address the specific control failure.

Card testing is an economics problem. The attacker’s cost is the automation setup and proxy infrastructure. The merchant’s defensive goal is to raise the per-card testing cost to the attacker above the market value of the validated card — making your endpoint unprofitable to test relative to alternatives.