Card Testing: The Attack That Costs the Merchant Everything | HL Hunt

Card Testing: The Attack That Costs the Merchant Everything | HL Hunt
Payments & AI

Card Testing: The Attack That Costs the Merchant Everything

An attacker runs 40,000 one-dollar authorizations through a donation page overnight to find out which stolen cards work. The merchant earns nothing and pays roughly $16,500 in fees and dispute charges. That is the smaller problem. In the same month its dispute ratio goes from 0.4% to 6.6%, and network monitoring starts at around one percent.

By the HL Hunt Research Desk · 13 min read · Updated September 2026

An attack that earns the merchant nothing and costs it everything

Card testing is the use of a merchant's checkout to find out which stolen card numbers work. The attacker submits large numbers of small authorizations, keeps the cards that approve, and uses them somewhere else. The merchant never sees a sale.

Take a single overnight attack on a donation page: 40,000 attempts at $1 each.

ItemAmount
Per-attempt processing fees at $0.10$4,000
Attempts that approve, at 4%1,600
Of those, disputed at 30%, at $25 each480 disputes, $12,000
Fees not returned when the rest are refundedabout $480
Revenue from the attack$0

Roughly $16,500 of direct cost for an event that produced no business. And the direct cost is the smaller part of the problem.

The number that actually threatens the account

The merchant normally processes 6,000 transactions a month and sees 24 disputes, a ratio of 0.4%.

After the attack, the month holds 7,600 transactions and 504 disputes.

0.4% to 6.6%
The merchant's dispute ratio in the month of a single card-testing attack. Network monitoring programs are triggered at a small fraction of that level, and the attack does not need to repeat for the account to be at risk.

That is the real cost. Per our dispute ratio analysis, monitoring thresholds sit around one percent, and a merchant pushed far above them faces fines, enrolment in remediation programs, a reserve, or termination. Per our reserve analysis, a processor that sees a sudden spike in disputes and declines is likely to hold funds first and ask questions afterward, and the merchant's legitimate settlements are the funds held.

The 96% decline rate is a second signal working against the merchant. A checkout that suddenly produces tens of thousands of declines looks, to the networks and the processor, like a merchant that is either compromised or complicit, and excessive decline and retry behaviour carries its own fees and scrutiny.

Which merchants get chosen

Attackers do not pick at random. They pick checkouts with specific properties, and recognizing them is most of the defence.

PropertyWhy attackers want it
Any amount acceptedA $1 test is cheap and less likely to be noticed by the cardholder. Per our donation analysis, donation pages are the classic target
No login or account requiredGuest checkout lets each attempt look like a new customer
Detailed decline messagesA response that says which field failed tells the attacker what to fix
No rate limitingThousands of attempts an hour from the same source go through
Card verification on a free trial or $0 checkA validation endpoint is a testing endpoint
Weak or absent bot detectionAutomation is the only way to run 40,000 attempts

The fifth row catches businesses that think they are not exposed. A subscription business that verifies cards before a free trial, or a marketplace that validates a card on file, has built a card-checking service whether or not anything is ever charged. Per our stored credential analysis, card verification at signup is good practice, and it is also the endpoint most worth protecting.

Card testing is invisible until the dispute ratio arrives

A single overnight attack moved this merchant from 0.4% disputes to 6.6%. HL Hunt AI Payment Processing watches authorization velocity, decline patterns and device signals in real time, and stops a testing run in its first hundred attempts rather than its forty thousandth.

See How HL Hunt AI Payment Processing Works

Controls, in order of value

The goal is not to stop every attempt. It is to make the checkout uneconomic to test against, so the attacker moves on. Stopping 97% of attempts takes per-attempt fees from $4,000 to $120 and removes most of the approved charges that become disputes.

  1. Velocity limits by device, IP address, card fingerprint and account, with lower limits for declines than for approvals.
  2. Bot challenges triggered by velocity or by risk signals rather than shown to every customer.
  3. Minimum amounts where the business allows it, because $1 attempts exist to avoid notice.
  4. Generic decline messages. Tell the customer the payment did not go through, not which check it failed.
  5. Require CVV and address checks, and decline on mismatch at the checkout rather than accepting the processor's approval.
  6. Alerts on decline rate, not only on fraud. Per our alert analysis, one well-tuned alert on a sudden rise in declines beats many noisy fraud rules.
  7. A kill switch. The ability to pause guest checkout or a single payment page in minutes, at 2am, without a deployment.

