Introduction

Entrust Identity Services (formerly Onfido) are streamlining their platform offering in 2025, bringing closer together:

• Identity Verification products
• Studio, their bespoke orchestration platform
• Mobile and Web SDK APIs

This guide is intended to offer instructions for the integration of, and migration to, the following major version of our SDKs:

• Android SDK (beta version released in June 2025)
• iOS SDK version (version to be released in July 2025)
• React Native SDK (version to be confirmed in Q3 2025)
• Flutter SDK version (version to be confirmed in Q3 2025)

Please note: the Web SDK is also in scope of this guide and will align with the new configuration API with an upcoming minor release of version 14.

Foreward on beta scope

Over the second half of 2025, the next major version of the Entrust Identity Verification SDKs (formerly Onfido Smart Capture SDKs) will introduce a fundamental redesign of the customer integration experience and configuration capabilities.

Starting with a beta program in June 2025 for the Android SDK, additional features and platforms will be released in the coming months with the aim of replacing the existing SDK architecture by the end of 2025. Until the beta program is closed, the SDKs in scope of this document will be labelled as next in their respective distribution platforms.

The first release of the beta SDKs for Android and iOS (due in June and July 2025 respectively) will have the following limitations:

• No support for NFC (will be introduced in September/October 2025)
• Limited supported for UI customisation (will be gradually introduced over July/August 2025)
• Some visual discrepencies between native and web modules (brand footer, fonts)
• Limited configuration options for the Document Capture module

In the first phase of the beta program (June to early August), the integration API and this guide are subject to change.

Once the full feature set is released on the Android and iOS SDKs, the React Native and Flutter SDKs will be released.

Minimum dependencies and SDK distribution

The SDKs are available from the main distribution channel for their respective platforms:

Android

iOS

Web

React Native

Flutter

Environments and testing with the SDK

Two environments exist to support the SDK integrations:

• sandbox - to be used for testing with sample documents
• live - to be used only with real documents and in production apps

The environment being used is determined by the API token that is used to generate the necessary SDK token.

Sample apps

Each SDK repository contains a set of sample apps that provide the minimum integration code required to initialise the SDK in supported frameworks.

Promotion to production

Once you are satisfied with your integration and are ready to go live, please contact Customer Support to obtain a live API token.

Check that you have entered correct billing details inside your Dashboard, before starting to send requests in the 'live' environment.

Staying up-to-date

We recommend you update your SDK to the latest version release as frequently as possible. Customers on newer versions of the SDK consistently see better performance across completion rates and fraud mitigation, so we strongly advise keeping your SDK integration up-to-date.

You can review our full SDK versioning policy.

Support

Should you encounter any technical issues during integration, please contact Customer Support.

Alternatively, you can search the support documentation available via the Customer Experience Portal.

SDK Bundle and Product Availability

The new SDKs will support the full Entrust Identity Verification Suite.

💡 A key innovation of this new generation of SDKs is the ability for the SDK integrator to select whether a given verification product should be included in the local bundle (and therefore contribute to the overall SDK bundle size) or be retrieved dynamically from the Entrust Content Delivery Network (CDN) as a Javascript component.

Availability of native and Web modules

The table below lists all verification modules available via the SDKs and whether they are available natively within the SDK bundles or only as Web variants. There is currently no plan to introduce new native modules.

Please note: all modules will have the same configuration and customisation interface across their native and Web variants and across platforms.

CDN module versioning and pinning

When a Web module or Web module variant is loaded dynamically at runtime, the version corresponding to the underlying SDK will be used. Note that: the ability to target different compatible versions will not be provided to integrators directly.

SDK Bundle Release

With every release, a default version and a 'core' version of the mobile SDK bundles will be made available, each providing distinct advantages.

Default bundle

Similar to previous versions of the SDK, the default SDK bundle (not labelled with a particular suffix) will include all available SDK assets:

• All native modules available at the time of the release
• All language files supported by the SDK UI (currently 44)
• All videos and other assets

Please note: particular effort has been put into reducing both the individual module size and the overall default bundle:

• More efficient alternatives have been introduced to support NFC and on-device document and face recognition
• The logic to override text has been simplified to only require 'deltas' instead of full custom files
• The iOS bundle in particular has benefited from core improvements (static build, no debug symbols etc.)

The default bundle is available as:

'Core' bundle

A key innovation of the new generation of mobile SDKs is the introduction of a secondary SDK bundle, labelled with the suffix -core. While the out-of-the-box core SDKs can function using only remote assets, integrators are able to explicitly select which native modules and assets are available locally in the app. This SDK variant is intended to provide full flexibility to integrators and control of the SDK size and the use of local or remote modules and assets.

Android

iOS

Web

React Native

Flutter

Whether included as a native module or not, all modules are available at runtime as Web modules.

Additionally, the core bundle will not include any local language files. Unless explicitly imported, localisation files will be retrieved at runtime from the Entrust CDN.

Adding modules to the 'core' bundle

Android

iOS

Web

React Native

Flutter

1dependencies {
2  ...
3  // SDK core libraries
4  implementation("com.onfido.sdk:api:<<version>>")        // Always required
5  implementation("com.onfido.sdk:core:<<version>>")       // Always required
6
7  // Native modules
8  implementation("com.onfido.sdk:core:<<version>>")
9  implementation("com.onfido.sdk:document:<<version>>")   // Available in Q3 2025
10  implementation("com.onfido.sdk:nfc:<<version>>")        // Available in Q3 2025
11  implementation("com.onfido.sdk:face.photo:<<version>>")
12  implementation("com.onfido.sdk:face.motion:<<version>>")
13  ...
14}

SDK Initialisation and Orchestration

The SDK is initialised in three steps:

• Applicant generation
• Workflow run and credential generation
• SDK runtime initialisation

The process is optimised for SDK sessions based on workflows predefined in Studio. Workflow-based SDK sessions may contain the full IDV product suite and benefit from a simplified API integration.

Applicant generation

'Applicant IDs' are used to track an IDV session across the capture and report verification stages. An applicant_id is required to generate the SDK token. This step applies to both Studio workflow and non-Studio-workflow-based verification flows.

Please refer to the Create applicant section of our API documentation for more details. ⚠️ As this request is authenticated with an API token, it is imperative to perform it from a secure backend.

Applicant reuse

When defining workflows and creating identity verifications, we highly recommend saving the applicant_id against a specific user for potential reuse. This helps to keep track of users should you wish to run multiple identity verifications on the same individual, or in scenarios where a user returns to and resumes a verification flow.

An applicant_id however must not be reused for different users.

Workflow run and authentication token generation

The integration of the latest SDK versions has been simplified by only requiring a Studio SDK token for authentication and orchestration. This token is available from the successful response to the workflow run creation API request. This request combines the instantiation of a Studio workflow predefined in the Workflow Builder with the linking to a unique applicant.

Please note: Studio SDK tokens are bound in time and scope to the validity of the underlying workflow run. Please refer to the Create worfklow run section of our API documentation for more details.

For integrations that are yet to migrate to workflow-based orchestration in Studio, a manual SDK token must be generated as defined in the Generate SDK token section of our API documentation. Generic SDK tokens are limited to a 90-minute expiry. It is highly recommended for integrators to adopt Studio workflows for a simpler, more secure and future-proof integration.

⚠️ As both the Create workflow run and Generate SDK token API requests are authenticated with an API token, it is imperative to perform them from a secure backend.

Handling expired tokens

The ability to automatically refresh expired tokens has been discontinued from the new SDKs.

It is highly recommended to adopt workflow-based flows and tokens to ensure that tokens remain valid for the same duration as the underlying workflow and thus reduce the impact to end users.

SDK runtime initialisation

This new generation of SDKs provide a common API for initialisation and customisation of SDK sessions across all platforms.

While the overall bootstrapping code is platform-specific, its contents are consistent in their structure and typing. The minimum integration code for the SDK to function requires an SDK token for authentication and the implementation of the three key callbacks that notify the embedding app when the SDK has completed its flow or has encountered errors:

Android

iOS

Web

React Native

Flutter

1class MainActivity : AppCompatActivity() {
2...
3  override fun onCreate(savedInstanceState: Bundle?) {
4      super.onCreate(savedInstanceState)
5      EntrustIdv.start(
6        StudioParameters(
7          sdkToken = studioToken
8          )
9        /* For clients that are yet to migrate to workflow-based verification flows, ClassicParameters would need to be provided instead of StudioParameters
10        ClassicParameters(
11          sdkToken = sdkToken,
12          steps = listOf<Step<*>>(
13              WelcomeStep(),
14              MotionStep(),
15              DocumentStep(),
16          )
17        )
18        */
19      )
20  }
21
22  private val entrustIdv = EntrustIdv(
23      activity = this,
24      callbacks = Callbacks(
25          onComplete = { result ->
26              // Note that the `result` payload will be an empty Map object for workflow-based sessions as the data is provided by dedicated webhooks to your integration
27              Log.d("MainActivity", "The verification flow was completed successfully with result $result")
28              finish()
29          },
30          onError = { error ->
31              Log.e("MainActivity", "Error category:${error.type.category} / error type ${error.type.name}/${error.type.message} / metadata: ${error.message}")
32              finish()
33          },
34          onUserExit = { userAction ->
35              Log.d("MainActivity", "The user exited the verification flow. Reason: $exitReason")
36              finish()
37          },
38      ),
39  )
40
41...
42}

onComplete(result) callback

The onComplete callback is triggered as soon as the last possible capture step defined in the underlying verification workflow has been completed without error. The result payload is an empty Map object (or equivalent) as information about the files uploaded by the end user during the session should be retrieved via the dedicated Document, Face Photo and Face Video API endpoints.

Please note: for integrations that are yet to migrate to workflow-based sessions in Studio, the onComplete callback will return a payload that details the identifiers of the media resulting from this flow. In this legacy construct, the result is a Map (or equivalent) object, mapping the module identifier (key) to an object containing the unique id of the uploaded media. These identifiers can then be used to retrieve the full document or face capture using the corresponding document, live_photos (for 'standard' selfies) or live_videos (for 'video' or 'motion' captures) endpoints defined in the API reference.

The json example below gives a serialised representation of the result payload returned at the end of non-workflow-based flows.

Note:

• The Map's keys are the same as the corresponding step's name
• At runtime, this payload will be typed for ease of integration

1{
2  "document": {
3    "type": "driving_licence",
4    "sides": {
5      "front": {
6        "id": "<DOCUMENT_ID_FRONT>"
7      },
8      "back": {
9        "id": "<DOCUMENT_ID_BACK>"
10      },
11      "front_video": {
12        "id": "<DOCUMENT_ID_FRONT_VIDEO>"
13      },
14      "back_video": {
15        "id": "<DOCUMENT_ID_BACK_VIDEO>"
16      }
17    }
18  },
19  "facePhoto": {
20    "id": "<MEDIA_ID>"
21  },
22  "faceVideo": {
23    "id": "<MEDIA_ID>"
24  },
25  "faceMotion": {
26    "id": "<MEDIA_ID>"
27  },
28  "poa": {
29    "type": "utility_bill",
30    "sides": {
31      "front": {
32        "id": "<POA_DOCUMENT_ID_FRONT>"
33      },
34      "back": {
35        "id": "<POA_DOCUMENT_ID_BACK>"
36      },
37      "front_video": {
38        "id": "<POA_DOCUMENT_ID_FRONT_VIDEO>"
39      },
40      "back_video": {
41        "id": "<POA_DOCUMENT_ID_BACK_VIDEO>"
42      }
43    }
44  }
45}

onError(error) callback

The onError callback is triggered when the SDK flow can no longer proceed due to an underlying operating system, browser or library issue. The error payload contains an error category property, paired with a more granular error type. This is intended to help integrators with handling errors over time as new codes are introduced under the existing category values. The message field is optional and may contain additional debug information.

The json example below gives a serialised representation of the error payload returned at the end of non-workflow-based flows. At runtime, this payload will be typed for ease of integration.

1"error": {
2    "errorType":{
3        "category": <<Error category>>,
4        "type": <<Error Type>>
5    },
6    "message": string
7}

onExit(userAction) callback

The onExit callback is triggered when the end user manually exits the verification flow. It is intended to provide the integrator with the opportunity to re-engage with the end user and potentially offer alternative verification flows. The userAction payload can be one of the following:

Optional callbacks

Biometric token handlers

When using Studio authentication tasks with on-device storage, the SDK stores encrypted biometric tokens on the end user's device or browser local storage. The SDK also allows clients to take control of the token lifecycle and exposes a callback to override the default implementation to read and write the token, so it can be stored on device, in cloud, in a keystore or in your infrastructure.

Please note:

• Defining the callback will prevent the SDK from storing the encrypted biometric token.
• To store the encrypted biometric token in your infrastructure, it is recommended to rely on webhooks instead.

Android

iOS

Web

React Native

Flutter

1class CustomBiometricCallback: BiometricTokenCallback {
2    override fun onTokenGenerated(customerUserHash: String, biometricToken: String) {
3        // Called when a new biometric token is generated during enrollment
4        // Please ensure that customerUserHash to biometricToken relationship is 1:1
5    }
6
7    override fun onTokenRequested(customerUserHash: String, provideToken: (String) -> Unit) {
8         // Called when the biometric token is requested during re-authentication
9    }
10}

onAnalyticsEvent(event) callback

The onAnalyticsEvent callback is an optional integration feature that requires activation from the Customer Support team. It is triggered whenever the end user reaches a new screen and is intended to provide integrators with a high-level view of the flow's progress and allow for some targeted progress and drop-off analysis. This mechanic is not recommended for most integrations.

onMedia callback

The onMedia callback is an optional integration feature that requires activation from the Customer Support team. The callback is triggered at the end of every applicable module execution.

Please note: Only the Document, Face Photo and Face Video modules return a payload.

This mechanic is not recommended for most integrations for security and performance reasons. The recommendation is to retrieve the media payloads from the corresponding Studio webhooks and API requests.

SDK permissions

In order to launch successfully and for individual capture modules to function, the SDK requires specific App or browser permissions.

If the embedding app has correctly declared the required permissions, the end user will be prompted at runtime to grant them:

• If the user declines any of the operating system or browser prompts, the SDK will attempt to recover the required permissions by providing instructions to the user
• If the user continues to permanently block the required permissions, the SDK will not be able to proceed and terminate in error

Modules not listed above do not require dedicated permissions.

Android

iOS

Web

React Native

Flutter

NSCameraUsageDescriptionRequired for document and face capture

NSMicrophoneUsageDescriptionRequired for video capture

NFCReaderUsageDescription
Required to read ePassports
...
com.apple.developer.nfc.readersession.felica.systemcodes
12FCcom.apple.developer.nfc.readersession.iso7816.select-identifiersA0000002471001A000000247200100000000000000D2760000850101

NSPhotoLibraryAddUsageDescription
Required to read images from the photo library, when uploading documents

1<key>com.apple.developer.nfc.readersession.formats</key>
2<array>
3    <string>PACE</string>
4    <string>TAG</string>
5</array>

SDK configuration

This section details the optional SDK configurations that can be set for a given capture flow. Please note: some features will be introduced as Studio configuration options later in 2025.

User Interface (UI) customisation

Studio's Theming Dashboard is due for beta testing in Q3/Q4 2025. Please contact your Customer Success Manager for more information. As an alternative to the Studio Theming Dashboard, the following options can be set at runtime as part of the SDK initialisation script under the property theme.

By default, the SDK uses the operating system or browser theme (i.e. Dark or Light) when rendering screens. The theme optional object allows integrators to preselect the overall theme and override specific UI properties.

Pre-selecting Light or Dark mode

• name {ThemeName} - optional

The optional name property is used to pre-select the base theme used by the SDK. It accepts either Light or Dark as values.

Customising the brand footer

• branding {Object} - optional

The optional branding object allows integrators to customise the screen's footer to provide brand continuity when the SDK flow is embedded in a 3rd party application. Note that by default, no brand footer is displayed.

The following options are available:

Please note:

• The integrator needs to consider the theme (Light/Dark) currently applied to the screen when custom text and logo are provided
• The colour of the text and logo provided in the branding object can be overridden as defined in the subsequent section of this guide
• ⚠️ As a change from previous versions of the SDK, by default, no brand name or logo is shown

Customising screen component style

• overrides {Map<String, String>} - optional

The style of all screens provided by the SDK can be customised to match the integrators brand and styling requirements. This is achieved by specifying the list of UI tokens that should be overridden for a particular flow. Remote UI customisation and overrides will be introduced via Studio in late 2025.

