Ask or search…
K
Links
Comment on page

SDKs response

This page explains the reasons why an SDK is terminated. To do this, check the failure type of the object class present in the result object.
InstanceOf
Description
Example
Present SDKs
InvalidTokenReason
The token entered is not valid for the corresponding product
Parameterize "test123" as token in the SDK builder
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
PermissionReason
You are missing some mandatory permission to run the SDK
Start DocumentDetector without camera permission granted
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
AddressCheck
AvailabilityReason
The SDK is not yet available for use. The variable SDKFailure.getMessage() contains instructions for the user
The device's internal storage is full when installing the app, and the face detection template cannot be installed together
PassiveFaceLiveness
FaceAuthenticator
NetworkReason
Internet connection failure
User was without internet during facematch in FaceAuthenticator
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
AddressCheck
ServerReason
When an SDK request receives a status code of failure
In theory, it shouldn't happen. If you see something like this, let us know!
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
AddressCheck
SecurityReason
When the SDK cannot be started due to a security reason
When Google Security Provider is not updating
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
StorageReason
There is no space on the user device's internal storage
When there is no space on the internal storage while capturing the document photo
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
LibraryReason
When an SDK internal library cannot be started
Forgetting to set theCompress configuration will lead to this failure in the DocumentDetector
DocumentDetector
InvalidFaceReason
There is no face record for the given peopleId
When the user authenticates with a peopleId that has no face record
FaceAuthenticator

Example

The following example shows how to discover and handle the shutdown reason for the SDK:
if (passiveFaceLivenessResult is PassiveFaceLivenessSuccess) {
// the SDK has closed successfully
String? imageUrl = passiveFaceLivenessResult.imageUrl;
} else if (passiveFaceLivenessResult is PassiveFaceLivenessFailure) {
String? message = passiveFaceLivenessResult.message;
String? type = passiveFaceLivenessResult.type;
switch (type) {
case 'InvalidTokenReason':
// the token entered as a parameter is not valid, please revise it
break;
case 'PermissionReason':
// permission must be granted by the user to start the SDK
break;
case 'NetworkReason':
// internet connection failure
break;
case 'ServerReason':
// there was a problem in any communication with the CAF servers, let us know!
break;
case 'SecurityReason':
// some security reason on the user's device prevents the use of the SDK
int? code = passiveFaceLivenessResult.code;
break;
case 'StorageReason':
// ask your user to free up internal storage space
break;
case 'LibraryReason':
// some internal library encountered problems running
break;
}
}else{
// the user closed the activity
}
}

Security returns

We are constantly taking actions to make the product more and more secure, mitigating many attacks observed in the capture processes and, consequently, reducing as many possible identity frauds as possible. The errors described here are returned in the message field of the SecurityReason class.

Error 100

Represents SDK blocking emulated devices.
The use of emulators is very common by fraudsters nowadays, because of the possibility to access any existing device, opening a huge range of possibilities for new frauds. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the emulatorSettings parameter in the SDK Builder.

Error 200

Represents the blocking of devices with root privileges by the SDK.
The use of root devices is the main means of fraud today, because of the possibility of accessing a device with extra privileges, allowing the fraudster to access hidden properties, as well as the possibility of modifying and circumventing the entire security system behind the SDKs. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the rootSettings parameter in the SDK Builder.

Error 300

Represents the locking of devices with developer mode active.
Using devices in developer active mode allows a user to access unique development settings, such as the ability to debug applications using USB cables. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the useDeveloperMode parameter in the SDK Builder.

Error 400

Represents the locking of devices with Android Debug Bridge enabled.
The ADB command facilitates a variety of device actions, such as installing and debugging apps and provides access to a Unix shell. Because of this, by default, the SDKs perform this locking.
If you want to disable this validation, use the useAdb parameter in the SDK Builder.

Error 500

Represents the locking of devices with debug mode enabled.
Using devices with debug mode enabled allows a user to debug applications using USB cables, allowing them to understand and test different ways to bypass the SDK flow. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the useDebug parameter in the SDK Builder.

Error 600 (soon)

Represents the blocking of devices with fraudulent app signatures.
Signature verification blocks reverse engineering attacks and all other malicious attacks that can be done after this process in which the app has its original signature changed. Because of this, SDKs perform this blocking by default.
Last modified 8mo ago