Card Testing: When Criminals Use Your Checkout to Try Stolen Cards

It has a shape you learn to recognise. Several hundred payment attempts inside twenty minutes, every one of them for pocket change, every one under a different name, nearly all of them failing. No orders. No customers. We have sat over that pattern in a payment log with an owner more than once, and the first thing they say is always some version of the same sentence: somebody has hacked the website. Nobody has. The website is working perfectly. That is the problem.

What they are looking at is called card testing, and it is one of the few attacks where the criminal does not want to break anything. They want your checkout to keep working, quietly, for as long as possible.

This is a reference for what card testing is, what it costs when it lands on a small shop, how to recognise it in the first hour instead of the third day, and which controls genuinely stop it.

What Card Testing Actually Is

Somebody buys a list of stolen card numbers. Most of those numbers are dead: cancelled, expired, already flagged. Before the list is worth anything, it has to be sorted into cards that still work and cards that do not. The cheapest way to sort it is to push every number through a real merchant's payment form and watch what comes back.

Stripe's own documentation on the subject uses the term card testing, and notes that the same activity goes by carding, account testing, enumeration and card checking. The method is scripted rather than manual. A program submits card after card, collects the issuer response, keeps the numbers that authorise and discards the rest. The confirmed cards are then cashed out somewhere else entirely, or resold.

There are two ways in, and the distinction matters when you go looking for the damage.

The first is card setup, the flow where a customer saves a card for later. Stripe notes that fraudulent actors prefer this route, because validations and authorisations during card setup do not typically appear on a cardholder's statement. Nobody notices, so nobody reports it.

The second is payments. Small ones. A charge of fifty cents or a euro sits below the threshold at which most people read their statement line by line.

So your checkout is not really the target. It is the instrument. The card being tested belongs to somebody else, the loss lands somewhere else, and your shop is the piece of equipment in the middle that happens to be free to use.

Why the Quiet Little Shop Is the Better Target

There is an assumption among owner-operators that attackers go where the money is, and that a business turning over a modest amount each month is beneath anyone's notice. For this particular attack, the opposite is true.

A card tester wants an endpoint that accepts payment attempts without arguing, belonging to a business that will not notice quickly. Large retailers have fraud teams, velocity rules and somebody watching a dashboard on a Sunday. A small shop has guest checkout, no CAPTCHA, a payment integration a freelancer wired up three years ago, and an owner who checks the orders screen once a day.

The forms that get hit are rarely the ones people worry about. A donation page. A pay-your-invoice page. A deposit form. A membership signup. Anything that takes an amount and a card without requiring an account first.

Consider a charter boat outfit in Donegal that takes a deposit online to hold a day's sea angling. One form, one amount, no login. To the owner it is the simplest page on the site. To a script it is a free card validation service that runs all night.

In that scenario, which is a composite of a pattern rather than one business, the morning after is the quietest disaster you will ever have. The deposits page still works. The site is still up. Nothing on it looks wrong. The only visible change is that the payment provider has paused the payouts while it works out what happened, and the genuine customer who tried to book a boat at seven that morning had her card declined for no reason she will ever understand.

What It Actually Costs You

The damage is not one bill. It arrives in five separate ways, and the later ones outlast the attack itself.

What happens	Why it costs you	When you feel it
Disputes and early fraud warnings	Successful test charges get reported as fraud by real cardholders	Days to weeks
Higher decline rates on legitimate payments	Issuers and networks start treating all your traffic as risky	Weeks, and it persists
Per-attempt fees	Authorisation and dispute fees accrue on transactions that were never sales	Next statement
Infrastructure strain	Thousands of requests hit checkout endpoints never built for that load	Immediately
Card scheme monitoring programmes	Fraud and dispute ratios breach network thresholds	One to three months

Disputes and early fraud warnings

Some test charges succeed. When a cardholder spots one, they report it as fraud, which produces an early fraud warning or a full dispute. Each of those carries a fee, and each one is counted against you. You did not sell anything, you have nothing to defend the dispute with, and you pay for the privilege of losing it.

Higher decline rates on legitimate payments

This is the consequence owners underestimate. Stripe's documentation states plainly that card testing associates a large number of declines with your business, that this can damage your reputation with issuers and card networks, and that the result can be an increased decline rate for legitimate payments even after the card testing stops.

Read that last part again. The attack ends and your real customers are still being declined. Somebody who has bought from you happily for two years puts in her card, gets refused, tries once more, then goes and buys the same thing from whoever ranks below you. She will not ring to tell you.

Per-attempt fees

Depending on your pricing arrangement, authorisation attempts and disputes carry fees whether or not anything was ever sold. Thousands of attempts overnight becomes a line on a statement for revenue that does not exist. The amounts per attempt are small. The multiplication is not.

Infrastructure strain

Card testing is high-volume automated traffic aimed at the two or three heaviest pages on a WordPress site. Checkout is not a cached page. It cannot be. Every one of those requests goes through to PHP and the database, which is precisely the load profile a cheap shared plan handles worst. Stripe lists infrastructure strain among the consequences, noting that the additional traffic can overburden your infrastructure and disrupt legitimate activity.

