Strict validation rejects legitimate phone numbers

What it is

Layered phone-number validation treats parseability, possible length, valid allocation range, current reachability, control by a person, and suitability for a communication channel as separate claims. Over-strict validation disguises assumptions from one region, number type, or metadata release as a global truth and consequently rejects usable numbers. Acceptance proves little in the opposite direction: a format check narrows candidates but does not establish that a number is real or controlled by the submitter.

Why it happens

Libphonenumber parsing normalizes several common notations, but successful parsing does not perform full validity checking. isPossibleNumber primarily checks length against regional metadata; isValidNumber additionally checks whether length and leading digits belong to ranges that may be assigned. The latter still cannot say whether a particular number is assigned now, reachable, or able to receive SMS. Library metadata follows authority documentation with some update latency, while carrier deployment can diverge from announced dates. Short numbers use a separate short-number API. Collapsing these stages into one Boolean—or requiring the number's allocation region to equal the user's country of residence—creates false rejections without eliminating false acceptance.

Studying it

Evaluate validation with a confusion matrix rather than one pass rate. Against manual confirmation or the result of the intended communication channel, measure both rejected usable numbers and accepted unusable numbers. Include international users, shared calling-code regions, newly activated and migrating ranges, short numbers, variable lengths, ported numbers, and every communication type the product claims to support; record library version and test date. Logging parse, possibility, allocation validity, type, channel verification, and failure reason as distinct stages reveals where losses arise. For sign-in, payment, and recovery, also measure completion and security effects of error copy, correction, retry limits, and fallback verification.

Where it stops holding

Permissive intake does not remove security requirements. SMS sign-in, voice contact, or regulated communication still needs channel-specific verification, risk controls, and consent evidence as proof that the channel was accessible at that time. Forwarding, SIM swaps, shared devices, and interception mean this evidence does not establish the holder's identity or continuing control. Even successful verification cannot promise that the number will not later be disconnected or reassigned. isValidNumberForRegion is appropriate only when the business requirement truly binds a number to a region, not for ordinary registration. Short codes, extensions, private-network numbers, and local-only numbers need separate contracts; rejection by an international public-number utility does not make them illegitimate.

Applying it

• Accept familiar punctuation and international notation before parsing. Distinguish “cannot parse,” “impossible length,” “unknown range,” and “channel verification failed” with actionable errors instead of one generic invalid-number message.
• For ordinary contact collection, use possibility checks for immediate feedback and range validity as a risk signal. Block only when the task warrants it, and always let people correct the region or enter a plus-prefixed number.
• When reachability or control matters, send a one-time code through the intended channel or place a confirmation call. Provide an accessible fallback that does not depend on the same number; static metadata is not delivery evidence.
• Pin and monitor the numbering-metadata version, update it regularly, and turn de-identified production false rejections into regression cases. Give newly announced ranges a reviewed, time-bounded fallback instead of permanent hard-coded exceptions.

Related

• Same group: S2.07.1 Relating country calling codes to national formats · S2.07.2 Phone-number length and grouping vary by country · S2.07.4 Separate telephone-number display from storage
• Adjacent: S2.05.5 Character-set restrictions reject legitimate names · S2.09.4 Permissive input and strict output outperform blanket rejection
• Search terms: isPossibleNumber · isValidNumber · phone verification