A WooCommerce credit card skimmer is malicious code that captures payment data entered by a customer and sends it somewhere the store did not intend. If you suspect one, restrict checkout exposure, preserve evidence, investigate the live checkout and site files, then contact your payment processor before treating the cleanup as complete.
These attacks are often described as Magecart-style attacks, even though the affected store may run WooCommerce rather than Magento. The important issue is not the label. It is whether JavaScript or a fake payment form is collecting information from your shoppers.
What a WooCommerce payment skimmer does
A payment skimmer runs in the shopper's browser. It can watch fields on the legitimate checkout form, copy values when the customer submits the form, or create a convincing form that looks like part of checkout. The code may send captured data to an attacker-controlled endpoint in the background while the customer still sees a normal confirmation page or a believable error.
This is different from an order-management problem or a fraudulent order. A skimmer puts customer payment information at risk, so it calls for careful incident handling. Avoid making assumptions about which data was accessed until you have evidence from the affected code, request logs, the processor, or a qualified investigator.
If you find a suspected skimmer, do not try to test it with a real card. Take screenshots, record the affected URL and time, and preserve a copy of the site files and database. Consider putting checkout into maintenance mode or disabling online payments while you investigate. The right containment choice depends on your store and payment setup, but continuing to accept payment while suspicious code is active can expose more customers.
Start with the checkout page customers receive
The live, logged-out checkout page is the key evidence. Test from a private browser window so you see the page as a customer does. Open the browser's View Source feature and search for <script tags, unfamiliar inline code, unexpected form actions, and external domains that you cannot connect to the store, its payment processor, its tag manager, or a documented service.
Use the browser Network panel next. Reload the checkout page and filter for JavaScript and Fetch/XHR requests. Watch what happens when you move through checkout with a test product and a payment method that does not expose real card data. Look for requests made on page load and after the checkout form is submitted. Note each request URL, the file that initiated it when the browser identifies one, the request method, and whether it includes form-like data.
An unfamiliar request is a lead, not proof. Payment gateways, fraud tools, analytics, tax services, and chat tools can all make third-party requests. Compare the requests with your documented integrations and with a clean staging site if you have one. A domain that appeared recently, an inline script that you did not add, or a request that follows card-field activity deserves closer review.
Check for a fake payment form too
A skimmer does not always modify the exact WooCommerce card fields. It can add an extra form, alter labels, place a payment overlay over the legitimate checkout, or redirect a shopper to a lookalike page. Compare the checkout form's labels, payment choices, and destination URLs with the configuration in WooCommerce and your gateway dashboard.
Inspect the form elements in browser developer tools. Check where each form submits and whether it has been added by a script after the page loads. Also review the checkout templates in your active theme and child theme, especially custom WooCommerce overrides. An older override may be legitimate, but it can be a place where injected or copied code remains unnoticed.
Ask customer support staff whether customers have reported duplicate charges, strange checkout errors, a payment page that looks different, or a request to re-enter card details. These reports do not prove a skimmer, but they can help establish when a change first appeared.
Where skimming code hides in WordPress
Malicious checkout code needs a way to load on public pages. Check your active theme and child theme first, including functions.php, header.php, footer.php, WooCommerce template overrides, and any custom checkout template. Review recently changed files against a clean copy or your version-control repository.
Check all plugin directories under wp-content/plugins, including inactive plugins. Attackers may use a fake plugin with a generic name, alter a legitimate plugin, or add a small loader that inserts JavaScript into every page. Also inspect wp-content/mu-plugins, since must-use plugins load automatically and can be missed during a dashboard-only review.
The wp_options table is a frequent hiding place for site-wide scripts. Review options belonging to header and footer injection plugins, page builders, tag managers, advertising tools, and custom-code plugins. Look for unexpected script references, long encoded values, or recently changed settings. Examine widgets, reusable content, checkout pages, and other database content that can emit HTML or JavaScript.
Check wp-config.php and unfamiliar PHP files in wp-content/uploads as well. A PHP file in uploads is not a normal WooCommerce extension file and warrants investigation. For a broader file review, see how to find a WordPress backdoor.
Clean up by replacing trusted components
Do not delete a single suspicious line and assume the store is safe. Preserve the suspicious file, option value, and request details in your incident copy. Then replace WordPress core files with clean copies of the same version, and reinstall trusted plugins and themes from their official sources. Do not keep a plugin or theme that you cannot verify, no longer need, or cannot update.
For your own custom theme or plugin, restore the affected code from a known-good repository or clean backup, then reapply only reviewed changes. Remove unauthorized plugins, unknown must-use plugins, fake checkout templates, and injected database values. Review WordPress users, hosting users, scheduled tasks, and any file changes that could reinstall the skimmer.
Update WordPress, WooCommerce, your payment gateway extension, and every retained theme and plugin. Identify and correct the original entry point, such as an outdated extension, a compromised administrator account, or stolen hosting access. The first hour after a WordPress hack article can help you keep the response ordered.
Tell the payment processor and plan notifications
Contact your payment processor promptly through its official support or incident channel. Give it a concise factual timeline: when you learned of the issue, which checkout URLs were affected, what code or requests you found, when you contained checkout, and what remediation is underway. Follow its instructions for preserving data, reviewing transactions, and securing payment integration credentials.
Rotate WordPress administrator passwords, hosting and SFTP credentials, database credentials, API keys, and payment gateway credentials as appropriate to your integration. Make changes from a known-clean device. Document who has access to the WordPress dashboard, hosting, payment processor, DNS, and code repository, then remove access that is no longer needed.
Data-breach notification duties vary by state and by the facts of the incident. Talk to a lawyer about your particular circumstances and do not rely on a general online checklist for legal decisions. Your payment processor, cyber insurer, and counsel may also have requirements about timing and evidence handling.
Reduce the chance of a repeat incident
Keep the store's software current and remove inactive plugins and themes. Limit administrator access, use unique passwords and multi-factor authentication where available, and maintain backups that are separate from the hosting account. Review plugin additions and checkout changes as production changes, not casual dashboard edits.
Periodically inspect a logged-out checkout page and its network requests against your approved integrations. Monitor for unexpected administrator accounts and changed files. A regular security audit can provide a baseline for a store that handles customer payments.
When to get help
Get help if checkout code is unfamiliar, customer payment data may have been exposed, or the suspicious script returns after removal. West Oakbridge can assist with WordPress malware removal and a security audit while you coordinate with your payment processor and advisers.