The list of UI tokens that can be overridden is provided in SDK language and UI customization guide and apply to all SDK platforms.

Please note:

• The integrator needs to consider the theme (Light/Dark) currently applied to the screen when customising tokens.
• While UI tokens available in previous SDK versions will still be accepted by the upcoming SDK releases, it is highly recommended that integrators migrate to the new token hierarchy and naming conventions to ensure that new screens and layouts are rendered correctly.

Localisation and text customisation

The ability to affect the text displayed in the SDK screens via the Studio Dashboard will be released in late 2025 to beta users. Please contact your Customer Success Manager for more information.

The SDK supports more than 40 languages and regional variants and, by default, uses the end user's device or browser locale to determine the language to be rendered on screen. By default, all screens are rendered in en-US English.

The list of available languages is available in the SDK language and UI customization guide.

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  EntrustIdv.start(
4  ...
5    configuration = Configuration(
6      ...
7      localisation = Localisation(
8        language = "en"
9        allowedLanguages = listOf("en", "el")
10        overrides = mapOf(
11            "en" to mapOf(
12                "welcome.title" to "Custom welcome title",
13            ),
14        ),
15      )
16    )
17  )
18}

Explicit language selection

• language {locale} - optional (default en-US)

For integrators that want to preserve their own app session's language across the verification flow, the language property can be set to any of the supported locales. Additionally, the integrator may define a custom language and use its identifier as the value for the language property. Refer to Custom Languages section below for more information on custom languages.

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(
4  ...
5    configuration = Configuration(
6    ...
7      localisation = Localisation(
8        language = "en"
9      )
10    )
11  )
12}

Please note: if the end user's language is not one of the supported languages or if the locale provided under language is invalid, en-US will be selected as the fallback.

Restricting possible languages

• availableLanguages [locale] - optional

If the integrator wants to limit the possible languages that could be rendered at runtime, a list of locales (including custom identifiers) can be passed to the optional property availableLanguages. This feature is intended for integrators that want to ensure that all languages shown to end users are limited to those supported by their own business and support teams.

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(
4    ...
5    configuration = Configuration(
6      ...
7      localisation = Localisation(
8        allowedLanguages = listOf("en", "el")
9      )
10    )
11  )
12}

Custom text overrides

• overrides {Map<String, String>} - optional

Custom text can be added by overriding individual text strings for all languages required or allowed by your implementation.

Android

iOS

Web

React Native

Flutter

The full list of keys that can be customised, and their hierarchy, is available on the Entrust Content Delivery Network (CDN) and is split by module and language.

Please note: the same keys are available across all supported languages and are accessible by specifying the appropriate language name in the URL (en_US.json in the example above).

Custom languages

The SDK allows the use of custom languages alongside all officially supported languages. This functionality is achieved by:

• defining a unique language identifier
• using the unique language identifier within the localisation object, mapping any required strings to the existing language file structure

Android

iOS

Web

React Native

Flutter

Please note: custom languages, in a similar way to regular text overrides, work as 'deltas' to the base language file they relate to. For example, a custom language defined as fr_Custom would be based off of fr for missing keys.

Additional SDK configuration

The following section details additional configuration options that can be applied to the overall SDK flow. For implementations that are yet to migrate to workflow-based orchestration in Studio, the options can be added to the object configuration at the root of the EntrustIdv initialisation object.

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(
4  ...
5    configuration = Configuration(
6      ...
7      disableAnalytics = false,
8      showExitButton = true
9    )
10  )
11}

Privacy and analytics

The SDK collects, by default, telemetry used to monitor the performance of the SDK, defend against fraud and help improve the accessibility of screens.

While core analytics are essential to the functioning of the overall service and are always sent to the Entrust services, behavioural analytics can be disabled during the initialisation of the SDK.

• disableAnalytics {Boolean} - optional (default false)

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(
4  ...
5    configuration = Configuration(
6      ...
7      disableAnalytics = false
8    )
9  )
10}

Please note:

• Disabling analytics will also disable browser cookies (when set for the Web SDK)
• Disabling analytics will also prevent any analytics returned via the onAnalytics callback

For more information about the scope of the SDK analytics and privacy implications, please refer to the our SDK Data Collection Overview guide.

