WooCommerce Checkout Blocks: Check Compatibility Before Switching
Before moving to WooCommerce Cart and Checkout Blocks, check the payment methods, fields and buying rules your store relies on. A cleaner layout is useful only when the complete order journey still works.
Read the guide
Search Field Notes
A useful next read.
36 field notes
No matching guide yet. Try “checkout”, “shipping” or “catalog”.
All Field NotesList what the current checkout does
Inventory gateways, express-payment buttons, discounts, delivery choices, tax tools and unusual product types. Add custom fields and validation rules, including details staff need for fulfilment. Describe the behaviour, not just where the field appears.
Clarify what the switch should improve: mobile usability, easier editing or a specific checkout issue. Keep a reference for the working journey so the team can distinguish an intentional change from a regression. The plan should not require breaking the live checkout to discover missing features.
Verify the exact extension and version
Cart and Checkout Blocks use an integration model that requires compatible extensions and payment methods. Classic-checkout support does not prove Blocks support. Check each installed component’s current documentation and the specific features your store uses.
A payment provider may have several WooCommerce gateway extensions with different support. Record the extension name and version, not only the provider brand. Mark each requirement as supported, unsupported or still to test. Missing compatibility is a planning gap to resolve before switching the page.
Follow custom fields into the order
For each required field, specify when it appears, what makes it valid and where its value is stored or sent. A delivery instruction that looks right but never reaches the warehouse is a broken workflow.
Confirm the designated Cart and Checkout pages and the implementation route for custom logic. Do not assume an alternative page is in use just because it has a checkout block. Have the developer verify validation, order data and connected-system handover with the same field values.
Include the buying paths that are easy to miss
Test subscriptions, bundles, bookings, trade pricing and other special types where they exist. Check the particular extension/gateway combination and the account actions tied to it. A one-off card payment cannot cover an ongoing subscription workflow.
Include guest and returning customers, the address regions you serve, cart edits and both qualifying and rejected promotions. Write the expected payment choices and totals for each case. That makes a missing option visible instead of letting the team accept whatever the new layout happens to show.
What must work before switching
Test the required fields, gateways and special buying rules together.
| Check | What to check | Next step |
|---|---|---|
| Payment method | The required gateway appears and completes its supported test. | Inspect the resulting order state. |
| Required field | Validation works and the value reaches the order and staff. | Check storage and fulfilment handover. |
| Special product | Subscriptions, bundles or trade carts retain required behaviour. | Verify the exact extension and product path. |
Rehearse on a copy with real operational checks
Use gateway test modes and isolate staging from customer messages and live fulfilment. Walk the test cases on desktop and mobile. Check field errors, focus, order summary, delivery changes and the final payment action.
Inspect the resulting order and the information staff receive. Compare the same cases against the current checkout. Keep the tested versions and open issues in the release record so later updates can use the same small regression set.
Keep a practical fallback for the switch
Before release, verify a current backup and record the previous working page and configuration. Decide which gaps block the switch and who checks the live payment paths afterwards. A missing required gateway or fulfilment field should not be treated as a cosmetic follow-up.
Prefer a scoped fallback for the changed checkout files and settings where appropriate. A full database restore can overwrite orders placed after release. Protect that trading activity and repeat the representative live checks before declaring the transition finished.
Common questions
Why is a payment method missing in Checkout Blocks?
Check support for the exact gateway extension and version, its settings and the features being used. A gateway that works with classic checkout may need a separate Blocks integration.
Will custom classic-checkout fields work automatically?
Do not assume so. Verify the supported Blocks implementation and test validation, order storage and the staff workflow using the field.
Can one successful order prove Blocks readiness?
It proves that one tested path. Check the other payment options, customer types, regions, promotions and special product types your store needs.