WooCommerce Checkout Not Working? Fix It in 2 Minutes

WooCommerce checkout not working is a symptom of why most store owners spend an afternoon deactivating plugins and still cannot say what broke.

The same complaint covers four different failures. A spinner that never stops. A blank page. A Place Order button that does nothing. Payment methods that never appear.

Each has its own cause and its own fix, and the traffic you already paid for is bouncing off the page while you work out which one you have.

If you want to skip guessing it over again, one browser check can tell you which category your failure falls into before you touch a single setting.

In this guide, we will show you how to diagnose a broken WooCommerce checkout in about 60 seconds, then work through the fix for each symptom.

We cover both the classic shortcode checkout and the newer Checkout Block, because the fixes are not the same for both, and we finish with the habits that stop the next outage from happening at all.

Start Here: The 60-Second Checkout Triage (Read the Network Tab First)

WooCommerce does not build the totals, shipping options, and payment section with the rest of the page.

It requests them separately in the background while the page is already on screen.

When checkout breaks, that background request is what failed.

Here are four steps you need to perform:

1. Open your checkout in a private window with a product already in the cart.
2. Press F12 to open developer tools, then click the Network tab.
3. Filter by Fetch/XHR and reload the page.
4. Click the checkout request and look at its Status and Response.

Next, match with what you see:

WooCommerce documents the -1 nonce failure and the HTML-instead-of-JSON case in its own endless spinner troubleshooting notes.

That last row matters more than it looks. Most owners don’t know which checkout they run, and half the advice written on this problem targets the other one.

Classic Shortcode or Checkout Block? The Fix Path Is Different

Most WooCommerce troubleshooting guides skip this question, and it changes the solution to almost everything.

WooCommerce ships two checkouts.

The classic one runs on the [woocommerce_checkout] shortcode and uses PHP hooks.

The Checkout Block is built with React and talks to the Store API instead.

Since WooCommerce 8.3 in November 2023, new installations get the block by default, while many established stores still use the shortcode.

To find out which you have, open Pages, edit the page assigned as your checkout, and check the editor.

A [woocommerce_checkout] shortcode means classic. A Checkout block in the editor means the block.

The difference decides where your failure lives:

• Classic checkout sends requests to ?wc-ajax=update_order_review and ?wc-ajax=checkout. It breaks most often due to caching, nonce expiry, and PHP hook conflicts.
• Checkout Block sends requests to REST routes under /wp-json/wc/store/v1/. It most often breaks when something blocks REST access for logged-out visitors, such as security plugins and firewalls.

You can rule out two block-specific causes here.

The first is a page builder conflict. If your theme or page builder ships its own checkout widget and the page also holds the Checkout Block, two scripts fight over the same order review section, and one waits forever for the other.

The second is an extension written for classic PHP hooks with no block equivalent, so its fields or fees never render and nothing reports an error.

Both are the same underlying problem. Every extension, gateway, and template override that modifies the checkout adds another piece of code competing for control of one page, and that is where breakages start.

FunnelKit Funnel Builder replaces the default checkout with a single page that works on both classic and block-based stores, which reduces the number of moving parts.

That is a structural fix for once you are stable, not an emergency repair.

For what the shortcode does and when it is still the right choice, see our guide to the WooCommerce checkout shortcode.

1. WooCommerce Checkout Stuck on the Loading Spinner

The order review section spins and never resolves, so shipping, totals, and payment methods never arrive.

A checkout page not loading and a checkout that keeps loading are the same failure under two names, and it is the one store owners hit most.

Use your Network tab reading to go straight to the relevant fix:

• Response is -1: Stop caching the checkout page. The nonce inside the cached copy is stale by the time the request fires. Exclude cart, checkout, and my-account from every cache layer, then purge everything.
• Response is HTML instead of JSON: Look for an index.html in your web root beside index.php, then a minification plugin, then a PHP notice. Set define( 'WP_DEBUG_LOG', true ); and read wp-content/debug.log.
• Valid JSON, spinner keeps spinning: The fragments returned and nothing consumed them. Check Console for a script error firing before WooCommerce’s handler, then check WooCommerce ⇨ Status ⇨ Templates for an outdated checkout/form-checkout.php override.
• No request fires: Look for a 404 on checkout.min.js, or a JS combine/defer setting reordering scripts. Cloudflare’s Rocket Loader is a repeat offender.
• Block stores: A 403 on /wc/store/v1/batch sends you to firewalls, not plugin conflicts.

