WooCommerce checkout stuck loading: find the failing request

Do not blindly repeat a payment

The checkout page stays grayed out, a spinner keeps turning or the button never returns to normal. This symptom means the browser’s workflow has not finished. It does not prove the order failed or the provider collected nothing. The desired result is a usable page, one order and the correct payment outcome.

If blocking occurs after Place order, first open WooCommerce, Orders in another administration window. Search for the purchase by time, amount and customer. Also check the transaction in the payment provider’s dashboard with the necessary permissions. Reconcile any existing order or identified charge before requesting another attempt.

This guide concerns a WordPress store already using WooCommerce, not WordPress core alone. A store administrator must be able to read settings, orders and logs. Network or hosting access may be required to fix a server block. On WordPress.com, store menus may be accessible through WP Admin; server-log access depends on the service.

The examined WooCommerce version is 11.2.1, free and published by Automattic. It declares minimum requirements of WordPress 7.0 and PHP 7.4, with declared testing through WordPress 7.1.4. Payment gateways and shipping modules have their own versions and compatibility requirements. No gateway replacement is necessary to begin diagnosis. These compatibility minimums are not a recommendation to use an old PHP branch.

Record the exact point where the page stalls

Distinguish three moments: opening the page, recalculation after an address or shipping change, then final submission. If blocking occurs before any submission, examine cart loading and required services. If it happens after Place order, also examine order creation and the payment call. Do not mix these scenarios within one test series.

Record the affected product, quantity, destination address, shipping method, payment method and login state. Use test data when reproducing. A problem limited to one shipping zone differs in scope from a page unusable for every cart. Information already reported by a customer may be enough to guide the first log review.

Prepare an isolated copy for changes that could interrupt sales. It must use a separate database. Disable customer email, notifications to real applications and commercial integrations before testing. Disconnect live gateways or use their documented test mode with its own credentials. If test validation depends on an incoming provider notification, retain only that correctly configured test route: blocking all notifications would prevent payment verification.

Then choose the route matching collected evidence. A wrongly assigned page is corrected in page settings. A cached response calls for a targeted exclusion. A script or server error calls for locating the responsible component. Changing theme, cache and payment simultaneously would prevent identifying which correction works.

Read the request that never finishes

In Chrome, open developer tools, then Network before the scenario. Enable Preserve log. Look under All for a blocked document or script, then Fetch/XHR for checkout exchanges. Clear only the displayed list and reproduce the trigger once on the safe copy. For a blocked production page, first read existing requests without another submission. If tools were just opened, missing history is not recovered automatically.

For classic checkout, look for requests containing wc-ajax=update_order_review during recalculation and wc-ajax=checkout during submission. The Checkout block uses the Store API with paths under /wp-json/wc/store/; cart and checkout exchanges may appear separately. Another integration may add its own requests.

Click the pending or failed entry. Under Headers and Response, record the sanitized address, method, status, duration and response. Status 200 is insufficient: JSON may report a business rejection, or HTML may replace expected data. Do not replay a checkout submission with Replay XHR or a copied command. A HAR export may contain cookies, tokens and customer data; share only necessary details after removing this information.

Also open Console, clear old entries and record the first relevant error at the same moment. Later errors may be consequences. Note the affected file or domain. Do not paste a forum command into the console to force payment completion or hide the indicator.

If the Store API reports an invalid nonce, a request-verification token, investigate a stale page or session mismatch. After correcting cache on the copy, reopen the workflow to obtain a consistent session. Do not add a snippet disabling nonce verification: that would hide the cause by removing protection.

• A 403 response calls for investigating a security or authorization denial at the same time.
• A 404 response calls for checking the path, redirects and routing.
• A 500 response calls for reading corresponding server errors.
• A request remaining pending calls for investigating a server delay or external service.
• A login or maintenance page in the response calls for checking the layer replacing the expected response.

Route 1: find the checkout page actually used

