# Credit card skimmer on your website: how to detect it

> How credit card skimmers work on WooCommerce and PrestaShop checkouts, where they hide, why owners miss them and what to do if you suspect one.

URL: https://webintacta.com/en/guides/credit-card-skimming-online-store
Language: English (Spanish version: see the hreflang alternate of the HTML page)
Last updated: 2026-10-28

**In short:** A skimmer is code that copies your customers' card details at checkout and sends them to a third party while the store keeps selling as usual; it is usually discovered when the bank or the payment provider asks about fraud. It hides in JavaScript, in modified payment modules or templates and in the database, and it is built so the store owner does not see it. On PrestaShop, check the theme's templates (especially the shared header) and the payment modules first. A skimmer is also a data breach: if your store is subject to the GDPR, it must be reported to the data protection authority within 72 hours.


By Jose Soriano (WebIntacta) · published 2026-10-24

A skimmer is a piece of code that copies your customers' card details while they pay and sends them to a third party. The store keeps selling as usual, orders come in and the money arrives. Usually you find out weeks later, when the bank or the payment provider asks you why so many defrauded cards were used to buy on your website.

## How a skimmer works

There are two variants, and it is worth knowing both because they are detected differently:

- **Form reader.** If your payment provider asks for the card on your own page (an embedded form), the skimmer is a JavaScript that reads those fields as they are typed or when the customer clicks “Pay”, and sends a copy to a server controlled by the attacker. The payment goes through: the customer notices nothing.
- **Fake form.** If your payment provider redirects to its own page or uses an iframe the skimmer cannot read, the attacker draws **their own card form** on your checkout. The customer enters the details, gets an error, and then the real payment appears. This is what PrestaShop described in the [July 2022 campaign](https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/): a fake payment form injected into the checkout.

The data is sent out in disguise: requests to domains with names that imitate analytics or CDN services, data encoded inside an image request, or stored on the server itself to be collected later.

## How it gets into the store