Advanced (for developers):

wc-ajax=update_order_review returns a fragments map keyed by CSS selector.

If a theme override renamed or removed .woocommerce-checkout-review-order-table, the fragment has nowhere to land, and the blockUI overlay is never removed.

Compare the override against core under Status ⇨ Templates.

2. Checkout Page Blank, White, or Showing a Critical Error

A white screen, or "There has been a critical error on this website", means PHP stopped executing. This shows the checkout failed outright.

Open WooCommerce ⇨ Status ⇨ Logs and read the newest fatal-errors entry. It names the file, the line, and the plugin.

9 out of 10 times, a plugin is most likely the cause. Deactivate it via FTP, and the page returns.

If you saw “There has been a critical error on this website,” check the recovery-mode email; it logs you in with that plugin paused.

Then rule out memory:

define( 'WP_MEMORY_LIMIT', '512M' );

256MB is the minimum.

If the log is empty, reproduce with debugging on:

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

In 2026, many WooCommerce errors are caused by an outdated payment plugin or an outdated checkout template that hasn't been updated to work with the latest WooCommerce version.

3. Place Order Button Not Working or Order Not Processing

The page loads correctly, the customer clicks Place Order, and nothing happens.

Or the page scrolls to the top with a generic error that tells them nothing.

• No network request fires

Open the Console tab and find the first red error, not the last one. Later errors are knock-on effects of the first.

A jQuery conflict, a script loaded out of order, or an optimization plugin combining and minifying checkout scripts all produce this.

Exclude checkout scripts from minification, deferral, and combining, then retest.

• Block checkout throws a minified React error

Direct DOM manipulation is a frequent culprit.

Custom code or a plugin inserting elements into the block checkout can trigger React errors such as “Failed to execute insertBefore on Node” and kill submission entirely.

Block customization has to go through the official filter and slot APIs.

• Field validation

A required custom field hidden with CSS is still validated on the server, so the order is rejected while the customer cannot see which field is failing.

For the correct methods on both checkouts, see our guides on customizing the Place Order button and WooCommerce checkout validation.

4. No Payment Methods Showing at Checkout

The checkout loads, but the payment section is empty. In this case, the order review request usually succeeded, and the gateway declined to display.

Make sure to work through this list:

• The gateway is enabled and configured: Confirm it is switched on under WooCommerce ⇨ Settings ⇨ Payments, with every required credential filled in.
• The keys match the mode: Test keys in live mode, or live keys in test mode, will stop a gateway from rendering without producing an obvious error anywhere.
• SSL is valid and current: Most gateways refuse to load without working HTTPS. An expired certificate or mixed-content warnings can hide the payment section.
• Currency and country are supported: Gateways restrict which currencies and billing countries they accept, which bites multi-currency stores first.
• The gateway supports your checkout type: Some extensions still don't support the Checkout Block. A gateway that appears on classic and vanishes on the block is telling you exactly that.

Express payment buttons carry an extra requirement.

Apple Pay and Google Pay need domain verification with the payment provider, and they only render on supported browsers and devices, so testing in the wrong browser makes a working setup look broken.

For configuring the most common providers, see our guide to multiple payment gateways in WooCommerce.

5. Checkout Says Your Cart Is Empty or Redirects Back to Cart

Customers add products, reach the checkout, and are told their cart is empty or sent back to the cart page.

This is a session problem. WooCommerce holds cart contents against a session identifier stored in a cookie.

When that cookie does not make it back to the server, the cart looks empty on arrival.

Here are three things to work on:

