WordPress checkout not working

WooCommerce builds checkout from a page you can edit like any other. That page has to contain the checkout block or shortcode, and WooCommerce has to know which page is the checkout. If someone pastes the shortcode into a text block, the browser shows the bracketed code as words and no form. If the page was duplicated, moved to the trash or rebuilt in a page builder, WooCommerce may still point at the old address, which loads nothing useful.

• Open the checkout page in a private window and read it for bracketed text or a missing form.
• Compare the checkout page's address with the checkout address named in the WooCommerce page settings.
• Confirm the checkout page is published, not a draft and not in the trash.
• Check the checkout address's response headers for a cache marker that shows a stored copy answered.
• Place a test order and read the submit request. A 403 response or a block page points at a security rule.

A shopper with a full cart reaches checkout and sees one of three things. The page loads with no form, so there are headings with nothing under them, which means the page shows text where the checkout should be. The form loads, the shopper fills it in, and Place order returns to the same page with an error notice at the top. Or the page never loads, and the browser reports too many redirects or shows a plain blocked page. Each one stops at a different point, so note which of the three the shopper hit before you change anything.

WooCommerce finds checkout through two things: the page itself, and a setting that names which page is checkout. When the page holds the bracketed shortcode as plain text, the code is never run, and the shopper reads the code instead of a form. When the page was duplicated, moved to the trash or rebuilt in a page builder, the setting can still name the old one, so the checkout address shows an empty page. Open the checkout address in a private window and read it as a shopper would, then compare that address with the one in the page settings.

A cache keeps a copy of a page and serves it to the next visitor without running the page again. A cached checkout is a problem because the cart, the totals and the form belong to one shopper, so a cached page can show a stale total or a form tied to a dead session. Security plugins and web application firewalls inspect the submit request, and they sometimes flag a checkout post as suspicious. The shopper sees the form, presses Place order, and gets a block page or nothing at all. A 403 response on that request is a common sign.

Test the two separately. Load the checkout in a private window and check the response headers for a cache marker. Then place a guest order up to the payment step and read the submit request. If it comes back blocked, exclude the checkout address from page caching and from the security rule that is catching it, then run the same guest order again.

A simulated visitor opens the cart, goes to checkout as a guest, fills in the address and continues to the payment step. The run records a screenshot at each stop, the address the page ended on, and the requests and script errors recorded there. A form that never appears shows as an empty checkout screenshot, and a blocked submit shows its response code on the step where it happened.

The run does not read your WordPress settings or your plugin list, so it cannot say which plugin or rule is responsible. Use the screenshot to pick the stop, then the checks above to pick the cause. Run the same guest order after each change, so you can see whether the stop moved or went away. Keep the same product in the cart each time.

Checkout breaks in the same places after the next change. A plugin updates, a page builder is redesigned, or a new caching rule starts covering the checkout address, and the form disappears or the submit fails. Run the same guest order after each change, before the next campaign sends buyers to checkout.