Fraud reports with one merchant in common
Several customers report misuse of cards they used at your store within the same period. One report is noise; a cluster is a finding.
Guide · Checkout skimming
Checkout skimming steals card data while every order still succeeds.
Customers are reporting card fraud, and the only place they all shopped is your store. The site works, orders complete, the gateway settles — because a skimmer does not interrupt the sale. It copies what the customer types at checkout and sends it to a third party, alongside a checkout flow that remains fully functional. This guide covers how skimming works on WooCommerce, the signals that reveal it, and what a defensible response looks like.
Published Last reviewed
- Symptom
- Card fraud reports clustering around your customers
- Technique
- Injected JavaScript or forms at checkout (Magecart-style)
- Why it hides
- Orders succeed — nothing visibly breaks for anyone
- Stakes
- Customer cards, breach obligations, gateway and PCI standing
How it works
The skimmer runs beside your checkout, not instead of it
Web skimming — the technique family often called Magecart — injects JavaScript into checkout pages that reads card number, expiry, CVC, and billing fields as the customer types, then posts them to attacker infrastructure. The legitimate payment still goes through, so conversion, refund, and error metrics all stay normal.
Stores using hosted payment fields or full redirects (Stripe Elements iframes, PayPal redirect flows) are harder targets but not immune: attackers overlay fake card forms before the real one, swap the gateway flow for a lookalike, or harvest the billing details that WooCommerce itself collects. The store’s own pages are the attack surface, whatever the gateway.
Discovery is usually external — a cluster of fraud reports, a processor inquiry, or a bank tracing compromised cards to their common merchant. By then the skimmer has typically been running for weeks, which is why treating the first credible report seriously matters.
Signals
What a skimmed store looks like from the inside
Unexpected script sources at checkout
Requests to domains you cannot attribute to your theme, plugins, or gateway — often lookalike names (stripe-cdn, googie-analytics) or recently registered domains.
Modified checkout templates or assets
Changed file timestamps or diffs in checkout-related theme files, gateway plugins, or minified scripts that no deployment explains.
Injected content in the database
Script tags stored in options, order pages, or widget content that load only on checkout paths.
A second “card form” in the flow
Customers asked for card details twice, or a card form appearing where the gateway normally shows an iframe or redirect.
Conditional behavior
Skimmers often activate only for real visitors — not for logged-in admins, known office IPs, or automated scanners.
Confirm safely
Verify like an investigator, not like a shopper
- 01
Preserve evidence first
Snapshot the site files and database, export access logs, and record dates from the fraud reports before touching anything.
- 02
Walk a test checkout with the network tab open
From a clean browser profile and non-office network, watch every request the checkout makes and attribute each domain. Do it on mobile as well — conditional skimmers discriminate.
- 03
Diff the store against known-good sources
Compare core, theme, and plugin files against pristine copies; review recently modified files and anything in uploads that executes.
- 04
Check the database for injected script
Search options, posts, and widget content for script tags and encoded payloads that render on checkout pages.
- 05
Do not announce before you understand
Communicating a breach badly creates its own damage. Establish what ran, since when, and what data was exposed — then meet the obligations that follow.
Response and duties
A skimming incident carries obligations a defacement does not
Once skimming is confirmed, the response is an incident response: remove the injection and every persistence layer, rotate credentials, close the entry path, and verify the checkout serves only attributable code to every visitor class. The store’s payment processor should be involved — they see the fraud pattern from the other side, and gateway credentials and webhooks may need rotation.
Data-breach notification duties depend on jurisdiction and card-brand rules, and are triggered by exposure of payment data regardless of whether your business ever “stores” cards. Document the incident timeline and exposure window carefully; that record is what regulators, processors, and insurers ask for. This guide is engineering guidance, not legal advice — a store with confirmed card exposure should get both.
Common questions
Common questions about checkout skimming
We use Stripe with hosted fields — can our checkout still be skimmed?
The hosted iframe protects what is typed inside it, but the surrounding page is yours. Overlay forms, swapped flows, and billing-field harvesting all work against stores with hosted fields, so the store’s own code and checkout behavior still need review.
Will a malware scanner find a skimmer?
Often not. Skimmers are small, obfuscated, frequently loaded from external domains, and conditional about when they run. Absence of scanner findings is weak evidence against a cluster of real-world fraud reports.
Do we have to tell our customers?
If card data was exposed, notification obligations typically apply — to affected customers, your processor, and in some jurisdictions a regulator. Scope and deadlines vary; establish the exposure window first and take proper advice on the duties that attach to it.
How do we prevent it from happening again?
Minimize and update checkout-touching plugins, restrict who can modify code, monitor file integrity and the script domains your checkout loads, and audit the store periodically. The WooCommerce audit reviews checkout integrity, business logic, and the recovery controls that limit the next incident.