Card testing on small checkouts: why the $1 charge is the whole attack
A store selling a two dollar add on should not process four hundred card declines before breakfast. When that happens, nobody wants the add on. A tester is running a list of stolen numbers through the cheapest door in your checkout, one dollar of authorisation at a time.
The economics of a one dollar test
A stolen card number is worth little until it is proven live. Testing converts a raw list into a priced list: live cards sell for more and get used for larger fraud elsewhere. The tester therefore wants the cheapest, quietest oracle available, which is why small ticket checkouts, donation forms, and trial signups absorb so much of this traffic. The FBI has warned charities and small merchants about exactly this pattern on donation pages.
Each test costs the merchant, not the tester. Authorisation fees, decline fees on some contracts, and the staff time spent refunding the tests that succeed. A run of a few thousand tests can cost more in fees than the store's smallest product line earns in a month, and the successful tests create chargebacks when real cardholders spot a charge they never made.
Reading the decline pattern before finance does
Testing has a shape your payment data already records. Declines concentrate in specific card network response codes, amounts sit at one value, and the time between attempts is machine regular even when addresses rotate. A useful alert is simple: declines per hour above a set multiple of your normal baseline, watched separately from completed sales.
Split the view by entry point. If the declines arrive through one form, a trial signup or a gift card purchase, that form is the oracle being used, and it is where a challenge or a minimum basket rule belongs. Stores that watch only total decline rate dilute a fierce local spike into a mild sitewide wobble and miss the run entirely.
Controls sized to a small checkout
Velocity rules do the heavy lifting: attempts per card fingerprint, per device, per account, and per address range inside short windows. Testers need volume, so a ceiling that a real buyer never reaches, say a handful of failed attempts before a pause, collapses the run while touching almost no legitimate traffic.
Raising the minimum transaction is blunter and sometimes right for a donation form, but it punishes the smallest genuine donors. A better pairing for most stores is a challenge that triggers on decline velocity plus authorisation holds reviewed daily during a run. The point is to make your checkout an expensive oracle, not to make it a harder shop.
What to do with the cards that passed
Cards that passed a test on your site will be used somewhere, possibly back on your site at a higher value. Flag accounts and sessions tied to successful test transactions, refund them promptly, and expect the follow up attempt to arrive with a different address and the same card fingerprint.
Report the run to your payment processor with timestamps and fingerprints intact. Processors see the same list tested across many small merchants at once, and your report is a piece of a pattern they can act on at network level. Deleting the logs in embarrassment helps only the tester.
Keep reading: Money mules recruited through romance chats: the account pattern platforms can see, Fake verification badges for sale: how the scam prices trust it cannot deliver.
Frequently asked questions
Why do card testers choose the smallest charge available?
Because they are buying information, not goods: a yes or no on whether a stolen card is live. The cheapest transaction gives that answer at the lowest cost and draws the least attention. Stores with very cheap items, trials, or donation forms offer the cheapest answer, so they get tested most.
Who pays for a card testing run?
Mostly the merchant. Authorisation and decline fees apply per attempt on many contracts, successful tests must be refunded, and some become chargebacks when cardholders dispute them. A tester with a stolen list pays almost nothing, which is why making the checkout an expensive oracle is the effective defence.
What is the earliest sign of card testing in my data?
A spike in declined authorisations, clustered at one low amount and often through one form or product, with machine regular timing between attempts. Watch declines per hour against your own baseline, split by entry point. Total site decline rate hides the local spike that identifies the run.
Should I raise my minimum charge to stop testing?
It can work on a donation form, but it taxes your smallest genuine customers to stop an attacker. Velocity limits on attempts per card, device, and account, plus a challenge that triggers when declines spike, usually stop the run with far less collateral damage to real buyers.