Blog

If you run a WooCommerce store and Stripe or PayPal has flagged your account, there is a strong chance it was not your customers. It was a card-testing attack on your checkout. This is the spam that costs money — chargeback fees, processor-side risk scoring, and in the worst cases a frozen merchant account. Here is how it works on WooCommerce and what to do about it.

What card testing actually looks like

A card-testing attack is automation that runs stolen card numbers against a low-risk public checkout to find out which ones still work. The attacker does not want your product. They want the success response from Stripe. They buy or generate a list of card numbers and need a checkout that does not stop them from trying.

WooCommerce is a popular target for three reasons: the checkout endpoint is well-known, there is rarely a CAPTCHA in front of the pay button, and most stores accept very small order totals (a $5 product is enough to validate a card). A typical burst looks like 80 to 400 attempts in a window of 2 to 15 minutes, often at 3am local time.

Why your processor flags you, not them

Stripe and PayPal score risk at the merchant level. A spike of declined charges, especially in a tight window, looks identical to a compromised merchant on their side. Their automated response is to:

• Raise your risk score
• Throttle your account
• Hold your payouts
• In severe cases, freeze the account pending review

The card tester moves on. You spend a week on the phone with risk teams. This is why “we accept the chargebacks” is not a strategy.

What does not work

Three things people try first that do not stop card-testing bursts:

• reCAPTCHA on checkout. Solvers handle it. It mostly annoys real buyers.
• IP rate limits. Attackers rotate residential IPs and you cannot tell them apart from real visitors on shared NAT.
• Stripe Radar alone. Helpful, but it sees individual charges. It does not see your checkout as a pattern.

What works on WooCommerce

The defence that has held up in production is checkout-level burst detection, not per-payment scoring. You watch the woocommerce_checkout_order_processed hook for velocity (orders per IP, per device fingerprint, per email domain, per amount range) and stop the burst before it gets to Stripe. You also score the customer-side fields (random-looking emails, mismatched billing data) before submission.

What to do this week

Two things you can do today even without a plugin: in your Stripe dashboard, turn on the Radar rule “Block if CVC check fails” and set a per-IP attempt limit on the checkout endpoint at the web-server level (Cloudflare rate-limit rules are free for one rule). That removes the smallest, fastest bursts. The next tier — the sophisticated bursts that rotate IPs and look like real traffic — is where a dedicated checkout-aware filter pays for itself in the first month.

Card testing is not the spam that fills your inbox. It is the spam that quietly costs you your merchant account. Treat it that way.

Akismet was the right answer for comment spam from 2008 to about 2022. It blocked the obvious junk — keyword stuffing, link salads, weird Cyrillic floods — and it shipped with WordPress so it was a default. In 2026 it is still useful as a first layer, but it is not enough on its own. Here is what changed and what to do about it.

What Akismet was always good at

Akismet scores each comment against a large pattern database: known spam URLs, IPs, emails, content fingerprints. It is fast, lightweight, and the false-positive rate is low. For comments that look obviously spammy, it still catches the vast majority.

What changed

The economics of comment spam shifted. The original spam was cheap to write but obvious. New comment spam is generated by language models and looks like this:

“Really enjoyed this read. The point you made about caching and TTFB matches what we saw on our last project. Have you considered looking at how this interacts with the new H3 stack?”

That comment is perfectly on-topic, conversational, and includes a relevant follow-up question. It will land on a post about WordPress performance. The link in the author’s URL field points somewhere mildly suspicious — usually a thin SEO site that just wants the backlink. Akismet has no signal to score this as spam. The pattern looks like a real reader.

Why this matters even if you do not care about comments

A surprising number of WordPress sites have comment forms still enabled on posts and pages where nobody reads them. Each successful spam comment that publishes drops a do-follow or no-follow link from your domain to a low-quality target. Google notices, eventually. Three years of accumulated comment spam links is a real Core Update risk.

What a layered defence looks like in 2026

1. Akismet for the easy lift. Keep it. It is still good at the bulk.
2. Intent scoring on the content of the comment. This is what catches the realistic AI-written stuff. The model reads the comment in context of the post and the author URL and decides whether it looks like a real reader or an SEO play.
3. Honeypot + timing in the comment form. Catches scrapers that bypass the JS and POST directly.
4. Author-URL reputation. If the URL field points somewhere new and thin, weight that as a signal even if the comment is well-written.

What to audit this week

Run this query in your wp-cli or phpMyAdmin to see how much spam is sitting approved on your site:

SELECT COUNT(*) FROM wp_comments WHERE comment_approved = 1 AND comment_author_url != '';

