WooCommerce Place Order Button Not Working? Causes & Fix
The customer clicks Place order and nothing happens. No spinner, no error, no order. Almost always a JavaScript error has stopped WooCommerce's checkout script from binding to the form — so the click never becomes a request. The browser console tells you which script in about a minute.
Last updated: 16 Jul 2026 · ~6 min read
The most common cause is a JavaScript error — usually from a plugin or theme script — that stops WooCommerce's checkout script binding its submit handler, so the click never fires the AJAX request. Open the browser console at checkout (F12), reload, and look for a red error. The plugin named in the stack trace is your suspect.
What's meant to happen when you click Place order
Place order isn't a normal form button. WooCommerce's checkout script intercepts the submit, validates the fields, and posts the whole checkout over AJAX to /?wc-ajax=checkout. The server replies with JSON, and the script redirects the browser to the Order received page.
That means there are exactly two failure shapes, and telling them apart takes ten seconds in the Network tab. No request at all means the JavaScript never bound — a script error broke the chain. A request that comes back non-200 means the JS is fine and something server-side is blocking it. Everything below follows from that split.
The most common causes (most likely first)
- A JavaScript error stops the checkout script binding the submit handlerOpen DevTools → Console on the checkout page. There's a red error on load, thrown by a plugin or theme script. Click Place order and the Network tab shows no request at all — the click goes nowhere. This is the number one cause by a distance.
- jQuery is missing, deferred or duplicated by an optimisation pluginThe console says something like
jQuery is not definedor$ is not a function. WooCommerce's checkout script depends on jQuery being loaded first — combining or deferring scripts breaks that order. Turn off JS combine/defer for checkout and retry. - The
wc-ajaxrequest is being blocked or redirectedThe Network tab does show a request to/?wc-ajax=checkout, but it returns 403, 404 or a 302 redirect instead of 200 JSON. A security plugin, a WAF rule or a server-level block is eating the request. - Validation is failing on a field you can't seeThe button flickers or a spinner appears briefly, then nothing. Scroll to the top of the checkout — there's usually a notice there, hidden off-screen or behind a sticky header. A required custom field added by a plugin is a common culprit.
- The checkout page is being cached, serving a stale nonceIt works in a fresh incognito window but fails on a normal visit, or fails only for logged-out customers. Checkout must never be cached — exclude
/checkout/and/cart/from page caching entirely.
Where to look first
- Open DevTools (F12) → Console and reload the checkout page. Any red errors before you click? That's cause 1 or 2 — read the file path in the error, it names the plugin or theme.
- Click Place order with the Network tab open. No request appears at all? The JavaScript never bound (cause 1 or 2). A request to
?wc-ajax=checkoutappears but isn't 200? That's server-side (cause 3). - Spinner flashes then stops? Scroll to the top of the page — there is almost certainly a validation notice you can't see from where the button is (cause 4).
- Exclude
/checkout/and/cart/from page caching, and turn off JS combine/minify/defer, then purge and retry. If it starts working, reintroduce the optimiser with checkout excluded. - Still stuck? On a staging copy, deactivate all plugins except WooCommerce and your gateway, confirm the button works, then reactivate one at a time. The one that brings the console error back is yours.
Can't find which script is breaking it?
Bisecting plugins is the honest answer and it's also the slow one — especially when the only place you can reproduce it is a live checkout with real customers in it. DiagnosticIQ's free dashboard checks the checkout render chain, the wc-ajax path and whether your checkout page is being cached when it shouldn't be, then the AI names the concrete break. It keeps watching afterwards, so the next update that kills the Place order button doesn't get to do it quietly.
Made by Prima Digital — the team behind this guide. Free forever; no card to install.
How to know you fixed it
Place a test order with DevTools open — the Network tab should show a POST to /?wc-ajax=checkout returning 200 with {"result":"success"}, and the browser should land on the Order received page.
Frequently asked
Was the customer charged?
No. If the button does nothing, no request ever reached your gateway. Check your gateway dashboard to confirm there's no charge, but a click that goes nowhere cannot take money.
Am I losing orders right now?
Yes — silently. Customers who can't complete checkout rarely email you, they just leave. Treat this as urgent and check your order rate against a normal day.
Why does it work for me but not for customers?
Usually caching. Logged-in admins bypass the page cache, so you get a fresh nonce and working scripts while logged-out customers get a stale cached copy.
Should I switch to the checkout block?
Not as a fix. The block checkout has its own failure modes and migrating mid-incident adds risk. Find the script error first, then decide separately.