Call for Participants: Help us understand checkout block adoption barriers

We’re looking for site builders and developers to participate in research about Gutenberg blocks-based checkout adoption. Your insights will directly shape the future of WooCommerce checkout experiences.  

Despite offering a more modern checkout experience, adoption of blocks-based checkout remains lower than expected. We need to understand why so we can better support you and improve the experience.

Who we’re looking to talk with

  • Site builders (agencies, freelancers, in-house teams for stores generating more than $1m in annual revenue)
  • Plugin developers (especially those working with checkout, payments, cart functionality)

Interview topics

We’re interested in understanding:

  • Custom checkout field implementation challenges
  • Workflow and skill set barriers
  • Styling and customization limitations
  • Documentation and resource gaps
  • Inner block access requirements
  • Your perspectives on benefits and drawbacks

How to participate

Interviews will be conducted between Monday, April 28th and Monday, May 5th. Various time slots are available to accommodate different time zones. The process:

  1. Complete our short screening form to help us match you to this research
  2. If selected, our research team will contact selected participants to schedule your interview
  3. Participate in a 30-60 minute Zoom conversation
  4. Receive your $175 USD gift card

Questions?

Contact our research team at research@woocommerce.com with any questions about the study.

Your feedback is invaluable and will directly influence how we improve the blocks-based checkout experience to better serve your needs and those of your clients.

This research is being conducted by the WooCommerce Research Ops team. Your participation is completely voluntary and we will never try to sell you anything.


