WooCommerce Checkout block or classic shortcode

Find the assigned page, then the block or the shortcode

WooCommerce's advanced settings say the store assigns the Checkout page at WooCommerce, Settings, Advanced, under page setup. Customers cannot check out if no Checkout page is assigned. The Checkout block guide repeats that the page has to be designated there before the block works as the store checkout. Start with that assignment. A Checkout block placed on some other URL is not, by itself, the store's checkout.

WooCommerce's current editor articles do not describe a single set of clicks for every theme. The checkout-page article tells a block theme to open Appearance, Editor, Templates, WooCommerce, and the Checkout template, and tells a non-block theme to edit the Checkout page under Pages. The cart-and-checkout article describes Appearance, Editor, Pages for a block theme. Use the path that matches the theme on this store, then open List View. A Checkout block means the block checkout. A Classic Shortcode placeholder, or the checkout shortcode, means the classic checkout. If you cannot see either, stop and ask the person who maintains the site.

You can record what that screen shows. You cannot record a type you have not opened. Reading this page does not change the live checkout.

The two checkouts WooCommerce documents

WooCommerce's Checkout block guide describes the block as the container for customer details, shipping and delivery, payment methods, and order review. Its cart-and-checkout guide says that for stores started after WooCommerce 8.3 in November 2023, the Cart and Checkout blocks are the default and do not need setup to function. That default does not tell you what an older store, or a store someone already converted, is using today.

The same guides call the other experience the classic cart and checkout. The editor transform turns the Checkout block into a Classic Shortcode placeholder. Advanced settings name the checkout shortcode, `[woocommerce_checkout]`, as the classic checkout that shows terms inline. Those are the two types this page compares. A page builder or a different plugin can present something else. If the assigned page matches neither description, write unknown rather than forcing the label.

Neither type is documented here as universally better. WooCommerce also says the blocks work with the cart: if you revert, revert both the cart and the checkout. This page does not tell you to do that revert.

List the behavior the current type is actually doing

Payment methods: the Checkout block guide says Payment Options shows methods that are available in the store and compatible with the block, according to the gateway settings. The cart-and-checkout guide says an incompatible gateway may not appear on the block checkout, and if every enabled gateway is incompatible, that checkout can show that no payment method is available. Those sentences are about the block. They do not say what the classic shortcode will display. A gateway's own settings still apply on either type, and only that gateway's documentation can say the method appears after a switch.

The disappearing gateway is the symptom this order of checks is for. A method that was visible on the classic shortcode and is missing after a move to the Checkout block is, first, the compatibility rule above: confirm the migration actually happened on the assigned page, then read the gateway's own block-compatibility statement and its settings, then compare what each checkout type shows for the same cart. While you isolate the difference, leave the store's terms, shipping, coupons, and business description alone. A gateway missing from a new checkout type is a compatibility fact about that integration. It is not, by itself, the provider declining the business, and changing the business description is not a repair.

Buyer controls are not identical. Advanced settings say the classic shortcode shows terms inline, opened from a link, with a checkbox. The block shows a purchase sentence with links to the terms and privacy pages when those pages are set, and the block editor can change that sentence. The Checkout block also has its own terms checkbox setting, a coupon form that can be removed, and express-payment and local-pickup areas that appear only when their settings are on. The block local-pickup option is different from the older shipping-zone pickup the block guide calls legacy.

Custom checkout fields are a separate dependency. WooCommerce says extensions that add markup with hooks, including custom checkout fields, usually need integration work before they support the blocks. Order status, stock, and email still follow WooCommerce's order documentation after either checkout creates an order. Those systems are not converted by renaming the checkout block. Accessibility behavior is not compared here, because the pages above do not state a difference.

Pair every dependency with that vendor's current statement

WooCommerce.com product pages have a Compatibility section for Cart and Checkout blocks. An extension that has declared itself incompatible can show a warning, and a one-click switch to classic checkout, when the Checkout block is selected. That warning is evidence about the extension. It is not an instruction to convert a store that needs the block, and it is not an instruction to convert a store that does not use the extension.

WooCommerce Checkout Add-ons is one checked example, not a stand-in for every plugin. Its documentation says that as of WooCommerce 8.3 the blocks are the default, that this extension has not yet been updated to be compatible with those blocks, and that stores needing it should revert to the cart and checkout shortcodes. It also says further compatibility updates are intended and points readers to its compatibility page for later news. Until that extension's own page says the installed version supports the Checkout block, the add-on is a blocker to moving a store that requires it onto the block. It is not a reason for a store that does not use it to leave the block.

Write the installed version next to the sentence you found. A forum post, or a compatibility claim for a different version, does not fill the gap. If a required behavior remains unverified, pause the proposed change until its support is confirmed. Other completed rows do not resolve that uncertainty; obtain current documentation or written vendor confirmation for the installed version.

Do not convert from a checklist

WooCommerce documents a transform to the Classic Shortcode and says both cart and checkout should be reverted together if you leave the blocks. It does not describe that transform as a backup. Have the person who maintains the site keep a recoverable copy of the current pages before any live change, and have them place a test order that proves the payment method, the required fields, shipping or pickup, taxes, coupons, order creation, and the buyer-facing confirmation. This page cannot run that test.

The order-received endpoint is WooCommerce's confirmation route after what it calls a successful purchase. Confirmation text is still not a reason to skip the gateway record. Proving the change means the gateway and the order agree, on the checkout type you intend to keep.

Confirm who is responsible for any checkout or gateway implementation. Nothing on this page changes your store. A provider's willingness to process a research-only catalog is a separate decision from whether a gateway appears in a block.

Hand the evidence to the people who can change it

The handoff names the WooCommerce version if you know it, the assigned Checkout page, whether List View showed a Checkout block or a Classic Shortcode, each required gateway and extension with its version, the vendor sentence and URL, and the behavior you have not proved. It names who may edit the live page. Unknown version stays unknown.

For a question like this one, Prism's checkout work starts by identifying the assigned checkout and the gateway and extension versions it depends on, before anything is changed. Supported platforms and payment arrangements are confirmed in the consultation, and any change to a live checkout needs an agreed scope and the store owner's authorization. Prism confirms scope, responsibilities, fees, and terms before work begins.

In the consultation request, include the WooCommerce version if you know it, whether the assigned page uses the block or the classic shortcode, the names and versions of the gateways and checkout extensions involved, what the buyer sees, and who maintains the site. Do not send logins, admin credentials, or plugin files through the form.

You can decide that the evidence is incomplete and that no one should switch the live checkout yet. You cannot decide from a count of checked rows that the other checkout is safe, or that a provider will approve the account.

Checkout compatibility matrix

One row is one required behavior. If current documentation or written vendor confirmation does not establish support for the installed version, mark it unverified. Checking rows does not authorize a conversion.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.