WooCommerce Place order button greyed out: what I check

The cart looks fine. Shipping calculated. Then the customer hits checkout and Place order is greyed out, or it looks clickable and does nothing. That is a conversion killer, and it usually lands on my desk as “checkout is broken” with no extra detail.

I treat a dead Place order button as a validation or JavaScript problem first, not a theme redesign. Below is the order I work through on live Woo stores before I start flipping gateway settings during trading hours.

Confirm it is greyed out, not just failing silently

Ask for a screenshot or a short screen recording from an Incognito window. A disabled button (opacity down, cursor blocked) is different from a normal-looking button that throws a console error. I also check mobile Safari and a desktop Chromium browser, because some themes only break on one viewport.

If the button works for logged-in admins but not guests, I immediately look at required account fields, guest checkout settings, and plugins that gate checkout by role.

Required fields and the terms checkbox

Woo will not enable Place order until required billing and shipping fields pass client-side checks. A custom checkout field marked required, a phone rule that rejects UK formats, or a postcode validator that hates BFPO and Irish codes will leave the button dead with almost no visible error on some themes.

I fill every field slowly and watch for red outlines or tiny “required” text under the fold. The Terms and Conditions checkbox is a classic: themes hide it, or a GDPR plugin moves it, and shoppers never see why Place order stays locked.

Payment method selected and gateway scripts loaded

If no payment method is selected, or the selected gateway’s fields are incomplete (empty card iframe, Apple Pay not available, “Additional information” still open), Woo keeps Place order disabled. Stripe, PayPal, Klarna, and local banking plugins inject their own scripts. When those scripts fail to load, the button never unlocks even though the radio looks selected.

I open the Network tab, filter for the payment plugin, and confirm the iframe or SDK returned 200 on production (not a blocked staging key). A gateway still pointed at test keys on a live site is another common cause.

JavaScript errors on the checkout page

One uncaught error higher on the page can stop Woo’s checkout scripts from binding the button. Theme custom JS, a broken tag manager container, a chat widget, and an old jQuery migrate warning that turned into a hard error after an update all show up here.

I load checkout with the console open, clear the log, refresh, then interact with shipping and payment. The first red error that appears before I click Place order is the lead. Fix that before blaming Woo core.

Cache, minification, and “optimize JS” plugins

Full-page cache on /checkout/, deferred jQuery, and aggressive JS combine plugins regularly break Place order after a “speed” tweak. The admin places a test order while logged in (cache bypass) and swears it works. Guests hit the cached, broken bundle.

I exclude cart and checkout from page cache, turn off JS combine for Woo scripts on a staging clone, and retest as a guest. When the button comes back, I re-enable optimisations one at a time instead of leaving checkout uncached forever without knowing which rule caused it.

Checkout blocks versus classic shortcode

Stores mid-migration between classic shortcode checkout and Cart/Checkout blocks see half-working buttons: block checkout expects different payment method registration, and some gateways only support one path. A page that still embeds both, or a theme override fighting the block, leaves Place order in a weird disabled state.

I check whether the checkout page uses the block, the [woocommerce_checkout] shortcode, or a page builder widget, then match the payment plugins’ documented support for that setup.

Plugin conflicts that rewrite checkout validation

Field editors, multi-step checkout, conditional logic, CAPTCHA, address autocomplete, and “one-page checkout” add-ons all hook the same validation events. Two of them fighting over required fields is enough to grey out Place order permanently.

On staging I disable non-essential checkout plugins, retest as a guest, then re-enable until it breaks again. When I find the pair, I read their checkout settings rather than deleting the live order form by hand.

When to stop guessing

If Place order is dead for every guest, the console is clean, every required field is filled, a payment method is selected, and it still only works while you are logged in as admin, stop shotgun-deactivating plugins on production mid-afternoon. At that point you want a staging clone, a guest session recording, and someone who has traced Woo checkout validation before.

Most of these tickets come down to a hidden required field, a terms checkbox, a payment script that never loaded, or a cache plugin mashing checkout JavaScript. Confirm the guest path first, then fix the validation so the next shopper can actually place the order. Cheers.