Skip to content

Problem

WooCommerce checkout errors: how to fix it

Checkout failures cost money the moment they start, so the priority is reproducing the error rather than theorising about it. WooCommerce writes detailed logs, payment gateways write their own, and the server writes a third set. Between those three you can nearly always name the failing step within an hour. Only then is it worth disabling plugins or changing settings.

By CartKernel · Last reviewed 2026-09-07

Does this look familiar?

  • Customers report an error message on placing the order while the cart still holds the items
  • The page reloads at the top of the form with a general failure notice and no detail
  • Payment is taken by the provider but no order is created in the store
  • Checkout fails only for certain countries, postcodes or shipping selections
  • Orders sit at pending payment and never move to processing
  • The failure happens for customers but never when an administrator tests it

Causes, ranked

Why it happens, most common first

Check them in this order. The first two account for most cases we open.

  • most common

    The checkout page is being served from a cache

    Checkout carries per visitor data and a security token with a limited lifetime. A caching layer, a content delivery network rule or an optimisation plugin that stores the page will serve one visitor's token to another, which fails validation. This is the classic cause of an error that administrators cannot reproduce.

  • most common

    Payment gateway credentials or configuration are wrong

    Keys left in test mode, credentials rotated on the provider side, a webhook endpoint that no longer resolves, or a currency the account is not enabled for all produce failures at the final step. The provider's dashboard usually shows the declined request with a clearer reason than the storefront does.

  • common

    A plugin conflict breaks the checkout scripts

    Checkout depends on scripts that validate the form and update totals. A plugin that combines, defers or minifies those scripts, or one that adds its own fields, can stop the submission before it reaches the server. The error is silent in the interface and visible in the browser console.

  • common

    No valid shipping method exists for the address

    Shipping zones that do not cover a region, a class with no rate assigned, or a weight or dimension rule with a gap will leave certain baskets with nothing selectable. Checkout then blocks. It affects a specific subset of customers, which makes it easy to miss.

  • common

    Server limits are being reached

    Memory limits, execution timeouts and outbound request timeouts stop the checkout while it is talking to the payment provider. The signature is an order created but never completed, or a blank response. Server error logs will carry the exact limit that was hit.

  • occasional

    The site is mixing checkout implementations

    WooCommerce offers both a block based checkout and the older shortcode based one. Extensions written for one may not fully support the other, and a partial migration can leave fields, validation or payment methods behaving inconsistently.

  • occasional

    Fraud or security rules are rejecting real customers

    A firewall rule, a rate limit, a bot challenge or an address verification setting on the payment account can decline legitimate orders. These usually cluster by country, by card type or by device, which is the clue to look for in the pattern of failures.

The fix

In this order

Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.

Prevent it next time

  • Run a full test order after every plugin update, theme change or hosting migration
  • Keep checkout excluded from caching in a documented list that survives new tools
  • Alert on orders stuck at pending payment so silent gateway failures are noticed the same day
  • Maintain a staging copy that mirrors production so conflicts are found before customers find them
  1. Reproduce the failure as a customer would

    Use a private browsing window, a real product, a real address in the affected region, and a genuine payment method in whatever test mode the provider supports. Record the exact wording of the error and the time, which you will need for the logs.

  2. Read all three sets of logs for that timestamp

    Open the store's own logging area, the payment provider's dashboard for the same minute, and the server error log. One of the three will usually name the failing step precisely, which saves the guesswork of disabling plugins first.

  3. Exclude checkout from every caching layer

    Confirm cart, checkout and account pages are excluded in the caching plugin, at the content delivery network, at the host level cache and in any optimisation tool. Then verify as a logged out visitor that the response headers show the page was not served from a cache.

  4. Verify the gateway end to end

    Check the mode, the keys, the enabled currencies and the webhook endpoint, and send a test event from the provider to confirm it reaches the store. Gateways that reconcile asynchronously will leave orders pending forever if the callback cannot arrive.

  5. Isolate plugin conflicts on a staging copy

    Duplicate the site, disable all plugins except WooCommerce and the gateway, and confirm checkout works. Reactivate in small groups until the failure returns. Never do this on the live store during trading hours.

  6. Check script optimisation is not breaking the form

    Open the browser console during a failing checkout and look for script errors. If combining, deferring or minifying is implicated, exclude the checkout scripts from that processing rather than switching optimisation off across the site.

  7. Close the gaps in shipping and tax rules

    Test the checkout with an address from each region you sell to, including one with an unusual postcode format, and confirm at least one shipping method is always offered. Add a fallback rate to every zone so no basket can reach a dead end.

  8. Raise server limits and watch for recurrence

    Increase memory and execution limits to values the host supports, extend the outbound request timeout for gateway calls, then monitor for failed orders daily for a fortnight. Add an alert for orders stuck at pending payment beyond a set period.

