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 Requirement
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.Provider-Specific Options
Onfido Provider
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
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 Config Object:
Sumsub Options Object:
Truuth Provider
Daon Provider
Methods
mount()
Mounts the IDV component to a DOM element and starts the verification flow.
Signature:
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:
isPreloaded()
Checks if IDV data has been previously captured for this entity.
Signature:
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:
- Whether the individual module has preloaded data
- Whether the entity has an attestation document (indicating completed IDV verification)
- 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
access()
Accesses reactive data accessors for the IDV component state.
Signature:
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.
- Default
- Onfido
- Truuth
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.Events
The IDV module emits events throughout the verification lifecycle.session_data_generated
Emitted when session data for the vendor is generated.
Arguments:
detection_complete
Emitted when initial detection/capture is complete.
Arguments: None
Example:
detection_failed
Emitted when detection/capture fails.
Arguments:
input_required
Emitted when a non-positive flow has occurred but is likely recoverable by retrying.
Arguments:
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.processing
Emitted when verification checks are processing.
Arguments:
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:
session_interrupted
Emitted when the user interrupts the verification session.
Arguments: None
Provider-Specific:
- Onfido: Emits this when the verification modal is closed.
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:
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 occurswarning- For non-critical warningsinfo- Informational messagesloading- Loading state changes
Complete Example
Best Practices
-
Handle all events, not just
results- Theresultsevent only fires withCOMPLETEorFAILED. Also listen toinput_required(for recoverable states like INCOMPLETE or INTERRUPTED),error(for system failures such as PROVIDER_OFFLINE), andprocessing(for intermediate states). -
Set up event listeners before mounting - Register all event handlers before calling
mount()to avoid missing events. -
Unmount on navigation - Always call
unmount()when the user leaves the page to clean up resources. - Provider-specific configuration - Review each provider’s documentation for optimal configuration.
-
Error handling - Always listen to the
errorevent 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 thevendor_event emissions for provider-specific error details and consult the provider’s documentation.