Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Woocommerce Business Critical Compromise

Restoring a Hacked Store Without Reopening Checkout Too Early

Reopen a recovered WooCommerce store in stages after code, checkout, payment, orders, accounts and monitoring have passed defined gates.

A clean-looking catalogue is not a safe checkout. Payment code, webhooks, accounts, stock and transactional email cross several systems; reopening before they are trusted can expose customers or create inconsistent orders.

Use staged acceptance gates and a maintenance rollback.

Keep checkout independently disabled

Serve catalogue or maintenance only if the rendered pages are verified safe. Disable cart/checkout/account writes and payment-provider routes through trusted configuration.

Do not hide checkout buttons with CSS while endpoints remain callable. Keep search engines from indexing temporary recovery pages.

Record who can authorise each reopening stage.

Prove code and account trust

Rebuild WordPress/WooCommerce/gateway plugins from verified sources, validate custom checkout code and inspect database/uploads. Remove persistence and close the entry vector.

Confirm approved WordPress, hosting, database, CDN/tag-manager and payment users/tokens. Rotate exposed secrets and enable MFA.

Keep infected roots non-executable.

Reconcile orders and payments

Compare WooCommerce orders with provider transactions, refunds, stock and fulfilment during the incident/backup window. Resolve unknown/missing records before accepting new orders.

Assign one authoritative status per transaction and document manual changes. Do not charge or refund to make dashboards match.

Control queued emails/webhooks.

Define explicit go/no-go gates

Require named approval for code/data integrity, account/secret rotation, order/payment reconciliation and sandbox checkout. A failed critical gate keeps checkout closed even when marketing pages work.

Record evidence and unresolved issues. Do not let a deadline silently convert a failed test into acceptance.

Keep a safe maintenance message and customer-support route.

Test cart and pricing

Verify simple/variable products, coupons, tax, shipping, currency, stock limits, guest/customer carts and mobile behaviour. Check cache excludes personalised cart/checkout state.

Use synthetic products/addresses and remove them afterward. Inspect totals at browser, WooCommerce and provider.

Do not expose real customer carts during tests.

Test payment in sandbox

Use provider test mode/sandbox and verify official hosted domains, checkout JavaScript/network destinations, successful/failed/cancelled flows, 3-D Secure where applicable and refunds.

Confirm no production capture can occur. Check order status/notes, transaction IDs and idempotent retries.

Get payment owner approval before live mode.

Test webhooks and background jobs

Verify signatures, endpoint TLS, retry/idempotency and order updates. Review Action Scheduler/WP-Cron for failed/past-due jobs.

Replay only controlled sandbox events until duplicates are ruled out. Test subscriptions/bookings separately.

Do not bulk-run the incident queue.

Test security and privacy controls

Verify CAPTCHA/rate limits, WAF rules, consent, CSP and uploads without weakening checkout. Confirm logs/analytics exclude card/customer fields and reset tokens.

Review administrator/shop-manager roles, API keys and application passwords. Test session revocation and access to order/download pages.

Test accounts and communications

Verify registration/login/reset, roles, customer order history/downloads and session revocation. Test administrator/customer emails through controlled recipients.

Ensure From authentication and mailbox delivery work. Check privacy/consent and that analytics fires after confirmed order.

Remove test users/orders and temporary recipients.

Rehearse emergency shutdown

Before enabling live payment, confirm who can disable checkout at provider/CDN/hosting layers and how quickly. Test the maintenance response without exposing the infected root.

Alert destinations must remain available if WordPress or transactional email fails. Record contacts and rollback commands/settings securely.

Reopen in stages

Enable low-risk browsing first, then accounts/cart, then payment only after all gates pass. Consider a limited product/payment window with active monitoring.

Keep rapid disable switch, rollback and named responder ready. Prevent old and new stores from taking writes simultaneously.

Communicate availability accurately.

Monitor the first live period

Watch checkout scripts/domains, payment/provider events, order-status mismatch, unknown users, file/database changes, outbound mail and original indicators.

Sample live orders without accessing unnecessary personal data. Reconcile exceptions immediately.

Request urgent staged reopening help when custom payment code or recent orders are involved. Share the acceptance matrix and managed access—never card data, secrets or customer exports publicly.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident