A fake payment redirect is an active customer-safety incident. It may originate in WordPress, tag manager, CDN rules, DNS or a compromised payment/plugin account. Hiding the link on one browser does not make checkout safe.
Stop transactions, preserve the redirect chain and involve the payment/incident owners immediately.
Take checkout offline
Disable checkout/payment at a trusted hosting/CDN/provider layer or serve static maintenance outside WordPress. Block account sessions if the page could steal credentials.
Do not ask customers to retry, use another real card or visit the fake destination. Never submit payment data for testing.
Record containment time and affected payment methods.
Preserve the redirect chain
From an isolated environment, record source checkout URL, timestamps, response statuses, script/frame/form destinations and safe screenshot. Capture browser network domains without entering data.
Do not publish malicious URLs or upload scripts to public tools. Store evidence securely with limited access.
Note whether the redirect depends on referrer, mobile, first visit or cart value.
Locate the control layer
Determine whether redirect occurs as HTTP status, JavaScript/form action, iframe or payment-provider handoff. Compare origin versus CDN response through authorised access.
Inspect WordPress files/database, .htaccess/server rules, tag-manager versions, CDN workers/redirects and DNS. A clean plugin directory cannot rule out external compromise.
Preserve audit events before correction.
Secure payment accounts
Review gateway/provider administrators, API keys, webhooks, payout details and recent configuration. Revoke unknown access and rotate exposed keys through the provider’s incident process.
Do not paste keys or payment logs into ordinary tickets. Confirm whether provider-side hosted pages/domains are the expected official values.
Use MFA and named accounts.
Check checkout code provenance
Inventory every script loaded on cart/checkout: payment, fraud, consent, analytics, chat and custom code. Confirm owner, domain and approved deployed version.
Review tag manager, custom snippets, theme checkout hooks and plugin updates. Preserve suspicious code without executing or decoding it on production.
Remove unowned third-party code from the clean build.
Inspect session and content-security controls
Review checkout cookies, CSP reports/policy, subresource integrity where used and iframe/form-action restrictions. Preserve violation reports and deployment history.
A stronger CSP can limit future injection but should be tested with official payment/challenge domains. Do not deploy an untested deny rule that silently breaks payment.
Keep report endpoints free of card/form values.
Assess orders and possible exposure
Define the incident window and identify customers who reached checkout, redirects, failed orders and provider events. Use logs/analytics cautiously; they may not prove data entry or exfiltration.
Coordinate legal/privacy/payment-industry assessment and customer communications through authorised owners. Do not claim no card exposure because WooCommerce stores no card number.
Protect customer data in evidence.
Rebuild from trusted components
Create a clean root with verified WordPress/WooCommerce/gateway code, validated customisations and assessed database/uploads. Close the entry vector and rotate hosting, database, WordPress, CDN/tag and payment secrets.
Keep infected roots isolated. Do not update over the top and reopen.
Remove unsafe staging and shared credentials.
Plan customer and provider monitoring
Monitor the fake destination/domain, checkout network allowlist, payment failures, new scripts and customer reports after recovery. Alerts should go through an independent channel.
Coordinate removal/blocking reports with hosting, registrar, browser/search and payment providers where authorised. Do not interact with the malicious operator directly.
Retain indicators for recrawl/review without keeping checkout exposed.
Test without real payment data
Use payment sandbox/test modes and synthetic customer details. Confirm expected checkout domains, CSP/network list, order/payment states, webhooks, refunds and emails.
Test direct/search/mobile/first-visit conditions and cache warm-up. Obtain payment owner approval before production.
Request emergency response immediately for fake payment pages. Share managed access and redacted redirect evidence—never card data, API secrets, customer exports or malicious code publicly.