Card Testing Attacks: Why High-Risk Merchants Pay for Them Twice

A high-risk merchant account comes with tighter rules than a standard one: higher fees, closer monitoring and, often, a reserve. Within those rules, one type of fraud does more damage than its size suggests. Card testing costs very little on the day it happens. The bill tends to arrive a month later, in the form of disputes that push a merchant’s ratio toward the line its processor watches.

Understanding how that delay works is the first step to stopping it.

What card testing is

Card testing is a way for fraudsters to check whether stolen card details still work before they use them. Stripe’s guide to protecting against card testing describes it as someone trying to confirm that stolen card information is valid so they can make purchases with it, and notes that it also goes by names such as “carding,” “account testing” and “enumeration.”

Testers usually run small payments or card setups, because cardholders are less likely to notice a tiny charge on their statement. They often use automated scripts that cycle through hundreds or thousands of card numbers on a single checkout page.

High-risk merchants make attractive targets, because many sell digital goods, subscriptions or services that deliver instantly, which gives testers fast feedback on whether a card works.

How a quiet hour turns into a dispute problem

The real cost of card testing shows up later, and a simple scenario makes the timing clear.

Picture a high-risk merchant that sees 400 one-dollar authorizations in an hour, most of them declined: the cards that do clear tend to come back as fraud disputes weeks later, and a prevention platform such as the one at chargebackstop.com, a London-based chargeback prevention service, uses Ethoca and Verifi alerts to flag disputes on those transactions before they are filed.

The scenario is illustrative, but the pattern behind it is well documented. Stripe notes that some card testing payments succeed, and that when real cardholders spot those charges and report them as fraud, the result can be early fraud warnings or full disputes. So a single batch of one-dollar charges can produce a cluster of fraud reports against one merchant, all arriving in the same few weeks.

For a high-risk account, that cluster can be enough to move the dispute ratio sharply in one month, while the money at stake stays tiny.

Why the ratio matters more than the money

Merchants tend to count fraud in dollars, but processors and card networks judge it as a ratio.

Card networks track how many fraud reports and disputes a merchant generates against its total transactions. Processors face limits of their own across their whole portfolio, so they act early when one merchant’s numbers start climbing. For a high-risk merchant, that action can mean a higher reserve, a review of the account or, at worst, termination.

Card testing hits this ratio from both directions. The fraud reports add to the top of the calculation, while the low-value test charges add almost nothing to sales. One bad hour can do more damage to a merchant’s standing than a month of ordinary refunds.

Stopping the test before it reaches the ratio

Merchants have more than one point at which to act.

At checkout. Rate limits on payment attempts, CAPTCHA on checkout and card setup pages, and blocks on repeated attempts from the same device or IP address make automated testing slower and more expensive. Requiring a customer account before payment raises the bar further.

At authorization. Fraud screening rules can decline patterns that look like testing, such as many low-value attempts in a short window or a long string of different cards from one session.

Before the dispute. For the test charges that slip through, pre-dispute alerts give the merchant a chance to refund before the cardholder’s report turns into a formal chargeback. A refunded alert does not add a chargeback to the ratio, which is the outcome a high-risk merchant needs most.

After the attack. Review the logs, refund any successful test charges quickly and tell your processor what happened. A processor that hears about an attack from you, with the fix already in place, tends to respond better than one that discovers it in its own monitoring.

Protecting the data that testers want

Card testing exists because stolen card data is cheap and plentiful. Merchants cannot stop data breaches elsewhere, but they can make sure their own systems are not part of the supply.

The PCI Security Standards Council sets the data security standard that applies to any business that stores, processes or transmits card data. For most high-risk merchants, the practical step is to keep raw card data off their own servers entirely by using a processor’s hosted payment fields or tokenization, which reduces both the risk of a breach and the scope of compliance work.

A short checklist for high-risk merchants

• Add rate limits and bot protection to every page that accepts card details, including account and card setup pages.
• Set alerts for unusual volumes of low-value authorizations or declines.
• Enroll in pre-dispute alerts so fraud reports on successful test charges can be refunded before they become chargebacks.
• Refund confirmed test charges as soon as you find them.
• Track your dispute ratio weekly during and after any attack, on top of the usual month-end check.

Card testing will not disappear, and high-risk merchants will keep attracting it. The merchants who keep their accounts healthy are the ones who treat a burst of one-dollar declines as the start of a dispute problem, and act in the hour it happens instead of the month after.