If the number is in the thousands and you do not have an active editorial review, you almost certainly have a pile of low-quality outbound links from your comment form. Disable comments on posts older than two years, sweep the approved-with-URL set for spam patterns, and add intent scoring on top of Akismet for the new comments going forward. That covers most sites without breaking anything that was working.

You filed your DKIM record, set up SPF, configured DMARC, and your transactional emails are still landing in spam folders. There is a good chance the cause is not your mail setup. It is your contact form quietly relaying spam through your domain.

The hidden relay problem

Most WordPress sites send mail directly from the web host using PHP’s mail() function or a basic SMTP plugin. Every contact form submission that gets accepted ends up as an outbound email — to you, with the visitor’s content. That message looks, from a mail-server reputation standpoint, like it came from your domain.

When the visitor is a spammer, what they typed in the message field is now an outbound email from your domain to your inbox, containing links to dating sites or crypto scams. Mailbox providers — Gmail, Outlook, Apple — score that against your domain. Enough of it, often enough, and your sender reputation drops.

How to tell if this is happening to you

Three signs:

• Your contact-form notification emails now go to your own spam folder, not your inbox.
• Your order confirmations or password resets get reported as junk by customers.
• Google Postmaster Tools shows a falling “domain reputation” score over the past 90 days.

None of these are conclusive on their own. All three at once is a strong signal that you are relaying spam content through your forms.

Why standard anti-spam plugins miss this

Most anti-spam plugins decide whether the submission is spam. They do not look at what happens after. If the submission gets accepted, the email still leaves your server with the spammy content intact. The reputation damage is identical to if the plugin had not been installed.

What actually fixes it

The fix has two pieces:

1. Filter the inbound submission using AI intent scoring (so realistic-looking spam still gets caught).
2. Guard the outbound mail — even for submissions that look borderline. Hold the outbound email for review instead of relaying spam content automatically.

That second piece is the part nobody talks about. It is the difference between “we blocked the spam” and “we did not damage the domain”.

If you do nothing else this month

Sign up for Google Postmaster Tools and add your domain. It takes ten minutes. Once your domain has 24 hours of data, you will see a clear graph of how Gmail rates your sending reputation. If the trend is down, this article is for you. If it is flat and high, you are probably fine — but watch it, because the trend tends to drift slowly over a year until the day it does not.

Deliverability is one of those problems that looks like a mail-server problem and is almost always a content problem. The content is what is leaving your forms.

If you run a WordPress site for any length of time, you already know the rhythm. Quiet for a week, then forty submissions overnight that all say “Hello dear, I checked your site and would like to offer…”. The contact form is the single most-abused public endpoint on a typical WordPress site, and every form plugin — Contact Form 7, WPForms, Gravity Forms, Fluent Forms, Elementor Forms — leaks by default. Here is why, and what actually stops it.

Why your form is a magnet, not a target

Spam bots do not pick on you because of who you are. They pick on you because contact-form HTML is recognisable: a couple of <input> fields, a textarea, a submit button, and a predictable JSON or POST endpoint. Scanners crawl the open web, fingerprint the form plugin from its CSS classes, and queue your URL into a list of working targets. The form does not need to be on a busy site to attract submissions — it just needs to be discoverable.

Why the usual fixes stop working

The three traditional defences are honeypots, reputation lists, and CAPTCHAs. Each has a hole that modern spam exploits:

• Honeypots catch lazy bots. They miss anything that runs a headless browser.
• Reputation lists (Akismet-style) score by IP and email patterns. They do not see the content of the message and miss realistic AI-written spam that uses a clean residential IP.
• CAPTCHA shifts the cost onto your real visitors and drops conversions 5 to 15 percent on most contact forms. Worse, modern solvers handle reCAPTCHA v2 in under a second for a fraction of a cent.

What actually works in 2026

The pattern that has held up across forty-plus client sites is layered, invisible-to-the-user defence:

1. Honeypot + timing trap in the form itself. Catches everything dumb. Costs nothing.
2. Server-side intent scoring on the submission. This is the bit that catches AI-written submissions: a model reads the message and decides whether it looks like a real enquiry or a sales pitch with a link.
3. Outbound mail guard. Even if a spam submission gets through, hold the email before it relays through your domain — that is what protects your sender reputation.

What to do this afternoon

If you do not want to install another plugin, you can get most of the way with two changes: add a hidden honeypot field to your form (a CSS-hidden <input> that humans never fill), and add a timestamp comparison that rejects submissions completed in under three seconds. That removes about 60 percent of incoming spam in our measurements. The remaining 40 percent — the realistic, AI-written stuff — is the bit you need intent scoring for, and that is what QWeb Spam Shield was built for.

The takeaway is not “another tool to install”. It is that the model of who is sending the spam changed, and the defence has to change with it. CAPTCHA-and-honeypot was the right answer in 2018. In 2026 it is reading the message that matters.