SMS registration like in the mobile app: whatsapp

The basic fundamentals are :

  1. Generate a random code in your app on the device. Ask user for his mobile number.
  2. Send this code and mobile number to your application running on server.
  3. Call the sms gateway API to send the code as a message to the mobile number specified.

There are many SMS gateway providers. You can search on google. Most of them also provide a tutorial for using their API in various programming languages. The cost is mostly based on per message and generally they are to be bought in the form of package of number of SMSes.


This article explains how to integrate sms verification to your android app just like whats App.

Android adding SMS Verification Like WhatsApp – Part 1

Android adding SMS Verification Like WhatsApp – Part 2

enter image description here

Basically the following steps involves in verifying mobile number

  1. First user mobile number will be sent to our server where new user row will be created.

  2. Our server requests the SMS gateway for an sms to the mobile number with a verification code.

  3. SMS gateway sends an SMS to the user device with the verification code.

  4. The verification code will be sent back our server again for verification. Our server verifies it and activates the user.


i know this post is too old, but this is for people that`ll visit this page in the future:

what the user "Harsh Shah" said is wrong..

you SHOULD NOT generate a random number on the device itself! this compromise the whole verification,

  1. you ask the user for phone number, send it to the server.
  2. as a response for that request, you generate a random number and save with the user number on there user records on db, and send SMS with that random number, the RESPONSE for the request should be SENT-OK, NOT-SENT.
  3. the device gets the SMS and send it back to the server to compare with the existed db record.

data exchange:

  1. phone sends('012345567')-> server respond('SENT-OK'); on background: server: [generate number, sends it in SMS, save in db for user 01234567, eg: 123123]

[phone reads the SMS eg as '123123']

  1. phone sends('01234567','123123')->server responds('AUTH-OK');

on background: server: [check db for record user 01234567, compare the random number generated in step 1 with the number the user sent).

if you generate the number in the user phone, any script-kiddie can hack your authentication by extracting this number from the memory/storage (so easy to do) and spoofing an sms containing it (super easy to do as well)... you might think this is a rare case, but this is a major hole in the security, you can authenticate yourself as any existing user and steal data from them if you do it the way "Harsh Shah" said...


Here's a simple phone number verification service built on top of Nexmo (disclaimer, I do a little developer evangelism for Nexmo). I think it's basically what you're looking for, the goal is to verify that a number actually belongs to a user (could also be used for 2nd factor authentication).

The basic integration for a mobile app (specifically for this example code, but a common flow):

  • Send the phone number to be verified, receive a unique hash.
  • The verification system sends a unique code to the user.
  • Once the user passes that code to your application, the original hash and the code are sent to the verification system to be validated.

You can drop out the hosted portion, and just take those steps inside your application (generate a code, send via a SMS API, check the code the user enters). However, there are a few things to consider at that point:

  • The credentials of the SMS API are compiled down into your distributed application. Is that something you want to risk?
  • The code is send via the network from the device; while SSL will stop casual observation of the code, someone who wanted to fake a registration could more than likely capture the code from the HTTP request.

Both of those issues are solved by putting the verification system outside the mobile application.