Merchant Card Testing: Detection and Prevention

Merchant Card Testing: What It Is and How to Stop It

Merchant card testing is a fraud pattern. Someone runs a large number of payment attempts to find out which card numbers still work. The tests are small. A test charge is often $0.01 to $1.00. The merchant sees many attempts in a short window, from many cards, from a small set of IP addresses. This article covers detection and prevention, not how to run tests.

What the pattern looks like

• Hundreds of authorization attempts in minutes.
• Low average order value.
• High decline rate, often above 50%.
• Many cards, few devices or IP addresses.
• Cards pulled from one bank identification number (BIN) range.
• Email addresses with random strings.
• Orders that skip the normal browsing path.

Why digital goods and donation pages are targets

Digital goods, gift cards, donations, and free trials with a card on file are common targets. There is no shipping address to verify and no physical delivery to stop. The attacker gets value before the chargeback arrives.

Cost to the merchant

Costs stack. Each approved test becomes a chargeback, a refund, and a fee. Authorization fees apply to every attempt, including declined ones. Acquirers and card networks track chargeback ratios. Visa and Mastercard run monitoring programs with published thresholds. A merchant that crosses the threshold pays fines and may be moved into a high-risk category.

Controls that work

No single control stops card testing. Use layers.

1. Require CVV and postal code on every transaction. Decline on a failed check.
2. Set velocity limits. Count attempts per card, per IP, per email, per device. Block on counts, not on single events.
3. Set a minimum order amount, or flag test-sized amounts for review.
4. Turn on 3-D Secure for card-not-present orders. It shifts liability on approved transactions and adds a step the attacker has to pass.
5. Run a bot check on the checkout page and on any card-update form.
6. Use a fraud tool with a card testing model. Stripe Radar and Adyen RevenueProtect ship rules for this pattern.
7. Block the BIN ranges, IP addresses, and email domains seen in an active attack. Treat blocks as short term, because attackers rotate them.
8. Decline when device, IP address, and billing country do not match.

What to do during an attack

Tighten decline rules first, then investigate. Export the attempt log. Group by IP address, BIN range, email domain, and user agent. Send the list to your acquirer and ask about a temporary rule set. Refund any approved test charges before the cardholder files a dispute. Acting first cuts fees.

What not to do

Do not store card data you do not need. Storage widens the breach surface and adds PCI DSS scope. Do not treat one declined test as noise. One decline is noise. Fifty declines in an hour is an attack.

Monitoring program numbers change. Check the current Visa and Mastercard program documents before you set internal limits.