Endless loading/spinner on the checkout page

If checkout stays dimmed behind a loading spinner, the browser is usually waiting for a request, rejecting its response, or unable to finish the JavaScript that updates checkout. The request and the best diagnostic steps depend on whether the page uses classic checkout or the Checkout block.

You need store administrator access and a staging site or test payment method for the checks below. This guide covers checkout behavior in WooCommerce core. If only one payment, shipping, tax, address, or fraud-prevention extension is affected, also review that extension’s logs and documentation.

Choose the next check

↑ Back to top

A spinner alone does not identify the cause. Start by identifying the checkout type and reproducing the failure safely, then use the request result below to choose a check. Possible causes include caching, an extension conflict, a blocked request, or a server error.

Identify the checkout type

↑ Back to top

Edit the page assigned as Checkout under WooCommerce > Settings > Advanced:

• Checkout block: The editor contains a Checkout block. The browser uses the WooCommerce Store API for cart and checkout requests.
• Classic checkout: The editor contains a Classic Shortcode block or a Shortcode block for WooCommerce checkout. The browser uses WooCommerce AJAX endpoints, including update_order_review while it updates totals, shipping, and payment methods.

Do not replace one checkout type with the other as a first troubleshooting step. Extensions can support them differently, so switching can hide the original compatibility problem.

Reproduce the problem safely

↑ Back to top

• Create a current backup and reproduce the problem on staging whenever possible.
• Disconnect live payment gateways and external services on staging, or enable their documented test modes.
• Start with one simple, in-stock product and no coupon. Record which address, shipping method, and payment method trigger the spinner.
• Note the exact time, browser, device, user state, expected result, and what happens instead.

Inspect the failing request

↑ Back to top

1. Open the checkout page, open your browser’s developer tools, and select Inspect if your browser offers it from the page menu.
2. Open the Network panel, select the Fetch/XHR filter, and enable Preserve log if your browser offers it.
3. Clear the recorded requests, then repeat the action that triggers the spinner. If it happens after Place order, check WooCommerce > Orders before retrying: the order may already exist.
4. Open the request that remains pending or fails. Save its URL, method, status, duration, and response.

For classic checkout, look for a URL containing wc-ajax=update_order_review while totals load or wc-ajax=checkout after selecting Place order. For the Checkout block, look for requests under /wp-json/wc/store/, especially cart and checkout routes. See Troubleshoot AJAX issues for more browser-tool guidance.

Result	What to investigate
Pending for a long time or timing out	Slow PHP, database work, an external API, email delivery, or a server resource limit.
403	A firewall, security rule, expired or missing nonce, or another authorization check.
404	An incorrect request URL, rewrite rule, proxy route, or moved site configuration.
500	A PHP fatal error or another server-side failure. Check logs at the same timestamp.
HTML, a login page, or a redirect instead of JSON	A cache, maintenance or security layer, redirect, proxy, or PHP warning is changing the response.
Blocked, mixed-content, or cross-origin error	The checkout page and request endpoint disagree about HTTPS, hostname, port, or allowed origin.

Check the site addresses and HTTPS

↑ Back to top

Go to Settings > General. Compare the public checkout URL with the request URL from the Network panel. Check for an old domain, an unexpected www difference, or HTTP requests from an HTTPS checkout page. Ask your host to investigate blocked requests or redirects before changing the site addresses.

The WordPress Address (URL) and Site Address (URL) are commonly the same, but they can differ intentionally when WordPress is installed in its own directory or a proxy is configured for that layout. Do not make them identical solely to troubleshoot checkout. If the fields are disabled or you are unsure about the intended addresses, ask your host to verify the configuration. The important test is whether the browser can call the checkout request URL from the public page.

Exclude checkout from caching

↑ Back to top

Exclude the Cart, Checkout, and My Account pages from page or edge caching. Make sure the cache, CDN, firewall, and reverse proxy also pass WooCommerce AJAX and Store API requests without serving a stored response. Use your caching provider’s exclusion settings or ask your host to configure these exclusions. Purge each cache layer and repeat the test.

A response containing only -1 can mean an AJAX nonce validation failed. A cached or expired nonce is one possibility, but the nonce can also be missing or changed before it reaches WordPress. Reload checkout, clear the relevant caches, confirm the page is excluded, then inspect the request data and response again.

Check JavaScript and extension conflicts

↑ Back to top

1. Open the browser Console, clear it, and reproduce the spinner.
2. Save the first relevant error and its source file. Later errors can be consequences of the first failure.
3. Check whether a content-security policy, consent tool, ad blocker, optimization service, or browser extension blocked a checkout script or request.
4. Follow the theme and plugin conflict test on staging. Confirm the result by making the problem disappear and reappear with the same combination.

The JavaScript troubleshooting guide explains how to open the Console in current browsers and interpret common errors.

Check server logs and resources

↑ Back to top

• Go to WooCommerce > Status > Logs and open the log that matches the affected extension and timestamp. Fatal PHP errors may appear in a fatal-errors log.
• Download a current System Status Report. Check software versions, memory limits, template overrides, and active plugins. Review scheduled actions under WooCommerce > Status > Scheduled Actions.
• If the log reports an exhausted memory limit, ask your host to review the limits and the failing request using the current memory guidance. Raising memory without an exhaustion error is not a substitute for finding the slow or failing request.
• If a request is blocked or times out before WordPress handles it, ask the host to check the web-server, PHP, firewall, proxy, and resource-limit logs at the recorded time.

If checkout stalls only after Place order

↑ Back to top

Check the selected payment gateway, fraud service, tax service, webhooks, and mail transport. Use the extension’s test mode and logs, and check the provider’s service status. Do not infer the cause from the spinner alone.

If your host or developer confirms that sending transactional email during checkout is delaying the request, WooCommerce includes a Deferred emails feature under WooCommerce > Settings > Advanced > Features. Test it on staging using a safe mail destination. After enabling it and saving the setting, verify that the queued email actions complete under WooCommerce > Status > Scheduled Actions and that the test emails arrive. Do not enable it as a blanket fix when the failing request occurs before an order is submitted.

Verify the fix

↑ Back to top

After each change, repeat the same steps with the same product, address, and payment method. Check that totals and payment methods load, the request finishes without the earlier error, and checkout becomes usable. If the problem occurred after Place order, complete a test-mode order and confirm that exactly one order is created and the expected confirmation appears. Restore any unrelated settings changed during the test.

Collect diagnostic information

↑ Back to top

If checkout still does not finish, collect the following information for your support request. Share extension-specific findings with the responsible developer:

• Whether the page uses classic checkout or the Checkout block.
• Exact reproduction steps and whether the problem occurs for guests, signed-in customers, or both.
• The failed request URL, method, status, duration, and response, with credentials and customer data removed.
• The first relevant Console error, matching server logs, System Status Report, and conflict-test result.

Remove customer details, payment data, credentials, cookies, and security tokens before sharing diagnostic information.

Questions and support

↑ Back to top

Do you still have questions and need assistance? 

• If you’re looking to extend the core functionality shown here, we recommend reviewing available extensions in the WooCommerce Marketplace.
• Need ongoing advanced support or a customization built for WooCommerce? Hire a Woo Agency Partner.
• Are you a developer building your own WooCommerce integration or extension? Check our Developer Resources.

If you weren’t able to find the information you need, please use the feedback thumbs below to let us know.