Item seven is the control that limits the size of any attack that gets through. Card testing typically runs overnight or at weekends, when no one is watching, and the damage is proportional to how long it runs. An attack stopped after an hour is a nuisance; one that runs until Monday is an account review.

Over-tightening has its own cost

Per our fraud rate analysis, every control declines some legitimate customers, and a bot challenge shown to everyone or a velocity limit set too low converts a fraud problem into a conversion problem. The useful design applies friction in proportion to risk: invisible to a returning customer on a known device, present for the thousandth guest attempt from one address in an hour.

After an attack

  1. Stop it first. Pause the page, tighten velocity, then investigate.
  2. Reverse uncaptured authorizations rather than capturing and refunding. A reversed authorization never settles, which avoids most fees and removes the transaction the cardholder would dispute.
  3. Refund any captured test charges promptly. Per our refund analysis, a charge refunded before the cardholder notices is far less likely to become a dispute.
  4. Tell the processor before it tells you. A merchant that reports an attack, with the controls it has added, is in a different position from one whose ratio spike is discovered in a monthly review.
  5. Check the descriptor. Per our descriptor analysis, cardholders who do not recognize a $1 charge dispute it; a recognizable name reduces that.
  6. Reconcile the attack window separately so test charges are not mixed into real sales and refunds. Per our reconciliation analysis, they will otherwise distort every figure for that month.

Item two is the most valuable and the least known. Many merchants refund approved test charges, which settles and then reverses each one, paying fees in both directions and leaving a settled transaction for the cardholder to dispute. Voiding before capture prevents almost all of that, but it has to happen before the capture runs, which for most merchants is within the day.

Item four is what protects the account. Per our chargeback analysis, processors and networks treat a merchant differently when a dispute spike has a documented cause and a documented fix, and the cost of making that call is an email.

The cheapest attack is the one that stops in the first hour

Card testing runs overnight because nobody is watching. HL Hunt AI Payment Processing applies risk-proportional friction, reverses uncaptured test authorizations, and gives you a kill switch for any payment page that does not need a developer at 2am.

Talk to HL Hunt About Payment Processing

Frequently asked questions

What is card testing?

Using a merchant's checkout to find which stolen cards work. One 40,000-attempt attack can cost about $16,500 and earn nothing.

Why is card testing dangerous for a merchant account?

Because one attack can take a 0.4% dispute ratio to about 6.6%, far above network monitoring thresholds of around one percent.

Which businesses are targeted for card testing?

Checkouts accepting any amount, guest checkout, detailed declines, no rate limits, card verification endpoints, and weak bot detection. Donation pages especially.

What should a merchant do after a card testing attack?

Stop it, reverse uncaptured authorizations rather than refunding, refund anything captured quickly, and report the attack and fix to your processor.

Key takeaways

  • Card testing uses a merchant checkout to validate stolen cards that are then used elsewhere.
  • A 40,000-attempt $1 attack costs about $16,500 in fees and dispute charges and earns nothing.
  • The real damage is the dispute ratio, which went from 0.4% to 6.6% in one month here.
  • Network monitoring starts around one percent, so one attack can bring fines, reserves or termination.
  • Attackers choose checkouts that accept any amount, allow guest checkout, and have no rate limits.
  • Stopping 97% of attempts takes per-attempt fees from $4,000 to $120.
  • A kill switch that pauses a page in minutes limits how long any attack can run.
  • Reverse uncaptured test authorizations rather than refunding them, which avoids most fees and disputes.

This guide is educational and does not constitute legal, compliance, or security advice. All figures are stylized illustrations using assumed attempt volumes, per-attempt fees, approval rates, dispute rates, dispute fees, and monthly transaction volumes, and do not describe any particular merchant or attack. Card network dispute monitoring thresholds, excessive authorization and retry fees, authorization reversal rules, and processor reserve practices vary by network and processor and change over time; consult your processor and qualified advisers about your obligations.