1. This route fits when the wrong page opens, a builder shows an old form or requests do not match the expected checkout type. Under WooCommerce, Settings, Advanced, record the page assigned to checkout. Open Pages, All Pages, then edit that exact page. Preserve its original content before changing it.
2. Examine the editor’s List View. A Checkout block indicates block checkout. A Shortcode block containing the WooCommerce form indicates classic checkout. A builder module may use another integration: check its documentation and compatibility without assuming it behaves like the native block.
3. If the wrong page was assigned, choose the already prepared correct checkout page in advanced settings and save. Cart, Checkout and My Account pages must retain distinct functions. Do not create a second payment page for every test or place two competing checkout forms on one page.
4. If content was replaced, first work on the copy with the saved version. For the already selected classic route, add a Shortcode block to the assigned page and paste only the code below; use Update or Save according to the editor. Check no second form remains. For block checkout, restore its intended Checkout block. Do not automatically replace the block with a shortcode: gateway compatibility may differ.
5. The expected result is an assigned page loading the intended form and requests consistent with it. Rollback restores the initial assignment and saved content without restoring every order in the database. If assignment was already correct, retain it and continue with network evidence.

[woocommerce_checkout]

Route 2: remove the dynamic page from shared cache

1. This method applies when the response contains a stale copy, behavior differs between visitor and administrator or diagnosis confirms caching of checkout exchanges. Start with systems already used: plugin, hosting cache, CDN or proxy. Installing a second cache does not help explain the first.
2. Cart, Checkout and My Account pages must remain dynamic. Check their actual addresses in WooCommerce advanced settings, including any subdirectory or language prefix. An exclusion targeting only /checkout/ does not cover a French page named /commander/. Also check that relevant WooCommerce exchanges do not receive a response shared between visitors.
3. If LiteSpeed Cache is already present, open LiteSpeed Cache, Cache, then Excludes. Under Do Not Cache URIs, add only missing actual paths, one per line, retaining existing entries. Save. The integration may already exclude these pages; do not multiply entries if the response shows they are not cached.
4. Under LiteSpeed Cache > Toolbox > Purge, find Purge By…, select URL, enter affected addresses one per line, then Purge List. This purges pages, not their CSS/JS files. If hosting or CDN cache still serves the document, also remove copies of those addresses in that service. Purging one level does not prove others are current.
5. The expected result is a response specific to the customer’s session and completed recalculation. Inspect available headers, such as X-LiteSpeed-Cache when exposed by that layer, and received content. A cache miss means only that this response was not served from that cache; it does not prove permanent exclusion. Confirm the rule and session checks. Remove only ineffective added exclusions; never reenable public caching of customer data to obtain a performance score.

Isolate a JavaScript transformation without adding a plugin

A checkout script may load but execute too late, be combined in the wrong order or be blocked. This differs from a fatal server response. If the console identifies a script or the problem followed optimization, compare the page without that transformation on the isolated copy.

With LiteSpeed Cache already in use, open Page Optimization, then Tuning. Add the exact checkout page path to URI Excludes to exclude it from page optimizations, then save. This differs from Do Not Cache URIs: one concerns transformations, the other stored responses. One exclusion does not necessarily replace the other.

Purge the affected page. If stale optimized files are involved, use Toolbox > Purge > Purge All - CSS/JS on the copy, knowing this purges generated resources across the site. It does not delete media or orders. Reload the scenario to regenerate what is necessary. If the failure disappears, reintroduce transformations one at a time on the copy to identify the responsible function.

Free LiteSpeed Cache 7.9.2 by LiteSpeed Technologies was checked: declared minimums are WordPress 6.0 and PHP 7.4, with testing through WordPress 7.1.4. Here it serves only as an example of configuring an existing tool, not an installation recommendation. Its server-cache features depend on a compatible environment.

The expected result is working checkout with the responsible transformation excluded. If nothing changes, remove the added line and return to initial settings before the next analysis. Do not globally disable consent, the firewall or browser security policy to make a script error disappear.

Route 3: locate the failing component in logs