Back navigation

A back button is present on all SDK module screens to allow end users to navigate back within any module. It is not however possible to navigate between SDK modules as the state of the previously completed task cannot be modified.

Please note:

• ⚠️ The back navigation behaviour is now applicable to both workflow-based and non-workflow-based flows (back navigation was previously possible between modules in non-workflow-based flows)
• When the back button is not displayed, the operating system, hardware or browser 'back' navigation is also disabled
• Forward navigation is disabled throughout the user flow

Exiting the flow

By default, the exit button is not present on any SDK screens for both workflow-based and non-workflow-based flows. It can be enabled using the following option

• showExitButton {Boolean} - optional (default false)

Note that when the end user taps or clicks the button, the flow will terminate with the onUserExit callback with the action UserExit.

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(
4  ...
5    configuration = Configuration(
6      ...
7      showExitButton = true
8    )
9  )
10}

SSL certificate pinning

SDK module configuration

This section details, per module, the configuration options that can be applied at runtime for a given flow. While certain options are currently only applicable to implementations that are yet to migrate to workflow-based orchestration, they will be gradually introduced in Studio over the rest of 2025.

Welcome

This module enables the display of the introduction screen shown at the beginning of a flow. It introduces the process and prepares the user for the steps that they will need to complete.

While this screen is optional, we only recommend its removal if you already have your own identity verification introduction screen in place.

For non-workflow-based flows, the display of the screen is controlled by the inclusion (or omission) of the Welcome step from the initialisation code.

Document and NFC capture

The Document module allows the image and NFC capture of the end user's identity document. The module combines both live capture and NFC scanning.

The execution of this module is controlled by the presence of a "Document Capture" task in your Studio workflow. The task has the following configuration options:

• Restricting the document type and country of issuance that can be selected by the end user
• Whether NFC is available. When enabled the option to force NFC can be selected

Document filtering

As part of the flow, the end user is prompted to select the issuing country and document type before proceeding to the document's capture. This information is used to optimise the capture experience, as well as inform the end user about which documents they are allowed to use.

Please note:

• The selection screen is dynamic and will be automatically hidden when the document filtering configuration doesn't require the end user to indicate which document will be captured
• In a very limited number of cases, the end user may also be asked if they have a card or paper version of their document via an additional prompt

As part of the workflow configuration, it is possible to restrict the documents that can be selected in two ways:

• Within a Document Capture task, documented in the Studio Product guide.
• Otherwise, the recommended approach is to apply this configuration globally in your Dashboard under Accounts \ Supported Documents, as this configuration is also applied to your Document Reports. Any document that has been uploaded by an end user against your guidance will result in a Document Report sub-result of "rejected" and be flagged as Image Integrity > Supported Document.

Document filtering for non-workflow based sessions

For integrations that are yet to migrate to workflow-based flows in Studio, the Document step defined in SDK initialisation configuration may optionally include:

• documentFiltering: {Filters} - default all documents allowed

The documentFiltering parameter accepts two optional lists of DocumentSelection objects: one to exclude particular document types or countries and one to onlyinclude certain document types or countries. The two can be used together to provide the appropriate selection to the user.

The DocumentSelection object is defined as below:

Android

iOS

Web

React Native

Flutter

1DocumentSelection(
2  documentType: <<Passport, DrivingLicense, NationalIdentityCard, PassportCard, ResidencePermit, Generic>>,  // "Generic" is defined in the following section
3  issuingCountry: String,    // Issuing country of the document in 3-letter ISO 3166-1 alpha-3 format. Must not be used in conjuction with "allCountries" option
4  allCountries: Boolean,     // Whether the documentType selected should be applied to all possible countries
5  id: String,                // Used to uniquely identify a "Generic" documentType
6)

In the example below, the user will only be able to select a passport or driving license from any country (as a result of the include definition), but for France only passports will be accepted (exclude removes the option of a driving license for that country):

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(ClassicParameters(
4    ...
5    steps = listOf<Step<*>>(
6      ...
7      Document(options = Options(
8        documentFiltering = DocumentFiltering(
9          include = listOf(
10            DocumentSelection(
11              documentType = DocumentType.Passport,
12              allCountries = true
13            ),
14            DocumentSelection(
15              documentType = DocumentType.DrivingLicence,
16              allCountries = true
17            )),
18          exclude = listOf(
19            DocumentSelection(
20              documentType = DocumentType.DrivingLicence,
21              issuingCountry = "FRA"
22          )),
23        )
24      )),
25    )
26  ))
27}