13 responses to “Call for Participants: Help us understand checkout block adoption barriers”

  1. Speaking from a business owner’s point of view. There is a desire to move towards the block checkout, (which in theory should be a higher converting) but there are blockers/barriers to doing so.

    Many payment gateways don’t support checkout blocks (which is the main issue).
    The Blocks (fields in this case) aren’t customizable as they need to be (VAT numbers, etc), and just general support of other upstream plugins is low.
    Shipping Plugin support, or lack thereof, is also a big issue.

    I have engaged with the plugin developers as much as I can. Even in some cases, had calls with the brand and their developers. The long and short of it is that their focus and investment is on their Shopfiy apps/plugins.

    1. Many payment gateways don’t support checkout blocks (which is the main issue).

      Do you have examples/links of exactly which ones you’re trying to use? We’ve been working through all of the official ones and making sure they’re compatible, but we know what folks aren’t always using them.

  2. Any fairly serious site will probably not be using the Block editor. So even if you make the checkout/cart blocks amazing, you’re stuck behind an extra level of the site itself needing to change, which impacts the entire site and not just e-commerce parts.

    I strongly believe you’re also shooting yourself in the foot by not adding the new features to the checkout/cart shortcodes. Older sites won’t be able to enjoy the benefits, and the bleed away to Shopify continues as they out-market you.

    1. Nadir Seghir Avatar
      Nadir Seghir

      There might be a misconception that you need to switch to the block editor to use the new Checkout. Your site can stay and work however it is, and you only need to insert the new block in the checkout page and be done, no other switching needed.

      1. Kuldeep Avatar
        Kuldeep

        I don’t understand how someone would add the checkout block to a page when the block editor is disabled. How is this possible? Can you provide the steps?

        This is also one of the main reasons we have not used it. We disable the block editor and dequeue a lot of scrips/styles etc from it.

        1. Nadir Seghir Avatar
          Nadir Seghir

          If you completely disable the editor and cannot access it, then you cannot add the checkout block via traditional ways. We would suggest you enable the block editor, insert the block, and then disable it back again.

          If that’s not possible, another avenue is to insert this HTML into the content of your checkout page. This is not something I recommend because this snippet might get stale but it’s a way to use it without touching Gutenberg. You would still be missing things like editing steps and titles and adding blocks via visual editor.

          https://gist.github.com/senadir/af3f05be07a0be786748f4f38c200e02

          Do test that on a staging website before doing it on a production website.

  3. Cart and Checkout blocks are hard to customize. The render_block_woocommerce/checkout filter isn’t enough, the CSS is bloated and hard to override. Even dequeuing the CSS and writing your own is messy because the class structure is not logically organized or uniquely named where it should be.

    Blocks are great for content creation, but I don’t want my customers editing sensitive areas like the Cart or Checkout. Using a simple shortcode prevents that.

    Aside from that, filters and actions are unbeatable tools that allow developers to fully customize the Cart/Checkout and provide reliable points to add additional functionality.

    I totally agree that both blocks look good (even if the design feels inconsistent with other parts of WooCommerce) and can increase the conversion rate. I also agree that the classic cart and checkout feel rusty and outdated. But for the reasons above, I still prefer the classic approach over the blocks.

    Why not offer an additional modernized shortcode version based on the block design but with minimal styles? Simple but solid.

    1. Kuldeep Avatar
      Kuldeep

      I agree with everything you say, it is the same for my stores.

      “Why not offer an additional modernized shortcode version based on the block design but with minimal styles? Simple but solid.” – Yes!

  4. Ethan Avatar

    As a developer, extending the WooCommerce Checkout Block is unnecessarily complicated. I followed WooCommerce’s internal structure—created a src folder, added webpack.config.js, installed all dependencies—and avoided using the woocommerce_register_additional_checkout_field hook because it’s too restrictive. That hook limits you to saving data in billing, shipping, or order, offers minimal admin control, and doesn’t support saving custom metadata your own way.

    I want to build my own parent block and handle everything—from rendering to saving—in a modern, flexible way using Gutenberg. But trying to pass attributes from edit.js to block.js, or even just making the block dynamic, is painful and poorly documented.

    I’ve referenced:

    Tyche Softwares guide: https://www.tychesoftwares.com/how-to-add-custom-fields-in-woocommerce-checkout-block/ Open Source How To But Limited Functionality

    Checkout Fields for Blocks plugin: https://wordpress.org/plugins/checkout-fields-for-blocks/#reviews Open Source Plugin

    WooCommerce Contact Info Block GitHub: https://github.com/woocommerce/woocommerce-blocks/tree/trunk/assets/js/blocks/checkout/inner-blocks/checkout-contact-information-block

    There’s almost no official guidance, and it feels like reverse-engineering everything. WooCommerce seriously needs proper developer docs for the Block Checkout system—especially for JavaScript-based, hook-free customization.

  5. Ethan Vaz Avatar
    Ethan Vaz

    As a developer, extending the WooCommerce Checkout Block is unnecessarily complicated. I followed WooCommerce’s internal structure—created a src folder, added webpack.config.js, installed all dependencies—and avoided using the woocommerce_register_additional_checkout_field hook because it’s too restrictive. That hook limits you to saving data in billing, shipping, or order, offers minimal admin control, and doesn’t support saving custom metadata your own way.

    I want to build my own parent block and handle everything—from rendering to saving—in a modern, flexible way using Gutenberg. But trying to pass attributes from edit.js to block.js, or even just making the block dynamic, is painful and poorly documented.

    I’ve referenced:
    • Tyche Softwares guide
    • WP Desk Checkout Fields for Blocks plugin
    • WooCommerce Blocks GitHub

    There’s almost no official guidance, and it feels like reverse-engineering everything. WooCommerce seriously needs proper developer docs for the Block Checkout system—especially for JavaScript-based, hook-free customization.

  6. Hi Brian

    I’m using Woo only under the block way (i do not like the hybrid approach, i landed quite recently on the WP ecosystem, i’m keen to have the best performances also). The block FSE way opens a new paradigm, e.g. with block variations, block bindings, etc., and ease UX creativity. We can manage our Conversions Rates correctly.

    I do think the FSE adoption have been lowered by the fact that many components were not ready at the begining, set under a Beta flag.
    – On the Checkout area, for instance the Paypal Gateway was not ready during months (i’ve just moved some of my customers recently from the classic to the new blockified version).
    – There are still some bugs to fix, like those identified with the Free Shipping area.
    – There are improvements in the hoves (like remove the Shipping Calculation Section – see discussions we had)

    For me, some articles about what’s ready / what’s will be is needed, because the checkout adoption is tied to the global process FSE availability of all the components : product template (for all product types), new product gallery block, product collection block, HPOS.

    Some old blocks or features have not been activated yet for all, or moved to the new ways, some are still in beta flags or being worked on, or only activated to the new shops. It’s hard sometimes to follow the current status, it’s a daily job for us to read the issues and PR to understand what will come (seems also you moved some EPIC management in an external tool, away from GitHub).

    The sooner we move away from the beta, the sooner some posts are publishing to show off the global process FSE availability, the better it brings confidence in the whole process incl. checkout, and incitate everyone to work exclusively under the FSE way. Working under a dual mode is for me a lack of time for the project.

    There is a still need also to reduce the gap with the old classic way (ex: manage correctly subcategories in the shop page, manage correctly image aspect ratio, etc.), to bring reinsurance. For now it’s not clear what’s still to be done (if we start a new big customer projects, we can pray not discovering some features are not ready).

    I’m finalizing a 100K+ products project (with grouped products), I’ve activated HPOS of course, to maximize performance. Will tell you more in few weeks.

    Hopes my feedback helps 🙂 Keep it up, and please publish some overview posts about the global readiness on the whole process (please take the end user process eye).

    Checkout XP must not be decoupled from the global (FSE) Buyer experience IMHO…

  7. Alexandra Avsterova Avatar
    Alexandra Avsterova

    Hi, how do I apply this if my website is made on Elementor and Elementor Pro?

Leave a Reply

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