Card Testing
What Is Card Testing? Definition and How It Works
Definition
Card testing is a fraud attack in which stolen card numbers are systematically tested with small-value transactions to validate which cards are active before using them for high-value fraud or selling verified card data.
How it works
In a card testing attack, fraudsters obtain a batch of stolen card numbers, typically from data breaches, dark web purchases, or skimming, and need to determine which numbers are still active and have available funds. They automate small-value authorisation requests or purchases against a merchant's checkout to validate cards at scale, often using bots and rotating IP addresses to evade detection.
Merchants are targeted specifically because they provide a mechanism to validate cards: a successful authorisation confirms the card is active; a specific decline code (such as "do not honor" vs. "invalid card number") reveals whether the card exists. Low-value transactions, sometimes as small as $0.00 or $1.00, are preferred because they minimise financial exposure while providing validation data.
Indicators in transaction data include: a high ratio of authorisation attempts to successful transactions in a short period, a concentration of small-value transactions from new cards, multiple cards sharing the same device fingerprint or IP address, and BIN ranges associated with known breach data appearing in high volume.
Once cards are validated through testing, the fraudster either uses them for high-value purchases or sells the verified data as a premium on fraud markets. The merchant who served as the testing ground suffers the authorisation costs, scheme monitoring consequences from elevated decline rates, and potential fraud chargebacks on the small test transactions.
Why it matters
Authorisation volume spikes are the primary operational signal: a card testing attack can generate thousands of authorisation attempts in minutes. Without real-time monitoring and automated blocking, the attack runs undetected until scheme monitoring flags the decline rate anomaly.
Scheme consequences are severe: elevated authorisation-to-decline ratios and unusual BIN patterns trigger card scheme fraud monitoring programs. Merchants who become repeat card testing targets face enhanced scrutiny and potential scheme fines.
Card testing costs money even when blocked: every authorisation attempt carries a processing cost. Card testing attacks that run for hours before detection generate significant processing fee exposure on declined transactions.
Detection requires velocity monitoring at the BIN level: card testing attacks often operate within a BIN range (issuer prefix). BIN-level velocity monitoring that flags when a specific BIN range produces an abnormally high decline rate can detect attacks that card-level velocity rules miss.
With PXP
PXP's risk engine applies real-time velocity monitoring at the card, BIN, IP, device, and email levels to detect card testing patterns. Automated blocking rules can be configured to fire when velocity thresholds are breached, and attack patterns are surfaced in the PXP risk dashboard for investigation.
Frequently asked questions
How do card testing attacks differ from normal payment declines?
Card testing produces a distinctive pattern: a high volume of authorisation attempts with an abnormally high decline rate, often concentrated in a short time window, from cards that have not transacted with the merchant before. Normal decline patterns are distributed across card types and reason codes. Card testing typically shows concentrated declines on specific BIN ranges with "do not honor" or "invalid card" codes.
What makes a merchant an attractive target for card testing?
Merchants with unprotected checkout flows, no CAPTCHA, no rate limiting, no velocity checks, that return consistent, informative decline codes are ideal for card testing. Low-value transaction categories (digital goods, micro-payments, charitable donations) are preferred because testing costs are minimal. Merchants who do not monitor authorisation-to-success ratios in real time are less likely to detect and block attacks quickly.
How quickly can a card testing attack cause damage?
Automated card testing attacks can submit thousands of authorisation requests within minutes. A merchant without real-time velocity monitoring may not detect the attack until scheme monitoring flags the anomaly, which could be hours or days later. By that point, the attacker has validated thousands of cards, and the merchant has incurred significant processing costs and may have entered a scheme monitoring program.
What controls are most effective against card testing?
The most effective combination is: velocity rules on authorisation attempts per card, BIN, and IP; CAPTCHA or behavioural bot detection on the checkout flow; real-time monitoring of authorisation-to-decline ratios with automated alerting; and BIN-level velocity monitoring to catch distributed attacks that stay under per-card thresholds. No single control is sufficient against sophisticated bot-driven attacks.
Revolutionize your business with PXP
Take complete control of your commerce and payments with one platform.
Get Started