WooCommerce billing validation can pass in shortcode checkout and fail in Checkout Block, or the reverse, because the Block uses the Store API, validation data store, additional field registration, and Block-specific events. Country locale, saved addresses, express payments, and gateway requirements add more branches.
Use this for stores migrating checkout layouts, plugins that modify billing fields, VAT or tax ID validation, country-specific requirements, saved addresses, fraud tools, and payment methods that depend on billing data.
Quick answer
Put Checkout Block and shortcode checkout on separate staging pages, use the same cart and customer fixtures, then compare visible fields, required state, sanitized value, client error, Store API response, order meta, and gateway request. Implement each rule through the supported API for that checkout surface and keep server validation authoritative.
What to check first
- Create guest and logged-in fixtures for at least two countries, same-as-shipping on and off, saved and new addresses, plus one express payment path.
- List every custom billing field and whether it comes from country locale, classic checkout filters, additional field registration, Store API schema, or a gateway extension.
- Submit missing, malformed, boundary, Unicode, whitespace, and cross-field values on both checkout pages.
- Capture browser validation state, Store API response, PHP error code, order values, customer values, and gateway payload separately.
- Check that errors are specific, visible near the correct field, announced accessibly, and removed after correction.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build paired checkout pages | Create guest and logged-in fixtures for at least two countries, same-as-shipping on and off, saved and new addresses, plus one express payment path. | The same business rule produces an equivalent result on both supported checkout surfaces. |
| Map field ownership | List every custom billing field and whether it comes from country locale, classic checkout filters, additional field registration, Store API schema, or a gateway extension. | Client and server validation agree, with the server remaining authoritative. |
| Run the same fixture matrix | Submit missing, malformed, boundary, Unicode, whitespace, and cross-field values on both checkout pages. | Order, customer, and gateway values match the approved sanitized value. |
| Use supported validation APIs | Capture browser validation state, Store API response, PHP error code, order values, customer values, and gateway payload separately. | Guest, saved-address, country-change, and express-payment fixtures all complete or fail as expected. |
Test scenarios to run
Run the same controlled fixture across these branches. Record the expected result before the test so a surprising response is visible immediately.
| Scenario | Fixture | Expected result |
|---|
| Guest missing field | Same cart and country on Block and shortcode pages | Both surfaces stop checkout with an accessible equivalent error |
| Saved address | Logged-in buyer selects a stored billing address | Approved value is revalidated and reaches order plus gateway |
| Country change | Buyer changes from US to DE after entering an address | Required state and format update without stale errors |
| Express payment | Wallet supplies partial billing details | Server and gateway enforce the approved rule without a blank order value |
Why this usually happens
- Classic `woocommerce_checkout_fields` behavior is not the supported extension path for every Checkout Block field.
- Block validation can exist in client state before the server response.
- Address fields can be stored separately for billing and shipping even when the UI copies one to the other.
Field notes
- Use non-production tax IDs and addresses that exercise format rules without representing real people.
- Record the checkout page ID and block or shortcode type with every failure.
- Retest the payment gateway because removing a billing field can weaken fraud or authorization inputs.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture:
checkout: block | shortcode
customer: guest | saved_address
country: US | DE
billing_same_as_shipping: true | false
value: missing | malformed | valid
assert:
visible_field + error_code + order_value + gateway_value
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build paired checkout pages
- Map field ownership
- Run the same fixture matrix
- Use supported validation APIs
- Verify order and gateway data
Decision rule
Hold checkout migration when a required field disappears, valid buyers are blocked, invalid data reaches the order or gateway, errors are inaccessible, or Block and shortcode behavior differ without an approved reason.
What to tell the client or owner
Provide checkout type, page ID, cart, customer state, country, field key, input, client error, API response, server hook, stored value, gateway value, and expected rule.
Production verification checklist
- The same business rule produces an equivalent result on both supported checkout surfaces.
- Client and server validation agree, with the server remaining authoritative.
- Order, customer, and gateway values match the approved sanitized value.
- Guest, saved-address, country-change, and express-payment fixtures all complete or fail as expected.
Mistakes to avoid
- Do not assume classic checkout filters automatically control Checkout Block.
- Do not remove country or billing data without checking tax, fraud, and gateway requirements.
- Do not validate only in JavaScript.
- Do not reuse live customer addresses in test logs.
Questions teams ask during testing
Why does my classic hook not fire in Checkout Block?
The Block uses Store API and Block extensibility contracts. Map the rule to the supported registration and validation APIs.
Can I test only the final order?
No. Capture client state, API error, server validation, stored values, and gateway payload to locate the mismatch.
Should Block and shortcode output be byte-for-byte identical?
No. The business rule, error meaning, sanitized data, and payment outcome should match even when the implementation differs.
When HandL WP should help
HandL WP can build a paired checkout fixture, trace each field to its owner, correct Block and classic integrations, and verify order plus gateway behavior.
If this is active on a production site, fix WooCommerce checkout validation.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references