Card testing mitigation in one answer
Card testing mitigation means breaking the feedback loop an attacker needs to confirm which stolen card numbers are live. Attackers submit many small authorizations in a short window and watch the responses. If your gateway returns a clear approve or decline for each attempt, they learn which numbers work. Mitigation combines three things: deny the attacker a clean signal, limit how many attempts reach your authorization endpoint, and detect the attempt while it is happening instead of after the chargebacks arrive.
Prerequisites
- Access to your payment gateway rules, fraud tools, and authorization logs
- Permission to change checkout flow and rate limits
- A contact at your acquirer or payment processor for escalation
- A named owner who reviews decline and chargeback reports
Steps to mitigate card testing
- Turn on address verification and card verification value checks for every authorization request, then set the gateway to reject on a failed check rather than flagging it for later review.
- Set velocity rules that count attempts per card number, per IP address, per email address, and per device fingerprint within a rolling one-hour window.
- Add a challenge step such as a CAPTCHA or a 3D Secure prompt once a visitor crosses a failed-attempt threshold, which removes the automated advantage.
- Apply a minimum order value and block checkout for zero-dollar and one-dollar baskets that arrive from the same network block.
- Rate limit the payment endpoint itself so a single source cannot push hundreds of authorization calls per minute.
- Screen email addresses for disposable domains and screen IP addresses against known hosting and proxy ranges at the point of sale.
- Review authorization logs each morning for bursts of declines, and keep the review short by filtering on decline reason codes.
- Escalate to your acquirer the same day you confirm an attack, and provide timestamps, IP ranges, and BIN ranges.
Detection signals to watch
Card testing has a recognizable shape. Look for a sharp rise in authorization attempts paired with a low approval rate, many distinct card numbers from one IP address, orders with mismatched billing data, and a burst of small-value transactions in minutes. A spike in decline codes for stolen or lost cards is another marker. Monitoring these signals gives you hours of warning before fees and chargebacks land.
Hardening after an attack
Do not store card verification values at any point, since payment card industry rules prohibit retaining sensitive authentication data after authorization. Rotate any API keys that may have been exposed, tighten the velocity thresholds that failed, and document the timeline. Repeat attacks are common because the same operators resell working BIN ranges and reuse the same infrastructure. Report the incident to the relevant authorities so the pattern is recorded, and keep the case file ready for acquirer review.