Completing User Verification
Last updated
Last updated
Once you have received the user profile details at your backend, you need to complete the verification flow at your frontend. This requires you to essentially setup a proper communication mechanism in place between your frontend client and your backend. You can implement any of the below suggested methods to achieve the same :
Long Polling : As soon as you initiate the user verification flow at your frontend and get a successful check that Truecaller is present on the device, you can make a long polling request to your backend to check if the user's profile data has reached your backend or not. This kind of request can hold until a particular threshold time so that it waits for the profile response from your server Periodic Polling : Unlike long polling, you could also make a specific number of periodic requests [ say every 3 seconds ] to check if your backend has received the profile response or not and accordingly stop the polling as soon as you receive the response.
As a good practice, we recommend you to implement periodic polling with 5 polling cycles at an interval of 3 seconds each.
WebSocket Connection : With this approach, you establish a two-way, persistent connection between your client and the server to push the data back to the client as soon as the server receives the profile response. Unlike polling, this does not require the client to request or wait for the data. As soon as you receive the callback from Truecaller and fetch the user's profile, you can send the corresponding data to your frontend via the web socket connection. (In simpler terms, it's similar to a publish-subscribe system).
Please note that once users click 'Continue' on the Truecaller profile dialog, the entire verification process might take a few seconds to complete. This includes the time taken for your backend to receive the access token callback and then fetch the user's profile info and then finally send it to your client. As a good practice, we recommend you to show proper wait message (and a loader) to your users so that they are aware on the progress and ensure that they don't feel stuck.
For example, you may refer to some implementations .
Also, for a scenario when a user sees the Truecaller verification screen, but doesn't takes any action before the configured timeout has elapsed, your implementation may treat this UX behaviour in the same way as you would treat the absence of Truecaller app on the device, and invoke an alternate custom flow.