Card testing prevention and mitigation is the practice of blocking the small automated authorization attempts attackers use to check whether stolen card numbers are still valid, then containing the damage when some attempts succeed. Prevention relies on detection rules, rate limits and authentication at the point of authorization. Mitigation is the response plan you run when an attack is already hitting your checkout, and it decides how much you lose in fees, chargebacks and processor scrutiny.
Best Practices for Card Testing Mitigation Comparison Review
How card testing attacks work
An attacker holds a list of card numbers and needs to know which ones are live. Running a full-price transaction on every number would be expensive and obvious, so they start with the smallest possible amount your gateway accepts. A typical pattern looks like a burst of low-value authorizations from many card numbers, often aimed at a single endpoint such as a guest checkout, a donation form, a subscription trial or a stored-card update page.
Each response tells the attacker something. An approval confirms the card works. A decline with a specific reason code narrows down why. Because of this, the attack is usually measured not in stolen goods but in authorization volume, and the merchant pays through interchange fees, fraud screening charges and eventual chargebacks.
Signals that appear in your transaction data
Velocity and pattern signals
- A sudden spike in authorization attempts against one endpoint or one payment form.
- Many different card numbers sharing one IP address, device fingerprint or email domain.
- Repeated attempts in a tight time window, often seconds apart.
- Amounts clustered at your minimum, or a sequence of identical odd amounts.
- Sequential or recognizable card number ranges, sometimes called a BIN attack.
Identity and geography signals
- Billing address, IP country and issuing bank country that do not match.
- Email addresses built from random strings, or disposable domains.
- Failed address verification or card verification value checks on otherwise approved authorizations.
- New accounts created in bulk shortly before the transaction burst.
Prevention controls that stop most attacks
Layer these controls so no single failure opens the door. Rate limiting by IP, device and card fingerprint is the first line, because it caps how many guesses an attacker can make per minute. A challenge such as a CAPTCHA or bot-detection script on the payment form raises the cost of automation. Requiring the card verification value and enforcing address verification rules blocks lists that carry only a card number.
Strong customer authentication, available through 3-D Secure in many markets, shifts liability and adds a step that automated scripts struggle to complete. Velocity rules should cover more than transaction count: track distinct card numbers per device, distinct devices per card, and failed authorization ratios per session. Blocklists tied to confirmed attack infrastructure, along with allowlists for your known good customers, reduce false declines.
Mitigation playbook for an active attack
- Confirm the pattern by pulling authorization logs for the last few hours and grouping by endpoint, IP and card fingerprint.
- Tighten thresholds immediately rather than waiting for a code change, so the next burst is throttled.
- Disable or harden the specific endpoint being targeted, including any API or stored-card path.
- Void or refund captured test charges where your processor allows it, and document each one.
- Notify your acquirer or payment service provider with the evidence you collected.
- Prepare for chargebacks on any test charge that settles, and submit representment only where the evidence supports it.
- Review the exposure afterward and adjust rules before the attacker returns with a new pattern.
Metrics that show whether your controls work
Track authorization attempt volume per endpoint, the ratio of declines to approvals, the share of approvals with failed verification checks, and the number of distinct card numbers per device. Watch chargeback ratios by reason code, since fraud-related codes reveal whether test charges are settling. A healthy program shows stable attempt volume and a low approval rate on unverified traffic.
Balancing friction with conversion
Every control you add can cost legitimate sales. Apply the strictest rules to new customers, high-risk geographies and unusual order values, and keep your returning customers on a lighter path. Test changes on a small share of traffic first, measure approval and conversion together, and expand only when both hold steady. Review rules quarterly, because attack patterns shift and a rule that caught last year's bot traffic may now block real buyers.