This page will cover all the possible use cases to be considered when implementing social login.

Use cases can be broadly classified into three categories 

  • Category 1: Social Login System 
  • Category 2: Email Login System 
  • Category 3: Inter-login System

Category 1: Social Login System


These use cases are handled by ShopSocially

Use Case 1: User attempts a registration via social account

  • SUCCESS response is sent 
  • User data gets registered in ShopSocially

Use Case 2: Registered user logs in through the same social network

  • SUCCESS response is sent

Use Case 3: Registered user attempts a login via different social network

  • If the email address for both the social networks is same, the user is prompted to use the social network using which he registered first. 
  • If the email address for both the social networks is the different, the user is treated as a new user. SUCCESS response is sent and user data gets registered in ShopSocially.

Category 2: Email Login System


These use cases are handled by the merchant

Use Case 1: New user attempts a registration using email address

  • Call to ssmi_does_user_exist(email_address) is made 
  • {'exists': 'false'} response is received 
  • Merchant creates a new user through the email registration process

Use Case 2: User registered via email login system attempts a email login

  • Check if the password exists 
  • User is simply logged in using the email system

Category 3: Inter-login System


These use cases are handled by the merchant.

Use Case 1: Registered via Email login but attempts a Social login

  • ShopSocially treats him as a new user, SUCCESS response is sent
  • Merchant match the email address received in user_info object
  • If email matches merchant makes the password field blank. So the next time, the user will have to mandatorily login using the social network. Next time, he will move to Use Case 2 because he will be treated as a social login user.

Use Case 2: Registered via Social Login but attempts an Email Login

  • Merchant can find this by checking if the user email is registered but the password field is blank.
  • Call to ssmi_does_user_exist(email_address) API is made
    {'exists': 'true',
           'network_type': ‘<social network>'}
  • Merchant prompts the user to login using the appropriate social network

Take a look at the Social Login example that implements all the use cases described above.