WooCommerce security: card testing, skimmers and what you owe customers afterwards

The first sign is rarely dramatic. It is usually a Tuesday morning and there are forty seven failed orders in the dashboard from overnight, all for small amounts, all from cards that were declined.

Or a customer emails to say their card was used somewhere else a few days after they bought from you. Or your payment provider gets in touch about your chargeback rate before you have noticed anything at all.

None of those look like the hacking you see in films, which is part of why store owners tend to dismiss them for a week or two. All three are worth acting on the same day.

Why a shop is a different problem to a website

Every WordPress site faces the same background noise of automated attacks. A store faces all of that, and then three more things, because there is money moving through it.

• Your checkout is a card validation service to somebody. A criminal with a list of stolen card numbers needs to know which ones still work. Your checkout will tell them, for free, at scale.
• Your customers type card details into your pages. That makes the pages themselves worth attacking, whether or not you ever store the numbers.
• You hold personal data. Names, addresses, order history, phone numbers. That has value on its own, and it carries obligations that a brochure site does not.

A brochure site being hacked is a problem. A store being hacked is a problem, a cost, and potentially a notification you have to make within seventy two hours.

Card testing: what those tiny failed orders are

Card testing, sometimes called carding, is the most common attack on small WooCommerce stores and the most commonly misunderstood.

Someone has bought a batch of stolen card numbers. Most will be cancelled already. To find the live ones they need a checkout that will attempt a payment and report back, and they need it to be a small enough amount that the real cardholder does not notice. Your store is not the target. Your store is the instrument.

What it looks like in your dashboard:

• A cluster of orders in a very short window, often overnight
• Mostly failed payments, with a few succeeding
• Small amounts, frequently on your cheapest product or a variable price field
• Different names and email addresses, sometimes randomly generated
• Repeating patterns in the addresses, or the same address with different names
• Traffic straight to the checkout with no browsing beforehand

What it costs you even though the payments failed: most providers charge a fee per attempted transaction, so a few thousand attempts is a real bill. Your decline rate climbs, which some providers treat as a risk signal against your account. The successful ones become chargebacks later, and chargebacks carry their own fee on top of the lost money. If the rate gets high enough, providers can and do close merchant accounts.

What actually helps: rate limiting at the checkout, a CAPTCHA on the payment step rather than on the contact form, blocking the obvious repeat offenders by IP, turning off guest checkout if your business can live without it, removing any product priced at a token amount, and enabling whatever fraud tooling your payment provider offers. Stripe Radar and its equivalents are usually already included in what you pay.

Payment skimming: the one that is genuinely serious

This is the risk that almost none of the general WooCommerce security advice covers, and it is the one with real consequences.

A skimmer is a small piece of JavaScript injected into your checkout page. It sits quietly and copies what customers type into the card fields, sending it to a server somewhere else. The customer’s order completes normally. Your store behaves normally. Nothing is broken, nothing looks wrong, and the theft can run for months.

The technique is usually called Magecart, after the group that popularised it against Magento stores, and the same approach works anywhere card details are typed into a page you control.

Why “we use Stripe so we are fine” is not quite right. If your checkout uses a hosted payment page or a properly isolated iframe, the card details are never typed into your pages and a skimmer on your site cannot read them. That is genuinely safer, and it is worth knowing which setup you have. But many stores use an embedded card field for a smoother checkout, and injected JavaScript on the page can interfere with that. Find out which one you are running before you rely on it.

How to check: open your live checkout, open the browser developer tools, and look at the Network tab while you type into the form. Anything being sent to a domain that is not yours, your payment provider, or a service you deliberately installed is worth investigating immediately. Also compare the scripts loading on the checkout against a staging copy you trust.

If you find one, treat it as an active data breach rather than a website problem, and read the obligations section below before you delete anything.

Fraudulent orders

Different from card testing, because here the goal is to receive goods rather than to validate a number. Warning signs are familiar to anyone who has run a shop for a while: an unusually large first order, express shipping chosen regardless of cost, a billing address and delivery address in different countries, an order placed at three in the morning, or several orders to the same address under different names.

The awkward truth about chargebacks is that for card-not-present transactions the liability usually sits with you rather than the bank, even when you did nothing wrong. That is why the boring controls matter: address verification, requiring a signature on high value deliveries, and simply holding a suspicious order for a phone call before dispatch.