Almost always through the same door: **a module or plugin with a known flaw**. For PrestaShop, Friends of Presta states explicitly in several advisories that the flaw has been used to install skimmers at scale, for example in `stripejs`, `supercheckout`, `simpleimportproduct`, `leoblog` or `jmsmegamenu`. I keep the list in [vulnerable PrestaShop modules](https://webintacta.com/en/guides/vulnerable-prestashop-modules). On WooCommerce the pattern is the same, with WordPress plugins.

The other usual ways in are stolen admin or hosting passwords, and compromised third-party scripts (a chat widget, a pixel or a library you load from elsewhere and that someone modifies at the source).

## Where it hides

### Credit card skimmer in PrestaShop: where to look

- **Theme templates**: the checkout ones (`themes/your-theme/templates/checkout/`) and the shared header, `templates/_partials/head.tpl`, which loads on every page. According to [Sansec](https://sansec.io/research/global-retailer-prestashop-hacked), PrestaShop issued a security alert in January 2026 asking merchants to check their theme template files for injected skimmers, and Sansec recommends checking `_partials/head.tpl` in particular. Any `<script>` there that you cannot trace to your theme or a module you installed needs explaining.
- **Core files** involved in the order, such as `classes/Cart.php` or `classes/PaymentModule.php`, or a new **override** in `override/`.
- **A module** hooked to `displayHeader` or to the payment hooks, sometimes with a name that imitates a legitimate one.
- **The database**: a `<script>` stored in `ps_configuration` or in an HTML block module, rendered on every page or only on the order page.

After replacing infected templates, clear PrestaShop's caches (`var/cache/` on 1.7 and later) and any CDN or object cache: a compiled copy of the old template can keep serving the skimmer after the source file is clean.

### In WooCommerce

- **The `wp_options` table**: scripts stored in theme or plugin options that let you add custom code to the header or footer.
- **The theme's `functions.php`** or a fake plugin, often in `wp-content/mu-plugins/`, which does not appear in the normal plugin list.
- **Legitimate JavaScript files** from the theme or a plugin with a few lines added at the end.
- **Content of posts, widgets or blocks** loaded on the checkout page.

## Why the store owner does not see it

Skimmers are built to stay hidden from the people who could remove them:

- They only activate on the **checkout page**, which the owner almost never goes through end to end.
- **They do nothing if there is an admin session** or if they detect the browser's developer tools are open.
- Many run **only once per visitor** (they store a marker) or only in certain countries.
- The code is **obfuscated**, split into pieces or loaded from the database, so it does not show up when you search the theme files.
- In PrestaShop, several advisories explain that the initial attack **hides the module path**, and the logs only show `POST /`.

## How to detect it

1. **Make a test purchase like any customer**: from a browser with no session, in a private window, on a phone if you can. Watch for a card form that should not be there, an extra step or an error before the real payment.
2. **Look at the checkout requests**: with `F12` → **Network** open before you reach the payment step, check which domains the page connects to. Every domain needs an explanation: your payment provider, your analytics, your CDN. One you cannot place needs investigating.
3. **Compare the scripts** loaded on the checkout with those of an old copy or of the home page: anything that only appears at checkout is suspicious. The [free scan](https://webintacta.com/en/free-website-security-scan) lists the external scripts on the home page and the visible versions of modules and plugins with published flaws.
4. **Check file integrity** against the original files for your version, and search for `<script` in the database configuration and content. The queries are in the [hacked PrestaShop](https://webintacta.com/en/guides/prestashop-hacked-what-to-do) guide.
5. **Pay attention to outside signals**: customers telling you about strange charges after buying, or the payment provider or bank asking about fraud on cards that have your store in common.

For ongoing monitoring, the card industry standards ask for it explicitly. Since March 31, 2025, PCI DSS 4.0 requires, in requirements 6.4.3 and 11.6.1, keeping an inventory of the scripts on the payment page, authorizing them, and having a mechanism that alerts you to changes on that page. According to the [PCI Security Standards Council](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a), merchants that use an embedded payment form must be able to confirm that their site is not susceptible to script attacks. Your payment provider will tell you which questionnaire applies to you.

A technical measure that helps a lot is a **Content-Security-Policy** header that only allows loading scripts from, and sending data to, the domains you choose. Start in `Content-Security-Policy-Report-Only` mode to see what would break before enforcing it.

## First steps if you suspect a skimmer

1. **Disable the affected payment method**, or put the store in maintenance mode. Every order with the skimmer active is one more card.
2. **Take a full copy** of the current state, logs included, before cleaning. It is the evidence of what happened and since when.
3. **Tell your payment provider or acquiring bank**: they have procedures for these cases and may ask you for a report.
4. **Change the passwords** for the back office, hosting, database and payment provider account.
5. **Clean up and close the way in**: removing the code is not enough if the vulnerable module is still there. Step by step in [how to recover a hacked website](https://webintacta.com/en/guides/recover-hacked-website).
6. **Work out the window**: since when the skimmer was there and how many orders went through checkout in that time. You will need it for the bank and for the notification.

## Notification obligations

Your customers' card details, names, addresses and email addresses are personal data. A skimmer is almost always a **data breach** with a high risk for the people affected. If your store is subject to the GDPR (EU), you must report it to your data protection authority without undue delay and, where feasible, within 72 hours of becoming aware of it, and tell the affected customers when the risk is high. The UK GDPR sets the same deadline for reports to the ICO; in the US, state breach notification laws apply depending on where your customers live. I explain it step by step in [data breach in your online store: what to do in 72 hours](https://webintacta.com/en/guides/online-store-data-breach-gdpr).

> This is not legal advice. For the legal side, rely on your lawyer or data protection officer; I handle the technical side: what data, since when and how they got in.

## If you want me to check it

Cleaning up a PrestaShop or WooCommerce store costs €349 excluding VAT ($349 outside the EU) and includes checking the checkout for skimmers and fake forms, modified overrides and templates, and guidance on notifying the breach. If you need it prioritized over other work: +€100. To prevent it, the store security report (€169) checks the payment flow even when there are no symptoms. More in [hacked PrestaShop repair](https://webintacta.com/en/hacked-prestashop-repair) and [WooCommerce security](https://webintacta.com/en/woocommerce-security).

## Sources

- [PrestaShop: notice about the July 2022 campaign](https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/).
- [Friends of Presta: module security advisories](https://security.friendsofpresta.org/).
- [PCI SSC: changes to SAQ A and requirements 6.4.3 and 11.6.1](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a).
- [Sansec: global retailer's PrestaShop store hacked](https://sansec.io/research/global-retailer-prestashop-hacked) (February 20, 2026; cites PrestaShop's January 2026 alert about skimmers in theme templates).
- [Regulation (EU) 2016/679, GDPR, Articles 33 and 34](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679) (EUR-Lex).

## Frequently asked questions

### How do I know if card details are being stolen on my online store?

Make a test purchase without being logged in and use the browser's developer tools to check which domains the checkout page connects to. The typical outside signals are customers with strange charges after buying and warnings from the payment provider or the bank.

### If my payment provider redirects to its own page, am I safe?

Not entirely. The skimmer cannot read the provider's page, but it can draw a fake form on your checkout before the redirect. That is the variant used in the 2022 campaign against PrestaShop.

### What is Magecart?

It is the name used for the groups and attacks that inject skimmers into online stores. It started with Magento (what to watch on that platform is in [Magento security](https://webintacta.com/en/magento-security)), but the same kind of attack hits PrestaShop, WooCommerce and any other platform.

### Do I have to tell my customers?

If card or personal data has been exposed, the risk is usually high and the GDPR requires telling the people affected, as well as notifying the data protection authority. Decide it with your lawyer, with the technical report in front of you.

### Can a security plugin detect a skimmer?

Sometimes, if it matches a known signature. But many skimmers live in the database or obfuscated inside legitimate files and only act at checkout, so the checkout is worth checking specifically.

## About the author

[Jose Soriano](https://webintacta.com/en/about): Full-stack developer specialized in PrestaShop, WordPress and WooCommerce, who has passed the official PrestaShop course and exam. He has been building online stores and modules since 2023 and is the founder of WebIntacta, the website security service through which he scans, cleans and maintains small-business websites and online stores himself, remotely from Ibi (Alicante, Spain). WebIntacta facts: https://webintacta.com/en/about#datos