When to get help

Ask for help when payments are being taken without orders being created, because that combination needs careful reconciliation against the provider's records before anything is changed, and customers are owed either an order or a refund quickly. It is also worth help when failures are intermittent and affect a small share of customers, since those are usually caused by caching, race conditions or resource limits under load, and they are hard to reproduce without proper monitoring in place.

Get a Growth Analysis

Free. We reply within one business day.

Questions

Asked alongside this problem

By CartKernel · Last reviewed

Why can I complete checkout but customers cannot?

Administrator sessions usually bypass caching, and your browser may hold session data a new visitor does not. Always test in a private window while logged out, and ideally from a different network. Most checkout faults that seem impossible to reproduce disappear once you test the way a customer arrives.

What should I do about orders where payment succeeded but no order exists?

Reconcile against the payment provider's transaction list for the affected period, create the missing orders manually or refund them, and contact those customers directly. Then fix the callback or timeout that caused it, because it will keep happening silently until the underlying request completes reliably.

Is the block based checkout more reliable than the older one?

Both are supported and both work well when the extensions in use support the one you have chosen. Reliability problems usually come from running extensions written for the other implementation. Pick one, confirm every payment and shipping extension supports it, and test the full flow after switching.

Could a security plugin be blocking checkout?

Yes. Rate limits, bot challenges and firewall rules can block the requests checkout depends on, particularly for customers on shared networks or unusual browsers. Check the security tool's block log for the timestamps of failed orders before disabling anything broadly.

Related problems, answers and terms

All problems
ProblemWooCommerce site slow: how to fix itA slow WooCommerce site is usually database work and uncached requests, not the theme alone. Diagnose server, database and front end in that order.OpenProblemHigh checkout abandonment rate: how to fix itA high checkout abandonment rate means people who decided to buy did not finish. Find the step they leave on, then remove what stopped them.OpenProblemEcommerce conversion rate dropped suddenly: how to fix itWhen ecommerce conversion rate dropped suddenly, check measurement, traffic mix and the site in that order. Most sharp drops have a single dated cause.OpenProblemGA4 purchase event not firing: how to fix itA GA4 purchase event not firing leaves ecommerce reports empty while orders keep arriving. Trace the event from checkout to property and repair it.OpenAnswerCan WooCommerce handle a large catalog?WooCommerce handles large catalogues with the right hosting and architecture. Where the strain shows first and the changes that keep it fast.OpenAnswerShould checkout require creating an account?Requiring an account at checkout costs orders. Offer guest checkout and create the account after purchase, except where accounts are genuinely required.OpenGlossaryCheckout abandonment rateCheckout abandonment rate is the share of started checkouts that never pay. Formula, a step by step worked funnel, and the causes worth checking first.OpenGlossaryEcommerce conversion rateEcommerce conversion rate is orders divided by sessions. Formula, why Shopify and GA4 report different rates, and how to read the number honestly.Open

Stop the leak.

A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.