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

Card testing — also called BIN attacks or card cracking — is one of the most operationally disruptive fraud patterns for online merchants. Unlike purchase fraud, which generates immediate financial loss, card testing's damage is often indirect: spiking authorization costs, elevating TC40 fraud reports that damage your Visa VAMP ratio, and consuming customer service capacity when legitimate cardholders notice small unauthorized charges on their statements.

Understanding how these attacks work mechanically is the starting point for building effective defenses.

How Card Testing Works

Fraudsters obtain lists of card numbers from data breaches, dark web purchases, or BIN number generation. These lists contain card numbers but not the full card data — expiry dates, CVVs, and billing addresses may be missing or guessed. Before using these cards for higher-value fraud, they test which ones are currently active and connected to funded accounts.

The test is simple: attempt small transactions on merchant sites. A $0.01, $1, or small-denomination transaction against a real merchant checkout reveals whether the card is active (authorization approved), expired (authorization declined with a specific code), or flagged (declined for security reasons).

The automation side is sophisticated. Attackers use bots that cycle through card numbers at high speed, submitting hundreds or thousands of authorization attempts per hour against a single merchant. They distribute the attack across IP addresses, rotate device fingerprints, and vary transaction parameters to evade basic velocity rules.

The aftermath for the merchant:

• Authorization fees on every attempt, including declines (typically $0.05–$0.25 per attempt)
• TC40 fraud reports filed by issuers when legitimate cardholders notice the small unauthorized charge — these count against your Visa VAMP ratio without generating formal chargebacks
• Acquirer scrutiny if authorization decline rates spike
• In some cases, card network flags that increase processing costs

A significant attack — 10,000 attempts in a weekend — can cost $500–$2,500 in direct authorization fees and generate enough TC40 reports to move your VAMP ratio meaningfully.

The Signals That Identify Card Testing

Card testing attacks have characteristic patterns:

Velocity on card fields. Many distinct card numbers attempted in a short time window, particularly if they're cycling through sequential BIN ranges.

High decline rates. Normal merchant decline rates are 5–15%. During a card testing attack, decline rates on new sessions may reach 60–90%.

Unusual session patterns. Legitimate checkout sessions have variable timing — users browse, read, pause. Bot sessions have consistent, rapid timing: page load, field fill, submit, in under 5 seconds, repeated identically hundreds of times.

Single BIN concentration. Attacks using generated card numbers from a specific BIN range produce authorization attempts concentrated on cards from the same issuing bank.

Small transaction amounts. $0.00–$2.00 transactions from new customer accounts are statistically anomalous for most merchant categories.

Headless browser signatures. Many attack scripts run in headless browsers (no UI) that have detectable signatures in the User-Agent string, missing browser APIs, or inconsistent JavaScript execution.

The Defenses That Actually Work

CAPTCHA on payment forms. Google reCAPTCHA v3 (invisible, risk-score based) or hCaptcha add friction for automated submissions without creating visible friction for legitimate users. CAPTCHA alone reduces card testing volume by 60–80% because it requires solving challenges that defeat most bot frameworks cheaply.

Rate limiting on authorization attempts. Limit authorization attempts per IP address to 3–5 per hour. Limit attempts per device fingerprint. Limit attempts per email address. These rules stop distributed attacks at the IP or device level and funnel high-volume attacks into detectable velocity patterns.

BIN velocity rules. If multiple distinct card numbers from the same BIN are attempted within a time window, flag and challenge further attempts from that session. BIN concentration is one of the clearest card testing signatures.

Require CVV. Card lists obtained from breaches often lack CVVs. Mandating CVV entry significantly reduces the usable pool of cards attackers can test, since cards where the CVV was stolen are fewer than raw card numbers.

Block authorization without intention to charge. Some merchants run $0 authorization checks unnecessarily. Eliminating these removes the easiest testing vector.

Device fingerprinting on checkout. Persistent device fingerprinting identifies devices that have previously been associated with fraud or declined transactions. A device that has attempted 20 card numbers is identifiable across IP address rotation.

3DS on suspicious sessions. Routing checkout sessions that match bot signatures to 3DS authentication challenges stops attacks that can complete authentication — the vast majority can't.

Bot management tools. Cloudflare Bot Management, Akamai Bot Manager, and similar WAF-level tools identify and block bot traffic before it reaches your checkout. For merchants experiencing frequent attacks, infrastructure-level bot detection is more cost-effective than checkout-level defenses alone.

The VAMP Ratio Consequence

This is the dimension most merchants don't account for. When a legitimate cardholder notices a $1 charge they don't recognize, many don't file a formal chargeback — they call their bank and ask about it, which generates a TC40 fraud report. TC40 reports count toward your Visa VAMP ratio even without a formal dispute.

A card testing attack that tests 5,000 cards, 500 of which belong to active cardholders who notice the charge, can generate hundreds of TC40 reports over the following weeks. If your total Visa transaction volume is 50,000 per month, that's a 1% TC40 rate from one attack — enough to push you into VAMP monitoring.

This makes card testing prevention a chargeback ratio issue, not just a fraud cost issue. Every measure that reduces card testing attempts also protects your VAMP compliance position.

Response When You're Under Attack

When you identify an active card testing attack:

1. Enable aggressive rate limiting immediately — 1 authorization attempt per IP per 15 minutes
2. Enable CAPTCHA if not already running
3. Alert your acquirer — they can sometimes provide additional signals or temporary protective measures
4. Preserve logs of all authorization attempts for the attack window — the patterns are useful for building permanent rules
5. Monitor TC40 reports over the following 30–60 days to assess the ratio impact

Card testing is a persistent background threat for online merchants. The defenses above should be baseline configuration, not emergency responses.