When the checkout page is the part that fails
A customer fills the cart, reaches the checkout, types their address and presses “Place order”. Then nothing happens. Or the button spins and never stops. Or the page reloads with a red notice at the top and the order is gone. From the outside the shop looks open, so you often hear about it only when somebody messages you to say they tried three times and gave up.
This page is about faults on the checkout page itself: the form, the button, the notices, shipping options that never appear and totals that never load. Checkout faults are one branch of the larger set of problems mapped out in our WordPress errors and fixes hub. If the checkout works but the payment step fails or orders sit unpaid after the customer has paid, that is a gateway problem and our payment gateway troubleshooting page covers it instead. The two are often confused, and telling them apart early saves time. If the store has never had a gateway connected at all, start with our walkthrough on connecting a payment gateway to a website.
What a broken checkout usually looks like
Store owners describe the same handful of symptoms. Each one points to a different layer of the site.
- The button does nothing. No notice, no reload, no order. This is very often a JavaScript error: a script from a plugin or theme fails, and the code that sends the order never runs.
- The button spins forever. The browser sent the order but did not get a proper answer back. The server may have thrown a PHP error, timed out, or returned something that is not the response WooCommerce expected.
- A red error appears. WooCommerce or a plugin rejected the order. The wording matters here, so a screenshot is worth more than a description.
- “No shipping options were found” or no methods shown. The customer’s address is not covered by any shipping zone, or a method has rules that exclude their cart.
- The session expires. The cart empties or the customer is sent back to the shop. This usually involves caching or cookies, and it overlaps with the problem described in our post on why a WooCommerce cart empties itself.
- It works for you but not for customers. You are logged in as an admin, which often skips the page cache. Visitors get a cached copy and a different result.
Why checkouts break
A checkout is the busiest page in a store. The theme, WooCommerce, the gateway plugin, shipping plugins, tax settings, caching, security rules and sometimes a page builder all touch it at once. Any one of them can stop an order. These are the causes we look at first, roughly in order of how often they turn out to be the reason.
A recent update
Most broken checkouts start right after something changed. A WooCommerce update, a theme update, a new version of a checkout field plugin or a PHP upgrade by the host. Extensions that customise the checkout are especially sensitive to WooCommerce changes, because they hook deep into how the form is built. If you know the date it stopped working, compare it with your update history. When an update is the cause, rolling back blindly can create new problems, which is why we treat it the way our page on a WordPress site broken after an update describes: confirm the cause first, then decide.
Caching the wrong pages
The cart, checkout and My Account pages must never be served from a full-page cache. Good caching plugins exclude them by default, but a manual setting, a host-level cache or a CDN rule can still catch them. When that happens, customers can see someone else’s empty cart, stale security tokens or a checkout that refuses every submission. Minification and “combine JavaScript” options can also break the checkout scripts even when the page itself is not cached.
Block checkout versus the classic checkout
WooCommerce now offers two ways to build the checkout: the Checkout block, which newer stores usually get, and the older shortcode-based checkout. Some plugins only support one of the two. A field editor, a delivery date picker or a gateway may appear on one and be missing on the other. If a feature disappeared from your checkout, check which version the page actually uses before assuming the plugin is broken.
Plugin and theme conflicts
Two plugins that both modify checkout fields, a theme that overrides WooCommerce templates with outdated copies, or a script loaded on every page that clashes with WooCommerce’s own. Template overrides are a quiet one. WooCommerce reports outdated template copies under WooCommerce, then Status, but many owners never look there. Finding which piece is at fault is the method our plugin conflict troubleshooting page covers in detail.
Shipping and tax settings
A store that never ships to a certain region, a zone that was deleted, a minimum order amount set on free shipping with no fallback method. The checkout cannot finish if it has nothing to offer the customer. Wrong totals are a related problem. Our post on wrong tax and shipping amounts at checkout goes through zones, classes and GST settings for stores that need them.
Server limits and errors
Placing an order does a lot of work at once: it creates the order, reduces stock, sends emails and talks to the gateway. On a stretched hosting plan, that can hit a memory limit or a timeout. Security rules on the server or a firewall plugin can also block the request because it looks unusual to them. These show up in the server error log or in wp-content/debug.log if logging is on, not on the page the customer sees.
What you can safely check yourself
Before changing anything on a live store, make a fresh backup of the files and the database, and keep it somewhere other than the server. Then work through these. None of them change your setup.
- Place a test order as a guest. Use a private browser window, not your admin login. Pick a cheap product and a payment method you can cancel, such as cash on delivery if you offer it. Note exactly where it stops.
- Try another browser and a phone. If it works in one and not another, the cause is more likely a script or a browser extension than the server.
- Watch for script errors. Right-click anywhere on the checkout, pick Inspect, switch to the Console tab and press Place order once more. Red lines there are worth a screenshot, even if they mean nothing to you.
- Read WooCommerce’s logs. Under WooCommerce, then Status, then Logs, look for entries with “fatal-errors” in the name or entries dated around the failed attempt.
- Check the order list. Sometimes the order was created and set to Failed or Pending payment, which tells you the checkout worked and the problem sits later.
- Look at what changed. Updates, new plugins, a new theme setting, a host notice about PHP. A date narrows everything down.
What we would not do on a live store is deactivate plugins one by one while customers are shopping. It can take the gateway or shipping offline mid-order. That kind of test belongs on a copy of the site.
How we fix a checkout
When you message us with the symptom and a screenshot, we first look at the live checkout as a customer would, so we see the fault ourselves. Then you hear from us, plainly, whether we think the fault is in a plugin, the theme, a setting or the server, and the earliest point we can begin. A shop that has stopped taking orders goes to the front of our queue.
Before touching anything we take our own backup. Then, wherever the host allows it, we clone the store to a staging copy and reproduce the failure there. On the copy we can switch plugins off, swap the theme for a default one and turn on debugging without your customers seeing any of it. Once the cause is clear, we fix it in the smallest way that works: a settings change, a cache exclusion, an updated template, a plugin replaced or rolled back, a server limit raised with your host.
The fix then goes to the live store, and we place real test orders through each payment and shipping option you use, checking that the order appears, the stock changes and the emails go out. Afterwards you get a plain explanation of what was wrong and what to watch for. If the root cause is a plugin that is no longer maintained, we say so rather than patch around it. The general approach is the same one behind our WordPress bug fixing service, applied to the page that earns your money.
Keeping the checkout working after the fix
Checkouts rarely break on their own. They break when something around them changes. A few habits keep that under control:
- Place a test order after every round of updates, not only when someone complains.
- Update WooCommerce and its extensions together, on a staging copy first if the store is busy.
- Keep checkout plugins to the ones you actually use. Each extra field editor or upsell plugin is another thing hooked into the same form.
- After any change to caching or a CDN, check the checkout as a logged-out visitor.
If you would rather not run those checks yourself, our ongoing WooCommerce support covers that kind of routine work for stores. For the official reference on settings and extensions, the WooCommerce documentation is the place to start.