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

Woocommerce Business Critical Compromise

Protecting Recent Orders During Emergency Store Recovery

Protect recent WooCommerce orders during hack recovery by freezing writes, preserving both databases and reconciling payments, stock and fulfilment.

Emergency restoration can secure code while losing orders created after the chosen backup. Keeping checkout live during parallel rebuild can also create two diverging databases and duplicate fulfilment.

Freeze the transaction boundary, preserve every state and assign one authoritative reconciliation process.

Define the incident and cutover windows

Record first credible compromise, checkout containment, backup date, recovery-build start and planned cutover. Use one timezone.

Identify the last order present in each database and provider. Do not use sequential order numbers alone; extensions and deletions can create gaps.

Name the person responsible for order reconciliation.

Pause new writes

Disable checkout/account-changing actions or serve static maintenance while data is frozen. If the business must continue, use an approved external/manual channel with explicit process.

Do not allow old and new stores to accept orders simultaneously unless a tested synchronisation architecture exists.

Record any orders already in payment flow.

Handle orders already in checkout

At containment, some customers may have payment authorisation but no WooCommerce success response. Identify provider sessions/events around the exact cut-off and avoid asking them to resubmit.

Use provider state and order/session reference to decide whether to recreate, cancel or contact the customer. Do not capture a second payment merely because no order is visible.

Record abandoned carts only when the site’s privacy process permits it.

Preserve all relevant sources

Snapshot current and backup databases, WooCommerce logs, Action Scheduler, mail, payment-provider events, ERP/shipping/accounting records and webhooks.

Store exports securely outside web roots. Avoid emailing customer data or full webhook payloads.

Record WooCommerce storage model and extension versions.

Use payment provider as financial evidence

For each recent transaction, retain provider ID, amount, currency, status, timestamps and authorised reference. Check captures, failures, refunds, disputes and payouts.

Provider payment evidence does not contain every product/order detail, but it prevents paid transactions from disappearing silently.

Never charge or refund again simply to make systems align.

Preserve order relationships

Orders depend on items, product/variation IDs, taxes, coupons, customer, notes, downloads, subscriptions/bookings and stock. HPOS and extensions may distribute these across several tables.

Use supported WooCommerce import/export/migration paths and test mappings. Do not copy a handful of rows with improvised SQL.

Keep old/new ID mapping where IDs change.

Reconcile fulfilment and stock

Compare warehouse/shipping/digital-access and staff records. Confirm whether each order was picked, shipped, downloaded, subscribed or refunded.

Avoid reducing stock or sending fulfilment twice. Assign an authorised status and document every manual adjustment.

Protect customer addresses and order notes.

Control messages and automations

Disable customer/staff emails, CRM, accounting and webhooks during trial import. Record what already fired from the old site.

After orders are correct, enable and send only necessary communications. Do not bulk-run scheduled actions until side effects are understood.

Use synthetic tests before live reconciliation.

Protect downloadable and subscription access

Recent orders may grant downloads, memberships, licences or renewals outside normal fulfilment. Compare those systems with provider and order evidence.

Restore legitimate access without issuing duplicate licence keys or renewal charges. Revoke attacker-created entitlements through the owning system’s audit process.

Import into the clean build

Bring only validated order/customer/product relationships from the incident database. Keep untrusted users/options/cron/snippets/code excluded.

Test on an isolated copy and compare counts/totals with provider and fulfilment records. Review privacy/legal retention before temporary exports.

Preserve an audit trail of source and transformation.

Verify before reopening

Sample every payment/status type, compare total captured/refunded amounts, stock, taxes, customer accounts and emails. Place sandbox orders and test webhooks.

Monitor duplicates and exceptions after cutover. Keep safe maintenance rollback available.

Request urgent order recovery when paid transactions span backup boundaries. Share IDs through secure channels—never card data, complete customer exports, credentials or compromised databases 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