1. If the request fails server-side or exclusion changes nothing, open WooCommerce > Status > Logs. Under Browse log files, filter the date and relevant source, then open the file. Fatal PHP errors may appear under fatal-errors. Absence of an entry there does not rule out failure in another layer.
2. Read several lines around the event. Record the error type, cited file, time and order ID if present. An old warning unrelated to the request is insufficient to identify a plugin. If the error reports exhausted memory or a specific timeout, send that message to hosting instead of raising every limit without measurement.
3. Under WooCommerce, Status, System Status, obtain the report for private diagnosis. It helps compare versions, overridden templates and active components. Remove sensitive data before sharing. For a request blocked before WordPress, also ask the administrator for firewall, web-server or proxy logs at the same time.
4. On the isolated copy, open Plugins, Installed Plugins and deactivate the identified component if the scenario can still work without it. For an essential gateway, instead use a documented minimal combination and its test mode. Retain WooCommerce and dependencies necessary to reproduce. Preserve the active-component list before comparison.
5. Then reactivate the component and check whether the same failure returns in the same scenario. One successful test after several changes does not prove a specific conflict. If the theme is suspected, change it only on the copy using an already available compatible theme; do not publish this appearance change as a mere experiment.
6. The expected result is a reproducible cause or usable server message. Correction may be a compatible update, component setting or targeted change supplied by its developer. Restore elements that are not responsible. Never copy the entire test database to production to deploy a file correction: it could overwrite recent orders.

Handle a slow service based on the observed request

If the browser waits persistently, correlate the request with external calls: shipping, taxes, payment or transactional email. The blocking point helps choose. Shipping calculation is not repaired by changing notifications, and slow email after order creation does not justify removing payment validation.

Consult the actual service’s log and official status. A rejection must be handled according to its cause: permissions, configuration or documented restriction. Disable neither TLS verification nor authorization checks to obtain an artificial response. A network delay or external outage needs a different correction from an invalid key.

If a sending delay is confirmed, the examined version offers Deferred emails under WooCommerce > Settings > Advanced > Features. On the copy, record the initial state, enable only this option and save. Under Status > Scheduled Actions, verify corresponding email actions complete and check receipt at a test address. If inconclusive, restore the initial option; monitor already created tasks, which this rollback does not automatically delete. This setting does not fix loading blocked before submission.

If the cause remains beyond your access, provide checkout type, time with time zone, request, status and corresponding error with secrets removed. This targeted request lets the administrator fix a specific rule or service. It follows available checks without replacing diagnosis of the page and response.

Validate one complete order and preserve rollback

After each correction, repeat the same product, address and payment method in test mode. First verify totals and shipping recalculate. For a final-submission failure, then complete one test order and check the result page and WooCommerce entry.

Verify only one order matches this test and its status agrees with the test transaction. A disappeared spinner is insufficient if the final response is missing or orders are duplicated. Conversely, an order correctly created but pending after funds were collected belongs to payment reconciliation, a separate diagnosis.

Document the retained value, affected components and settings restored to their initial state. Before deployment, prepare rollback of only the correction: page assignment, exclusion or compatible component version. Preserve new commercial data; global restoration is not equivalent to undoing a setting.

On the live store, then check actually authorized workflows for visitors and logged-in customers without creating a series of real purchases. The desired result remains concrete: the request finishes, the page confirms the correct operation and commercial tracking leaves no ambiguous payment unresolved.

Distinguish Store API tokens in a custom integration

If the store uses custom development around the Checkout block, the maintainer must identify the actual cart-tracking method. POST cart requests and Store API checkout requests normally require a valid nonce; an integration using a Cart-Token follows WooCommerce’s intended alternative route. Neither mechanism is diagnosed by pasting an administration token into the console.

For a nonce-based route, the client must account for the new Nonce header returned after a successful request. A cached page or client indefinitely reusing an old value can produce rejection. The maintainer compares initialization, response and next request on a copy without retaining secret values in a report.

For a Cart-Token route, they check the same cart is identified throughout the sequence. Replacing the token with one from a new session may remove items instead of fixing checkout.

The expected result is a request sequence consistent with one session, then one test order. Correction belongs in the identified client or cache. Do not disable nonce checks or add a generic authentication plugin: the native block and Store API documentation already supply the appropriate mechanism.