Card testing is one of the most prevalent and automated forms of payment fraud targeting online merchants today. Unlike opportunistic fraud that requires human effort, card testing is almost entirely bot-driven—making it fast, scalable, and difficult to catch without purpose-built defenses. Understanding how it works is essential for any business accepting card-not-present payments.
How Card Testing Works
Card testing follows a predictable attack chain, from data acquisition through monetization. Fraudsters automate each step with bots capable of executing thousands of attempts per hour, making manual detection nearly impossible without the right tooling.
Data Acquisition
Attackers obtain bulk card data from dark web markets, phishing campaigns, or data breaches. A single breach can yield millions of raw card numbers, but only a fraction remain active at any given moment.
Target Selection
The fraudster identifies a merchant with a checkout that lacks friction—no CAPTCHA, no velocity limits, no fraud detection scoring. Donation pages, free trial signups, and unprotected APIs are common targets.
Micro-Transaction Probing
Bots submit small-value charges—often $0.01 to $1.00—using real card data. Each attempt triggers an authorization request to the card network, which returns an approval or decline code. This reveals whether the card is live.
Card List Refinement
Approved cards are flagged as valid and separated from declined ones. The result is a curated list of confirmed, active cards ready for high-value exploitation or resale.
Monetization
Validated cards are either used directly for large purchases, sold in batches on fraud marketplaces, or distributed across money mule networks. The merchant is left with processing fees, potential chargebacks, and a compromised authorization rate metric.
Why Card Testing Matters
The financial and operational impact of card testing extends far beyond the individual fraudulent transactions. Merchants often don't realize they're under attack until they review end-of-day reports—by which point thousands of authorization attempts may have already been processed.
Card testing fraud is estimated to cost merchants billions annually. According to industry research, card-not-present fraud—of which card testing is a primary driver—accounted for over 75% of all card fraud losses in markets with mature chip card adoption. The Merchant Risk Council has found that authorization rates can drop by 5–15 percentage points during active card testing attacks, triggering false signals that prompt payment processors to flag the merchant's account for review.
Even failed transactions are not free. Card networks charge authorization fees on every attempt—approved or declined. A bot submitting 50,000 test transactions at $0.01 each can cost a merchant hundreds of dollars in pure processing fees before a single fraudulent purchase is made. Additionally, high decline rates can damage a merchant's standing with acquirers, sometimes resulting in increased processing fees or account termination.
Industry Benchmark
Merchants with authorization decline rates above 15% within a short window are frequently flagged by acquirers for review. A card testing attack can push a healthy merchant past this threshold within minutes.
Card Testing vs. BIN Attack
Card testing and BIN attacks are related but distinct fraud techniques. Both exploit the authorization system, but their mechanics and scope differ significantly.
| Dimension | Card Testing | BIN Attack |
|---|---|---|
| Data source | Pre-stolen card numbers | Algorithmically generated card numbers using a known bank identification number |
| Volume | Hundreds to thousands per attack | Tens of thousands to millions per attack |
| Goal | Validate known stolen cards | Discover valid card combinations |
| Detection difficulty | Moderate | Higher—generates extreme velocity spikes |
| Primary targets | Any unprotected checkout | Merchants accepting small or zero-value transactions |
| Typical transaction size | $0.01–$1.00 | $0.00–$1.00 |
| Bot sophistication | Moderate | High—requires combinatorial generation logic |
Both attack types share a defense: velocity controls and transaction pattern monitoring catch the abnormal request density that neither humans nor low-volume legitimate traffic would produce.
Types of Card Testing
Card testing is not monolithic. Fraudsters adapt their approach based on merchant defenses and the quality of the card data they possess.
High-velocity bulk testing is the most common variant. Bots submit hundreds of micro-transactions per minute, attempting to clear through as many cards as possible before rate limits or fraud rules activate. These attacks are noisy and fast, often burning through an attack window in under an hour.
Low-and-slow testing is a more sophisticated approach where fraudsters space out attempts over hours or days, staying beneath velocity thresholds. This is harder to detect in real time and is often used against merchants with known rate limit configurations.
Distributed testing routes attempts through residential proxy networks, spreading the attack across thousands of IP addresses to evade IP-based blocking. Each IP may submit only one or two transactions, making geolocation and IP reputation filters less effective.
API endpoint targeting bypasses the front-end checkout entirely. Fraudsters call payment tokenization or authorization APIs directly, often using leaked API credentials or exploiting unauthenticated endpoints on mobile app backends.
Best Practices
Effective defense against card testing requires controls at multiple layers—no single mitigation is sufficient alone.
For Merchants
Add CAPTCHA or invisible bot detection (such as reCAPTCHA v3 or hCaptcha) to your checkout flow before a payment attempt is submitted. This introduces enough friction to deter automated scripts without impacting legitimate customers.
Set velocity rules that flag or block accounts submitting more than a defined number of failed payment attempts within a time window—typically 3–5 failures within 15 minutes is a reasonable starting threshold. Review and tighten these limits based on your normal traffic patterns.
Monitor your authorization rate in near real time. A sudden drop of more than 5% from your baseline within a short window should trigger an immediate investigation. Most payment dashboards expose this metric; set automated alerts if your platform supports them.
Require authentication for any guest checkout transaction above a minimum value. For markets where 3D Secure is available, apply it selectively to transactions that match risk signals rather than universally, to avoid unnecessary friction for legitimate buyers.
For Developers
Never expose raw authorization endpoints without rate limiting. Apply both IP-level and session-level throttling at the API gateway layer, not just at the application layer.
Use device fingerprinting libraries to associate transactions with browser and device characteristics. Multiple transactions sharing a device fingerprint but different card numbers are a strong card testing signal—flag these for review rather than processing silently.
Log every authorization attempt—approved and declined—with full metadata: IP address, user agent, session ID, card BIN, and timestamp. This data is essential for forensic analysis after an attack and for tuning fraud rules prospectively.
Implement webhook or real-time alert pipelines that fire when decline rate thresholds are breached. Delayed detection is the primary reason card testing attacks cause sustained damage; automated alerting compresses response time from hours to minutes.
Common Mistakes
Relying on IP blocking alone. Fraudsters route attacks through residential proxies and VPNs, rotating IPs continuously. IP-based blocking catches only the least sophisticated attackers and creates false positives that block legitimate customers sharing IP ranges.
Setting velocity limits too high. Many merchants configure velocity thresholds based on worst-case legitimate traffic without accounting for abuse scenarios. A threshold of 20 failed attempts per hour per IP is trivially bypassed by distributed attacks. Start conservative and adjust upward only with evidence.
Ignoring $0 authorization failures. Some fraud prevention setups filter out zero-value or very low-value declines as "noise." These are often the clearest signal of card testing activity and should be surfaced in monitoring dashboards, not suppressed.
Not distinguishing between authorization and settlement decline reasons. Not all declines are fraud signals—insufficient funds, expired cards, and wrong CVV all produce declines. Analyzing decline reason codes helps separate card testing (which produces specific decline patterns like "do not honor" or "card not found") from ordinary payment failures.
Treating card testing as a one-time event. Once fraudsters identify a vulnerable merchant, they often return after defenses are relaxed or reconfigured. Post-attack, permanently raise your baseline controls rather than reverting to pre-attack configuration.
Card Testing and Tagada
Card testing attacks are directly relevant to merchants using Tagada as their payment orchestration layer. Because Tagada sits between merchants and multiple payment processors, it has visibility into authorization patterns across all connected processors simultaneously—a significant advantage for detecting distributed card testing that spans multiple payment methods or routing paths.
Tagada and Card Testing Defense
Tagada's orchestration layer enables cross-processor velocity checks, meaning a fraudster who splits card testing attempts across different payment processors to stay beneath per-processor thresholds can still be caught by aggregate pattern detection. Merchants can configure global velocity rules in Tagada that apply regardless of which downstream processor handles the transaction.
Tagada also provides unified decline reason code normalization across processors—a critical capability because different processors return different codes for the same underlying condition. Normalized decline data makes it significantly easier to identify card testing signatures in real time and trigger automated rules without building custom parsers for each processor's response format.