Checkout not working: find the step that fails

A shopper moves through checkout in a fixed order: contact, address, shipping, payment, review. Each step can fail for a reason that lives in another system. The address step may reject a postal code format that the store's own rules accept. The shipping step may show a blank list because no rate covers that country, which looks like a slow page rather than an error. The payment step may refuse a discount the server already counts as used. The shopper sees a button that does nothing, then leaves. An owner who tests while logged in, with a saved address, never reaches those rules.

• Does the address step accept a ZIP code from another region, or show a message under the field?
• Does the shipping step list at least one option for a guest in a country you ship to?
• Does a discount code change what the Place order button does, or stop the step from moving on?
• Does the browser console show a red error at the step where the page stopped responding?
• Does the last step name the exact field or rule it rejected, or only say something went wrong?

Start with an empty cart and a guest session. Go to the cart, press Check out, and fill in each step with the details a new customer would use, not the ones saved on your own account. Write down the step name and what the page shows at the moment it stops: a spinner, a message, a disabled button, or a page that reloads with the fields cleared. Most failures look like a page that froze, but the step that froze is usually the one where a rule runs on the server. The address, shipping and discount steps each call the server, so their failures can look alike from outside.

The Network tab in the browser's developer tools tells the two apart. Press the step's button with the tab open and read the request that fires. A request that returns 400 or 422 with a message in its body is a rule the server enforced, such as a discount that is used up or a postal code the store does not accept. A request that returns 500 is the server failing, and the store's error log will show it. A request that never returns is a hang, usually a shipping or tax lookup to another service.

No request at all is a different case. If the button press sends nothing, a script rejected the input before it reached the server. The Console tab shows that as a red error on the same press, often naming a file from an address or payment widget. Write down the exact step, the status code and any message text. Those three details are what a developer needs, and they are what a fix prompt needs too.

A store owner usually checks out while logged in. The address is saved, the shipping option is remembered, and a discount from last month may still sit in the cart. A guest has none of those saved, so a shopper without a saved address meets the address form first, then a shipping lookup your account never triggers. Run the same checkout from a private window, signed out, with an address in a country you rarely ship to. The two runs differ at the step where the guest stopped.

A simulated test sends a visitor who arrives from a search or an ad, has never been to your store, and goes through the steps in order. You name the start page and the task, and the run records each step, the errors on it and a screenshot. The run ends at the payment step, because a visitor cannot pay with a real card. A checkout that requires sign in with Google stops the run at that screen, because a visitor cannot sign in that way.

Checkout flow testing

A new shipping zone, a tax rule or a coupon limited to some countries can stop checkout the week it goes live, and only for shoppers in one place. Rerun the same guest shopper after each change and compare the step where they stopped. Owners also test a store behind a site password, and check each preview deploy before a sale starts.