Stay on the classic checkout if your store has real customizations, depends on a gateway or plugin without block support, or is making money and nobody is asking for a change. Move to the block checkout if you are building a new store, your customizations are light, and your gateway and shipping plugins list block support. The block checkout is where WooCommerce is heading and it has been the default for new stores since version 8.3, but for an established store the migration is a rebuild of everything you did to the old one, and that cost has to be earned back.
How each one is built
Classic checkout
The classic checkout is a shortcode rendering PHP templates. Every part of it is reachable from PHP: the fields through a filter, the layout through template overrides, and dozens of action hooks before and after each section. A developer who knows WooCommerce can add a field, hide it for a customer role, validate it, save it to the order, and show it in the admin and the email with a small plugin. More than a decade of plugins and snippets assume this model.
Block checkout
The block checkout is a React application. The page contains a block, the browser fetches cart and checkout state from the Store API, and the form is rendered client-side. PHP hooks that changed the classic form do nothing here, because there is no PHP form. Customization happens through JavaScript extensions built with WooCommerce's block packages and registered into the slots the checkout exposes, plus a PHP API for registering additional fields with a limited set of field types and positions. Server-side logic, like validation and saving data to the order, still lives in PHP, but it attaches to Store API endpoints rather than to form submission.
The practical difference: a classic customization needs a PHP developer. A block customization needs a developer comfortable with React, a build toolchain and the Store API, plus the PHP side. That is a smaller pool, and the work takes longer for the same result. If you hire a WooCommerce developer for block work, ask to see a block extension they have shipped.
Which plugins and gateways support which
Every gateway supports classic. A gateway supports block checkout only if its developer has written the JavaScript integration and registered it, and WooCommerce shows a notice in the admin when an active gateway is incompatible. The large gateways did this early. Regional gateways, bank-specific integrations, and anything not updated in the last couple of years often have not. The same applies to checkout field editors, conditional field plugins, delivery date pickers, gift options, and most other plugins that touch the checkout page: many were built for the classic form and either do nothing on block checkout or have a separate, less complete block mode.
Before deciding, list every plugin that adds something to your checkout and check each one's documentation for block support. Then do it again for anything that reads the order afterwards, because a field saved through the block fields API may be stored under a different key than the classic plugin used, and reports, exports and fulfilment integrations may be looking in the old place.
What migrating heavy classic customizations really means
It means rewriting them. There is no converter. Each feature is inventoried, the ones that map onto the additional fields API are re-registered through it, and the rest are built as block extensions in JavaScript with matching PHP on the Store API side. Anything that changed the order of the form, injected content between sections, or altered behavior based on the cart contents is in the second group. Block extensions ship as plugins, which makes them custom plugin development in their own right. Payment and shipping plugins without block support are replaced, which can mean a new merchant account and a new settlement schedule. Then the whole thing is tested against every combination that mattered before: guest and logged in, each shipping method, each gateway, coupons, each customer role. Budget it as a checkout rebuild, because that is what it is. Our WooCommerce checkout customization service covers both models, and the estimate says which one we recommend for your store and why.
When to stay on classic
- A gateway or shipping integration the business depends on has no block support.
- Your checkout has more than a handful of custom fields, or conditional logic tied to products, roles or destinations.
- B2B features: purchase orders, net terms, company accounts. Most of that ecosystem still assumes the classic form.
- Conversion is fine and the ask is a visual refresh. Restyling the classic checkout is cheap. Rebuilding it is not.
- Nobody on your side can maintain a JavaScript build, and you do not want to pay someone to.
Classic is not going away this year. WooCommerce still ships and maintains the shortcode checkout, and a store can run on it for a long time while the block ecosystem catches up.
When block checkout is worth it
- A new store, where there is nothing to migrate and every plugin can be chosen for block support from day one.
- Light customization: a couple of extra fields, custom styling, express payment buttons.
- You want the built-in behavior: inline validation, express payments, local pickup and shipping selection that work without extra plugins, and that improve with each WooCommerce release without you paying for it.
- Your roadmap includes features WooCommerce is building only for blocks, and you would rather be on the platform they are investing in.
What a conversion-focused checkout actually needs
Whichever you choose, the checkout that converts is the one that asks for the least and hides nothing. Concretely:
- Guest checkout on, with account creation offered after the order rather than demanded before it.
- Every field justified. If nobody downstream uses a field, remove it. Company name, second address line and order notes are the usual candidates.
- Shipping cost and delivery expectation visible before the customer reaches the payment step, not revealed at the end.
- Errors shown next to the field, at the moment of the mistake, in plain language.
- The payment methods your customers already use, including at least one express option on mobile.
- A page that responds quickly on the server. Page caching cannot help here, so a checkout with a slow time to first byte loses people while they wait for the form to appear.
- Nothing that surprises: no unexpected fees, no pre-ticked newsletter box, no upsell that moves the button.
Most of that is possible on both checkouts. The difference is what it costs to get there, and that is what should decide the question.
Common questions
Can I switch back from block checkout to classic?
Yes. Replace the checkout block on the checkout page with the classic shortcode and WooCommerce uses the old form again. Data already collected through block extensions stays on the orders, but any block-only customization stops showing.
Does the block checkout convert better than classic?
Not on its own. Its layout and defaults are good, and stores that had a cluttered classic checkout sometimes improve from the reset alone, but the same reset is available on classic. Test with your own numbers rather than trusting either camp.
Can I add a custom field to block checkout without JavaScript?
For simple fields, yes, through the additional checkout fields API in PHP, which supports a few field types placed in the contact, address or order sections. Anything conditional, anything outside those positions, or anything with custom behavior needs a JavaScript extension.
Who should build a block checkout extension?
A developer who has shipped one before. The toolchain and the Store API have specifics that a general React developer and a general WooCommerce developer will each meet for the first time. Ask for an example before you commit, and ask who will maintain the build after handover.
Next step
Send us your checkout URL and the list of plugins on it through start a project, and we will tell you whether we would stay on classic or move.
Want a senior developer to look at your site?
Tell us what you need. You get a written scope and a fixed price, usually within one business day.
