Card Testing Attacks: How to Detect and Stop Card Enumeration

Visatk Team · October 16, 2026 · 9 min read · اقرأ بالعربية

Learn how to detect and stop card testing attacks: key signals, velocity rules, BIN patterns, CAPTCHA, 3-D Secure and monitoring to protect your checkout.

Card testing is one of the most common attacks against online checkouts, and one of the most expensive to ignore. Fraudsters who obtain lists of stolen or guessed card numbers need a way to find out which ones still work. Your payment form, donation page or free-trial signup can become their testing lab. The fraudulent orders themselves are often tiny, but the side effects are not: authorization fees on thousands of attempts, elevated decline ratios that worry your acquirer, possible network monitoring program exposure, and chargebacks when validated cards are later used elsewhere and traced back.

This guide explains how card testing (also called card enumeration or carding) works, the signals that reveal it, and a layered set of controls that stop it without punishing legitimate customers.

What Is a Card Testing Attack? #

A card testing attack is the automated or semi-automated submission of many card numbers to a merchant's payment flow to learn which cards are valid and can be authorized. Validated cards are then sold or used for larger fraud elsewhere.

There are two broad variants:

• List testing. The attacker already has card data, often from a breach or phishing kit, and wants to check which cards are still live before reselling or using them.
• Enumeration (BIN attacks). The attacker starts from a known BIN and generates candidate numbers that pass the Luhn check, then guesses expiry dates and security codes until authorizations succeed.

Enumeration is noisier and produces very high decline rates. List testing can look cleaner, with a higher approval rate, which makes it harder to spot with decline-based rules alone.

Why Merchants Are Targeted #

Attackers favor checkouts with these characteristics:

• Low-value or user-defined amounts, such as donations, tips or pay-what-you-want pricing.
• Guest checkout with no account, email verification or login.
• Card validation flows, such as zero- or low-value authorizations when a card is added to a wallet.
• Detailed error messages that reveal exactly which field failed.
• No rate limiting on the payment endpoint or on the payment API exposed to the browser.
• Payment APIs that can be called directly, bypassing the front-end.

You do not need to be large to be targeted. Small merchants with lightweight defenses are often chosen precisely because they are less likely to notice quickly.

The Costs of Card Testing #

Signals That Reveal Card Testing #

No single signal is conclusive. Card testing is detected by combining several weak signals into a strong one.

Volume and velocity signals #

• A sudden increase in payment attempts that is not matched by traffic to product pages or cart activity.
• Many attempts per minute from a single IP address, IP range, device fingerprint, session or account.
• Many distinct card numbers used by a single customer, email, device or shipping address.
• Attempts at unusual hours relative to your normal traffic pattern.

Decline pattern signals #

• A sharp rise in the overall decline rate, especially when concentrated on one endpoint.
• High volumes of responses indicating invalid card number, expired card, incorrect CVV or "do not honor".
• Many CVV mismatches and AVS failures in a short period. Our AVS and CVV response code reference explains each result.
• The same card number retried with different expiry dates or security codes.

BIN and card pattern signals #

• A cluster of attempts sharing the same 6- or 8-digit BIN.
• Card numbers that are sequential or near-sequential within a range.
• Card countries that do not match your typical customer base.
• An unusual concentration of prepaid or specific card products.

Running suspicious prefixes through a bulk BIN checker quickly shows whether a burst of traffic concentrates on one issuer, country or card type.

Order and behavior signals #

• Very small or identical amounts, often the minimum your form accepts.
• Identical or random-looking names, emails and addresses, or the same billing data reused with different cards.
• Missing or abnormal browser behavior: no mouse movement, instant form fills, headless browser markers.
• Direct API calls to your payment endpoint without the normal page sequence.
• IP addresses from hosting providers, proxies or anonymizers. Check suspicious addresses in bulk with the bulk IP lookup.

Building Velocity Rules #

Velocity rules limit how many times something can happen within a time window. They are the backbone of card testing defense. Start with conservative limits based on your own legitimate traffic, then tighten based on data.

Tips for effective velocity rules #

• Use multiple keys. Attackers rotate IPs, so also key on device fingerprint, account, email, card fingerprint (a hashed PAN), BIN and shipping address.
• Use sliding windows. Combine short windows (minutes) for bursts with long windows (hours or days) for slow, distributed attacks.
• Compare to baselines. Absolute thresholds break during peak sales periods. Relative thresholds based on rolling averages adapt better.
• Respond gradually. Escalate from invisible scoring to challenges to blocks, so a false positive costs a customer a few seconds rather than a sale.
• Never store raw PANs for velocity counting. Use your processor's card fingerprint or a keyed hash within your PCI scope.

