WooCommerce Checkout Blocks: Default by Design, Rollback for Compatibility

The direction is settled. The rollout risk is not.

WooCommerce has been clear about where it wants stores to go: Cart and Checkout blocks are the modern default. Its documentation says stores created after version 8.3 in November 2023 get the block cart and checkout by default, and block-theme stores can customize those templates without extra setup.

What matters for real stores is the second half of that same guidance. WooCommerce still documents the rollback path prominently: both Cart and Checkout blocks can be converted back to Classic Shortcode, and if you revert one, Woo says you should revert both. That is not how a platform writes docs when edge cases are rare. It is a practical acknowledgment that compatibility issues still show up often enough to need an operational fallback.

For stores with older payment gateways, checkout-field extensions, and custom hook-based behavior, that gap is where the work starts. This is not a visual refresh. It is a compatibility project tied directly to revenue flow.

Payment issues surface early, and they are not cosmetic

The Checkout block docs are direct about how payment methods work. The Payment Options block only shows methods that are both available in the store and compatible with the Checkout block based on gateway configuration. The same page says the Express Checkout block only appears when an active gateway supports express checkout.

That changes the commercial risk. Moving to block checkout does not just alter page structure or styling. It can change which payment options a customer actually sees at the point of purchase.

WooCommerce makes that risk even clearer in its broader Cart and Checkout documentation. If a store uses the checkout block and all active gateways are incompatible, no payment methods will be available at checkout and a warning is shown. Woo also notes that incompatible extensions can cause checkout elements to disappear or fail to appear as expected, including payment gateways.

For a merchant, that is the key distinction. This is not a minor frontend defect. It is a broken purchase path.

Checkout add-on debt is still blocking stores in 2026

The Checkout Add-ons documentation gives a concrete example that many stores will recognize immediately. WooCommerce says that as of version 8.3, Cart and Checkout blocks are the default experience, but Checkout Add-ons has not yet been updated for compatibility with those blocks, so stores are advised to revert to Cart and Checkout shortcodes.

That matters because this plugin is not doing anything exotic. The same documentation describes familiar order-level additions such as tips, gift wrapping, rush handling, gift messages, and other fields customers can adjust during checkout.

For stores that rely on those fields for margin, fulfillment, or operational data, the decision is not aesthetic. If that add-on logic does not survive the block flow, the safer path may still be classic checkout. Someone has to verify what the store depends on, confirm what still works inside blocks, and decide whether rollback is the lower-risk option.

Gateway compatibility is still uneven

The SkyVerge compatibility page is useful because it shows the problem in a way most store owners and operators can act on. Updated on February 20, 2026, it still lists a mix of DONE, PENDING, YES, and NO states across extensions.

Some of the examples are straightforward. Local Pickup Plus is listed as not compatible with either Cart or Checkout blocks. Measurement Price Calculator is listed as incompatible with Cart blocks and compatible with Checkout blocks, with an extra note that the cart becomes incompatible when Track Inventory is enabled. Checkout Add-Ons is listed as not compatible with either block and still pending.

The same page also says Apple Pay and/or Google Pay setups are not WooCommerce Blocks compatible at this time for gateway plugins that offer those express methods. It adds that Apple Pay can still be used with the Checkout shortcode option, but not with Cart and Checkout blocks at the moment.

That is the kind of detail that gets missed in broad migration discussions. A store can look generally gateway-compatible on paper and still lose wallet behavior that matters to conversion once the live checkout flow changes.

Why this becomes paid cleanup work

The developer documentation explains why a plugin status check is rarely enough. WooCommerce's Cart and Checkout extensibility guide, updated May 25, 2026, shows that support for blocks follows a different technical model. On the frontend, integrations may require a block of their own or filters that modify existing values. Developers can import WooCommerce block components and checkout utilities. On the backend, Woo says PHP can still modify the server-side portion of Cart and Checkout blocks, but some actions and filters from the shortcode experience will work and some will not.

That technical shift matters commercially because many older stores depend on exactly those assumptions. WooCommerce's own main documentation says extensions that use hooks to render extra markup in cart or checkout pages, including custom checkout fields, usually need integration work to support Cart and Checkout blocks.

Once that is true, the job stops being “turn on the new checkout” and becomes much more familiar consulting work: audit the stack, identify where behavior breaks, implement the necessary changes, and test the whole flow before it reaches customers.

The cart side adds more regression surface than teams expect

Checkout is where revenue risk becomes obvious, but the Cart block adds its own layer of testing. WooCommerce says most blocks in the filled-cart state are locked because they contain dynamic content. It also notes that the older Cross-Sells block was soft-deprecated in WooCommerce 10.2 and replaced by the Product Collection block.

At the same time, some areas remain editable. The cross-sells section can still be removed or rearranged. In Cart Totals, the order summary heading and coupon form stay unlocked. The Proceed to Checkout block also includes a setting that can change where the button sends the shopper.

None of that is inherently problematic. It just widens the list of things that can regress when a store changes cart architecture: theme assumptions, CSS, merchandising placement, coupon visibility, and even button routing. For existing stores, migration cost is rarely limited to accepting the new default.

What a practical remediation engagement looks like

Inventory the live gateway, wallet, shipping, pickup, pricing, and checkout-field extensions, then verify which ones are explicitly marked compatible with Cart and Checkout blocks on their WooCommerce product pages.
Test actual purchase paths, not just the editor view: card payments, express wallets, local pickup behavior, coupons, cross-sells, checkout add-on fields, and any flow that changes order totals or required customer data.
Decide whether the store can safely stay on blocks or whether both Cart and Checkout should move back to classic shortcodes until the missing compatibility is resolved.
Patch theme and extension assumptions where needed, including layout adjustments, hook replacements, and integration work required by the block extensibility model.
Retest the full buying journey before traffic is sent to a checkout missing payment methods, wallets, or order-level fields.

That is a credible service gap for Greg to fill. The value is not hype around blocks. It is clear decision-making about where the block flow is production-safe, where classic shortcodes are still the safer option, and what needs to be fixed before checkout issues start costing money.

The useful way to think about checkout blocks now

WooCommerce has made block checkout the default direction. The 2026 documentation also makes it clear that compatibility boundaries are still active and operationally important. Payment methods can disappear when gateways are not block-compatible. Express wallets still have plugin-specific gaps. Checkout field extensions can still force a shortcode fallback. Hook-based customizations often need integration work to survive the move.

So the real question is not whether blocks are the future. They are. The question is whether your current extension stack can preserve the checkout behavior your store depends on today. If that answer is unclear, block checkout is still a paid compatibility cleanup project, not a free upgrade.