WooCommerce 10.9 continued checkout performance changes, and Checkout Blocks rely on Store API behavior rather than old classic checkout assumptions. Custom checkout fields need validation that proves the field is captured, saved, and available to fulfillment, tracking, or CRM systems.
Use this when a WooCommerce store uses custom checkout fields for delivery notes, tax IDs, lead source, gift messages, B2B fields, or CRM routing.
Quick answer
WooCommerce Checkout Blocks Custom Field Validation Checklist should be handled with a narrow evidence-first workflow: capture request, check validation, verify order meta, then verify the result before making broader changes.
What to check first
- Capture the Store API request that includes the custom field.
- Confirm validation errors appear before payment or order creation.
- Verify the field is saved to order meta and visible to fulfillment or CRM exports.
- Retest failed payment, retry payment, guest checkout, and logged-in checkout.
- Confirm purchase tracking still deduplicates by order ID.
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 |
|---|
| Capture request | Capture the Store API request that includes the custom field. | The field appears in the Store API payload and final order record. |
| Check validation | Confirm validation errors appear before payment or order creation. | Invalid values stop checkout before payment is attempted. |
| Verify order meta | Verify the field is saved to order meta and visible to fulfillment or CRM exports. | Fulfillment, CRM, and email templates receive the expected value. |
| Retest payment paths | Retest failed payment, retry payment, guest checkout, and logged-in checkout. | Purchase conversion tracking still fires once per completed order. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
checkout_field_test:
field_key: delivery_window
validation: required
store_api_request: PATCH /wp-json/wc/store/v1/checkout
order_meta_saved: true
crm_export_field: delivery_window
purchase_dedupe: order_id
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.
- Capture request
- Check validation
- Verify order meta
- Retest payment paths
- Check dedupe
Production verification checklist
- The field appears in the Store API payload and final order record.
- Invalid values stop checkout before payment is attempted.
- Fulfillment, CRM, and email templates receive the expected value.
- Purchase conversion tracking still fires once per completed order.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, debug WooCommerce Checkout Blocks tracking.
Helpful references
Trace the exact billing field error
For country, postcode, phone, tax, or address failures, use the Checkout Blocks billing validation debug guide to connect the visible field to the Store API schema and server error.