¹

In the first part of this series I explained about the what OTP is, the initial prepations you need to do to implement your own OTP flow and the differences between the common channels that OTP is sent over.

For this episode, I will explain the last two parts of this series:

• Sending of the OTP via communication channels
• Receiving the OTP from the customer and verifying it

Sending the OTP via communication channels

There are multiple channels or ways which you can send the OTP to your customer for verification. Which you use depends on the needs of your business, and also what is available for your customer. The most common ones are email, SMS and also voice calls. Their pros and cons have been explained in the previous post.

How do you actually send the OTP?

The most common and perhaps easiest way to send your OTPs is through a third-party communications API. Companies like Twilio, Vonage, Plivo or MessageBird has APIs that allow you to send SMS or make phone calls.

There are certain factors you should take into account on deciding which communications API you will use. Things such as

• Pricing
• Supported countries and networks
• Country and network restrictions
• Quality of connection

are some of the important factors which you will need to consider. I will add more context for some of these below.

Country and network restrictions

Due to different regulations in each country, you might need to talk to the communications provider and provide documentation or request for explicit permission to send messages and make phone calls to phone numbers in certain countries. If you plan to only have customers from a single country, this might not be of an issue, but if your business goes beyond just a few countries, then understanding the regulations and where you can or cannot send/call to is important. Certain countries have strict regulations and hefty fines if you break their rules.

Having said that, OTP messages or calls are generally considered transactional , which means they are contractual in nature and generally allowed in most cases. You should still check with your communications provider to be sure.

Quality of connection

Sometimes a particular OTP was not received by the intended recipient after you’ve sent it. There are many reasons for this, but is most common seen in the SMS channel.
Sometimes communications providers uses so-called “gray” routes which are relatively cheaper but have poor quality, which results in messages or calls getting lost or not received.

This is a part where you’ll just have to do trial and error to find which communications provider is reliable.

Resending OTPs

Sometimes a particular OTP was not received by the intended recipient after you’ve sent it, or the OTP has already expired when it reached the recipient. You’ll need to incorprate resending logic in your OTP flow to be able to hande these cases. It can be one of the more complicated part when implementing your 2FA authentication system.

The most important thing you’ll need to decide is how many times you will allow OTPs to be resent. The need to resend OTPs are more common than you’d like to think, so not allowing resending of OTPs will have a negative impact on customer experience.

Having said that, allowing too much resends will open your system to abuse. Sending OTPs are not free, and if you’re sending over the more expensive channels like SMS or voice where you’re being charged per sending, then you’ll want to make sure you can control this.

Receiving the OTP and verifying it

The final part the whole process is to receive the OTP back from the customer and verifying that it was the same OTP that you sent out.
In your web application, you will usually have a view with a form that accept input from the customer. This view will check if the entered OTP exists and if it hasn’t expired. From this information, you can continue to identify which customer, her email address or his phone number is connected to the OTP and to proceed to mark that account as verified.

Things to watch our for

If your intention of getting OTPs from customers is to prevent fraudulent registrations like bot accounts or people trying to abuse your service, there are certain things which you need to consider and watch out for.

Receiving SMS at a number doesn’t mean the recipient owns the phone

Being able to receive a message at a certain number doesn’t mean the recipient owns and has physical access to the mobile. There are many services online which allow anonymous people to receive messages from various phone numbers worlwide. These numbers are nearly all the time temporary.

You need to combine other data such as IP addresses to create a better picture

Identifying possible fraudulent registrations cannot be done just from one or two points of data. You will need to combine multiple data points to create a clear picture of who your customers are.

In all cases, constant checking of phone numbers or email address is important. Using a synchrnous channel such as voice for particularly sensitive sections of your service might also be effective. This will force the customer to always be available to be contacted via a particular number.

Wrapping it up

I have explained in general the steps and things you’d need to watch out for when implementing your own OTP flow for 2FA.

There are many moving parts which needs to be accounted for, and getting it correct, working and safe takes many iterations. Here at LaLoka Labs OÜ we have found out from our customers that one of the main uses they have for communications platforms API is to send out OTPs, but the OTP implementation itself is repetetive and complex. They spend too much time building and mainatining the OTP functionality rather than on their own business logic.

If your web service requires 2FA and OTP, I strongly suggest that you signup to GetOTP, a simple web API service that simplifies your OTP logic which removes the headache and complex implementation. You just need to make one API call and all the logic of the OTP flow is handled by GetOTP.