Checking your store this week

None of this needs a developer.

1. Sort your orders by date and look at the overnight hours. Clusters of small failed payments are the card testing signature.
2. Check your payment provider dashboard for decline rate. A climbing decline rate with flat sales is the clearest early warning there is.
3. Look at your Users list. WooCommerce creates customer accounts, so scan for administrators specifically, and for a burst of customer registrations that never ordered anything.
4. Open the checkout in developer tools and read the list of scripts loading on it. You should recognise every domain.
5. Check wp-content/uploads for PHP files. There should be none, ever.
6. Confirm your backups actually restore. A store backup that has never been tested is not a backup, and a store has a database that changes every hour rather than every month.

If any of that turns something up, our WordPress malware removal service covers stores, including the checkout side and the search recovery afterwards.

The part nobody writes about: what you owe afterwards

Search for WooCommerce security advice and you will find a great deal about prevention and detection. You will find almost nothing about what happens once something has actually got in, which is the moment a store owner most needs to know what to do.

Three separate sets of obligations can apply, and they are not the same thing.

Data protection

If personal data has been exposed, UK GDPR sets out when a breach must be reported to the Information Commissioner’s Office, and the headline figure people remember is 72 hours from becoming aware of it. There are also circumstances where you have to tell the affected customers directly.

Whether a specific incident meets the threshold is a judgement, and it is not one to make from a blog post. What matters practically is that the clock starts when you become aware, so “we will look into it next week” is the wrong instinct. Get advice quickly rather than deciding on your own that it probably does not count.

Your payment provider and PCI

Separate obligations, owed to your provider and the card schemes rather than to a regulator. Your merchant agreement will say what you have to report and when. If card details were captured, tell them early. Providers deal with this constantly and would far rather hear it from you.

Preserving evidence

This is where good intentions do damage. The instinct is to delete the malicious file immediately and restore a backup. If you may have a reportable breach, you have just destroyed the record of what was taken and when, which is exactly what you will be asked for.

Take a full copy of files and database first. Keep the server logs. Note the times. Then clean.

We are a web agency, not solicitors, and the paragraphs above are context rather than legal advice. If customer data may have been exposed, that is the point to speak to somebody qualified rather than to work it out from a search result.

More on protecting a store

We have written a fair amount about the practical side of blocking bad actors on a WooCommerce store, which sits alongside everything above:

• WooCommerce security: essential tips to protect your store
• Top fraud prevention tactics for WooCommerce
• Protecting your store from phishing threats
• Blocking users by IP address
• Email blacklisting to prevent fraud and spam
• Blocking fraudulent users in WooCommerce

Frequently asked questions

Is WooCommerce less secure than Shopify?

Not inherently. The difference is who is responsible. On a hosted platform the provider patches the software whether you think about it or not. On WooCommerce that is your job, or your agency’s. WooCommerce gives you far more control and hands you the maintenance along with it. Neither is safer in the abstract, and a well maintained WooCommerce store is safer than a neglected anything.

Does WooCommerce store card numbers?

Standard WooCommerce with a normal payment gateway does not store full card numbers in your database. It does store names, addresses, email addresses, phone numbers and complete order histories, which is still personal data and still worth stealing. “We do not hold card details” is true and it is not the same as “there is nothing here to protect”.

Do I have to worry about PCI compliance?

Almost certainly something applies, and how much depends on how your checkout is built and how many transactions you process. A store using a hosted payment page carries a much lighter burden than one accepting card details directly on its own pages. Your payment provider is the right first call, because they will tell you which category you fall into.

Can I just block the countries the attacks come from?

You can, and it reduces noise. It is a blunt instrument, because attackers use proxies in whatever country you allow, and because you may block genuine customers. Useful as one layer, not as the strategy.

How often should a store be updated?

More often than a brochure site, and more carefully, because an update that breaks the checkout costs money immediately. That is the argument for staging: apply updates to a copy, confirm the checkout still takes a test payment, then apply to the live store. Our WordPress security plans include a WooCommerce tier that does exactly this.

---

Seeing odd orders, or worried about your checkout?

Send us what you are seeing and we will tell you whether it is card testing, fraud or something worse. If your checkout has been tampered with, that is urgent and we will treat it that way.

Marketing the Change is a digital marketing agency based in Liverpool. We build and maintain WooCommerce stores for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n