An additional option to extend the DocumentFiltering list can be used to add custom document types to the existing list of documents. This is explained in the following section.

Please note the following SDK behaviour:

• Hard-coding any document type and issuing country configuration in your SDK integration will fully override the Dashboard-based settings.
• Passports have the same format worldwide, so the SDK will not show the country selection screen if include only contains passports and they are not restricted by country (e.g. allCountries = true).
• Currently only the following document types are supported by the SDK. If you select other document types in your Dashboard (visa, for example), these will not be displayed in the SDK selection screen. If you need to add other document types to the document selection screen, you can mitigate this limitation in the short-term, using the Generic Document feature.
  • Driving Licence
  • National Identity Card
  • Passport
  • Passport Card
  • Residence Permit
  • Generic - more information in the next section

Inclusion of generic document types

This feature is currently only available for non-workflow-based flows. It allows for an arbitrary document type to be shown to the end user for selection. To use this feature:

• Generic documents must be defined in the genericDocuments property

• Using their unique identifiers, the newly defined generic document types can be added either to the extend property of the DocumentFiltering property (to add it to the default selection list) or the include property (to add it to a specific filtered list)

• genericDocuments: {List<GenericDocument>} - defaults to no generic documents

The GenericDocument object is defined as below:

Android

iOS

Web

React Native

Flutter

1GenericDocumentType(
2  id: String,         // Unique identifier of the document type. Used in the "DocumentFiltering" object
3  country: String,    // Issuing country of the document in 3-letter ISO 3166-1 alpha-3 format
4  pages: Int,         // Number of pages that should be captured for this document. Can either be 1 or 2
5  title: String,      // Name of the document as it will appear on the screen
6  subTitle: String,   // Short description of the document that will appear on the document selection screen
7)

In the example below, a custom, one-sided, document type is added to the default document selection list. It will only be available for French documents (as per its definition):

Android

iOS

Web

React Native

Flutter

1...
2  entrustIdv.start(ClassicParameters(
3    ...
4    steps = listOf<Step<*>>(
5      ...
6      Document(options = Options(
7        genericDocuments = listOf(
8          GenericDocumentType(
9            id = "custom_lunch_card_FR",
10            country = "FRA",
11            pages = 1,
12            title = "Lunch Card",
13            subTitle = "Front picture of your lunch card"
14          )
15        ),
16        documentFiltering = DocumentFiltering(
17          extend = listOf(
18            DocumentSelection(
19              documentType = DocumentType.GenericDocument,
20              id = "custom_lunch_card_FR"
21            ),
22          )
23        )
24      ))
25    )
26  ))

NFC

Recent passports, national identity cards and residence permits contain a chip that can be accessed using Near Field Communication (NFC). The SDK provides a set of screens and functionalities to extract this information, verify its authenticity and provide the results as part of a Document report.

The behaviour of NFC capture is controlled within the Document Capture Studio task by one of the following options:

• Disabled: NFC reading will not be asked of end users
• Optional (Default): NFC reading will be attempted, if possible
• Required: NFC reading will be enforced, preventing end users from completing the flow without a successful reading

For more information on how to configure NFC and the list of supported documents, please refer to the NFC for Document Report guide.

For non-workflow-based flows, the Document step may optionally include the following options:

• nfcPolicy: { Disabled | Optional | Required } - default: Optional

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(ClassicParameters(
4      ...
5      steps = listOf<Step<*>>(
6        ...
7        Document(options = Options(
8          nfcPolicy = NFCPolicy.Required
9        )),
10      )
11    )
12  )
13}

Proof of Address capture

The Proof of Address capture module allows for the verification of an end user's address document. Users will be asked to select the issuing country of their document, the document type, and to provide images of their selected document. They will also have a chance to check the quality of the images before confirming.

There are no customisation options for this step.

Face Photo

The Face Photo module enables the capture of the end user's face in the form of a photo. For performance and compliance purposes, the Face Motion module is recommended instead.