Layered Controls to Stop Card Testing #

1. Bot management and CAPTCHA #

Most card testing is automated, so bot mitigation is the first barrier. Invisible or risk-based challenges are preferable to forcing every customer through a puzzle. Trigger a visible challenge only when risk signals fire, such as high velocity, a datacenter IP or repeated declines. Remember that CAPTCHA alone is not sufficient, because some attackers use human solving services or real browsers.

2. 3-D Secure (EMV 3DS) #

3-D Secure lets the issuer authenticate the cardholder, often frictionlessly using device and transaction data, and with a challenge when risk is higher. It makes testing harder and, for authenticated transactions in many regions, can shift fraud liability to the issuer. Consider requiring 3DS for risky segments: new customers, unusual BINs, mismatched countries, or sessions that already hit velocity limits.

3. Harden the payment endpoint #

• Require a valid session, cart and server-generated token before a payment request is accepted.
• Rate limit at the edge (CDN or WAF) and in the application.
• Do not expose secret API keys in front-end code, and restrict publishable keys to the domains you control.
• Block or challenge direct requests that skip the expected page flow.

4. Reduce the information you leak #

Return generic error messages to the shopper, such as "Your payment could not be processed", instead of revealing whether the card number, expiry or CVV was wrong. Detailed reasons should go to your logs and fraud tools, not to the browser.

5. Raise the cost of an attempt #

• Set sensible minimum amounts on donation and tip forms.
• Require email verification or account login before adding cards to a wallet.
• Limit how many cards can be added to an account in a time period.
• Avoid running unnecessary card verification authorizations on page load or on every keystroke.

6. Respect retry rules #

Card networks have rules limiting how often a declined transaction can be resubmitted, and certain decline responses indicate the transaction should never be retried. Configure your billing and retry logic to honor these responses. Excessive retries look like testing and can incur fees.

7. Use BIN intelligence carefully #

When an attack concentrates on a specific BIN, you can temporarily add friction for that range, for example by requiring 3DS. Use a BIN checker to confirm issuer, country and card type before writing rules. Avoid permanent blanket BIN blocks, which can lock out legitimate customers of that issuer long after the attack has ended.

8. Use your processor's tools #

Most gateways and processors provide fraud scoring, card testing detection, rule engines and dashboards. Enable them, review the defaults and integrate their signals into your own monitoring.

Monitoring and Alerting #

Attacks often start at night or on weekends when no one is watching. Real-time monitoring turns a costly incident into a brief one.

Metrics to track #

• Authorization attempts per minute, compared with the same time last week.
• Approval and decline rates, overall and by endpoint.
• Decline reasons, especially invalid number, expired card and CVV failures.
• Distinct cards per IP, device and account.
• Top BINs by attempts and by declines.
• Share of traffic from hosting providers, proxies and new countries.

Alert design #

• Page someone when the decline rate or attempt volume exceeds a multiple of baseline for a sustained window.
• Send lower-priority notifications for smaller anomalies so you can spot slow attacks.
• Prepare a "stricter mode" switch that enables mandatory challenges and 3DS within minutes.

Incident Response Playbook #

1. Confirm the attack. Check attempt volume, decline reasons and BIN clustering.
2. Contain. Enable stricter mode: challenges, tighter velocity limits, 3DS for risky traffic, edge rate limits.
3. Block the obvious. Temporarily block abusive IP ranges, devices and accounts. Review IP ownership before blocking large ranges so you do not cut off legitimate networks.
4. Stop the bleeding on approvals. Void or refund successful test authorizations before they settle where possible, which reduces later chargebacks.
5. Inform your acquirer. Proactive communication usually goes better than an acquirer discovering the spike on its own.
6. Investigate. Identify which endpoint was abused and how. Use the fraud investigation tool to analyze samples of suspicious transactions.
7. Fix root causes. Close exposed APIs, add missing rate limits and adjust rules.
8. Review afterward. Document timeline, losses and lessons, and add tests or alerts that would have caught it sooner.

Testing Your Defenses Safely #

Developers should validate defenses in a sandbox, never against live payment endpoints with real card numbers. Use your processor's test card numbers and simulated decline responses, and generate format-valid numbers for front-end validation tests with the test card number generator. Simulated load tests against staging can confirm that your rate limits and alerts trigger as designed.

Frequently Asked Questions #

#card testing#fraud prevention#BIN attack#velocity rules#checkout security