WooCommerce 11 adds phone validation and formatting hooks intended to support local formats and non-English numerals. A checkout test with one US number cannot prove the change. Extensions may normalize too early, reject valid local digits, accept alphabetic input, format a number twice, or store different values across checkout, accounts, REST, and admin updates.
Use this for international stores, address validation extensions, SMS tools, payment gateways, CRM connectors, fraud services, and custom checkout fields. Include each supported billing country and the digit scripts used by real customers.
Quick answer
Build a country-by-country fixture table with raw input, Unicode digit set, expected validation result, canonical stored form, display form, and downstream value. Submit each case through shortcode checkout, block checkout or Store API, My Account, admin order editing, REST, and imports. Record which hook changes validation versus formatting, and confirm that normalization is idempotent.
What to check first
- List supported countries, required or optional phone rules, accepted separators, extensions, leading zeros, country codes, Unicode digits, and downstream format requirements.
- Create valid boundary, invalid, empty, pasted, right-to-left, mixed-digit, full-width digit, and malicious string fixtures with expected outcomes.
- Trace raw input, normalized input, validation decision, stored order meta, customer meta, displayed value, webhook payload, email, export, and CRM or SMS value.
- Exercise classic checkout, Checkout Block or Store API, My Account, admin edit, REST update, CSV import, subscription renewal, and saved-address reuse where relevant.
- Run normalization twice and prove the second pass does not alter an already canonical number.
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 |
|---|
| Define locale and downstream contracts | List supported countries, required or optional phone rules, accepted separators, extensions, leading zeros, country codes, Unicode digits, and downstream format requirements. | Fixtures cover supported countries and digit scripts. |
| Build valid and invalid Unicode fixtures | Create valid boundary, invalid, empty, pasted, right-to-left, mixed-digit, full-width digit, and malicious string fixtures with expected outcomes. | Classic and Store API checkout paths make the same decision. |
| Trace every input and output path | Trace raw input, normalized input, validation decision, stored order meta, customer meta, displayed value, webhook payload, email, export, and CRM or SMS value. | Order, customer, email, webhook, export, and integration values match their contracts. |
| Separate validation from canonical storage and display | Exercise classic checkout, Checkout Block or Store API, My Account, admin edit, REST update, CSV import, subscription renewal, and saved-address reuse where relevant. | Running normalization twice does not corrupt the value. |
Why this usually happens
- Unicode numerals can look valid while failing ASCII-only regular expressions.
- A local leading zero can be significant before a country code is applied.
- Validation and display formatting are different responsibilities but extensions often combine them.
- Checkout blocks and shortcode checkout may pass through different hooks and schemas.
- A gateway or CRM may require E.164 even when the customer should see a familiar local format.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case_id: WC11-PHONE-EG-03
country: EG
raw_input: "٠١٠ ١٢٣٤ ٥٦٧٨"
unicode_digits: arabic_indic
validation_expected: pass
stored_expected: "+201012345678"
display_expected: "010 1234 5678"
store_api: pass
admin_edit: pass
webhook: pass
idempotent: pass
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.
- Define locale and downstream contracts
- Build valid and invalid Unicode fixtures
- Trace every input and output path
- Separate validation from canonical storage and display
- Retest downstream integrations and idempotency
Decision rule
Pass when every supported valid local number is accepted, every defined invalid case is rejected with a useful message, canonical storage is stable, display remains appropriate for the locale, and all downstream systems receive the documented form.
What to tell the client or owner
Give the site owner the affected version, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Fixtures cover supported countries and digit scripts.
- Classic and Store API checkout paths make the same decision.
- Order, customer, email, webhook, export, and integration values match their contracts.
- Running normalization twice does not corrupt the value.
Mistakes to avoid
- Do not convert digits by deleting every non-ASCII character.
- Do not require E.164 in the customer-facing field unless the product clearly explains it.
- Do not test only successful checkout.
- Do not log full customer phone numbers in general debug output.
Questions teams ask during testing
Should WooCommerce store the local or E.164 number?
Choose a documented canonical form that downstream systems can use, while retaining only the display information genuinely required. The right answer depends on the business and country coverage.
Can a regular expression validate every international number?
A single generic expression is usually too strict or too permissive. Combine country-aware rules, careful normalization, and downstream verification.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
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