The execution of this module is controlled by the presence of a "Face Capture: Photo" task in your Studio workflow. The task has the following configuration options: - Show introduction screen (default true). When disabled, the end user would be taken directly to the capture screen.

⚠️ As the Intro screen provides valuable information on how to successfully get verified, it is recommended to display it unless the integrator decides to provide their own instruction screen.

For non-workflow-based flows, the FacePhoto step may optionally include the showIntro: Boolean property (default true) in its Options.

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(ClassicParameters(
4      ...
5      steps = listOf<Step<*>>(
6        ...
7        FacePhoto(options = Options(showIntro = true)),
8      )
9    )
10  )
11}

Face Video

The Face Video module enables the capture of the end user's face in the form of a video. For performance and compliance purposes, the Face Motion module is recommended instead.

The execution of this module is controlled by the presence of a "Face Capture: Video" task in your Studio workflow. The task has the following configuration options: - Show introduction screen (default true). When disabled, the end user would be taken directly to the capture screen. - Show confirmation video preview (default true). When disabled, the video file is automatically submitted after the capture finishes. - (coming soon to Studio) Record Audio (default false). When enabled, the video capture will include sound capture.

⚠️ As the Intro screen provides valuable information on how to successfully get verified, it is recommended to display it unless the integrator decides to provide their own instruction screen.

For non-workflow-based flows, the FaceVideo step may optionally include the following options:

• showIntro: Boolean (default true)
• showConfirmation: Boolean (default true)
• recordAudio: Boolean (default: false)

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(ClassicParameters(
4      ...
5      steps = listOf<Step<*>>(
6        ...
7        FaceVideo(options = Options(
8          showIntro = true,
9          showConfirmation = true,
10          recordAudio = false
11          )),
12      )
13    )
14  )
15}

Face Motion

The Face Motion module enables the capture of the end user's face in the form of motion capture.

The execution of this module is controlled by the presence of a "Face Capture: Motion" task in your Studio workflow. The task has the following configuration options: - Show introduction screen (default true). When disabled, the end user would be taken directly to the capture screen. - Record Audio (default false). When enabled, the video capture will include sound capture.

⚠️ As the Intro screen provides valuable information on how to successfully get verified, it is recommended to display it unless the integrator decides to provide their own instruction screen.

For non-workflow-based flows, the FaceMotion step may optionally include the following options:

• showIntro: Boolean (default true)
• recordAudio: Boolean (default: false)

Android

iOS

Web

React Native

Flutter

1override fun onCreate(savedInstanceState: Bundle?) {
2  ...
3  entrustIdv.start(ClassicParameters(
4      ...
5      steps = listOf<Step<*>>(
6        ...
7        FaceMotion(options = Options(
8          showIntro = true,
9          recordAudio = false
10          )),
11      )
12    )
13  )
14}

One-time Password (OTP)

The One-time Password task allows the verification of a mobile phone number when used in conjuction with the Qualified Electronic Signature task.

This task has no SDK configuration options and is available only via Studio.

Qualified Electronic Signature (QES)

The Qualified Elentronic Signature task embeds the process provided by a Qualified Trust Service Provider to digitally sign a document.

This task has no SDK configuration options and is available only via Studio.

Retry task

The Studio Retry task allows orchestration between workflow tasks based on logical checks. When the task's condition fails, the SDK will diplay a dedicated screen to the user, prompting them to proceed to the next logical task (or repeat a previous one).

This task has no additional configuration option beyond selecting a "Retry Reason". It is only available via Studio. Please note: when a custom reason is provided in the task definition, it cannot be automatically translated by the SDK.

More Information

Accessibility

All SDKs have been optimised to provide the following accessibility support by default:

• Screen reader support: accessible labels for textual and non-textual elements available to aid TalkBack navigation, including dynamic alerts
• Dynamic font size support: all elements scale automatically according to the device's font size setting
• Sufficient color contrast: default colors have been tested to meet the recommended level of contrast
• Sufficient touch target size: all interactive elements have been designed to meet the recommended touch target size

Refer to our accessibility statement for more details.

Licensing

Due to API design constraints, and to avoid possible conflicts during the integration, we bundle some of our 3rd party dependencies as repackaged versions of the original libraries.

Please refer to the SDK license acknowledgements guide for more information.