End User Verification Even your Grandma Can Use

Verifying users is easy right? All you have to do is send them an email with a verification link and you’re done. Well, sometimes that may be all you need. If the stakes are low and it doesn’t really matter if they are a real person then that is typically enough. But what about if the stakes are high? What about when you want to know the person is a real human? This used to be quite difficult, but thanks to the IoT (Internet of Things) and cloud services like Nexmo this has gotten much easier. While it may not be possible to know for absolute certain your user is a real person without meeting them in person, there are things you can do to gain a reasonable level of trust that your user is real. A common method for this is to send the user a text message with a unique code and have them enter it into your application and make sure it matches. Of course a truly dedicated prankster or hacker may find ways to get around this, but it takes a lot of work and will be far too difficult for most people. Sending text messages from your application is quite simple with APIs from Nexmo, but there may be some challenges.

The first challenge I’ve run into is that users aren’t always very savvy and might give you their landline phone number rather than a mobile. This may just be my communication skills but I’ve had the real challenge on how to clearly communicate to users what text messaging is and how to know if their phone number supports it. It would have been nice if I didn’t even have to worry about that and could just ask the user for a phone number. I could just send the message and hope for the best, but that doesn’t seem like a very good way to take care of customers. Of course Nexmo “has an API for that”, the Number Insight API, which I can call  to determine if the number is a landline or a mobile, but then I’m stuck implementing all the logic required to check if the phone can support text messaging and if not, deciding what to do. If you are providing a service to the general public then you don’t just have to worry whether the number is a mobile or landline. Another concern you may have is whether the number is virtual, a premium/toll-free number, or a number known to be used by fraudulent punks.

The technology behind sending quick text messages to your friends and family is pretty good but it wasn’t designed for transactional business functions. If user verification is really important to you and probably has an impact on your bottom line, increase of verified users=increase of revenue, then using SMS is for business functions is the route to go. I don’t want to have to deal with this logic myself, I want to focus on my business and my user’s experience and not build out failover plans for things that should be simple, like validating a PIN with a user.

nexmo-verify

Thankfully these challenges have already been solved and in a way that could not be easier for me to use. Nexmo has released a new API called Verify that is designed specifically for user verification. With a single call to the Verify API you can provide a phone number and Nexmo will deal with the hassle of identifying if it is a landline or mobile phone or if it should be blocked. Based on what they find they will either send the PIN via a text message or make a voice call to the phone number and read the PIN to the user. Not only that, but if the user does not respond to the text message within a certain threshold, they will automatically failover to making a voice call. They’ll even make the voice call a second time for a total of three attempts to get the PIN to the user before giving up. So if the telco network fails to deliver the text message, there are still two opportunities for the user to answer a phone call and get the PIN. Now there are no communication issues with non savvy users, you can just ask for a phone number and use it. When the user submits the PIN to your application you simply call the Verify API again and validate that it is correct. Pretty nice. No need to generate codes, no need to expire them, just let Nexmo handle it.

Nexmo has also included features to make this service even more business and end user friendly like providing localization for text and voice messages. So you don’t have to translate a bunch of strings or try to record a bunch of voices reading messages, just tell Nexmo what language to use and they’ll do it. They have also implemented a flat rate billing model for it so costs are predictable and you only pay for successful verifications. You don’t pay for people who enter an incorrect phone number or are just trying to mess with your application by submitting dummy phone numbers. You also don’t need to try to account for the variances in cost for global messaging and voice calls. Your operations and finance teams will be happy.

I mentioned that these APIs are easy to use right? Check out these simple examples:

Example 1: Sending verification code

curl 'https://api.nexmo.com/verify/json' \
-d api_key=MY_API_KEY \
-d api_secret=MY_API_SECRET \
-d number=NUMBER_TO_VERIFY \
-d brand=MyApp

Response:

{
   "request_id": "79892501ad62196fbacbc547e5af2ccb",
   "status": "0"
}

Example 2: Validating a response

curl 'https://api.nexmo.com/verify/check/json' \
-d api_key=MY_API_KEY \
-d api_secret=MY_API_SECRET \
-d request_id=79892501ad62196fbacbc547e5af2ccb \
-d code=1728

Response:

{
   "request_id": "79892501ad62196fbacbc547e5af2ccb",
   "status": "0",
   "event_id": "0300000062186D73",
   "price": "0.10000000",
   "currency": "EUR"
}

There are also many clients for the Nexmo APIs that make this even easier from your favorite language, check out our libraries for PHP, Ruby, Node.js, Python and more.

I hope this article has helped you think through some of the challenges of end user verification and I encourage you to check out the Nexmo Verify API if you’re in need of a better system of verifying your users.

About the author: 

Phillip Shipley is the IT Applications Development manager at SIL International, Inc. He spends the majority of his work time developing web applications and has a particular passion for APIs and integration. When he’s not building software he’s probably building Legos with his son. Follow him on Twitter.

Phillip Shipley

Comments