Merchant card testing is a fraud attack in which someone runs a batch of small transactions through your checkout to find out which stolen card numbers are still live. The attacker does not want your product. Your payment page is being used as a validator, and every approved test becomes a card that can be sold or spent elsewhere.

Before you start

• Access to your payment gateway dashboard with permission to change fraud rules.
• A list of the decline reason codes your processor returns.
• A way to search orders by IP address, email, and card fingerprint.

Signals that an attack is running

Card testing rarely looks like normal shopping. It looks like a lot of activity that produces very little revenue.

• A sudden rise in declined authorizations, often with the same decline reason.
• Many different card numbers hitting the checkout from one IP address or device.
• A burst of orders priced at the cheapest item you sell.
• Billing addresses that do not match the card, the shipping address, or the customer email.
• High CVV mismatch rates across a short window.
• Traffic spikes at hours when your real customers are asleep.

How to shut a card testing run down

1. Enable velocity limits on your gateway. Cap attempts per IP, per device, per card, and per email address within a rolling hour.
2. Turn on AVS and CVV checks and set the rules to decline on mismatch instead of flagging for review. Review queues are too slow to stop a scripted attack.
3. Add bot detection or a challenge to the checkout page. Card testing depends on automation, so any friction that requires a real browser hurts the attack.
4. Block disposable email domains and require email verification before an order is accepted.
5. Set a minimum order value for anything that delivers instantly, such as gift cards, codes, and downloads.
6. Send risky orders through 3D Secure. The liability shift matters more than the lost conversion.
7. Watch your decline rate as a metric. A jump from 5 percent to 40 percent in an hour is an alarm, not a coincidence.

What to do after a run

1. Export the transaction log for the attack window, including IPs, device fingerprints, emails, and card BINs.
2. Block the IPs, devices, and email patterns you find, then re-check that your velocity rules would have caught them.
3. Void or refund every authorization tied to the attack. Unsettled holds still cost you fees.
4. Contact your acquirer and processor with the log. They can add the BINs and IPs to network-level blocklists.
5. File a report with the relevant authority if losses are material.

Why the cost is bigger than the transactions

Most test charges are a dollar or less, so the direct loss looks trivial. The real damage sits elsewhere. Each declined authorization carries a fee. Chargebacks from the cards that were later used drive up your chargeback ratio. A high ratio can land your account in a card brand monitoring program, and repeated failures can end your ability to accept cards at all.

Controls that hold up over time

Attackers rotate infrastructure, so single-point blocks expire fast. Layer the defenses: authorization checks at the gateway, bot detection at the edge, order limits in your platform, and manual review on the leftover edge cases. Review your rules after every attack and after every major change to your checkout, because a new form field or a new payment method can quietly reopen the door.