After a hacked-store rebuild, security verification and business verification must meet. A store can be free of the known redirect yet calculate tax incorrectly, duplicate webhooks or expose another customer’s account data.
Use synthetic identities, payment sandbox and a written pass/fail matrix.
Prepare isolated test data
Create dedicated test customer, products/coupon and controlled email addresses. Label every order and prevent sales/fulfilment/accounting from processing it.
Do not use real card data or random phone/email addresses. Configure sandbox/test payment keys and disable live captures.
Record expected totals and routes.
Test cart isolation
Add, update and remove simple/variable products as guest and logged-in user. Verify sessions/cookies and page cache do not expose one user’s cart to another.
Test mobile, language/currency variants and back navigation. Inspect console/network for unknown scripts or domains.
Confirm stock constraints and quantity limits.
Test catalogue and product integrity
Check product/variation prices, sale schedules, tax classes, stock, downloadable files and purchase limits against business records. Review unknown products/coupons created during the incident.
Do not assume a clean checkout template means catalogue data is trustworthy. Record and approve every manual correction.
Test checkout calculations
Verify billing/shipping validation, tax, shipping methods, coupon, fees, currency rounding and consent. Compare browser totals with WooCommerce order and provider amount.
Test allowed uploads/notes only with synthetic content. Ensure errors are clear and do not create an order/payment prematurely.
Check cache/WAF/CAPTCHA behaviour.
Test payment outcomes
Use provider sandbox cases for success, decline, cancellation, authentication challenge and timeout/retry. Confirm official hosted domains and no unknown checkout code.
Verify one charge/transaction per intended order, correct status/notes and no duplicate side effects after refresh or webhook retry.
Test refunds through the approved sandbox flow.
Test webhooks and queues
Confirm signature verification, endpoint TLS, retries and idempotency. Review Action Scheduler/WP-Cron for failed or delayed jobs.
Deliver duplicate/out-of-order sandbox events and verify final order state follows provider logic without duplicate stock/email.
Test subscription/booking actions separately.
Test failure and recovery paths
Simulate validation rejection, payment decline, webhook delay, browser refresh and network retry in sandbox. Confirm the customer sees truthful status and can resume safely without duplicate order/charge.
Verify support can locate a transaction by approved references when WooCommerce and provider status differ.
Test order operations
Check administrator new-order visibility, search/filter, status transitions, stock reduction/restoration, invoice/shipping/ERP and refunds. Confirm recent recovered orders remain intact.
Do not bulk-run old incident actions. Record each synthetic order/transaction ID for cleanup.
Compare accounting/fulfilment only in test channels.
Test customer accounts
Verify registration, login/logout, password reset, MFA where applicable, order history, addresses, downloads and account deletion/export workflows.
Confirm one test user cannot access another’s order/download. Review roles, application passwords and sessions.
Do not expose security tokens in analytics or logs.
Test transactional email and analytics
Verify customer/staff emails, Reply-To, provider acceptance and final mailbox. Ensure no spam queue or unknown recipient remains.
Confirm analytics records checkout/order success only after server/payment confirmation, once, with consent behaviour and no personal/order field data.
Remove/filter QA conversions.
Confirm operational ownership
Assign owners for payment alerts, failed scheduled actions, order mismatch, file changes and customer reports. Set critical thresholds and an independent escalation channel.
Document when temporary sandbox users, test orders, allow rules and responder access will be removed. Monitoring without a named response owner is not an acceptance control.
Re-run incident indicators
Test original referrer/mobile/first-visit redirect conditions, cron cycles, cache warm-up and checkout script/network allowlist. Monitor file/database/user changes during tests.
Confirm no unknown DNS/CDN/tag-manager/payment administrators or secrets remain and backups restore cleanly.
Request independent post-recovery review for payment-page incidents. Share the test matrix and redacted IDs—never card data, secrets, customer records or malware publicly.