Unknown JavaScript, an unfamiliar payment field or hidden checkout markup can be a legitimate extension change, a tag-manager deployment or a payment-skimming incident. Because checkout handles customer and payment data, treat unexplained code as high risk until its owner and purpose are verified.
Pause unsafe transactions and preserve the exact deployed state before cleanup.
Protect customers immediately
Disable checkout or place the store behind a static maintenance response served outside the untrusted WordPress runtime. If only one payment method is affected and containment is verified, disable that method through a trusted control path.
Do not ask customers to retry or enter test card data. Never submit a real card to determine whether the code steals it.
Notify the payment provider and internal incident owner under their required process.
Preserve checkout evidence
Capture the rendered script URL or inline-code hash, page URL, timestamp, response headers and safe screenshot. Save filesystem, database, web/CDN logs and tag-manager configuration before changes.
Do not paste the full malicious script into ordinary email or execute it in an online decoder. Store evidence in an access-controlled incident location.
Record the first known appearance and recent deployments.
Determine whether the code is authorised
Compare the code with approved payment, analytics, consent, chat and fraud-prevention integrations. Check change tickets, plugin updates and tag-manager versions.
An approved vendor script should have a named owner, documented domain and business purpose. A familiar CDN name alone is not proof; compromised accounts can publish malicious changes.
Keep checkout code to the minimum required suppliers.
Locate the injection layer
Inspect final HTML and network requests to see whether the code comes from a WordPress option/post, theme, plugin, tag manager, CDN worker or server-side auto-prepend.
Compare origin and proxied responses through authorised protected testing. Search database content and widgets, wp_head/wp_footer hooks, active/must-use plugins and executable files in writable directories.
Do not delete the first matching string before finding how it returns.
Review payment settings
Check WooCommerce payment gateways, webhook URLs, API keys, payout/bank details and recent configuration changes. Verify payment-provider administrators and sessions.
Rotate payment API credentials through the provider after evidence is preserved and exposure is assessed. Do not store replacement secrets in tickets or the same compromised browser.
Reconcile payment records with WooCommerce orders independently.
Audit privileged access
Review WordPress administrators, application passwords, hosting users/keys, database accounts, Cloudflare/CDN and tag-manager users. Revoke unknown access and enforce MFA.
Examine audit and deployment logs around the code’s first appearance. Confirm whether a legitimate developer account was compromised rather than assuming the account name identifies the actor.
Check sibling stores sharing credentials or hosting.
Coordinate evidence and notifications with the payment processor or acquiring bank. Their contractual incident requirements may specify logs, timing and forensic handling beyond the WordPress repair.
Do not make unsupported statements to customers about whether payment data was accessed.
Rebuild checkout from trusted components
Replace WordPress core, WooCommerce, plugins and themes from verified sources. Validate custom checkout code line by line and import only assessed content/configuration into a clean environment.
Close the vulnerable component or stolen-access path and rotate related secrets. A scanner removing the visible script is not a recovery.
Keep production contained until validation is complete.
Verify and monitor after release
Test checkout with the payment provider’s sandbox or approved low-risk method. Inspect rendered code, network domains, order creation, payment state, emails, refunds and mobile checkout.
Monitor file/database/tag-manager changes and payment-provider alerts. Follow legal, contractual and payment-industry incident obligations when data exposure is possible.
Request emergency WooCommerce rescue immediately for unexplained checkout code. Provide managed access, timestamps and supplier list—never card data, API secrets or malicious scripts through public channels.