• A cached checkout page serving one visitor’s copy to everyone.
• A cookie domain mismatch between the www and non-www versions of your site.
• A security or consent plugin stripping the WooCommerce session cookie before it is ever set. Mixed HTTP and HTTPS in URLs produce the same result, because a cookie set on one protocol is not sent on the other.

Fix it by excluding cart, checkout, and my-account from all caching, enforcing one canonical domain with a site-wide redirect, and confirming your cookie consent tool treats the WooCommerce session cookie as strictly necessary.

6. Checkout Works for You as Admin but Not for Customers

If checkout works perfectly while you are logged in as an administrator and fails for real customers, you have a caching problem.

Logged-in users bypass most cache layers, so you're seeing a freshly generated page while your customers receive a stored copy with an expired nonce inside it.

Reproduce the customer experience before you change anything.

Open the store in a private window, add a product, and check out without logging in.

If that works but your normal browser doesn't, go straight to the caching section below.

The same pattern applies to guests specifically. If orders complete for logged-in customers and fail for guests, confirm guest checkout is enabled under WooCommerce ⇨ Settings ⇨ Accounts & Privacy.

Make sure that no account-only required field is blocking submission.

For the correct settings, see our guide to WooCommerce guest checkout.

7. Shipping Rates, Totals, or Coupons Not Updating

The checkout loads, but the numbers never move when a customer edits their address or applies a coupon.

The update request fails while the rest of the page continues as though nothing happened.

Read the response first, then clear WooCommerce’s shipping transients.

• Clear rate caches: Go to Status ⇨ Tools and click on 'Clear transients'. Rates are cached per cart hash and go stale after a zone change.
• Zone matching: An address matching no shipping zone returns no methods. Check that “Hide shipping costs until an address is entered” isn’t masking it.
• Block stores: Address changes post to /wc/store/v1/cart/update-customer. A 403 there means nothing ever recalculates.
• Coupons: Usage limits, "individual use only", and product exclusions all let a coupon apply and then do nothing to the total.

Why Isn’t My Shipping Address Showing Up in WooCommerce Checkout?

There are likely four causes. The cart holds only virtual or downloadable products, so shipping is hidden by design. Shipping is disabled entirely under Settings ⇨ Shipping.

The selected country’s locale rules hide fields WooCommerce treats as optional there.

Or a failed order-review request left stale markup on screen.

In block checkout, the shipping step disappears whenever needs_shipping returns false in the cart response. Check that field before assuming the fields were deleted.

8. Checkout Broken Only on Mobile, Safari, or in Incognito

Checkout works on desktop and fails on phones, or works in Chrome and fails in Safari.

Browser-specific checkout failures are usually due to cookies or third-party frames.

Safari’s tracking prevention and incognito’s cookie partitioning drop session cookies set on a different host, and 3DS/SCA challenges fail when the bank’s iframe is blocked, or the popup is suppressed.

• Host consistency again: Assets loading from www while the page runs on the bare domain costs the session cookie in Safari specifically.
• SameSite attributes: Payment iframes need SameSite=None; Secure. A security plugin rewriting cookie attributes site-wide breaks 3DS.
• Content security policy: A missing frame-src directive for your gateway’s domain means the SCA challenge never appears, and orders sit at pending. Invisible in Network; only Console shows it.
• Cached mobile variants: A separate mobile cache bucket or AMP variant can serve a checkout that was never meant to be cached.

Make sure to test your checkout and buying journey on Safari's private mode, Chrome's incognito mode and real phone on cellular data.

9. Checkout Stopped Working After an Update (WordPress, WooCommerce, Plugin, or Theme)

A WooCommerce checkout not working after an update comes from four places, all checkable in five minutes.

It includes an unfinished database update, an outdated template override, a payment extension that hasn’t caught up, and a WordPress version ahead of your WooCommerce version.

• Finish the database update

WooCommerce 11.0, released August 4, 2026, requires one. A yellow “WooCommerce database update required” notice means the upgrade is half-applied, and block checkout behaves unpredictably until it completes.

• Check template overrides

Status ⇨ Templates lists every theme override that’s fallen behind core.

