What a card testing device is
A card testing device is any automated tool that submits many card numbers to a live payment form to learn which ones still authorize. The device is usually a bot, a headless browser, or a scripted checkout client pointed at a merchant's payment endpoint. The merchant sees a burst of small-dollar authorization attempts, a spike in declines, and a wave of chargebacks weeks later.
This guide is written for the side that absorbs the loss: store owners, payment engineers, and fraud analysts who need to spot the pattern and cut it off. Running a card testing device against payment systems that you do not own is access device fraud and identity theft under U.S. law, and it carries federal criminal penalties.
Prerequisites
- Read access to your gateway authorization log, including response codes, timestamps, IP addresses, and card BIN.
- Permission to edit fraud rules, velocity limits, or blocklists in your payment gateway or fraud vendor console.
- CVV and AVS verification switched on for your checkout.
- A contact at your acquiring bank's fraud desk for attacks that are still running.
How to detect a card testing attack
- Export the last 24 hours of authorization attempts with amount, response code, IP address, device fingerprint, and BIN.
- Sort by response code and count the share of do-not-honor and invalid-card responses. Testers generate far more failures than real shoppers.
- Group the attempts by IP address and device fingerprint. A small pool of addresses hitting many distinct cards is the clearest signature.
- Group by BIN range. Dozens of attempts inside one BIN within a few minutes points to a generated list.
- Check ticket size. Testing runs cluster at small amounts, often under one dollar or at one repeated round figure.
- Compare your CVV and AVS mismatch rate for the day against your normal baseline.
- Cross-check order data. Many card numbers, few completed orders, and billing addresses that do not match the shipping address confirm the pattern.
- Pull your decline-rate chart for the week. A vertical spike that lasts minutes to hours is typical.
How to block a card testing device
- Set velocity limits per IP address, per BIN, per email, and per device fingerprint, then tune the thresholds to your real traffic.
- Require CVV and AVS on every transaction and auto-decline mismatches.
- Add a challenge at checkout, such as a CAPTCHA or a proof-of-work step, and trigger it when the risk score rises.
- Block datacenter IP ranges and known proxy and Tor exit lists at your edge or WAF.
- Enforce 3-D Secure for first-seen devices and for BINs that your logs flag as high risk.
- Rate-limit the payment endpoint on its own, separately from the rest of the site, so browsing traffic stays fast.
- Alert your on-call channel when the decline rate crosses a threshold you set in advance.
- Review the rules every week and retire limits that block legitimate repeat customers.
Metrics to track after an attack
- Authorization attempts per hour, split by response code.
- Distinct cards per IP address per hour.
- CVV and AVS mismatch rate against the 30-day baseline.
- Chargeback count and reason codes for the following 60 days, since testing losses surface late.
- False-positive rate on your new velocity rules.
Why the pattern matters
A single blocked test costs a merchant a few cents in gateway fees. An unblocked run costs far more: interchange on declined attempts, chargeback fees, and the risk of landing in a monitoring program that raises processing costs across the whole account. Detection is cheap because the traffic is loud. The work is in the thresholds, not in the tools.