Common scenarios to check for in you app verification flow for non-Truecaller users

If the user does not have the Truecaller app present on their device or they chose to verify using a different number than the one already verified on Truecaller app currently, they can be taken to this flow in which we provision the verification of the user by sending missed call using our infrastructure.

User verifying via Truecaller's missed call mechanism for the very first time

Proceed to the flow where the user needs to input their mobile number. Give the necessary permissions ( as described here ) and proceed with the verification. You would receive a missed call on the device which gets automatically detected by the SDK. Post this, you need to pass the user's first name and last name to the SDK to complete the verification

User verifying via OTP mechanism ( if users deny phone permissions, as described here )

In case the user denies the needed permission in the above step, the means of verification would fallback to SMS based OTP instead of missed call. In that case, you can chose to implement your own fallback OTP infrastructure or opt for Truecaller's fallback SMS based OTP infrastructure. If you have opted for your own SMS infrastructure, you can chose to proceed as per your own flow. In case you have opted for Truecaller's SMS based OTP infrastructure, when you request for a verification for the user's number, Truecaller sends an SMS to the user containing the OTP. Once the OTP is keyed in by the user or automatically read ( using the SDKs SMS retriever functionality ), you need to pass the user's first name and last name along with the OTP to the Truecaller SDK method to complete the verification flow.

User already verified with the same credentials previously on the smartphone

Once a user's verification is completed successfully on a particular device, and they re-attempt to verify on the same app using the same credentials ( same smartphone, same mobile number ), Truecaller SDK is able to identify the user and we can tell you it's the same user. In this case, no additional missed call / OTP is needed to re-verify the user. The SDK will directly tell the status of the repeat user, and in this case returns the first name and last name of the user back to you in response.

Common scenarios to check for in you app verification flow for existing Truecaller users:

Truecaller app present and registration completed on Truecaller app

Ensure that the Truecaller app is present on your device and you have completed the profile creation step on Truecaller app. Open your app and initiate the Truecaller verification flow. The user should see the Truecaller profile dialog. Click on continue to complete the verification flow and ensure that the verification is completed.

Truecaller app present but registration not completed on Truecaller app

Ensure that the Truecaller app is present on your device but you have not completed the profile creation step on Truecaller app. Open your app and initiate the Truecaller verification flow. The user should not see the Truecaller profile dialog, and you would receive the control in onFailureProfileShared() with the specific error code.

Truecaller app not present on the device

Remove the Truecaller app from your device. Open your app and try to initiate the Truecaller verification flow. The user should not see the Truecaller profile dialog and should be taken to either your alternate verification flow or in case you are using Truecaller SDK's functionality of verifying non-Truecaller users, user should be redirected to that flow.

Network not available on device

Ensure that the Truecaller app is present on your device and you have completed the profile creation step on Truecaller app. Turn off the mobile data and WiFi on your device. Open your app and initiate the Truecaller verification flow. You would see the Truecaller profile dialog. Click on continue button on the dialog, you would receive control in onFailureProfileShared() method with a specific error code.

Partner key should be working fine ( onFailureProfileShared() Error Type 3 )

For complete details on this part, please refer here

User wishes to proceed with another number OR does not want to share their Truecaller profile

Initiate the Truecaller verification flow in your app to invoke the Truecaller profile dialog. Click on system back or Use another mobile number button on the dialog to dismiss the dialog. In such a scenario, user should be taken to either your alternate verification flow or in case you are using Truecaller SDK's functionality of verifying non-Truecaller users, user should be redirected to that flow.

We also recommend that you go through the FAQ section to go through some of the commonly asked questions

In case you are using the app signing feature of google play store, when you upload your release build to the google play store, it assigns a new SHA1 fingerprint to your app - which might lead to UNAUTHORISED_PARTNER_KEY error for your app, since the appKey used by you in your app config was generated for a different SHA1, and hence won't work for the new SHA1.

In this scenario, you need to go to the "app integrity section" of the Google play console, where you would see 2 SHA1 keys (a) Upload Certificate SHA1 and (b) App Signing Certificate SHA1.

You need to note down the "App Signing Certificate SHA1" from the console, and generate a new Truecaller partner key ( app key ) for your play store build. Configure this key for your play store build in your project, and upload the build on play store for your users.

Quick guide on getting your test setup ready to test the common verification scenarios as described in previous sections:

Pre-Requisites

• We suggest you to keep handy at-least 2 android smartphones with active SIM connections. Ensure that both the smartphones have your test app installed (Integrated with Truecaller SDK)

• 2 different smartphones are required so that in case you get verified on one of the smartphones, you can use the second smartphone to check for the fresh verification scenarios.

Steps to follow for testing user scenarios :

Truecaller SDK versions lower than v2.7.0 use device ID and SIM serial identifiers for the non-Truecaller user verification flow ( drop call based verification ). With the v2.7.0 release, we have removed dependency on these attributes. As per the recent Google play store app policy changes, apps shouldn’t use these identifiers in conjunction with the phone number. Google Play sends your app a warning in case your app ( including any integrated 3rd party libraries ) is using these identifiers.

If you are using Truecaller SDK version less than v2.7.0, we recommend you to update the same to 2.70 and above. Once you upgrade the SDK version, the above mentioned issue around play store publishing would be resolved.

The latest SDK version is completely in line to google play’s new data privacy policies and hence has been listed on the google play SDK index as well. Only policy compliant SDKs are listed on the SDK index.

For you to upgrade to the latest SDK version, you may refer to the change log here.

This section is only relevant for apps who are using the Truecaller SDK for verifying non-Truecaller user as well and seek phone permissions from the users

If you are using the functionality of verifying non Truecaller users also via the SDK, your app would need specific phone permissions as has been described in this . If you are using the Truecaller SDK for verification of existing Truecaller users only ( 1-tap flow ), you can skip this section.

As you upload the new app build to PlayStore with user verification feature via Truecaller SDK and the requisite permissions, you might be asked to fill an app permission declaration form.

We are sharing some tips on how to appropriately justify the need for these permissions for your verification flow :

#1: In one sentence, please describe the core functionality of your app. To be defined by you as a publisher of your app

#2: What is the core functionality in your app requiring the Call Log and / or SMS permissions? Mobile number verification to onboard users on <your_app>

This is in-line with Google’s allowed usage of this permission for account verification via phone call, as stated here: https://support.google.com/googleplay/android-developer/answer/9047303 Flow: a)Enter mobile number b)Request READ_CALL_LOG permission c)Initiate drop call from 3rd party service to respective number d)Drop call hits user’s device and is rejected automatically via above permission to complete verification

#3: Do any of the following disallowed use cases apply to your app’s core functionality request for Call Log or SMS permissions? NO

#4: Do any of the following other use cases apply to your app’s core functionality request for Call Log or SMS permissions? OTP & Account verification via Phone Call (select this from the given list of options)

#5: Is your app’s use of Call Log or SMS permissions to provide functionality required by law or regulation? No

#6: Other We use drop call based verification of users’ mobile number for account creation or logging into their <your app name> accounts. Such method of mobile number verification results in better verification success rates in our key markets like India, etc.

Android guidelines for asking app permissions from user