The notice about the new block-based checkout in your WooCommerce admin is not an order to click right away - it is a decision you can make calmly, knowing in advance what might break. The WooCommerce block checkout, an order page built from blocks instead of the old shortcode, is where the whole platform is heading. But being the direction of travel does not mean your store has to be there by tomorrow morning.
This piece is for a store owner facing one question: switch, or stay on the classic checkout. I am not covering how to add a field in code, how to shorten the form or how to fix a checkout that has already failed - those are separate topics, and I link to each of them below. This is about the decision itself, and how to make it without putting sales at risk.
How the block checkout differs from the classic one
The classic checkout is a page holding the [woocommerce_checkout] shortcode. PHP builds the form on the server, and plugins and themes have been modifying it with their own actions and filters for years. Most of the live stores I work with still run this version - because that is how they were built.
The block checkout is the same page assembled from blocks in the WordPress editor. The form renders in the browser and talks to the server through a separate store API. For the customer the difference is often small - they see a checkout, type their details, pay. For you the difference is large, because the way plugins hook into the form changes.
Three facts from the WooCommerce documentation frame this decision:
- New stores get blocks by default. Stores set up after WooCommerce 8.3 start straight on the cart and checkout blocks. If your store is older, you are most likely still on classic.
- Not everything from the classic checkout works in blocks. The developer documentation says plainly that some of the shortcode actions and filters work in the blocks, but not all of them. So every customisation of your checkout is an item to check.
- Extensions are expected to declare compatibility. A plugin that changes the cart or checkout should declare whether it is compatible with the blocks. When an active extension declares itself incompatible, WooCommerce shows a warning in the checkout block settings, along with a button to switch back to classic.
Checking which version you have takes a moment: open the “Checkout” page in the editor. A single shortcode block means classic; a set of blocks with a form preview means the block checkout.
The cost of switching: fields, payment and shipping plugins
I will not give a figure, because on this topic it depends entirely on what your store has bolted onto its checkout today. What I can do is show what the cost is made of, so you can judge whether it is a trifle or a project in your case.
Three things generate most of the work:
- Custom fields. A field added years ago with a snippet or a field editor plugin in the classic checkout does not move across by itself. In blocks, fields are registered with a separate function,
woocommerce_register_additional_checkout_field(), in one of three locations: contact details, address or order. Every old field has to be rewritten, or replaced with a plugin that supports blocks. What that looks like on the code side I set out in the piece on custom checkout fields in WooCommerce. - Payment gateways. The WooCommerce documentation notes that an incompatible gateway may simply not appear among the payment methods. That is the most dangerous case, because the store reports no error - the customer just sees a checkout without their usual way to pay.
- Shipping and invoicing plugins. Parcel locker selection, tax ID fields, consents, cash-on-delivery surcharges - anything a plugin adds to the form has to be checked on its own.
Then there are the less visible items: theme CSS written for the classic form, analytics scripts tied to old checkout events, translated messages.
The time involved can only be described in words. When a checkout failure comes down to a conflicting plugin or caching, we are talking hours, not days - and it takes longer when an integration has to be rewritten for the block checkout. I wrote about that in WooCommerce checkout not working. The same logic applies to the switch itself: a store with a plain checkout and compatible plugins is a small job, while a store with several custom fields and a niche gateway is a project I only scope after going through its list of extensions. It all depends on the scope.
How to decide: a plugin list to check and a test on a copy
I always make this decision in the same order, and I recommend it to anyone doing it themselves.
First, the list. Write down every plugin that touches the cart or the checkout:
- Payment gateways - each one separately, including the ones only a small share of customers use.
- Shipping integrations - parcel lockers, couriers, pickup point selection.
- Field editors, invoicing and tax ID plugins, marketing consents.
- Discounts, coupons, loyalty programmes, surcharges and extra fees.
- Your own snippets in a child theme or a small plugin - these carry no compatibility declaration at all, because nobody ever declared one.
For each item, check two things: is it up to date, and does the author declare compatibility with the cart and checkout blocks. Extensions from WooCommerce.com show this on their product page, in the compatibility section. For the rest you have the author’s documentation, or a test.
Then, the test on a copy. The editor warning about an incompatible extension is a good signal, but not the only one - a snippet in your theme will never trigger it. That is why you switch on a copy of the store, not on production, and place real test orders there with every payment method and every shipping method.
That leaves three possible outcomes:
- You switch - every plugin is compatible, test orders go through, fields are saved.
- You stay for now - one or two plugins are not ready, but their authors are working on it. You come back to it at the next round of updates.
- You stay deliberately - the store has an elaborate checkout built in code, and rewriting it now gains you nothing. The classic checkout still works, and the WooCommerce documentation itself describes how to return to it, so this is an honest answer too.
One caveat: switching to blocks is not, in itself, a way to get more orders. If the checkout has too many fields and forces account creation, blocks will not fix that - what genuinely shortens the path is covered in the piece on a shorter checkout.
If you have switched and something goes wrong, there is a way back. The WooCommerce documentation describes it like this: in the editor you select the checkout block, transform it into the classic shortcode and save. There is one recommendation - revert both blocks together, cart and checkout, because they work as a pair.
What I do differently - switching on staging with test orders
On client stores I do not switch the checkout on the live site. Just as with the updates I described in the safe WooCommerce updates checklist, I do it in four steps:
- A backup before anything else. Files and database, restorable - not just “there is a backup somewhere”.
- Staging. A copy of the store at a separate address, invisible to customers and to Google. That is where I switch the checkout and where I look for problems.
- The full purchase path. I place test orders through every gateway and every shipping method, and check that custom field data reaches the order admin and the emails, that it all works on a phone, and that nothing gets lost after changing the shipping method.
- A rollback plan. Before the change reaches production, I know how to undo it - for the checkout that means going back to the shortcode for both cart and checkout, already tried on staging.
Custom fields that need rewriting for blocks go into a child theme or a separate small plugin, never into the parent theme’s files. The code lands in the client’s repository, so after I am gone it is clear what is in the checkout and why.
If you would rather have someone work through this list for you, that is exactly what I do as part of site and store optimization - from the plugin review to the switch on staging and the release.
WooCommerce block checkout - FAQ
How do I add a custom field to the block checkout?
With the woocommerce_register_additional_checkout_field() function, registered when WooCommerce initialises, or with a field plugin that declares block support. An old snippet using a classic checkout filter needs checking - do not assume it will work.
How do I go back to the classic checkout? In the editor, select the checkout block on the checkout page, transform it into the classic shortcode and save. Do the same on the cart page. If an active extension declares itself incompatible, WooCommerce shows a ready-made button for this switch next to the checkout block.
Which plugins do not work with checkout blocks? There is no single fixed list, because authors add compatibility with each new release. You check your own: the author’s compatibility declaration, the warning in the checkout block editor, and a test order on a copy of the store. Snippets without an author you always test.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. See how I work on it: site and store optimization.