Skip to main content

Overview

The OCR (Optical Character Recognition) module handles document capture and extraction of identity information from government-issued documents. It integrates with third-party OCR providers to capture document images and extract data such as name, date of birth, document number, and expiry date.

Accessing the Module

The OCR module is accessed through the SDK’s component factory:

Supported Providers

The OCR module supports multiple document capture providers:
Each provider has different capabilities, supported document types, and geographic coverage. Visit the provider’s website to understand their specific features and limitations.

Configuration Options

Basic Configuration

Common Options

Documents Array Structure:
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

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 Onfido Custom UI Properties: The customUI object allows extensive styling customization:

Incode Provider

Incode Options: Supported lang values: 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 renderCamera Options:

renderCameraProps vs renderCamera

renderCamera and renderCameraProps are separate, additive options:
  • renderCamera ({ showDocSelector, showTutorial }) is a OneSDK-defined object. OneSDK reads these two flags itself to decide whether to show the document selector/tutorial screens before capture.
  • renderCameraProps is an arbitrary Record<string, unknown> that OneSDK spreads directly into the underlying Incode SDK’s renderCamera(type, mountElement, options) call, ahead of OneSDK’s own onSuccess/onError/onLog/token/numberOfTries handlers. Use it to pass Incode SDK-native camera options that OneSDK doesn’t otherwise expose. It applies to the front/back document capture calls only, not the consent screen (renderCombinedConsent).
Both options can be set at the same time — they don’t conflict, since renderCamera only controls OneSDK’s own pre-capture screens.

Sumsub Provider

Sumsub Options:

IDVerse Provider

IDVerse Options:

Daon Provider

Daon Options: Process Instance Parameters:

Methods

mount()

Mounts the OCR component to a DOM element. Signature:
Parameters: Description: Mounts the OCR component to the specified DOM element. After mounting, call start() to begin the document capture process. Example:

start()

Legacy Method: This method is for headless OCR integration and is not recommended for standard use. Modern provider integrations handle the capture flow automatically after mounting. Avoid using this method unless you have a specific headless integration requirement.
Starts the document capture process in headless mode. Signature:
Description: Initiates the document capture flow for headless OCR implementations. For standard provider integrations, the capture flow begins automatically when mounting.

unmount()

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

isPreloaded()

Not typically used: isPreloaded() is not used in standard OCR integrations and can be safely ignored. Use events (detection_complete, results) to track document capture progress instead. This method was designed for legacy headless OCR flows.
Checks if OCR data has been previously captured for this entity. Signature:
Returns: boolean | null - true if OCR data exists for this entity, false if not, null if unable to determine Description: Returns true if the entity has existing OCR/document data in local state. This method was designed for headless integrations where you need to check local state before rendering capture UI. For standard provider integrations, document capture status should be determined by:
  • Using the results event to receive capture completion status
  • Querying your backend API for document verification results
  • Checking entity status through the FrankieOne API
Example:
This method only checks for the presence of document data in local state, not the actual verification result. Always verify document status through your backend API before proceeding with verification workflows.

access()

Legacy Method: This method is for headless OCR integration and is not recommended for standard use. For standard provider integrations, use events to track document capture progress instead of polling status. Avoid using this method unless you have a specific headless integration requirement.
Accesses reactive data accessors for the OCR component state. Signature:
Description: Provides access to internal OCR status for headless implementations. For standard provider integrations, listen to events (detection_complete, results, etc.) instead of polling status.

statuses

Object containing all possible OCR status constants. Type: Readonly<typeof OCRStatus> Description: Provides access to OCR 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 provider’s workflow and capabilities.
Example:

Events

The OCR module emits events throughout the document capture 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:

ready

Emitted when the OCR component is ready and mounted. Arguments:
Example:

detection_complete

Emitted when document capture is complete. Arguments:
Example:

detection_failed

Emitted when document capture fails. Arguments:
Example:

input_required

Emitted when a non-positive flow has occurred but is likely recoverable by retrying. Arguments:
Description: This event indicates that document capture cannot proceed in its current state, but the issue is typically recoverable. Common scenarios include:
  • Waiting for front or back side of document
  • User needs to retry capture
  • Document type mismatch
Legacy Parameter: The provideFile callback is for headless OCR integration and is not recommended for standard use. For standard provider integrations, the provider handles file capture automatically. Avoid using this parameter unless you have a specific headless integration requirement.
Example:

results

Emitted when OCR processing is complete and document data is available. Arguments:
Description: Contains the extracted document information including ID number, expiry date, date of birth, and other fields depending on document type. The document structure matches the Document Structure used in the Individual module. Example:

file_uploaded

Emitted when a file is successfully uploaded.
Legacy Headless OCR: This event is primarily used in legacy headless OCR implementations. For standard provider integrations, use the results event instead.
Arguments:
Example:

session_closed

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

session_interrupted

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

session_data_failed_loading

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

vendor_event

Emitted for provider-specific events. Arguments:
Example:

Common Events

The OCR 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 - Also listen to input_required (for recoverable states like WAITING_FRONT, WAITING_BACK, DOCUMENTS_INVALID), detection_failed (for capture failures), and error (for system failures).
  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.