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.
Each provider has different capabilities, UI/UX, supported documents, and geographic coverage. Visit the provider’s website to understand their specific features and limitations.
documents: [ { type: 'DRIVERS_LICENCE', // Document type countries: ['AUS', 'NZL'] // ISO country codes (optional) }]
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:
checkProcessingPool: { enabled: true, // Enable polling for check results wait_time: 5, // Wait time between polls (seconds) max_attempts: 1 // Maximum polling attempts}
CSS selector string (e.g., '#idv-container') or HTMLElement object where the component will be mounted
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:
// Mount to element by IDidvFlow.mount('#idv-container');// Mount to element referenceconst container = document.getElementById('idv-container');idvFlow.mount(container);
Unmounts the IDV component from the DOM.Signature:
unmount(): void
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:
Checks if IDV data has been previously captured for this entity.Signature:
isPreloaded(): boolean
Returns:boolean - true if IDV verification data exists for this entity, false otherwiseDescription:
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)
Example:
const idvFlow = sdk.flow('idv', { provider: { name: 'onfido' }});if (idvFlow.isPreloaded()) { console.log('User has completed IDV verification'); // Skip verification, proceed to next step proceedToNextStep();} else { console.log('User needs to complete IDV verification'); // Mount and start verification idvFlow.mount('#idv-container');}
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.
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
Value
Description
CHECK_NOT_STARTED
'CHECK_NOT_STARTED'
Verification check has not been initiated
CHECK_PROCESSING
'CHECK_PROCESSING'
Verification check is currently processing
COMPLETE
'COMPLETE'
Verification completed successfully
FAILED
'FAILED'
Verification failed
INCOMPLETE
'INCOMPLETE'
Verification incomplete (missing data or steps)
DOCUMENTS_INVALID
'AWAITING_DOCUMENT_UPLOAD_INVALID_TYPE'
Provided documents are invalid
PROVIDER_OFFLINE
'PROVIDER_OFFLINE'
Verification provider is offline/unavailable
AWAITING_CONSENT
'AWAITING_CONSENT'
Waiting for user consent
WAITING_SELFIE_UPLOAD
'WAITING_SELFIE_UPLOAD'
Waiting for selfie/biometric upload
WAITING_DOC_UPLOAD
'WAITING_DOC_UPLOAD'
Waiting for document upload
INTERRUPTED
'INTERRUPTED'
Verification flow was interrupted (provider-specific)
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.
Status
Event
COMPLETE
results
FAILED
results
INCOMPLETE
input_required
DOCUMENTS_INVALID
input_required
WAITING_SELFIE_UPLOAD
input_required
WAITING_DOC_UPLOAD
input_required
INTERRUPTED
input_required
PROVIDER_OFFLINE
error
AWAITING_CONSENT
error
CHECK_PROCESSING
processing
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.
Onfido does not use the common status mapping. Instead, it delegates to internal OCR and Biometrics sub-modules, which emit events directly.Two-step mode (default): The IDV module creates separate OCR and Biometrics components. Events from each sub-component (results, input_required, error, detection_complete, detection_failed) are forwarded to the IDV event hub. The status values in these events come from the sub-modules’ own processing.One-step mode (useOneStep: true): The Onfido SDK handles both document and face capture in a single flow. On completion, the biometrics initProcess is called. Its mapping differs from the default:
Status
Event
COMPLETE
results
FAILED
results
DOCUMENTS_INVALID
error
WAITING_DOC_UPLOAD
error
WAITING_SELFIE_UPLOAD
error
PROVIDER_OFFLINE
error
AWAITING_CONSENT
error
CHECK_PROCESSING
processing
In one-step mode, if the user exits, input_required is emitted with INTERRUPTED status, along with detection_failed and session_interrupted.
Truuth has its own status interpretation based on the provider’s userBehaviourChecks response. It emits input_required directly for non-complete statuses before calling the backend, treating them as recoverable conditions.
Status
Event
COMPLETE
results (via common mapping after initProcess)
FAILED
results (via common mapping after initProcess)
INCOMPLETE
input_required
AWAITING_CONSENT
input_required
WAITING_DOC_UPLOAD
input_required
WAITING_SELFIE_UPLOAD
input_required
INTERRUPTED
input_required
CHECK_PROCESSING
processing (via polling)
Unlike other providers, Truuth maps AWAITING_CONSENT to input_required rather than error, treating consent rejection as a recoverable user action. Truuth also enables check processing polling when the vendor reports processing has started.
Example:
const idvFlow = sdk.flow('idv', { provider: { name: 'onfido' } });idvFlow.on('input_required', (info, status) => { if (status === idvFlow.statuses.WAITING_DOC_UPLOAD) { console.log('Waiting for document upload'); } else if (status === idvFlow.statuses.WAITING_SELFIE_UPLOAD) { console.log('Waiting for selfie upload'); }});idvFlow.on('results', (results) => { if (results.checkStatus === idvFlow.statuses.COMPLETE) { console.log('Verification completed successfully'); } else if (results.checkStatus === idvFlow.statuses.FAILED) { console.log('Verification failed'); }});
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.
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:
idvFlow.on('input_required', ({ entityId }, status) => { console.log('Input required. Status:', status); console.log('User can retry to continue verification'); if (status === idvFlow.statuses.WAITING_DOC_UPLOAD) { showMessage('Please upload your document to continue'); enableRetry(); } else if (status === idvFlow.statuses.WAITING_SELFIE_UPLOAD) { showMessage('Please capture your selfie to continue'); enableRetry(); } else if (status === idvFlow.statuses.AWAITING_CONSENT) { showMessage('Please provide consent to continue'); enableRetry(); }});
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:
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).
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 error event and provide user-friendly error messages.