WooCommerce Checkout Block Support in Twilio SMS Notifications

The latest update to our Twilio SMS Notifications extension—version 1.19.0—introduces support for WooCommerce’s block-based checkout experience.

This update was several months in the making, so we wanted to take the opportunity to give a look into our development experience integrating with WooCommerce’s Checkout block. We’ll discuss the challenges we faced, the decisions that shaped this release, and look at the state of block extensibility in WooCommerce.

WooCommerce Checkout Block Integration – A History

Starting with some historical context, WooCommerce introduced block-based checkout as the default experience in version 8.3 (November 2023).The options for plugins to extend that experience have continued to evolve ever since. For their part, Woo has been cultivating an active discourse around block-extensibility in the developer community, with the stated goal of finding a sweet spot that allows the blocks to incorporate the additional functionality provided by extensions, while still providing a consistent quality experience to site owners and their customers. In practice, this has meant that the new block-based checkout doesn’t have the same extension options as the old shortcode checkout form. Extensibility needs for blocks are openly discussed (and petitioned) in developer channels before being added to the codebase.

With that in mind, we’re sharing our team’s experience as a contribution to this conversation, giving a look into block-extensibility from a plugin development perspective and how SkyVerge plans to approach block-compatibility moving forward.

Case Study: Twilio SMS Opt-in

The Twilio SMS Notifications extension relies on a simple but essential checkbox in the checkout flow that allows customers to opt-in for SMS order updates.

For this checkbox to work as expected, we have to properly record the customer’s selection, store it with the order data, and seamlessly integrate it into WooCommerce’s Checkout Block interface.

Since the integration was relatively simple—without complex logic or advanced frontend interactions—our focus was on finding a straightforward method to add support.

Slot & Fill

One of the first solutions we explored was WooCommerce’s Slot & Fill API. This approach is designed to insert custom content into predefined locations within the checkout and cart blocks. The API leverages WooCommerce’s Integration Interface to register custom scripts for rendering on the frontend, which our team had already used to update several payment gateway extensions, so this method seemed like a natural fit.

However, we quickly encountered a few limitations:

• Existing slots didn’t provide the exact placement we needed for the opt-in checkbox
• Many slots rendered content in both the cart and checkout blocks by default, which was unnecessary for this feature and would have required additional workarounds
• As of this writing, all slot names still carry an Experimental prefix, signaling potential instability in the API

Due to these concerns, we decided to find a different approach.

Custom Child Block

The next integration method we looked at involved registering a custom child block alongside one of the WooCommerce Checkout block’s constituent inner blocks. This method gave us more placement options and maintained the consistency of using the Integration Interface to register a custom script.

By defining our script as a custom block and registering it with WooCommerce’s checkout-billing-address-block as the parent, we were able to place the checkbox directly within the checkout form:

// block.json

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "name": "skyverge/twilio-opt-in",
  // [...]
  "parent": [
    "woocommerce/checkout-billing-address-block"
  ]
}

This tells WooCommerce that the checkbox should appear as a child element any time the checkout-billing-address-block is rendered.

A significant portion of our development time focused on building this child-block integration, which included extending the Store API and creating custom React components with a dedicated build process and bundling pipeline to include the new scripts in the final plugin zip. Unfortunately, just as the integration was nearing release, we discovered another placement issue that required further adjustments.

Placement problems

Initially, our goal was to place the checkbox directly after the billing phone number field in the checkout form, making it clear to customers that they would be opting in to using that number to receive SMS updates. This placement also matched our existing shortcode checkout integration. Registering WooCommerce’s checkout-billing-address-block as the parent seemed like the right approach, as it positioned the checkbox correctly—but only when the parent block was rendered.

The key challenge we encountered was due to a change in the checkout flow introduced in the Checkout block. Unlike the shortcode checkout, where billing fields appeared first, the new Checkout block prioritizes shipping fields. If a customer chooses to use the same address for both, the billing fields might never appear, preventing them from opting in to SMS updates altogether.

We evaluated several parent block options to try to ensure that the opt-in checkbox remained visible, but none provided the same level of clarity regarding where messages would be received. Additionally, child blocks could only be rendered after their parent inner block—never before or within—and some checkout blocks do not support child-rendering at all. While this approach offered more placement flexibility than Slot & Fill, it still failed to consistently position the field where we needed it.

Beyond placement challenges, the child block method introduced a significant maintenance burden, requiring multiple new PHP classes, Store API integration across PHP and JavaScript, and custom React components with their own build and bundling processes. We weren’t comfortable adding this level of complexity for a solution that could lead to customer confusion and increased support inquiries.

Fortunately, by this stage of development, WooCommerce had introduced a simpler method for adding fields to the Checkout block. So it was time to pivot once again.

Additional Fields API

Reviewing the documentation for the Additional Fields API made it clear that this approach offered the the best solution, even if it meant scrapping a significant amount of our previous work. While the available placement options still didn’t fully align with our existing implementation, placement challenges were a known limitation at this point and, given the trade-offs, the benefits of Additional Fields made it the right choice for our Twilio integration.

A key advantage of the Additional Fields API is its fully PHP-based implementation, which eliminates the need for a separate build or bundling workflow and allows us to add the checkbox without adding any bespoke JavaScript to the browser bundle. It also means that our plugin data can be stored in a shared, known structure under the _wc_other meta key (namespaced under /skyverge), which makes it easier to interoperate with Woo and other extensions.

It’s hard to overstate the importance of the addition of an integration method like this. Our team is experienced in working on large-scale applications that incorporate complex micro-frontend architectures, and we also have access to frontend engineers familiar with building custom React components and wrangling webpack configurations. All of that made the other integration methods we explored viable in the first place, but these aren’t a given for the average WooCommerce extension developer. While we’re in favor of modernizing WooCommerce development standards to benefit from the advancements in the broader web ecosystem, providing integration methods like Additional Fields gives plugin developers a path to integrate with these latest advancements without adding additional barriers based on existing developer workflows and experience. Integration options like this benefit everyone, but are crucial for teams that don’t have the same access to resources that we do.

State of Block Checkout Extensibility

For development teams building products for the WooCommerce block ecosystem, the question remains: does the Additional Fields API provide a complete solution for all use cases?

WooCommerce’s ongoing efforts to expand extensibility, including the introduction of the Additional Fields API, have improved the integration process by aligning with existing developer workflows and best practices. This API offers a a simpler approach and is our preferred method for straightforward checkout field additions. However, it comes with limitations in field types and placement options, meaning it may not be the right fit for more complex implementations. Those will continue to require a full custom block integration.

On that front, WooCommerce has indicated a shift toward aligning more closely with broader WordPress trends for block development and extensibility, including postponing development of the new product editor experience to focus on standardizing with upstream APIs. At the moment, it looks like this will involve some combination of DataViews and the Interactivity API, which are being standardized in WordPress. This means that the baseline for more advanced WooCommerce block integrations could change significantly over the next year.

For now, teams building block integrations will have to balance the risks of adopting an evolving API against the costs of remaining on an outdated system. This challenge is common in platform-based development, but more stability can come as WooCommerce defines clearer timelines and communicates expectations for future updates.

As the WooCommerce platform continues to evolve, we extension developers will certainly need to learn and build with new tools like DataViews, Additional Fields, and the Interactivity API. It’s also clear that participation in the community discussions that shape these platform decisions will be key. We’ve found the WooCommerce Community Slack to be a great resource for engaging with the WooCommerce team and fellow developers. We’ll keep watching there for insights into upcoming changes and best practices, and collaborating to shape and grow our shared ecosystem together. Say hey if you see us around! 👋