Cart and Checkout Blocks: Your feedback on most common extensibility requests

The new WooCommerce Cart and Checkout blocks are built with conversions and ease of use in mind. In this pursuit, we have made deliberate design and engineering choices to enhance the overall experience. As a result, this requires a new approach to extensibility, which diverges from tradition hook and filter methods and instead leverages more focused extensibility interfaces to ensure the best developer and user experience.

We’re committed to increasing our investment in this domain to simplify the process of making extensions compatible and facilitating the implementation of their features for a seamless shopping experience. In this article, we’ll provide a concise overview of the most common extensibility requests, link to relevant GitHub discussions, followed by a preview of our upcoming roadmap.

We want your opinion

We have organized these extensibility points into the following categories. You’ll find links to a GitHub Discussion for each of the points below.

  1. Payment gateways integration/customization
    1. Embedded checkout
    2. Read-only billing/shipping addresses
    3. “Place order” button replacement
  2. Shipping methods – calculation changes and customization
    1. Estimated Delivery Dates
  3. Product options and configurations
    1. Per-item inputs or data
  4. Custom checkout fields
    1. Creating additional fields
    2. Editing/Removing existing checkout fields

Payment gateways integration/customization

Embedded checkout

This use-case covers extensions that have their own custom checkout form and want to show that in place of the form we offer.

Currently, we don’t have any way to remove or replace specific inner blocks and the extensions currently doing this use CSS to remove the unwanted blocks which is not an ideal solution.

We have an issue open about this topic


We understand this use case has the following requirements:

  • Extensions must be able to programmatically disable some of our checkout blocks.
  • They should be able to replace our blocks with their own
  • Any custom fields being rendered in the checkout form should be surfaced to the relevant block/block replacement
  • We must allow for extension to stop the checkout process and show notices or errors if any validation errors are present in their replacement blocks

💬 Discussion

Read-only billing/shipping addresses

If you are running a B2B shop, it could be that you only allow synced users from a CRM or similar system to place orders and therefore don’t want to allow WooCommerce users to change their billing and/or shipping addresses.

Making the billing and shipping addresses read-only fields is a good way of achieving this.

In this case, it is also possible that, since they are not editable, the merchant may want to display the information in a more condensed fashion, e.g. an address card, instead of a full form to save space.


  • The developer must be able to set the address fields to readonly.
  • The shopper must not be able to change the data in them.
  • The address may be condensed into a smaller component and the form itself hidden, since it is readonly, opting not to display the form will save space. See the following issue for more information:

💬 Discussion

“Place order” button replacement

Some payment gateways would like to display a different “Place order” button based on specific factors, such as geolocation. In this case, the payment gateway ensures that buyers only get presented with the payment buttons that are relevant to them and the ones they are not eligible for will not be displayed.

As an example, buyer A from country A may be presented with different payment options to buyer B from country B, without the merchant setting up any logic.


  • Developers must be able to replace the “Place order button” with a new component
  • The button may only be replaced by a payment method when that method is the active one chosen by the shopper
  • The original “Place order” button must reappear if the user changes their selected payment method to something else
  • The custom component must also render when a saved token belonging to the payment gateway is selected.

💬 Discussion

Shipping methods – calculation changes and customization

Estimated Delivery Dates

This use-case is for shipping methods that may want to show an estimated delivery time alongside their rates. Here is an example of what this may look like:

A screenshot of the shipping options step of the WooCommerce Blocks Checkout block. Under each shipping method is an estimated delivery date.


  • Shipping extensions must be able to specify an estimated delivery date, or range of dates
  • This estimate must be shown in the shipping methods block. It should show regardless of whether the rate is selected or not.
  • It should not be too distracting from the rest of the checkout process (keep it text-only, for example)
  • Shipping methods should not be able to interfere with rates that do not belong to that method.

💬 Discussion

Product options and configurations

Per-item inputs or data

Each item in the cart may need controls to change settings, or to display some data. For example, a checkbox to indicate a product is a gift, or a text input to enter a custom note for the gift.


  • The developer must be able to add one or more controls to specific cart items to control a value.
  • The configuration requirements must be available to consumers of the Store API, e.g. they must know that there should be a checkbox rendered for each cart item with the label “This is a gift”
  • An extension must be able to conditionally show or hide an individual field (this may depend on a value of one of its other fields too)

