Unknown checkout code, changed administrator accounts or missing orders after an emergency restore need a recovery plan that covers both the compromise and the trading records. A home page that loads is only one part of that assessment.
Contain the attack before taking more orders
If checkout may expose customers to unknown code, discuss pausing the affected sales route while evidence is preserved. Record the first alert, affected URLs, recent access changes and any restore already attempted. Do not repeat live card payments to see whether the symptom has gone.
The investigation can include files, database content, privileged accounts, scheduled tasks and relevant hosting or deployment access. The affected layers determine the scope; a cache purge alone cannot establish that a compromise has been removed.
Recover the store without blindly rolling orders back
Before choosing a backup, compare its timestamp with the incident and recent trading activity. Identify which order storage was active, which later snapshots exist and which payment or fulfilment records can support reconciliation.
An old database may omit newer orders. Payment records do not necessarily preserve the full basket. Recovery must distinguish validated records from unknown details and avoid charging again, reducing stock twice or replaying customer notifications.
Check payments and orders as separate parts of the journey
A captured payment with a pending or missing order can involve callback delivery, processing errors, an order-storage mismatch or a rollback. The order status alone does not establish which cause applies. Review gateway and application evidence before changing it.
Where the gateway supports it, agree a sandbox test covering order creation, payment callbacks, stock, fulfilment hand-off and transactional email. If a live check is necessary, agree its limits and approval first; do not use customer purchases as an uncontrolled test.
Agree what the recovery will deliver
The proposed intervention should identify containment, evidence preservation, the supported repair, any order-reconciliation work and the checks required before reopening. A restoration and an order import are separate operations with different risks.
Close-out records what was found, what changed, which paths were tested and what remains unresolved. Missing source records can limit recovery. Availability, timing and quote follow assessment; this page does not promise complete order recovery or permanent immunity from another attack.
Request an assessment with the recovery window
Send the store URL, first alert and restore times with timezone, the affected sales journey, an approximate missing-order count and whether checkout is paused. Describe the available snapshots and gateway or fulfilment evidence without uploading the records themselves.
Start with a description, not access details. Do not send customer exports, payment-card data, passwords or a compromised database through the public form. Detailed evidence can be requested through an agreed secure route after the scope is established.
Request a hacked WooCommerce assessment
- What to do when a restore removes recent WooCommerce orders
- Restoring WordPress without restoring the intrusion
EVIDENCE-LED WORDPRESS RECOVERY
Evidence and acceptance checks for the recovery
The assessment connects the suspected compromise with the store functions and records at risk. The agreed scope determines which layers and integrations are reviewed.
What we verify
- Incident and restore timeline, affected URLs and containment already applied
- Relevant code, accounts and persistence within the agreed scope
- Available order snapshots and payment or fulfilment evidence
- Controlled checkout, callback, stock and notification checks
- Documented findings, unresolved records and reopening responsibilities
What a verified outcome means
A close-out distinguishes containment, completed remediation and the evidence supporting the tested sales journey. Unresolved order records, access dependencies and follow-up actions remain explicit. A successful test does not establish that every historical order was recovered.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
Will restoring a backup recover every paid order?+
Not necessarily. A backup predating recent orders can omit them, and payment records may lack the basket or fulfilment details. Available snapshots and independent evidence are assessed before agreeing what can be recovered.
Does a pending order prove the payment webhook failed?+
No. Callback delivery, processing errors, storage changes and a database rollback are possible causes. Gateway and application records must be compared before changing the order status or retrying payment.
Can checkout be verified without a real charge?+
A supported sandbox is preferred for controlled tests. If a live transaction is required for a specific check, its scope and approval are agreed first. A sandbox result has limits and does not prove every production path.
How soon can work start and what will it cost?+
The initial assessment establishes urgency, available evidence, access needs and the proposed work. Availability, timing and quote are confirmed before intervention; sending a request does not itself authorise a charge.