WooCommerce Checkout Broken After an Update: 30 Minute Fix Checklist

If your WooCommerce checkout broke right after an update, the fastest safe fix is usually to roll back the one thing that changed, then find the real cause on staging. Before you roll back, spend five minutes reading the fatal-errors log in WooCommerce > Status > Logs, because it often names the exact plugin and line. The checklist below gets most stores taking orders again within 30 minutes.

Minute 0-5: What exactly is broken?

Do not start deactivating plugins yet. First, describe the failure precisely, because different symptoms point to different causes.

• Open the checkout in a private browser window, logged out, with a real product in the cart.
• Try every payment method you offer, not only the main one.
• Open the browser console (F12, Console tab) and note any red JavaScript errors.
• Check WooCommerce > Orders for new orders stuck in "Pending payment" or "Failed".
• Write down what was updated, and when. Plugin, theme, WooCommerce core, WordPress core, or the PHP version on the server.

This table maps common symptoms to the first place to look.

Symptom	Most likely cause	First check
White screen or "critical error" on checkout	PHP fatal error in a plugin or theme	fatal-errors log
Checkout loads, button spins forever	JavaScript error or blocked AJAX/API request	Browser console, network tab
Payment form fields missing	Gateway script not loading, often minified or deferred	Console, cache and JS optimisation settings
Customer is charged but order stays "Pending payment"	Payment webhook not reaching the store	Gateway webhook status and delivery logs
Works for you, fails for customers	Cached checkout page or cached session	Cache plugin, CDN and host cache rules
Layout broken, fields in wrong places	Outdated template override in the theme	Templates section in WooCommerce > Status

Minute 5-10: Read the logs

WooCommerce logs

Go to WooCommerce > Status > Logs and open the most recent file whose name starts with fatal-errors. WooCommerce's PHP error log guide explains that it records the time of the error, the error message, the file and line, and a stack trace.

The file path tells you which plugin or theme failed, for example wp-content/plugins/some-plugin/. That is usually your answer.

Also open the log source for your payment gateway, if it has one. Gateway logs often show API errors such as invalid keys or rejected requests. WooCommerce can store logs in files or in the database. The setting is on the same Logs screen under Settings, as described in the WooCommerce logging docs.

WordPress debug log

If the WooCommerce log is empty, enable the WordPress debug log. Add these lines to wp-config.php, above the "That's all, stop editing" line. This follows the WordPress debugging documentation:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors go to wp-content/debug.log and are not shown to visitors. WordPress recommends against debug mode on live sites, so turn it off when you are done. You can also point WP_DEBUG_LOG to a file path outside the public web root, which we prefer on production. Your host's PHP error log (in the hosting panel) is another good source.

Minute 10-15: Roll back what changed

If the log points to a specific plugin, or the timing clearly matches one update, roll that plugin back. Keeping checkout working matters more than finding the perfect fix now.

• Free plugins from wordpress.org: WooCommerce's FAQ recommends the WP Rollback plugin for its public extensions.
• With WP-CLI: install a specific version over the current one with wp plugin install plugin-slug --version=X.Y.Z --force. The --version and --force options are documented in the WP-CLI handbook.
• Premium WooCommerce extensions: the FAQ says to open a support request for a prior version. Keep previous zip files from your own update process so you do not depend on this in an emergency.
• Whole-site restore: use this only if you cannot identify the culprit, and only if you understand the cost. Restoring a database backup loses every order placed since the backup was taken.

Be careful with WooCommerce core itself. A WooCommerce update can run database updates, as noted in the update guide. Downgrading core after a database update is riskier than rolling back an extension. If WooCommerce core is the suspect, prefer rolling back the extension that conflicts with it, or restore on staging first.

After any rollback, place a real test order immediately.

Minute 15-20: Run a conflict test without breaking the live site

If there is no clear culprit, you need a conflict test. WooCommerce's conflict testing guide recommends doing it on a staging site. There, switch to a default theme such as Twenty Twenty-Five or Storefront and deactivate all plugins except WooCommerce and the extensions involved. Then reactivate plugins one at a time, testing checkout after each.

