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

Backups Restoration Verification

A Backup Restores the Site but Removes Recent WooCommerce Orders

Recover recent WooCommerce orders after an emergency restore by reconciling database snapshots, payment events, stock and customer notifications.

Restoring an older WooCommerce database rewinds orders, users, stock, coupons and settings together. The payment provider may still show successful charges that the restored store no longer knows about.

Stop new checkout activity, preserve both database states and reconcile transactions before fulfilment resumes.

If paid orders disappeared after a restore, start with the missing time window rather than another restore. Our WooCommerce recovery assessment can separate missing records, an order-storage mismatch and payment callbacks before defining the intervention.

Are orders lost or just missing from the dashboard?

  • The database really went backwards. Orders created after the backup may be absent. Preserve the later snapshot, if available, and compare it with payment and fulfilment evidence.
  • The active order store changed. Records may exist in HPOS tables or the legacy store while the dashboard reads the other store. Establish which tables were authoritative before and after the restore; do not switch storage or synchronise speculatively.
  • The payment completed without a usable order. A captured charge needs investigation against checkout and gateway records. Retrying the payment or forcing a paid status does not reconstruct the basket.

Check the order search, date and status filters too. A dashboard count alone cannot distinguish deletion, a storage mismatch or a payment integration failure.

Contain further divergence

Pause checkout or serve controlled maintenance while orders are reconciled. Keep the restored store from sending automatic status emails or webhooks that conflict with payment records.

Do not ask customers to pay again. Notify fulfilment staff that the dashboard is incomplete and name the temporary authoritative order list.

Record restore and containment times.

Preserve pre- and post-restore data

Obtain the database snapshot taken immediately before restore if available, plus the backup now running. Preserve web, payment/webhook, mail and Action Scheduler logs.

Store exports securely outside public paths. Do not run broad imports on the only copies.

Record WordPress table prefix and WooCommerce storage mode/version.

Define the missing window

List the last order present in the restored database and the first known transaction after that point. Use timestamps in a common timezone.

Compare payment provider charges, WooCommerce/webhook logs, administrator emails and shipping/ERP records. A provider charge does not prove the final WooCommerce order content, but confirms money movement.

Protect card/customer data during comparison.

Account for order storage

WooCommerce can use HPOS order tables or legacy posts/postmeta. Confirm the active storage and compatibility settings for each preserved snapshot, not just the WooCommerce version or the presence of tables. Extensions can keep additional subscription, booking or invoice records.

The official HPOS documentation distinguishes authoritative working tables from backup tables. Synchronisation copies pending changes from the authoritative store; it is not an independent historical backup and may propagate deletions. Do not use it as a blind recovery command.

Do not copy only posts rows. Validate order items, addresses, notes, taxes, coupons, refunds and extension relationships through WooCommerce-compatible recovery tooling on an isolated copy.

Reconcile payments and refunds

For each missing transaction, record provider transaction ID, amount, currency, status and authorised customer/order reference. Check captures, failures, partial refunds and disputes.

Never change provider status to match WordPress cosmetically. Recreate/import an order only through an audited process that does not charge again.

Coordinate with the payment provider for unclear webhook history.

Reconcile stock and fulfilment

Determine whether inventory was reduced, items shipped, digital access granted or subscriptions activated. Avoid applying stock reduction twice.

Use warehouse/ERP/shipping records as independent evidence. Assign one owner to approve each recovered order’s fulfilment state.

Document manual adjustments and customer communication.

Preserve customer and accounting references

Maintain original provider transaction IDs, invoice numbers, tax evidence and customer-visible order references. If internal order IDs change, create an audited mapping.

Do not fabricate a paid status without provider evidence or silently renumber legal documents. Coordinate accounting exports and refund workflows with their owners.

Check subscriptions/bookings separately because one missing parent order can affect future scheduled events.

Import without reintroducing compromise

Extract only validated business records from the later compromised database or provider sources. Do not overwrite clean users/options/plugins/cron with a wholesale database restore.

Test the import on an isolated copy, maintain old-to-new order/transaction IDs and preserve audit notes. Scan customer uploads if orders include files.

Keep malicious indicators and privileged records excluded.

Control notifications and automations

Disable automatic emails, CRM/webhooks and accounting sync during test import. Once order states are correct, send only necessary communications and prevent duplicates.

Check scheduled actions tied to missing orders. Do not bulk-run a stale queue before mapping side effects.

Record what customers already received.

Review privacy and retention obligations before copying customer/order data between incident and clean databases. Limit access and securely remove temporary exports.

Verify before reopening

Compare order counts/totals with payment records, inspect samples and confirm stock, tax, refunds, users and fulfilment. Place a sandbox test order and verify checkout/webhooks/mail.

Monitor for duplicates and reconciliation exceptions. Retain evidence under incident policy.

Request urgent WooCommerce recovery when paid orders disappeared. Share order/transaction IDs through secure channels—never card details, customer exports, credentials or compromised databases publicly.

What if there is no later database backup?

A payment reference may establish a charge, amount and currency without preserving products, delivery details, discounts or consent. Administrative emails, shipping systems and accounting records may fill some gaps; assess their completeness before rebuilding anything.

Mark unresolved fields as unknown and agree the next check with the store owner. Complete recovery cannot be promised when the required records no longer exist. Request an assessment of the missing-order window before choosing an import method.

What to send for a WooCommerce recovery assessment

Start with the store URL, restore time and timezone, backup date, approximate missing-order count and whether checkout is currently paused. Say which snapshots and payment or fulfilment records are available; a description is enough for the initial request.

Ask for a scope covering evidence preservation, storage-mode verification, a reconciliation plan, an isolated trial, duplicate-charge and notification controls, and acceptance checks before reopening. Availability of source records determines what can be recovered; the assessment comes before a recovery commitment.

Request a missing-order recovery assessment. Do not attach customer exports, payment-card data, passwords or a compromised database to the public form. Agree a secure route if detailed evidence is needed.

To review the recovered records with the business owner, use the WooCommerce order reconciliation worksheet after a hacked-site restore. It connects payments, recoverable order details, existing fulfilment and unresolved decisions.

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↗