An outdated checkout/form-checkout.php is the most common cause of a checkout that broke the moment WooCommerce updated.

• Check extension compatibility

Read each payment plugin’s changelog for the WooCommerce version it’s tested against.

Gateways lag major releases by days to weeks.

• Check the WordPress floor

WooCommerce 10.8 and later require WordPress 6.9 or newer, and 11.0.1 added compatibility work for WordPress 7.1.

A WordPress update landing ahead of your WooCommerce version breaks blocks before anything else.

• Roll back on staging, never on live

If checkout started failing on stock or price mismatches immediately after updating, note that WooCommerce 11.0 changed stock restoration on failed orders and enabled product object caching by default for new stores.

Both are in the 11.0 release notes.

10. Checkout Broke After a Migration, Domain Change, or Staging Push

Migrations break checkout in ways no other page reveals, because checkout is the only place touching sessions, serialized gateway settings, REST routes, and outbound API calls at once.

• Search-replace must be serialization-safe

Use wp search-replace old.com new.com --all-tables or Better Search Replace.

A raw SQL find-and-replace corrupts serialized gateway settings, which then throw fatal errors only at checkout.

• Flush rewrite rules

Go to Settings ⇨ Permalinks and hit save.

Most /wp-json/ 404s after a move are this and nothing else.

• Clear staging constants

Make sure to remove staging constants from wp-config.php: WP_ENVIRONMENT_TYPE, gateway test-mode flags, DISABLE_WP_CRON.

Separate the object cache prefix while you’re in there.

• Repoint gateway webhooks

Orders sitting at pending after a successful payment are almost always due to webhooks still calling the old domain.

• Confirm HPOS tables came across

wc_orders and its companions don’t always survive a partial database copy.

Once done, always re-verify Apple Pay domain verification and re-issue SSL before testing.

How to Run the WooCommerce Conflict Test Without Taking Your Store Offline

Install the Health Check & Troubleshooting plugin. Its troubleshooting mode disables plugins and switches themes for your session only. Customers will still see the live store throughout.

Bulk-deactivating plugins on a live store is never necessary and costs orders while you test.

Enable troubleshooting mode, switch to a default theme inside it, and test checkout in that same session.

If it works, re-enable plugins one at a time until it breaks. If it still fails with everything off, the cause is server, cache, or firewall, not a plugin.

Please note that the WooCommerce conflict test is session-scoped, so a page cache can still serve you cached HTML. Append a cache-busting query string while testing.

And custom snippets count as plugins here: a snippet manager runs regardless of what's paused, so disable those separately.

WooCommerce’s conflict test documentation covers the theme-side variations.

11. Caching and CDN Rules That Break Checkout (WP Rocket, LiteSpeed, Cloudflare, and Host-Level Cache)

Caching is why a WooCommerce checkout page loads for you but not for shoppers. It serves a page whose nonce was generated at cache time and validated much later.

The fingerprint is a -1 response, or a checkout that works for you and fails for logged-out shoppers. Every layer needs its own rule, including the plugin, CDN, and host.

• WP Rocket

It excludes cart, checkout, and my-account automatically, but only the pages assigned in WooCommerce ⇨ Settings ⇨ Advanced.

A custom checkout URL isn’t covered. So make sure to add it under Advanced Rules ⇨ Never Cache URLs, and disable 'Delay JavaScript Execution' and 'Optimize CSS Delivery' on checkout if the spinner hangs.

• LiteSpeed Cache

Go to Cache ⇨ Excludes ⇨ Do Not Cache URIs, add your checkout and cart paths plus /wp-json/wc/store/.

Add wp_woocommerce_session_ under Do Not Cache Cookies.

If you use ESI, confirm checkout blocks aren’t cached as public fragments.

• Cloudflare

Create a Cache Rule bypassing cache for /checkout, /cart, /my-account, /wp-json/wc/store/, and any URI containing wc-ajax.

Then turn Rocket Loader off on checkout. It reorders script execution and is a recurring cause of a dead Place Order button.

