Best practices for phone number validation during new user enrollment

You have a new user! Great! Twilio provides a set of tools for quickly validating and verifying a user's phone number, perfect for quick and seamless onboarding. Let's look at some best practices for how to get a user registered for your service and on their way while ensuring accuracy and reducing fraudulent sign ups.

This blog post will cover recommendations and best practices for seamless user registration that uses a phone number. Similar recommendations apply to existing user accounts that are providing their phone number for the first time, even if the user account already exists.

You'll want to focus on three areas when enrolling a new user:

1. Phone number input, collecting the phone number from the user.
2. Phone number validation, ensuring the phone number is legitimate.
3. Phone number verification, ensuring that the user has access to the phone number.

Best practices for phone number input

Keep the country code in a separate field

Plugins like international telephone input provide user friendly interfaces and support the variety of global phone number formats. Keeping the country code separate is more user friendly and helps ensure that the input can be transformed into the standard E.164 format.

Transform the phone number into E.164 format

E.164 is a standardized international phone number format that ensures unique numbers. This format is returned by the Lookup API and is used by most Twilio APIs, including the Verify API and the Messaging APIs.

This blog post has recommendations for processing international telephone input in HTML and JavaScript.

[Optional] Check that the IP geolocation matches the phone number country code

There are legitimate reasons a user may be signing up with a phone number in a different country, but this behavior may be correlated with fraudulent activity.

Best practices for phone number validation

Once the user has inputted their phone number, the Twilio Lookup API provides phone number intelligence with support for formatting, validation, carrier information, line type, and more.

Use the Twilio Lookup API to:

1. Confirm that the phone number is valid

Don't allow users to sign up or enter invalid numbers like 12345 or +1 (111) 111-1111. This blog post will show you how to validate phone numbers in HTML.

2. Check for line type, including mobile, landline and VoIP numbers

Detecting a landline line type allows you to send voice verification codes instead of SMS, especially useful if your company has an older clientele base that is less likely to have an SMS capable phone. VoIP numbers (detection available for US numbers only) can be legitimate, but you may decide to add additional protection at this stage like reCAPTCHA.

Learn how to detect line type with the Lookup API in this blog post.

3. Build an allow list of country codes to accept

An allow list of countries at sign-up is a great way to ensure you're meeting compliance requirements, reducing fraud, or otherwise controlling your onboarding pipeline.

This blog post will walk you through how to build an allow list of countries using the Lookup API.

4. Maintain a list of carriers based on reputation

Similar to the country code allow list, certain carriers and prefixes are associated with increased rates of fraud and spam. Detecting a carrier before sending the SMS can help protect your application.

Apply for approval with the CLNPC for Canadian carrier information

If you're operating in Canada, you'll need to get additional approval from the CLNPC before the Lookup API will return information about Canadian numbers.

Best practices for phone verification

Send an one-time passcode to the provided phone number to ensure that the user has access to the number

This helps prevent the user from providing someone else's phone number, helps your business ensure unique sign ups, and is essential for future deliverability of authentication passcodes or notifications.

Learn how to send an SMS OTP in 5 minutes or less with the Twilio Verify API in this blog post.

Build retry buffers into verification workflows

Humans are impatient, so we recommend building retry logic into your phone verification interface. The Verify API will start rate limiting requests after you attempt to send an OTP to the same phone number more than 5 times in 10 minutes without verifying the number. Retry buffers help prevent both accidentally spamming users and hitting API rate limits.

Keep phone numbers visible in enrollment flow and allow users to edit the phone number

Typos happen, so for phone verification use cases (as opposed to ongoing login or two-factor authentication), display the complete phone number in the interface so the user can detect and fix any mistakes instead of waiting helplessly for a verification code.

Best practices for ongoing user authentication

Store users' preferred channel preferences

Once a user has verified their number, store any preferred channels (whether that's SMS, voice, email, TOTP, push) and send the code to their preferred channel by default in the future. Allow the user to change the channel for two-factor authentication (2FA) delivery in the interface if they decide they prefer a different channel for a given authentication.

Mask phone number during ongoing user authentication

Unlike initial phone verification, for ongoing authentication or 2FA you should mask the phone number in order to prevent leaking PII. Unlike phone verification, there is no option to edit a phone number for ongoing authentication. We recommend exposing 3 or 4 numbers and masking the rest like +1 (5**) ***-**67 or ********567.

Other recommendations for account security

Designing usable security is an ongoing process that evolves as technology advances and your customers adapt. SMS and voice are a great basis for most account security use cases and aren't going away anytime soon.

If you're interested in verification beyond SMS, make sure you check out:

• Is email based 2FA a good idea?
• What is a Time-based One-time Password (TOTP)?
• Understanding push authentication

I can't wait to see what you build and secure!