The one-dollar charge that is not a sale: card testing at checkout
The pattern that gives it away
Your dashboard shows a spike in failed payments, all for the same small amount, from a run of email addresses that look generated. The cards change every attempt. The amount does not. That is card testing, and the goal is not your product. Your checkout is being used as a card validator, and the test is whether the number works.
Stripe's card testing guidance describes two methods. The first is card setup: a validation that runs when a card is saved, which usually does not appear as a charge on the cardholder's statement. The second is a small-amount payment, small enough that the cardholder is unlikely to notice it. Both exist because the attacker wants the answer from the issuer, not the goods.
Visa's June 2026 guidance puts a number on small: attack transactions are often less than ten dollars. That is why the charges sit just under the threshold where a cardholder checks. A dollar charge looks like a rounding error. A thousand dollar charges look like a business.
What it costs after the attack stops
Every attempt costs money, including the declined ones. On many pricing plans you pay an authorization fee whether the charge succeeds or not, so a thousand attempts is a line item before a single card approves. The approved ones are worse: they are charges on real people's stolen cards, and when the cardholder sees a charge they do not recognise, they dispute it as fraud.
Stripe reports that about 40 percent of Visa and Mastercard early fraud warnings become fraud disputes when the charge is not refunded, and refunding a flagged payment does not remove the warning. The dispute arrives as Visa reason code 10.4, the same code as a stolen-card purchase, and it carries a dispute fee on top of the refund.
Then there is the monitoring. Visa watches card testing on its own track through the Acquirer Monitoring Program, separate from disputes and fraud. The enumeration ratio counts enumerated authorization attempts against all authorization attempts in a month, and a ratio of 20 percent or more with at least 300,000 enumerated attempts in the same month counts as excessive. A sustained attack can put the merchant account itself at risk, not just the week's revenue.
Three layers, in the order that matters
The first layer is the checkout itself. Rate limit payment attempts per IP, per device, and per card, and put a bot check in front of the payment step. Stripe reports that adding its managed CAPTCHA for all Checkout users reduced card testing by 80 percent with under two basis points of impact on authorization rates. A challenge that scripts cannot pass ends most attacks before they reach the issuer.
The second layer is Radar rules that match the pattern, not the symptom. Block when one IP tries more than a few distinct cards in an hour, or when declined charges per IP pass a small threshold, or when the CVC check fails repeatedly. The pattern is specific enough to be worth an explicit rule: many cards, one IP, one amount, in minutes.
The third layer is the minimum charge and the velocity check on new customers. A checkout with no minimum is a free validator. A small minimum does not stop a determined tester, but it raises the cost of every attempt, and card testing is a volume business that dies when the unit economics break. Combine that with a limit on payment attempts from new customers in their first day, and the attack has nowhere cheap to run.
What not to do
Do not just block the IP and declare it fixed. Testers rotate IPs, user agents, and card numbers precisely so that a single filter misses them. Stripe's own guidance says filters based on one heuristic, such as blocking an IP, are usually not enough. The block buys an hour. The pattern is what buys the month.
And do not ignore a small wave because the amounts are small. A hundred test charges at a dollar each is a hundred dollars of authorizations, a damaged authorization rate, and a set of live cards that will be used somewhere else, possibly at your store, for the real fraud. The small charge is the warning. The big charge is the consequence.
Keep reading: Why do bots attack the password reset page instead of the login page?, How do bots turn stolen cards into gift cards?, and How do bots exploit buy-online-pickup-in-store to move stolen cards? cover the nearby cases in this series.
Frequently asked questions
What is card testing?
Card testing is when someone runs stolen card numbers through a payment form in small amounts to find out which cards are still valid. The goal is not the purchase. It is the answer from the issuer, and the cards that approve are then used for larger fraud or sold on.
How do I know my checkout is being card tested?
Look for a spike in declined authorizations, many small charges for the same amount in quick succession, and a run of different cards from the same IP or device. The attempts usually arrive at machine speed, far faster than a person could type, and the email addresses often look generated.
Why do testers use such small amounts?
Because small charges are less likely to be noticed by the cardholder and less likely to trigger alerts. Visa's guidance says attack transactions are often less than ten dollars. The tester wants the authorization answer, not the money, so the cheapest charge that still returns an answer is the right one.
Does refunding the test charges fix the problem?
No. Refunding returns the money but does not remove the early fraud warning, and about 40 percent of Visa and Mastercard early fraud warnings become fraud disputes when the charge is not refunded in time. The fix is stopping the attempts at the checkout, not cleaning up after them.