Skip to content
Rescue 404
Rescue

WooCommerce Errors

WooCommerce Checkout Keeps Loading (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

A WooCommerce checkout spinner that never stops means the order-review or checkout AJAX request did not return usable data; inspect its Network response, make WordPress and Site URLs identical, exclude checkout from cache, and isolate JavaScript or extension conflicts before retrying payment.

This WordPress Repair guide focuses narrowly on checkout that renders but leaves the order review, payment methods, or Place order action spinning forever. Unlike a blank checkout page, the initial HTML arrived; unlike a general checkout failure, the defining evidence is an AJAX cycle that never completes. Diagnose with a zero-value or sandbox-safe test and avoid creating repeated live payment attempts.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

What the error means

WooCommerce refreshes order totals, shipping choices, and eligible payment methods in the background as the customer edits checkout. The browser shows a spinner while a WooCommerce AJAX request calculates that state and returns structured data. If JavaScript crashes, the request crosses to a different hostname, a firewall blocks it, PHP returns a fatal or warning instead of JSON, or a slow hook never finishes, the browser cannot clear the loading state. The decisive clue is the checkout-related XHR or fetch entry: its URL, duration, status, and response show whether the spinner is waiting, blocked, or trying to parse the wrong content.

Common symptoms

  • The order-review panel shows a spinner indefinitely after page load
  • Changing a billing field starts loading and payment methods never return
  • Place order disables itself and keeps spinning without confirmation or error
  • The Network panel shows a pending or failed wc-ajax checkout-related request
  • The AJAX response contains HTML, PHP warnings, -1, or a firewall challenge instead of expected data
  • Checkout works with a default theme or minimal extensions but not the normal stack
  • The spinner appears only for guests, one hostname, or certain shipping or payment choices

Most likely causes

  1. 01 WordPress Address and Site Address use different schemes or hostnames, breaking same-origin AJAX
  2. 02 A theme or extension JavaScript error stops checkout update handlers
  3. 03 Cache, CDN, or JavaScript optimization alters dynamic checkout content or scripts
  4. 04 A plugin, host firewall, or WAF blocks WooCommerce AJAX POST requests
  5. 05 PHP warnings, notices, or a fatal contaminate the structured AJAX response
  6. 06 A slow shipping, tax, payment, or email-related hook exceeds server resources or timeouts
  7. 07 Insufficient WordPress memory causes checkout AJAX processing to fail

What changed before the problem started

  • The store domain, HTTPS redirect, reverse proxy, or www preference changed
  • WooCommerce, the theme, gateway, shipping, tax, or checkout extension was updated
  • Caching, JavaScript delay, bot protection, or firewall rules changed
  • A new shipping zone, tax service, payment method, or checkout field was introduced
  • PHP version, memory limit, hosting plan, or transactional email behavior changed

Troubleshooting steps

  1. 01

    Inspect the request that owns the spinner

    Open DevTools → Network, filter to Fetch/XHR, reload checkout, and trigger the spinner once. Select the newest WooCommerce AJAX request and record its URL, duration, status, and sanitized response. Do not rely on the spinner alone to name the cause.

  2. 02

    Match WordPress and Site URLs exactly

    Under Settings → General, confirm both URLs use the same HTTPS scheme, hostname, and path customers use. Repair redirects so checkout and its AJAX requests stay on one canonical origin; do not mix www and non-www during the session.

  3. 03

    Exclude every dynamic commerce page from cache

    Ensure Cart, Checkout, and My Account are excluded from page cache at the plugin, host, reverse-proxy, and CDN layers. Purge all layers and retest as a guest, because administrators often bypass the cached response.

  4. 04

    Check the Console before changing gateways

    Capture the first red JavaScript error after a fresh reload. Errors from the theme, checkout customizer, consent tool, or optimizer can stop WooCommerce even when the failed line does not mention the payment gateway.

  5. 05

    Read WooCommerce logs for the same timestamp

    Open WooCommerce → Status → Logs and inspect fatal-error, gateway, shipping, and extension logs around the failed request. A timeout or fatal during totals calculation is more useful than repeatedly clicking Place order.

  6. 06

    Compare shipping and payment combinations safely

    Without submitting a live charge, change one field at a time and note whether a particular country, shipping method, coupon, or payment option starts the spinner. That boundary identifies the extension whose server calculation should be isolated.

When to stop troubleshooting

Stop DIY testing when Place order may have reached the gateway despite the spinner, customers report duplicate charges, AJAX requests remain pending long enough to exhaust workers, or production is the only place a conflict can be reproduced. Pause checkout if payment state is uncertain and escalate with request evidence, WooCommerce logs, affected cart conditions, and gateway transaction records.

Information to collect before requesting help

  • 01 Exact spinner location: order review, payment methods, or Place order
  • 02 Checkout AJAX request URL, duration, status, and sanitized response
  • 03 First Console error after a clean page reload
  • 04 WordPress Address, Site Address, and public checkout hostname
  • 05 WooCommerce, WordPress, PHP, theme, gateway, shipping, and tax versions
  • 06 WooCommerce fatal and extension logs for one exact timestamp
  • 07 Cache, CDN, optimization, firewall, and reverse-proxy configuration
  • 08 Whether the issue follows a specific address, shipping method, coupon, gateway, guest status, or device

How a professional repairs the problem

A technician records the precise AJAX lifecycle and proves whether the browser crashed, the request crossed origins, the server blocked it, or PHP returned bad data. They align canonical URLs, enforce dynamic-page cache exclusions, isolate the conflicting checkout component, repair the first fatal or slow callback, and tune only the firewall rule involved. Before reopening sales, they reconcile test transactions and complete guest checkout with each important shipping and payment path.

Frequently asked questions

Why does the order review spinner appear before I click Place order? +
WooCommerce updates totals, shipping, and payment eligibility over AJAX while fields change. The spinner waits for that calculation even before an order is submitted.
Is this the same as a blank checkout page? +
No. Here the checkout markup and loading indicator render, but a background update stalls. A blank page needs page-content and PHP-rendering diagnosis first.
Can mismatched www and non-www URLs cause endless loading? +
Yes. WooCommerce documents that checkout AJAX cannot complete across different domains. Keep WordPress Address, Site Address, redirects, and checkout on one origin.
Should customers click Place order again? +
Not until you verify whether the gateway received the first attempt. Repeated clicks can create duplicate authorizations or confusing pending orders.
Why does disabling JavaScript optimization fix it? +
Delay, combine, or minify settings can change script order or suppress a required checkout event. Exclude the affected checkout assets and page rather than abandoning all performance work.
Can slow email sending hold the checkout spinner? +
Yes. WooCommerce notes that transactional email work on a slow server can delay or disrupt the checkout AJAX response. Diagnose the mail callback instead of masking every timeout.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.