What a Card Testing Attack Is
A card testing attack is an automated fraud pattern in which an attacker submits many payment attempts to find out which stolen card numbers are still active. The attacker does not care about the goods or the order. The goal is a yes-or-no signal from the payment processor. A charge that authorizes proves the number is live. A decline proves it is dead. Once a batch of live numbers is sorted out, those numbers are used elsewhere for larger purchases.
Payment Test Cards: Luhn Check, 3DS Challenge, Sandbox CVV
Small amounts are typical because they are cheap to test and easy to hide. Attackers often try a few cents or a dollar, then repeat at scale across thousands of attempts in a short window. The damage is not only the tested charges. It is the interchange fees on every decline, the fraud risk rating that follows the merchant account, and the chargebacks that arrive weeks later.
Warning Signs to Watch
- A spike in authorization requests with a decline rate far above your normal baseline.
- Many attempts from the same IP range, device fingerprint, or email domain.
- Small or oddly rounded order totals placed in rapid succession.
- Multiple different card numbers billed to the same shipping address or account.
- Order volume concentrated in a few minutes rather than spread across a day.
How to Reduce the Risk
These steps assume you have access to your payment gateway dashboard, your fraud rule settings, and your web server or CDN configuration.
- Pull the last 30 days of authorization logs and establish your normal decline rate per hour.
- Set an alert that fires when the decline rate or attempt count passes that baseline.
- Enable velocity limits in the gateway so one card, email, or IP can only attempt a set number of charges per hour.
- Turn on CAPTCHA or a bot challenge on checkout and on any card-update form.
- Require the card verification value and the billing postal code to match on every transaction.
- Block or challenge traffic from hosting providers, known proxy ranges, and countries where you do not sell.
- Add a minimum order value or a small fixed fee that removes the economics of low-value testing.
- Route flagged attempts to manual review instead of auto-declining, so you keep the order data.
- Contact your acquirer and processor when an attack starts, and ask for their rule sets to be applied.
- Review the rules monthly and tighten any threshold that is producing false positives.
What to Do After an Attack
Log the affected card numbers and report them through your processor. Document the time window and the attempt volume, because issuers and acquirers will ask for it. If cardholder data touched your systems outside a compliant environment, follow your incident response plan and notify your acquirer. Finally, watch for chargebacks tied to the same window. They usually land 30 to 90 days later and are the part of the attack that costs the most.