Checkout page not loading: find the cause

The shopper taps Check out, and the browser either keeps the old page on screen, shows a blank page under a spinner, or lands on an error. The address bar may change several times before it gives up, which is the signature of a redirect loop. Or the checkout address answers with a server error, because the cart holds a product the store has since deleted. An owner who is signed in rarely sees this, since a session that skips sign in never triggers the same redirect.

• Does the address bar change more than once after you press Check out, and end on the same page?
• Does the Network tab show the checkout request returning a 500, or a chain of 301 and 302 redirects?
• Does a private window with no cookies open the checkout, while your normal window fails?
• Does a verification screen or a 403 response appear in place of the checkout for a signed-out visitor?
• Does the checkout finish loading, or does one request stay pending with no response?

Start at the address bar. Press Check out and watch where the address goes. A checkout that sends a shopper to a sign in page, back to checkout, then to sign in again has a redirect loop. Redirects also cross hosts: a store that moves between the bare domain and the www address, or between http and https, can send the browser around in a circle. The browser gives up with a too many redirects message, and the shopper sees an error that names no cause.

The Network tab shows the same chain as status codes. Each 301 or 302 line is one hop, and the last line is the page that ended the trip. A checkout that returns 200 with a blank body and a long spinner did not redirect at all, so the fault is later, in a script or a request the page waits on. A 500 on the checkout address means the server failed to build the page, often because the cart holds an item that no longer exists in the catalog.

The loop often comes from a cookie. The session cookie is set on the bare domain, and the checkout reads it only on the www address, so every request looks signed out and goes back to sign in. Open the checkout from a private window that starts with no cookies. If it loads there and not in your normal window, the fault is a saved cookie or a saved redirect, and clearing the site data for your own browser will confirm it.

Firewalls and bot protection can answer a request for the checkout with a verification screen, a blank page or a 403 or 429 status. The owner sees the checkout fine, because the firewall trusts the owner's address and session. A stranger on a new network, or a browser the firewall dislikes, gets the challenge instead. Read the response body in the Network tab, since a challenge page means the firewall is speaking, not the store.

A simulated visitor can meet this too. Visitors are browsers at a public address, and a CAPTCHA or bot protection can stop them. A visitor stopped that way is marked as blocked by the site, so the report tells you the firewall answered, not that the checkout is broken. Many firewalls keep an event log of blocked requests, and the entry for this one can name the rule that matched. Read it, change the rule, then test again.

When the page arrives but stays blank, it is usually waiting. The checkout may fetch the cart total, a shipping quote or a tax figure from another service before it draws the form. If that service does not answer and the page sets no time limit on the request, the form never appears. Read the Network tab for a request in the pending state, which shows no response. Your own visits may finish before the other service stalls, so the hang can reach some shoppers and never reach you.

A deleted product, a changed redirect or a new firewall rule can break the checkout address again without any change to the cart page. Rerun the same signed-out shopper after each catalog, redirect or firewall change, and compare the status code of the checkout request.