💬 Discussion

Custom checkout fields

Creating additional fields

In WooCommerce Core, there is a filter which enables the fields displayed in the checkout form to be modified. Using this filter enables merchants and extension developers to add custom fields to their form to collect specific information that is not usually collected, e.g. VAT Number.

This is a common use case we see requests for fairly often. Some examples:


  • Extensions must be able to define custom fields to force-render in the Checkout block without requiring the merchant to add them
  • Extensions must be able to add a range of optional custom fields that the merchant may or may not add to the Checkout block
  • The custom fields added to the Checkout block must be discoverable by the Store API
  • The merchant/extension must be able to add fields of various types: e.g. checkbox, text field, email, number, select, multi select etc.

💬 Discussion

Editing/Removing existing checkout fields

Similar to the above, WooCommerce core has filters that allow the checkout form to be modified. Using this filter, as well as adding fields, merchants and extension developers can modify existing fields and alter their form, so it behaves differently to the default. This is an extension of the above use case, but we feel that editing and removing will require a separate effort and maybe a different approach to simply adding fields.


  • Extensions must be able to edit existing fields in the Checkout block without requiring the merchant to manually do it.
  • Extensions must be able to remove existing fields from the Checkout block without requiring the merchant to manually do it.
  • The edited fields in the Checkout block must be discoverable by the Store API, it must be able to tell what was edited and its new state
  • Removed fields must be discoverable by the Store API, it must be able to tell which fields have been removed.

💬 Discussion

Exporting WooCommerce Blocks components

We identified that a lot of developers are creating extensions that need specific UI components to function. We also realized that we have already written a lot of these UI components for use in the WooCommerce Blocks plugin. By exporting these, we can reduce the work required by developers to get their extensions working.

We identified the following components as the most important and will work on making these available on the wc global object.

  • CheckboxList
  • RadioControl
  • RadioControlAccordion
  • Label
  • Textarea
  • Combobox
  • FormTokenField
  • SortSelect
  • Title
  • Spinner
  • FormStep
  • Chip & RemovableChip
  • FormattedMonetaryAmount

More details on these components will be available in the GitHub discussion for this work.


You can also keep track of all of our plans for WooCommerce and see what the team is working on right now by viewing the WooCommerce Roadmap.

The roadmap is a living document, and it will evolve as we explore use cases, release new endpoints, and gather feedback from the community.

We’re currently focusing on Custom Checkout Fields and migrating the commonly used components to an easily accessible package for developers to use in their own projects.


We welcome your feedback on our plans, and we are open to suggestions for new extensibility points based on specific use cases.

Each use case listed above has an associated GitHub discussion, and we welcome and encourage anyone with questions, comments, or suggestions to contribute to the discussion.

We ask that requests for extensibility APIs are posted on our GitHub discussions board and that they include a concrete use case. It may be the case that we have something in place to help you already, so knowing the use case is very important.

7 responses to “Cart and Checkout Blocks: Your feedback on most common extensibility requests”

    1. Thanks, Helga. There is a section on Child Products in the doc, but the link was broken. I’ve gone ahead and fixed them.

      1. Thanks Stephanie. Am I missing something? Looks like the heading
        “Product options, configurations, and child products”
        Talks about
        “Per-item inputs or data”

        And then goes right to customizing checkout fields with no mention of child products.

    2. Thanks Helga, we updated the links! I want to let you know that Child Products was removed from this list. This is because there’s a CSS workaround in place now that is being used by plugins. The other points have no workarounds, so we’re prioritising them. We do plan to look at a focused API for child products at some point, it’s just not something that’ll be looked at as part of this effort.

      1. Gotcha! Yes I’m using CSS to style my child items, but was interested in any new info.

        In a different plugin I’d like to be able to add a button after the title (like where to have custom options). Currently the button is added via workaround by PHP filtering it into the product s title.

        1. Thanks for your understanding. Would you be able to open a GiHub discussion about the button and the use case for it? I see you added to our discussion already, thanks! It might be covered by the “Product options and configurations” section, but the more use cases we understand before working on this the better the end result will be.

Leave a Reply

Your email address will not be published. Required fields are marked *