Card testing is an attack where someone runs many small authorization attempts against a payment form to learn which stolen card numbers still work. Defense rests on three controls: make each attempt cost the attacker something, make every attempt visible in your logs, and cut off the pattern before it scales. The steps below apply to any gateway that exposes transaction logs and rule-based fraud filters.
Card Testing Defense Protocols Buying Guide
Prerequisites
- Access to gateway transaction logs with IP address, card BIN, response code, and timestamp
- Permission to edit fraud rules, or a contact who can apply them during an active attack
- A baseline for your normal authorization rate, average ticket, and daily order volume
Set up detection first
- Export the last 30 days of declined authorizations and group them by IP address, email domain, and card BIN.
- Flag any IP address that produced more than five declines in one hour, or more than twenty in a day.
- Flag any single email address, phone number, or card fingerprint that appears on more than three distinct accounts.
- Chart your authorization rate per hour and compare it to the 30-day baseline, since a sudden drop of several points is the earliest reliable signal.
- Set automated alerts on three thresholds: decline rate, order count per IP, and count of low-value orders under one dollar.
Harden the payment form
The goal is to make automation expensive without slowing real customers. Layer the controls so a single bypass does not open the whole form.
- Require the security code and enforce a mismatch rule that blocks the attempt, not just the order.
- Turn on address verification and reject a full mismatch on card-not-present orders.
- Add a challenge step, such as a CAPTCHA or a device check, to guest checkout and to any session that has already failed once.
- Set a minimum order value on high-risk product categories so test charges of a few cents are refused outright.
- Rate limit the payment endpoint itself, not just the page that hosts it, and return a generic error on the limit.
- Block disposable email domains and require a verified email before the first charge.
Apply gateway rules
- Block or challenge traffic from hosting providers and known proxy ranges, since most test traffic comes from servers rather than residential connections.
- Set velocity caps per BIN and per card fingerprint, for example five attempts across all accounts in 24 hours.
- Require 3-D Secure on orders from new accounts where the issuer supports it.
- Route orders scored as high risk to manual review instead of auto-approving them.
Respond during a live attack
- Raise the challenge level on every new session and keep it raised for at least one hour.
- Block the IP ranges and BINs identified in the first ten minutes of analysis.
- Disable guest checkout or the affected product until the attempt volume drops.
- Notify your acquirer or gateway risk team with the transaction IDs, and ask about the fee exposure from declined authorizations.
- Log every block decision with a reason code so you can measure false positives later.
Review after the attack
Compare the blocked traffic against orders you approved in the same window. If legitimate customers were caught, loosen the specific rule that fired rather than removing the whole layer. Keep the decline-rate alert active, since testers often return with a different BIN range within a few weeks. Review chargebacks tied to the attack window and dispute any that came from test transactions.