In practice the shop gets slow or falls over for real customers while the attack runs. It is the same underlying pattern as the automated scripts that hammer WordPress login pages looking for a password that works, pointed at a more expensive part of the application.

Card scheme monitoring programmes

This is the one that can end a business's ability to take cards at all, and almost nobody hears about it until they are in it.

The card networks monitor the ratio of fraud and disputes to legitimate transactions, and they act on merchants who cross a line. The Merchant Risk Council, the industry body for payments and fraud teams, reported that from 1 April 2026 Visa tightened the merchant threshold in its Acquirer Monitoring Program from 2.2% to 1.5%, with the ratio built from reported fraud and disputes together, measured against settled card-not-present transactions, and a fee in the region of eight dollars per fraudulent or disputed transaction for enrolled merchants.

Thresholds, grace periods and enforcement vary by region and by acquirer, so treat those figures as the shape of the rule rather than the terms of your own arrangement. Your acquirer's contract is the document that actually governs you.

The arithmetic is what makes this dangerous for a small shop. A ratio is a fraction. If you process forty card-not-present orders a month, it does not take many disputed test charges to push that fraction past one and a half percent. A large retailer absorbs the same number of incidents inside a far bigger denominator and never notices. Small volume is not protection here. It is exposure.

Does Being in the EU Protect You?

Partly, and it is worth being precise about how much.

European cardholders benefit from strong customer authentication, introduced under the revised Payment Services Directive, which is why so many online payments now bounce through a bank app or a code. The joint European Banking Authority and European Central Bank report on payment fraud published in December 2025 confirms the effect. It put card fraud at roughly 1.3 billion euro for 2024, up by somewhere close to a third year on year, and noted that card payment fraud was seventeen times higher where the payment recipient sat outside the European Economic Area, which is precisely where that authentication is not legally required.

So the authentication works against the fraud it was designed to stop. The same report is careful to add that new types of fraud are emerging which target transactions where an authentication exemption applies, or which manipulate genuine users into authenticating a fraudulent payment themselves.

Card testing lives in exactly that gap. Card setup flows, zero-value or very low-value authorisations, and cards issued outside the EEA are the routes a tester works, precisely because they are the ones least likely to raise a challenge.

The Irish picture supports the point rather than softening it. The Central Bank of Ireland's analysis of payment fraud statistics found that online card payments accounted for 86% of the total value of card fraud in Ireland in 2023, getting on for nine euro in every ten, and that the Irish card fraud rate sat slightly above the equivalent EU figures rather than below them. Low overall as a share of all transactions, and concentrated almost entirely in the remote, card-not-present channel that your website is.

A reality check while we are here, because leaving it out would be dishonest. Nothing you or your host configures makes card testing impossible. A determined operation running one attempt each from thousands of residential addresses walks past any per-address rule you write, because from the server's point of view every request looks like a different person trying once. What good controls do is change the economics. Testing becomes slow, expensive and noisy, and the script moves to an easier shop. That is the honest objective. Not immunity.

How to Tell It Is Happening

The symptoms are consistent, and they show up in your payment dashboard before they show up anywhere else. Stripe's guidance lists the ones to watch for, and they match what we see at the hosting layer.

• A spike in failed or blocked payments. Not a handful. A cliff edge on a chart that is normally flat.
• A spike in card errors in your logs, often with generic decline responses, and often inside a narrow window of time.
• Low transaction amounts with nonsensical customer names and email addresses. Stripe's advice is to refund any of these that got through rather than wait for them to become disputes.
• Orders that never become orders. In WooCommerce, a pile of failed and pending entries with no corresponding fulfilment.
• Traffic concentrated on checkout endpoints rather than spread across the catalogue the way genuine browsing is.

One more signal that owners tend to receive first and misread: your payment provider contacts you, or pauses a payout, before you have noticed anything at all. That is not the provider being difficult. That is the earliest warning you are going to get, and it deserves to be treated as an incident rather than an administrative query.

Shutting a Card Testing Attack Down in Five Steps

If it is happening now, work in this order. Do not start with the clever part.

1. Identify. Open your payment dashboard and confirm the pattern: the time window, the amounts, the volume of failures. Write down what normal looks like for you, because you will need the comparison.
2. Refund. Refund the suspicious charges that succeeded, immediately. A refund costs you a fee. A dispute costs you a fee, a fraud report, and a contribution to the ratio that gets merchant accounts reviewed.
3. Restrict. Put a CAPTCHA in front of the payment form, validated on the server rather than in the browser, and require a valid session before the form accepts anything. Stripe's documentation is direct about this: the easier it is to reach your payment form, the easier the attack is to run.
4. Throttle. Apply rate limits at the edge and inside the checkout flow. Limit attempts per address, limit how many customer records one address can create in a day, and use your payment provider's velocity rules where your plan includes them.
5. Verify. Watch for a full day and confirm two things: that the attack traffic has stopped, and that genuine payments are still completing. Only one of those on its own is not success.

