A WooCommerce store can look online and still be unable to complete a sale. Recovery has to follow the real customer journey and respect order and payment data, because the same visible symptom can come from the browser, the session, the gateway or order creation.
Step 1 — Read the WooCommerce logs first
Go to WooCommerce › Status › Logs and Status › Tools. Fatal errors, gateway responses and failed webhooks are recorded here with timestamps. The System Status report also flags an outdated database, a template override that is behind, or a plugin conflict — often the fastest route to the cause.
Step 2 — Isolate without gambling with orders
Reproduce the failure with a test product and a sandbox or low-value order — never repeated live card attempts. If you suspect a plugin conflict, test on staging rather than deactivating payment or tax plugins on the live store, where turning them off can break checkout further or lose configuration.
Is your website affected right now?
Send the URL and the symptom you can see. Jordi Ensenyat reviews the case personally and defines the scope and quote before anything is changed. This form never asks for passwords.
Step 3 — Caching is the usual culprit
Cart, checkout and my-account pages must be excluded from full-page caching. A cached checkout is one of the most common causes of a store that loads perfectly but cannot take an order. Confirm your caching plugin, host cache and CDN all bypass those pages, and that no “optimise/минify JavaScript” setting is breaking the checkout scripts.
Step 4 — Reconcile payments and orders
If payments succeed but orders stay on “pending”, the gateway callback (webhook/IPN) is not reaching the site. Check the gateway dashboard for failed webhook deliveries and confirm the callback URL still points at the live domain — a leftover staging URL after a migration is a classic cause. Match paid transactions against orders before changing any status.
Step 5 — Verify the whole cycle
A store is not recovered when the error disappears. Place one controlled order and confirm it is created with the correct status, payment reconciles, stock decreases, the confirmation email sends and the webhook is received. If any step involves customer data or real payments and you are not certain, that is the point to bring in a specialist.
EVIDENCE-LED WORDPRESS RECOVERY
Restore sales without gambling with orders or payments
WooCommerce incidents need both technical and commercial verification. A checkout that appears fixed can still fail on a payment callback, lose a session, duplicate an order or send the wrong stock state. Recovery focuses on the exact sales journey and the data it touches.
What we verify
- Cart and checkout behaviour for the affected device or customer path
- Payment gateway responses, callbacks, webhooks and order creation
- Sessions, taxes, shipping, coupons and transactional email where relevant
- Order integrity, stock movement and logs before and after the repair
What a verified outcome means
The repaired path is tested from product selection through order confirmation using an agreed safe method. Known limitations, test evidence and any gateway or hosting dependency are included in the close-out.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
Can checkout be tested without creating a real charge?+
Usually a sandbox, low-value controlled order or gateway-specific test route can be used. The method is agreed before testing.
Will existing orders be preserved?+
Order data is treated as critical. A backup or rollback route is established and database changes are kept as narrow as the diagnosis permits.
What information helps diagnose a WooCommerce outage?+
The failing step, device, gateway, error text, recent updates and example order times are especially useful. Never send card details.
RELATED INCIDENTS