If you have no staging site, the Health Check & Troubleshooting plugin has a Troubleshooting mode. It gives you "a clean WordPress session, where all plugins are disabled, and a default theme is used, but only for your user". Customers keep seeing the normal site. Two cautions: at the time of writing the plugin was last updated in 2024, and some reviews report plugins staying inactive after leaving troubleshooting mode. Take a backup first and check your plugin list afterwards.

Keep your payment gateway and WooCommerce active during the test, otherwise you are not testing the real checkout.

Minute 20-25: Check payment gateway webhooks

"Customer paid, order still pending" is almost always a webhook problem, not a checkout page problem. The gateway charges the card, then calls your store back to confirm. If that call fails, the order never moves on.

For Stripe, WooCommerce's webhook documentation explains that missing webhooks leave orders stuck in pending or on-hold. You can see webhook status under WooCommerce > Settings > Payments > Stripe > Settings by clicking "Configure connection", with separate Live and Test tabs. The same screen has a "Reconfigure webhooks" button. The store's endpoint looks like https://www.example.com/?wc-api=wc_stripe.

For any gateway:

• Open the gateway dashboard and check webhook delivery attempts and their HTTP response codes.
• Look for 403 responses from a security plugin or firewall that started blocking the gateway after an update.
• Check for redirects (HTTP to HTTPS, www to non-www) and maintenance mode, which can make a webhook fail.
• Once deliveries succeed, resend the failed events from the gateway dashboard so stuck orders update.

Minute 25-30: Rule out caching and theme templates

Caching

An update often changes JavaScript files or session behaviour, and a cached checkout keeps serving the old version. WooCommerce's caching guide says cart, checkout and my account pages must be excluded from caching. It also lists cookies that must bypass the cache, including woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_. For WP Rocket, it recommends avoiding JavaScript minification.

Quick actions:

• Purge the page cache, the object cache, the host cache and the CDN.
• Temporarily turn off JavaScript minify, combine and delay features, then test again.
• Confirm checkout is still excluded at every layer, especially a CDN that was added later.

Outdated template overrides

If the checkout looks wrong rather than failing, check WooCommerce > Status, Templates section. It lists files your theme overrides and flags outdated ones. WooCommerce's system status guide notes that switching to Storefront will use the original template files, which is a fast way to confirm the cause.

Also check which checkout you run. The Checkout block has been the default for new stores since WooCommerce 8.3, while older stores often still use the classic shortcode checkout. Some extensions only support one of them, so an update that adds block features can behave differently on each.

The 30 minute checklist

1. Reproduce in a private window with every payment method. Note console errors.
2. Check WooCommerce > Orders for pending or failed orders.
3. List what changed and when.
4. Read the newest fatal-errors log in WooCommerce > Status > Logs.
5. Read the gateway log and, if needed, wp-content/debug.log.
6. Roll back the suspected plugin, not WooCommerce core, if you can.
7. Place a real test order.
8. If no culprit is found, run a conflict test on staging or in troubleshooting mode.
9. Check webhook status and delivery logs in the gateway dashboard.
10. Purge all caches, disable JS optimisation, confirm checkout exclusions.
11. Check outdated template overrides in WooCommerce > Status.
12. Turn debug logging off again.

After the fire is out

Once orders flow again, write down what failed and why, then reproduce it on staging with the new version. Contact the plugin vendor with the log entry. Then fix your update process: updates on staging first, a test order after each production update, and automatic updates disabled for the gateway and checkout plugins.

Also contact customers whose payments were captured but whose orders stayed pending, and match them against your gateway dashboard before you refund or ship anything.

When to get help

If checkout is still down after these steps, or the log points to custom code you cannot safely change, get a developer on it quickly, because every hour costs orders. Our WooCommerce emergency support starts from $250 for the first 2 hours, with triage within 1 hour in European working hours. To avoid the next broken update, a maintenance plan with staging tests before every update is the long-term fix.