Remove any legacy “Cache Everything” page rule outright; it will hand one shopper another shopper’s cached checkout.

Cloudflare’s cache rules documentation has the syntax.

• Host-level cache

Kinsta, WP Engine, SiteGround, and Varnish stacks each keep their own bypass list, and none of them know about a custom checkout URL.

Ask support to confirm rather than assuming. We’ve watched stores fix all three layers above and stay broken because the fourth was still serving a cached page.

To do a quick test, append ?nocache=1 to the checkout URL. If it loads with the query string without fail, that’s your answer.

We keep host-specific and CDN-specific exclusion rules in our checkout caching post, worth bookmarking once you’ve fixed it, because this failure comes back.

12. Security Plugins and Firewalls That Block the Store API

If checkout doesn't work while the rest of the site loads normally, and you get a 403 or 406 on /wp-json/wc/store/v1/…, a firewall is rejecting the request.

Wordfence, Sucuri, Solid Security, NinjaFirewall, Cloudflare’s managed rules, and host-level ModSecurity all do this by default or when hardened.

Here are the two patterns that cause almost all of it.

• Blanket REST hardening

A “disable the REST API for logged-out users” toggle kills block checkout instantly. The Classic checkout keeps working.

• Rule-triggered blocks

ModSecurity fires on an apostrophe in a surname, a long order note, or an address string that pattern-matches an injection attempt.

These fail for some shoppers and not others. That intermittency is the tell.

• 406 is almost always ModSecurity

Ask your host for the rule ID from the audit log at the exact timestamp of the failed request.

That’s a two-minute lookup for them; it names the rule to allowlist, and in our experience it’s the fastest way out of a block checkout outage that no amount of plugin-disabling will touch.

Make sure to test it directly:

curl -I https://yourstore.com/wp-json/wc/store/v1/cart

