Card Testing Defense Strategies: Stop BIN Attacks

Short answer

Card testing is an attack on a payment endpoint. A script submits many card numbers, often thousands per hour, and reads each authorization response to learn which numbers are live. Defense needs four layers: rate limits, payment checks, bot detection, and a response plan that runs in minutes.

No single control stops it. Rate limits cut volume. Payment checks raise the cost per guess. Bot signals catch the script before it reaches the processor. Monitoring catches what the first three miss.

How the attack shows up in your data

• Authorization attempts per minute jump, often 10x to 100x baseline.
• Decline rate climbs. Attackers use dead numbers, so 60% to 90% declines is common.
• Ticket sizes sit at $0 to $1, or match a fixed test amount.
• Many card numbers share one email domain, one IP range, or one device type.
• BIN spread is wide. Numbers come from issuers the merchant has never seen.
• Cardholder names are random strings or repeat a single value.
• Traffic hits the same endpoint path, often a checkout API or a subscription update form.

Controls that stop it

Rate limits and velocity rules

Set limits per IP, per card fingerprint, per email, and per device. A practical starting point: 5 authorization attempts per card per hour, 20 per IP per hour, and 3 failed attempts per customer session. Block the identifier for 24 hours after it trips. Apply limits at the edge, not only in application code, so the request never reaches the processor.

Payment-level checks

Require CVV and AVS on every authorization. Reject a mismatch instead of accepting the charge. Enable 3-D Secure on high-risk traffic. Use the issuer response codes: a high share of do not honor and invalid card number replies from one source points to enumeration. Set a floor ticket size and flag orders below $1.

Bot and device signals

Add a challenge on the payment form when risk scores rise. CAPTCHA, proof-of-work, or a JavaScript check raises the cost per attempt. Collect device fingerprint, TLS fingerprint, and header order. Scripts reuse the same fingerprint across hundreds of cards. Reject requests with no browser history on a session that submits a card.

Blocklists and BIN rules

Keep a list of IPs, ASNs, and proxies tied to prior attacks. Block disposable email domains. For high-risk BINs, require 3-D Secure or decline. Refresh the list weekly. Attackers rotate hosts, so pair static lists with velocity rules.

Response playbook

1. Alert on decline rate above 35% for 5 minutes, or attempts above 3x baseline.
2. Throttle the source: IP, ASN, or device range. Keep the rule for 24 hours.
3. Add a challenge to the payment form for all traffic until the spike ends.
4. Notify the acquirer and the processor with timestamps and volume counts.
5. Refund any valid charges the attacker pushed through, then close the accounts.
6. Write the incident to a log with the rule that fired and the volume blocked.

Metrics to track

• Authorization attempts per minute, with baseline and alert threshold.
• Decline rate by BIN, IP, and device.
• Share of traffic that passes a challenge.
• Chargeback count from test-sized orders.
• Time from first alert to rule deployed.

Small merchants can run the first two layers with processor rules alone. Merchants above roughly 10,000 orders per month need the bot layer and a named owner for the alert queue.