Skip to main content

Overview

The IDV (Identity Verification) module provides an integrated document capture and biometric verification flow through third-party provider integrations. It manages the complete identity verification process with minimal configuration required.
Consent must be collected before mounting the IDV flow. Without consent, verification submission will fail. Use the Form Module CONSENT screen to collect consent from the user before calling idv.mount(). See the IDV Flow guide for a complete example.

Accessing the Module

The IDV module is accessed through the SDK’s flow factory:

Supported Providers

The IDV module supports multiple identity verification providers:
Each provider has different capabilities, UI/UX, supported documents, and geographic coverage. Visit the provider’s website to understand their specific features and limitations.

Configuration Options

Basic Configuration

Common Options

In addition to provider-specific settings, you can configure: Documents Array:
Daon provider: The documents parameter and document selection are not required when using the Daon provider — Daon provides its own document type selection screen. To use custom document selection instead of Daon’s built-in screen, contact your FrankieOne account team.
Check Processing Pool:

Provider-Specific Options

Onfido Provider

Onfido Options: Supported language values: ar, bg, cs, da, de, el, en_GB, en_US, es, es_419, es_DO, et, fa, fi, fr, fr_CA, he, hi, hr, hu, hy, id, it, ja, ko, lt, lv, ms, nl, no, pl, pt, pt_BR, ro, ru, sk, sl, sr, sv, th, tr, uk, vi, zh_CN, zh_TW

Incode Provider

Incode Options: Supported Languages: 'bn', 'ca', 'zh', 'hr', 'nl', 'en', 'en-BZ', 'en-DG', 'fr', 'de', 'ht', 'hi', 'hmn', 'hu', 'id', 'it', 'ms', 'pl', 'pt', 'pt-BR', 'pt-PT', 'ro', 'sr', 'sr-LATN', 'so', 'es', 'es-ES', 'tl-PH', 'tr', 'vi'

Sumsub Provider

Sumsub Options: Sumsub Config Object: Sumsub Options Object:

Truuth Provider

Truuth Options:

Daon Provider


Methods

mount()

Mounts the IDV component to a DOM element and starts the verification flow. Signature:
Parameters: Description: Mounts the IDV Smart UI to the specified DOM element and initiates the identity verification flow. The provider’s interface will be displayed within this element. Example:

unmount()

Unmounts the IDV component from the DOM. Signature:
Description: Removes the IDV component from the DOM and cleans up resources. Call this when the user navigates away or the verification flow is complete. Example:

isPreloaded()

Checks if IDV data has been previously captured for this entity. Signature:
Returns: boolean - true if IDV verification data exists for this entity, false otherwise Description: Returns true if the entity has existing IDV verification data (indicated by an attestation document). This allows you to skip the verification flow for returning users who have already completed identity verification. The method checks:
  1. Whether the individual module has preloaded data
  2. Whether the entity has an attestation document (indicating completed IDV verification)
Example:
Use Cases:
  • Skip verification UI for returning users with completed IDV
  • Show different messaging for users with existing verification
  • Conditionally render verification components based on verification status
This method checks for the presence of verification data, not the verification result. A user may have completed verification but failed checks. Always verify the actual verification status through your backend before granting access.

access()

Accesses reactive data accessors for the IDV component state. Signature:
Returns: Currently returns void (not implemented) Note: This method is present for API consistency but is not yet implemented for the IDV module.

statuses

Object containing all possible IDV status constants. Type: Readonly<typeof IDVStatus> Description: Provides access to IDV status enum values for comparison in event handlers and status checks. Available Statuses:
Provider-Specific: Not all statuses are used by all providers. The specific statuses emitted depend on your chosen verification provider’s workflow and capabilities.
Status-to-Event Mapping: The results event only fires for terminal statuses. Non-terminal statuses surface through other events. The exact mapping varies by provider.
Used by Sumsub, Incode, Daon, Mastercard, and OcrLabs. These providers call the backend initProcess endpoint after the vendor flow completes and map the returned status to events using the common mapping.
Daon enables check processing polling by default. If the initial status is not COMPLETE or FAILED, the SDK polls the backend until a terminal status is reached, then emits results.
Example:

Events

The IDV module emits events throughout the verification lifecycle.
Provider-Specific Behavior: Events and statuses vary by provider. Not all providers emit all events, and some events are provider-specific. Always test with your chosen provider to understand which events are emitted and when.

session_data_generated

Emitted when session data for the vendor is generated. Arguments:
Example:

detection_complete

Emitted when initial detection/capture is complete. Arguments: None Example:

detection_failed

Emitted when detection/capture fails. Arguments:
Example:

input_required

Emitted when a non-positive flow has occurred but is likely recoverable by retrying. Arguments:
Description: Emitted when the check could not be completed due to user input — not because of a system failure. For example, the user uploaded the wrong document type, or the user closed the session before completing it. Retrying the step will always help resolve input_required. Common scenarios:
  • Waiting for document or selfie upload
  • Awaiting user consent
  • User closed or interrupted the verification session (remounting the module allows them to resume)
There is no way to differentiate between user abandonment and session timeout within the SDK. Both surface as input_required with INTERRUPTED status. Whether to limit retry attempts depends on your business process.
Example:

processing

Emitted when verification checks are processing. Arguments:
Example:

results

Emitted when verification reaches a terminal state. Only fires with COMPLETE or FAILED status. Other statuses surface through input_required, error, or processing events. Arguments:
Example:

session_interrupted

Emitted when the user interrupts the verification session. Arguments: None
Provider-Specific:
  • Onfido: Emits this when the verification modal is closed.
Example:

session_closed

Emitted when the verification session is closed. Arguments: None Example:

session_data_failed_loading

Emitted when session data fails to load. Arguments: None Example:

vendor_event

Emitted for provider-specific events. Arguments:
Example:
Truuth: vendor_event payloads are { provider: 'truuth', vendorEventType } — the raw event payload (which could contain PII from the vendor SDK) is intentionally not included. If your integration previously relied on fields from the Truuth event payload, read them from the results event or your backend API instead.

Common Events

The IDV module also emits common events inherited from the event system:
  • error - When an error occurs
  • warning - For non-critical warnings
  • info - Informational messages
  • loading - Loading state changes
See Event System Reference for details.

Complete Example


Best Practices

  1. Handle all events, not just results - The results event only fires with COMPLETE or FAILED. Also listen to input_required (for recoverable states like INCOMPLETE or INTERRUPTED), error (for system failures such as PROVIDER_OFFLINE), and processing (for intermediate states).
  2. Set up event listeners before mounting - Register all event handlers before calling mount() to avoid missing events.
  3. Unmount on navigation - Always call unmount() when the user leaves the page to clean up resources.
  4. Provider-specific configuration - Review each provider’s documentation for optimal configuration.
  5. Error handling - Always listen to the error event and provide user-friendly error messages.

Common Issues

Component not displaying

Ensure the mount element exists in the DOM and has sufficient size:

Session data failed to load

This usually means the backend session setup failed. Ensure your backend is correctly generating IDV tokens.

Provider-specific errors

Check the vendor_event emissions for provider-specific error details and consult the provider’s documentation.