200 means the route is reachable; 403 or 406 means you’ve found it. Allowlist /wp-json/wc/store/v1/* rather than disabling the firewall.

The Store API also rate-limits, and a 429 under shared-IP conditions is a different problem wearing a similar shape.

The Store API reference documents the nonce and cart-token behavior behind both.

13. Page Builder Conflicts (Elementor, Divi, and Duplicate Checkout Handlers)

Elementor Pro’s Checkout widget and Divi’s checkout module render their own markup around WooCommerce’s.

When a builder widget and the block or shortcode both exist on the page, two scripts bind to the same form, and the second overwrites the first.

The main result is the Place Order button not working, or totals updating twice.

Here's how you can check it in ten seconds:

• Click "View Source" and search for "woocommerce-checkout".
• It should appear once. Two instances mean two handlers, and the fix is to pick one owner. Running both isn’t a configuration.
• Check whether the builder loads its own jQuery version. That breaks WooCommerce’s checkout script without throwing an error.

Stores that break at checkout repeatedly are usually running a theme override, a builder widget, and WooCommerce’s own handlers competing for the same DOM.

A purpose-built checkout that renders one consistent set of handlers for classic and block stores removes that conflict surface, which is part of why FunnelKit Funnel Builder exists.

14. Server-Side Causes (PHP Version, Memory Limit, Execution Time, and HPOS)

Start at WooCommerce ⇨ Status and read the server environment block.

PHP version, memory limit, and execution time, everything is listed there, and WooCommerce flags anything below its own recommendations in red.

• PHP version, in both directions: WooCommerce recommends PHP 8.3 or greater; 7.4 hit end of life in November 2022. But a PHP version newer than your gateway’s SDK supports fails identically at the API call. That call only happens at checkout. Test one version step at a time on staging.
• Memory: 256MB is the floor. Raise WP_MEMORY_LIMIT and confirm the host isn’t capping it lower.
• Execution time and 504s: A slow gateway call or a synchronous transactional email can exceed max_execution_time mid-order. Move emails off the checkout request: add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Our guide to transactional emails delaying order completion covers when that’s the right call and when it hides a deeper problem.

• HPOS: Settings ⇨ Advanced ⇨ Features shows the order storage setting and lists incompatible plugins. An extension that isn’t HPOS-aware can accept a payment and fail to write the order.
• Action Scheduler backlog: Status ⇨ Scheduled Actions. Thousands of pending actions mean WP-Cron has stalled, and order transitions are queued behind it.

The full walkthrough is in our WooCommerce system status report guide.

Still Broken? Here’s Exactly What to Send Your Host or Developer

Most tickets take five rounds because the first message says “WooCommerce checkout not working” and nothing else. Send this instead:

• The full request URL and method (for example, POST /wp-json/wc/store/v1/checkout)
• The HTTP status code
• The first 200 characters of the response body
• The exact console error text, copied, not paraphrased
• The newest fatal-errors entry from Status ⇨ Logs
• Status ⇨ Get system report ⇨ Copy for support
• The exact timestamp and the IP you tested from, for the firewall audit log
• Whether it still fails in Health Check troubleshooting mode
• Whether you’re on classic or block checkout

Bonus: 3 Tips to Streamline WooCommerce Checkout Process After Resolving the Issues

Now that your checkout page is working again, here are three quick ways to make it faster and easier for customers to complete their purchase.

• Replace the default checkout with a multi-step one 

Many customers may find a one-page checkout lengthy and complex, which can lead to cart abandonment. You can replace that with a multi-step checkout, which makes the process smoother and more user-friendly by dividing it into multiple steps. 

With FunnelKit Funnel Builder, you can easily create a multi-step checkout (as shown below).

Additionally, you can enable multi-step preview, allowing users to easily review the information they entered in the previous step and make corrections or changes as needed.

• Offer an auto address completion option 

Google address autocomplete automatically completes users' addresses as they type. It automatically completes the street address, city, zip code, state, and country fields.

This helps users enter the right address without manually typing every detail, speeding up and smoothing the checkout process.

• Allow customers to adjust cart item quantity on checkout 

By default, users can’t update or remove quantity at checkout, which can be a handy feature. If you force users to return to the cart page to update a quantity, it can ruin their shopping experience and cause them to abandon the cart. 

With FunnelKit’s checkout mini cart option, you can easily allow customers to update, remove, and undo deletions right on the checkout page, making the checkout process even smoother. 

WooCommerce Checkout Troubleshooting FAQ

Get Your WooCommerce Checkout Working, then Stop It Breaking Again

If you got here from a broken store, the worst of it is over, and the stores we’ve seen stop hitting this problem aren’t the ones that fixed it hardest.

They changed three habits.

Update WooCommerce and gateways on staging before production. Run one live test order after every update. Write the cache exclusion rules down for every layer, so nobody has to rediscover them at 11 pm.

Add one more if you can. Point an uptime monitor at your checkout URL rather than your homepage.

A homepage check will report 100% uptime while checkout returns a 500 to every shopper, which is how most owners find out about an outage from a customer email instead of an alert.

Once orders are flowing again, the checkout itself is worth a second look.

Fewer fields, fewer competing handlers, one set of scripts instead of three.

That’s a stability story as much as a conversion one, and it’s what FunnelKit Funnel Builder is built to give you on classic and block stores alike.

But do not rush into anything. Fix first and optimize after.

Related Blogs

Editorial Team

September 2, 2026

How to Add Trust Badges to WooCommerce Checkout (Block & Classic)

Adding trust badges to your WooCommerce checkout can help remove the hesitation shoppers feel before entering their card details. That hesitation matters because 19% of shoppers abandon checkout because they...

Editorial Team

August 27, 2026

WooCommerce Frequently Bought Together: 4 Placements That Increase AOV

WooCommerce frequently bought together offers are one of the easiest ways to increase revenue on a product page. Think about the counter at a kitchen appliance store. Let's say someone...

Editorial Team

August 25, 2026

How to Add Easy Login to WooCommerce Checkout for a Smooth Customer Experience

Ever wondered why so many customers abandon their carts without completing the purchase? Studies show that 18% of online shoppers leave orders midway due to a complicated checkout process. [Source:...