Confirm phone

Problem Context

• The product has already collected a phone number and must decide whether number format, dialability, SMS capability, or actual access must be proven.
• Confirmation may be needed for account activation, phone-number change, account recovery, sensitive notifications, high-risk actions, or a verified contact route.
• Users may receive SMS late, enter the wrong number, use a landline, share a phone, lack cellular service, lose access, or face privacy and safety risks from phone contact.
• SMS and voice codes depend on the public telephone network and can be affected by interception, SIM-swap, forwarding, number recycling, roaming, and device access limitations.
• Some flows can show the destination number safely; sign-in and recovery flows may need to mask it or use neutral copy to avoid account or number exposure.

Selection Rules

• Choose confirm phone when the product must prove that the user can receive a time-limited text-message or voice code at an already captured number.
• Use phone number entry when the task is collecting, formatting, validating, warning about, reviewing, or changing the phone number before access is proven.
• Use confirm email when the proof route is a mailbox link or code rather than SMS or voice call.
• Use two-factor authentication when an enrolled factor protects sign-in or authorization; do not present one-time phone confirmation as equivalent to a complete MFA strategy.
• Use password reset when the phone code is part of replacing a forgotten password rather than confirming ordinary phone reachability.
• Show the exact phone number when it is safe and useful; mask or omit it in sign-in recovery contexts where revealing the number could expose account data.
• Explain whether the code was sent by SMS, voice call, or another approved route, and provide an alternative when SMS is unavailable or inappropriate.
• Make codes short-lived, single-purpose, rate-limited, and bound to the number, user or pending record, and flow purpose.
• Invalidate previous codes when the number changes, when confirmation succeeds, or when the pending record is revoked.
• Do not force phone confirmation for low-risk contact collection, receipts, or flows where a review step is enough.
• Treat PSTN-based SMS or voice authentication as risk-bearing; provide notice and unrestricted alternatives when assurance requirements demand them.

Required States

• Sent-code state with target phone number when safe, channel, purpose, code length, expiry, resend, and change-number or support action.
• Blocking pending state where the task cannot continue until phone access is confirmed.
• Non-blocking pending state where users can continue with limited access while verified-phone state remains pending.
• SMS code-entry state with a labelled input, inputmode numeric, one-time-code autocomplete, paste support, and visible expiry.
• Voice code state for users who cannot receive SMS or are confirming a voice-capable number.
• Resend-limited state with server-backed wait time and clear current-code behavior.
• Change-number state that sends a fresh code and invalidates previous codes for the old number.
• Incorrect-code state with specific error copy and preserved input affordances.
• Expired-code state with request-new-code recovery.
• Too-many-attempts or rate-limited state with wait time, support, and abuse-protection copy.
• No access to phone state with voice, backup, support, or alternative-contact route.
• Verified phone state that returns to the originating task and clears pending warnings.

Interaction Contract

• The confirmation page states why phone access is required, what channel was used, and what phone number is being confirmed when disclosure is safe.
• Code entry accepts paste, spaces, hyphens, and familiar formatting, then normalizes only for comparison.
• Resend, voice-call, change-number, no-access, and support actions preserve the originating task or pending account context.
• Changing the number invalidates previous codes and sends a fresh code to the new number.
• Expired, incorrect, reused, or rate-limited codes do not expose raw token values and always offer a safe next step.
• Verified phone state is stored separately from phone number syntax validity, dialability, SMS capability, two-factor enrollment, and account authentication.
• Phone confirmation does not reveal whether a number or account exists unless the user is already in a safer authenticated route.

Implementation Checklist

• Define why phone access is required, which channels are allowed, whether the loop blocks the task, code length, expiry, retry limits, resend behavior, change-number behavior, and alternatives.
• Design sent, SMS code, voice code, pending, resend-limited, changed-number, incorrect, expired, rate-limited, no-access, verified, and support-needed states.
• Use a labelled text input with inputmode numeric and autocomplete one-time-code for short code entry rather than a numeric spinbox.
• Allow paste and common separators while validating code length and numeric content with specific messages.
• Bind each code to the phone number, pending record, channel, purpose, expiry, and retry policy; invalidate it after use, number change, or revocation.
• Protect phone numbers, codes, token status, and failure reasons from logs, analytics, referrers, support tools, screenshots, and notification previews.
• Provide voice, backup, support, or non-phone alternatives for landline, no-SMS, inaccessible-device, shared-phone, or no-phone situations.
• Apply abuse controls such as resend throttling, retry limits, monitoring, and progressive delays without trapping legitimate users.
• Test delayed delivery, wrong number, no signal, number change, resend, multiple active messages, expired code, too many attempts, voice fallback, mobile autofill, screen readers, high zoom, and browser Back.

Common Generated-UI Mistakes

• Treating phone-number format validation as proof that the user can receive texts or calls.
• Hiding the destination number when users need it to spot a typo.
• Providing no resend, wait time, change-number, voice, no-phone, or support route.
• Forcing SMS for users with landlines, shared phones, inaccessible devices, no cellular signal, or no phone.
• Using SMS confirmation as the only high-assurance authentication option without risk notice or an unrestricted alternative.
• Letting previous codes remain valid after the phone number changes or confirmation succeeds.
• Logging codes, full phone numbers, token failure reasons, or replayable verification URLs.
• Revealing account or number ownership through request-new-code, activation, or error messages.

Critique Questions

• Why does this flow need proof of phone access rather than only a phone number field and review?
• Does the page make clear whether phone proof stops the task, grants limited pending access, or only verifies a contact route?
• Can users see, mask, or change the target number appropriately for the context?
• What happens when SMS is delayed, the number is wrong, the code expires, too many attempts fail, or the user cannot access the phone?
• Are SMS and voice codes being treated as authentication, and if so, what alternatives and risk notices exist?
• How are codes bound, expired, invalidated, throttled, and protected from leakage?