That fifth step is not padding, and I will admit why. Years ago we throttled an endpoint under attack far harder than the situation needed, and left it that way. The attack stopped that afternoon. A customer's genuine promotion the following week ran into the same limit, and a good number of real people were turned away at the point of paying before anyone connected the two events. Rate limiting is a tourniquet. Effective, and not something you leave on.

Where Hosting Helps, and Where It Does Not

There are two layers of defence here, and confusing them is how shops end up protected in the wrong place.

The payment layer is where the fraud decision belongs. Your provider sees the card, the issuer response, the device and the pattern of attempts across thousands of merchants at once. No hosting company has that view, and any that tells you otherwise is selling something.

The server layer is where the volume is absorbed. Intrusion prevention that bans an address after repeated abusive requests, malware scanning in case a test run was reconnaissance rather than the attack itself, and enough headroom that a flood of uncached checkout requests does not take the shop down while the payment provider's models catch up.

Every site on the hardened Irish stack Web60 runs sits behind that layer by default, with server-level hardening, fail2ban intrusion prevention and automatic malware scanning in place before anyone puts a product on the site, because the alternative is discovering on the morning of an attack that nobody ever set it up. That, and the routine described in our complete WordPress security and backup guide for Irish websites, is most of what infrastructure can honestly contribute.

Now the genuine concession. If you are running a high-volume subscription or marketplace business, with a fraud analyst on staff and a real need to write custom velocity rules against your own transaction history, the premium fraud-management platforms are built for exactly that and will serve you better than anything a hosting stack provides. That work is a job, not a setting. For the great majority of local firms selling a few dozen orders a month, a well-integrated payment provider plus a properly configured server is not a compromise. It is the correct amount of machinery.

Conclusion

Card testing is worth understanding because of what it reveals about your own website. A checkout is not a shop counter. It is a publicly reachable endpoint that performs a valuable operation for anybody who asks, and it will perform that operation ten thousand times without complaining or getting tired.

Most of the defence is unglamorous. Do not leave a payment form reachable without a session. Put a CAPTCHA on it. Know what a normal day looks like in your payment dashboard so that an abnormal one is obvious. Refund fast. Treat a message from your payment provider as an alarm rather than paperwork.

If there is a form on your site that takes a card without asking for anything else first, that is the page to look at today.

Frequently Asked Questions

What is a card testing attack in plain English?

Criminals buy lists of stolen card numbers, most of which no longer work. To find out which ones do, they run each number through a real business's payment form, usually for a very small amount, and keep the ones that authorise. Your website is not being hacked and nothing on it is broken. It is being used as a free tool to sort somebody else's stolen data, and you carry the fees, the disputes and the reputational damage with the card networks.

Why would anyone target my small business rather than a big retailer?

Because the attack needs a payment form that will accept a high volume of attempts without pushing back, from a business unlikely to notice for a while. Larger retailers have fraud teams, velocity rules and monitoring. A small shop often has guest checkout, no CAPTCHA and an owner who looks at the orders screen once a day. Low turnover also makes it worse rather than better, because network fraud ratios are fractions, and a small number of monthly transactions makes a small number of disputes a large percentage.

Does Stripe or my payment provider not stop this automatically?

Modern hosted checkout components include rate limiting, risk models and CAPTCHA triggers, and they stop a great deal. Stripe's documentation notes that the effectiveness of those controls depends heavily on your integration and on how much information it passes across, such as the customer's address, email and IP address. Older custom integrations, or payment forms wired together by hand years ago, often send very little of that and get correspondingly weaker protection.

How do I know whether card testing is happening to me right now?

Look for a sudden cliff edge in failed payments in your payment dashboard, a batch of very small charges with names and email addresses that look like keyboard noise, and traffic concentrated on your checkout or donation page rather than spread across your site. If your payment provider pauses a payout or contacts you about unusual activity, treat that as the alarm rather than as an administrative query.

Will a CAPTCHA on my checkout put real customers off?

Modern CAPTCHA is mostly invisible to genuine users, scoring behaviour in the background and only presenting a challenge when something looks wrong. The important detail is that it has to be validated on the server, not just displayed in the browser, or a script simply skips it. If you already see checkout abandonment, check what else is causing friction before assuming the CAPTCHA is the cause.

Can card testing get my merchant account shut down?

It can put you into a card scheme monitoring programme, which is the step before losing the facility. The networks measure fraud and disputes as a ratio against your card-not-present transactions, and the Merchant Risk Council reported that the Visa merchant threshold tightened from 2.2% to 1.5% in April 2026, with per-transaction fees for enrolled merchants on top. Terms differ by acquirer and region, so the contract with your own payment provider is the one that matters.

Sources

Stripe, Protect yourself from card testing

European Central Bank, Joint EBA-ECB report on payment fraud, December 2025

Central Bank of Ireland, Insights from Irish Payment Fraud Statistics

Merchant Risk Council, Stricter VAMP ratio thresholds are now in effect

OWASP, Cross-Site Request Forgery Prevention Cheat Sheet