Skip to main content

Overview

This page documents all non-positive scenarios across the OneSDK, including error events, failed verification states, timeouts, network issues, and recoverable conditions. Understanding these scenarios helps you build robust error handling and provide better user experiences.
For API error codes, see API Error Codes. This page focuses on SDK-level errors and verification outcomes.

Global SDK Errors

Network Events

network_offline

Module: SDK Context (Global) Description: Emitted when network connection is lost. Example:
Recovery Steps:
  • Display offline indicator to user
  • Queue pending operations
  • Listen for network_online event to resume

network_online

Module: SDK Context (Global) Description: Emitted when network connection is restored after being offline. Example:

Error Event

Event: error Available On: All modules (SDK context, Individual, IDV, OCR, Biometrics, Device, Form) Description: Emitted when an error occurs in the SDK or any module. Error Structure:
Example:

Known error.name Values

Some errors set a specific name value you can check programmatically. Many errors do not set name — for those, inspect error.message instead. Form Module: Individual Module: IDV / OCR / Biometrics — IDVerse provider: IDV — Truuth provider:

Errors Without a name

Most errors emit with an empty name. Use error.message to identify them: Recovery Steps:
  • Check error.name first if set; fall back to parsing error.message
  • Use error.payload for additional context (e.g. HTTP response body, issues array)
  • For session creation failures, session_data_failed_loading fires alongside error and includes the HTTP code and message
  • For vendor SDK load failures, handle vendor_sdk_failed_loading directly — it carries the same information in a structured format

Warning Event

Event: warning Module: All modules Description: Emitted for non-critical warnings that don’t prevent operation but should be noted. Structure:
Example:

Initialization Failures

Scenario: SDK initialization fails with Promise rejection Causes:
  • Invalid or expired session token
  • Configuration error
  • Network connectivity issues
  • CSP policy blocking SDK resources
Example:
Recovery Steps:
  1. Wrap initialization in try-catch
  2. Generate fresh token from backend
  3. Retry initialization with new token
  4. Check browser console for CSP errors

CSP (Content Security Policy) Errors

Scenario: Browser blocks OneSDK resources due to CSP policy Symptoms: Browser console shows CSP violations when loading or running the SDK. Blocked resources may originate from FrankieOne’s own domains or from third-party vendor SDKs (Onfido, Sumsub, Sardine, ThreatMetrix, etc.). Recovery Steps: Update your CSP headers based on what is being blocked: Check the browser console for the specific blocked URL, then add the relevant domain to the appropriate directive. Both FrankieOne’s domains and your chosen vendor’s domains may need to be allowlisted.
Replace [vendor-domains] with the actual domains used by your chosen provider. See Vendor CSP Settings for vendor-specific domain lists.

Session Management Errors

Session Expiration

Method: getExpirationEpoch() returns timestamp in past Description: User’s session token has expired before verification completion. Example:
Recovery Steps:
  1. Call getExpirationEpoch() to check expiration
  2. Warn users when less than 5 minutes remaining
  3. If the session expires mid-flow, the user must start over — there is no refresh token mechanism
  4. Reinitialize SDK with a fresh token obtained from your backend
There is no token refresh mechanism in OneSDK. If a session token expires while the user is mid-verification, you must generate a new token from your backend and reinitialize the SDK. Instruct users to start the verification flow again.

Missing Entity ID

Method: getEntityId() returns null Description: Session hasn’t been associated with an entity yet. Example:
Recovery Steps:
  • Always check for null before using entity ID
  • Entity will be created after first data submission

Individual Module (KYC) Errors

Verification Status Failures

failed

Property: CheckSummary.status.type Description: Verification failed automated checks. Example:
Recovery Steps:
  1. Examine checkResults array for specific failed checks
  2. Review issues object for detailed error information
  3. Check retryPages for screens that can be retried
  4. Allow user to correct data and resubmit

fail_manual

Property: CheckSummary.status.type Description: Manually rejected after review by compliance staff. Recovery Steps:
  • Contact support for rejection reason
  • May require completely new verification with different data
  • User should be informed this is a final decision

refer

Property: CheckSummary.status.type Description: Requires manual review; not automatically approved or denied. Example:
Recovery Steps:
  • Inform user that manual review is in progress
  • Provide expected timeline (if known)
  • Set up webhook to receive result notification
  • Don’t allow resubmission until review complete

wait

Property: CheckSummary.status.type Description: Waiting for additional information from user. Example:
Recovery Steps:
  1. Check alertList for specific actions required
  2. Implement handlers for common action types:
    • additional_document_required - Upload missing documents
    • upload_proof_of_address - Provide address verification
    • document_expired - Upload current document
  3. Allow user to provide missing information
  4. Resubmit verification after data provided

unchecked

Property: CheckSummary.status.type Description: No checks have been run yet. Recovery Steps:
  • Call submit({ verify: true }) or runChecks() to execute verification
  • This is the initial state before any verification

archived

Property: CheckSummary.status.type Description: Entity has been archived in the system. Recovery Steps:
  • Archiving is irreversible. You cannot unarchive an entity.
  • Create a new entity and session to onboard the customer again.

inactive

Property: CheckSummary.status.type Description: Entity has been deactivated. Recovery Steps:
  • Deactivation is irreversible. You cannot reactivate a deactivated entity.
  • Create a new entity and session to onboard the customer again.

Personal Information Validation Failures

Properties: CheckSummary.personalChecks.* Possible Values:
  • true - Field validated successfully
  • false - Field failed validation
  • null - Field was not checked
Example:
Recovery Steps:
  1. Identify which specific fields failed (=== false)
  2. Prompt user to correct the failed field
  3. Resubmit verification with corrected data

Risk Assessment Failures

Properties: CheckSummary.risk.class, CheckSummary.risk.level Risk Classes: low, medium, high, unacceptable, null Risk Level: Numeric value in the range 0–100. Lower numbers indicate lower risk.
The mapping between risk.level (numeric) and risk.class (categorical) depends on your risk configuration in FrankieOne and is not a fixed universal scale. When risk.class is null, risk.level is typically also absent. Contact your FrankieOne account team to understand your configured thresholds.
Example:
Recovery Steps:
  • high - May require manual review; check blocklistPotentialMatches and duplicatePotentialMatches
  • unacceptable - Likely verification failure; escalate to compliance team
  • Review alertList for specific risk factors

Check Result Issues

Property: CheckSummary.checkResults[].issues Each check result may include an issues array with { code, description } entries identifying what failed. See Individual Module — CheckSummary for full structure. Recovery Steps:
  • Parse issues array to identify specific failures
  • Display issue.description to user
  • Use issue.code for programmatic handling

Credit Header Issue

Property: CheckSummary.issues.creditHeader Accessor: individual.access('creditHeaderIssue') Description: A boolean flag set after submit({ verify: true }) indicating the credit header check encountered an issue (e.g. the backend reported hasCreditHeaderIssue or a creditHeaderIssueMessage). Available on both the v1 and F2 API paths.
This is not a hard failure — it does not affect CheckSummary.status.type. Treat it as a data-quality signal about the credit header check rather than a blocking error.
Example:
Recovery Steps:
  • No user-facing action is required by default — the verification can still proceed based on status.type
  • Optionally surface this to the user or your compliance team as an informational note
  • Do not treat this flag alone as grounds to fail or block the applicant

Alert List

Alert Types

All alerts in alertList have a type property that indicates severity: The term property describes the specific topic of the alert. Known term values include:
The term value depends on the checks configured for your account. Handle unknown term values gracefully.

Action Required

Type: action Property: CheckSummary.alertList Common Actions:
  • additional_document_required - Upload supporting document
  • upload_proof_of_address - Provide address verification document
  • document_expired - Upload current/unexpired document
Example:
Recovery Steps:
  1. Filter alertList for type === 'action'
  2. Implement handler for each action type
  3. Collect required information from user
  4. Resubmit verification

Warnings

Type: warning Example:
Recovery Steps:
  • Display warnings to user
  • Assess if warnings prevent verification completion
  • Some warnings may not block approval

Duplicate Detection

Duplicate Potential Matches

Property: CheckSummary.duplicatePotentialMatches Description: Entity may be a duplicate of an existing entity in the system. Each match includes entityId, matchStrength (0–1 confidence), and matched fields. See Individual Module — CheckSummary for full structure. Recovery Steps:
  1. Review duplicate matches manually
  2. Verify if user already has an existing account
  3. If legitimate duplicate, merge or link entities via backend API
  4. If false positive, proceed with verification

Duplicate Blocklist Matches

Property: CheckSummary.duplicateBlocklistMatches Description: Entity matches found across combined duplicate detection and blocklist/sanctions analysis. These represent entities flagged simultaneously in both checks and are high-priority alerts. Recovery Steps:
  • This is a critical alert
  • Immediate investigation required
  • Likely verification failure
  • Escalate to compliance team

Blocklist Matches

Property: CheckSummary.blocklistPotentialMatches Description: Entity matched against blocklist/sanctions/AML databases. Example:
Recovery Steps:
  • Stop verification process immediately
  • Escalate to compliance/risk team
  • Do NOT proceed with onboarding
  • Perform manual investigation

Retry Pages

Property: CheckSummary.retryPages Description: Recommended pages where the user can retry their submission, so they don’t need to go through the entire flow again. Can be empty if the backend cannot determine which pages should be retried. Example:
Recovery Steps:
  • Navigate user to the recommended retry pages if provided
  • User can correct specific data and resubmit
  • If retryPages is empty, the user should restart the full verification flow

checkResults, checkTypes, and checkCounts

For the relationship between checkTypes, checkResults, and checkCounts, see Individual Module — CheckSummary. Key points:
  • checkResults depends on which checks are configured. A missing entry for a checkType typically means that check hasn’t run yet.
  • checkCounts lists data source names that verified each personal info field — not the check results themselves (those are in personalChecks).

Submit Failures

Method: submit() or submit({ verify: true }) Description: Promise rejection on error. Causes:
  • Network error
  • Validation error
  • Server error
  • Timeout
Example:
Recovery Steps:
  1. Pass retryOptions explicitly to enable automatic retries (not on by default)
  2. Implement custom error handling in the catch block
  3. Show user-friendly error messages
  4. For persistent errors, contact support

Accessor Usage

Method: individual.access(fieldName) Description: Returns a reactive Accessor object for reading and writing individual entity fields. Use access() for reading or writing entity data within the module — you don’t have direct access to the full raw entity data object. Accessor Interface:
Use individual.search() to refresh entity data from FrankieOne (fetches latest from backend). Use individual.access() for reading/writing the local entity state. Example:
See Individual Module - access() for the full list of available fields.

Data Not Persisted

Method: isPersisted() returns false Description: Changes haven’t been submitted to the server yet. Example:
Recovery Steps:
  • Warn user before navigation
  • Implement unsaved changes detection
  • Prompt to save before leaving page

Common Events: Vendor Modules

The following events are emitted by all vendor-based modules — IDV, OCR, Biometrics, and Device. See the respective module docs for full parameter details.

vendor_sdk_loaded

Emitted when the third-party provider’s SDK has been successfully loaded and is ready.

vendor_sdk_failed_loading

Emitted when the provider’s SDK fails to load. This is the primary signal that the module cannot function.
Recovery Steps:
  • Check CSP headers allow the provider’s domains
  • Verify credentials (clientID, environment setting)
  • Ensure the provider is configured for your account in FrankieOne
  • Fall back to an alternative flow if possible

session_data_generated

Emitted when a provider session has been created. Useful for logging or debugging.

session_data_failed_loading

Emitted when session data fails to load from the provider. Usually indicates a backend configuration issue.

IDV Module Errors

For vendor_sdk_failed_loading, vendor_sdk_loaded, session_data_generated, and session_data_failed_loading, see Common Events: Vendor Modules.

Status-to-Event Mapping

IDV statuses are delivered through different events depending on their nature:
The results event is only emitted with COMPLETE or FAILED status. All other statuses appear via input_required, error, or processing events. The Biometrics module uses the same IDVStatus enum — all statuses above apply to both IDV and Biometrics.

IDV Status Failures

FAILED

Property: results.checkStatus Example:

INCOMPLETE

Description: Verification could not be completed because of missing user input. Example:

DOCUMENTS_INVALID

Description: Provided documents are invalid or of wrong type. Example:

PROVIDER_OFFLINE

Description: IDV provider is offline/unavailable. This status surfaces as an error event. Recovery Steps:
  • Show unavailable message to user
  • Retry after a delay
  • If persistent, contact support

Description: Waiting for user consent to proceed. Example:

WAITING_SELFIE_UPLOAD

Description: Waiting for selfie/biometric capture. Example:

WAITING_DOC_UPLOAD

Description: Waiting for document upload. Example:

INTERRUPTED

Description: Verification session was closed or interrupted by the user. Example:

input_required — Semantics

Event: input_required The input_required event is emitted when a check could not be completed due to user input — not because of a system failure. For example:
  • The user uploaded the wrong document type
  • The user closed the verification session before completing it
  • Required captures (selfie, document) have not been provided
Retrying the step will always help resolve input_required — if the user closed the session, remounting the module allows them to continue. Whether to limit the number of retry attempts depends on your business process.
There is no way to differentiate between user abandonment (user deliberately closed the session) and session timeout within the SDK. Both emit input_required with INTERRUPTED status.
Example:

Detection Failed

Event: detection_failed Example:
Recovery Steps:
  • Log error details from payload
  • Show user-friendly error message
  • Offer retry option

Session Interrupted

Event: session_interrupted Provider: Onfido-specific. Other providers do not emit this event — if you listen for it while using a non-Onfido provider, the handler will simply never fire. Example:

OCR Module Errors

For vendor_sdk_failed_loading, vendor_sdk_loaded, session_data_generated, and session_data_failed_loading, see Common Events: Vendor Modules.
isPreloaded() in OCR: The isPreloaded() method is not typically used in standard OCR integrations and can be safely ignored. Use events (detection_complete, results) to track document capture progress instead.

OCR Status Failures

DOCUMENTS_INVALID

Example:

DOCUMENTS_UPLOAD_FAILED

Description: Document upload failed during OCR processing. Recovery Steps:
  • Retry upload
  • Check file size and format
  • Verify network connection

PROVIDER_OFFLINE

Description: OCR provider is offline/unavailable. Recovery Steps:
  • Show provider unavailable message
  • Retry after delay
  • Fall back to manual data entry if available

FAILED_FILE_SIZE

Description: File size exceeds provider limit. Recovery Steps:
  • Show file size error
  • Indicate maximum allowed size
  • Ask user to provide smaller file or different format

FAILED_FILE_FORMAT

Description: Incorrect file format provided. Recovery Steps:
  • Show format error
  • List accepted formats (JPG, PNG, PDF, etc.)
  • Prompt user to select valid file

INTERRUPTED

Description: Capture flow was interrupted. Recovery Steps:
  • Allow user to restart capture\

Biometrics Module Errors

The Biometrics module uses the same IDVStatus enum as the IDV module. All statuses documented in the IDV section (COMPLETE, FAILED, INCOMPLETE, DOCUMENTS_INVALID, etc.) apply equally to Biometrics. There are no Biometrics-specific statuses.
For vendor_sdk_failed_loading, vendor_sdk_loaded, session_data_generated, and session_data_failed_loading, see Common Events: Vendor Modules.

Session Data Failed Loading

Event: session_data_failed_loading Example:

Input Required

Event: input_required Common Scenarios:
  • User closed verification session
  • Session timeout occurred
  • Waiting for selfie capture
  • Camera permission denied
Example:

Detection Failed

Event: detection_failed Example:

Device Module Errors

For vendor_sdk_failed_loading, vendor_sdk_loaded, and session_data_generated, see Common Events: Vendor Modules. For the Device module specifically, vendor_sdk_failed_loading means device fingerprinting is unavailable — you should fall back to proceeding without device data.

Configuration Validation Errors

Scenario: Missing provider configuration Error Message: “Your account is missing the environment configuration…” Recovery Steps:
  • Ensure recipe.deviceCharacteristics.provider is configured
  • Verify clientID and environment are set and correct
  • Contact FrankieOne support to verify the provider is enabled for your account

Invalid Activity Type

Scenario: Invalid activity type provided to start() Error Message: “Activity Type should be one of the following…” Valid Types: REGISTRATION, LOGIN, CRYPTO_DEPOSIT, CRYPTO_WITHDRAWAL, FIAT_DEPOSIT, FIAT_WITHDRAWAL Example:
Recovery Steps:
  • Use exact activity type string (case-sensitive)
  • Verify spelling matches valid types

Device Data Not Appearing in Dashboard

Troubleshooting checklist:
  1. Check environment — Verify you are checking the correct environment (sandbox vs production) in the dashboard. A mismatch here is the most common cause.
  2. Check clientID — Ensure the clientID matches what FrankieOne has configured for your account.
  3. Provider configured — Confirm with your FrankieOne account team that the device fingerprinting provider is enabled and configured for your account before integrating.
  4. CSP blockage — There is no direct client-side indicator that device data was blocked (other than the vendor_sdk_failed_loading event or CSP console errors). Check browser console for blocked requests.
  5. Success indicator — Listen for the device_characteristics_extracted event to confirm device data was collected client-side. If this event fires, the data was captured successfully.
  6. Timeline — How quickly device data appears in the dashboard depends on the vendor. Contact your FrankieOne account team for expected timing.

Form Module Errors

Screen Failed Events

Event Pattern: form:{screen}:failed Screens: welcome, start, consent, document, personal, review, loading, result, retry, doc_upload, required_document_upload, partial_document_upload, optional_document_upload Example:
Recovery Steps:
  • Log error for investigation
  • Show user-friendly error message
  • Offer page refresh or retry
  • Contact support if persists

Review Events (form:review:*)

form:review:failed, form:review:success, form:review:partial, and form:review:pending are only emitted when customResult: true is set in manual mode. When customResult is false (the default), the form automatically navigates to and displays the configured result screen — no review events are emitted for you to handle.In OCR mode, the only review event is form:review:ready.See verify and customResult in the configuration reference.
Use customResult: true when you want to intercept the review outcome and handle navigation yourself (e.g., display a custom message or CTA):

form:review:failed

Description: Verification did not pass at review stage. Only emitted with customResult: true. Example:

form:review:partial

Description: Partial verification result. Only emitted with customResult: true. Example:

form:review:pending

Description: Result pending manual review. Only emitted with customResult: true. Example:

Result Screen States

Result screen states are display configurations — not error events to handle. They control what message and CTA the built-in result screen shows. Set the state when initializing the RESULT screen to display the appropriate message to the user. Example — configure a failure result screen:
Example — configure a timeout result screen:
TIMEOUT uses its own icon and copy, distinct from FAIL. When the RESULT screen is configured with state: 'TIMEOUT', the module emits a form:result:timeout event (in addition to the generic form:result:loaded) — listen for it if you want to handle the timeout case specifically, for example to log it separately from a hard verification failure.

Review Screen — Retry Configuration

When a form submission fails on the Review screen, the SDK has built-in retry behavior controlled by the Review screen’s CTA (cta) configuration. This is not on the Retry screen. CTA Configuration (Review screen):
  • timeoutRetryMiliseconds — The form automatically retries submission after this delay. No user click needed.
  • retryAmount — Maximum retry attempts. After exhausting retries, the user sees maxRetryAttemptedString.
  • The retry counter is per submission, not persistent across sessions.
  • No event is emitted per retry attempt.

Retry Screen

Screen: RETRY The Retry screen is specific to the eKYC flow — it is shown when verification fails and the user needs to re-enter data. It is not the same as the Review screen’s submission retry. Example:

Best Practices

1. Always Handle Errors


2. Provide User-Friendly Messages


3. Check Status Before Acting


4. Log Errors for Investigation


5. Handle Network State


6. Validate Session Before Critical Operations


7. Ignore Telemetry Events in Production

Telemetry events (telemetry) are emitted internally by FrankieOne for diagnostic purposes. You do not need to listen to them in your application. Error handling should be done via the error event on each module, not via telemetry.
Before being included in COMPONENT:INIT / COMPONENT:INIT:ERROR (and other) telemetry events, sensitive values (tokens, API keys, secrets, clientID, etc.) are automatically redacted from the reported options and recipe data.

Provider Event Compatibility

Some events are provider-specific and will not fire when using a different provider. If your flow supports multiple providers, check the provider name before registering provider-specific event listeners.
If you register a listener for session_interrupted while using Sumsub (or any non-Onfido provider), the handler will simply never fire. This is safe — it won’t cause errors.

Document Selection

The Document Selection screen in the Form module is not deprecated and not tied to legacy flows. It is a standard part of the OCR and manual verification flows. Recommended patterns for document type selection:
  1. Use OCR mode — Specify document types in the documents array when creating the OCR component. The provider’s built-in selector will guide the user.
  2. Hard code the document type — If your flow requires a specific document type, specify it directly in configuration rather than letting the user choose.
  3. Use the provider’s built-in selector — Most IDV and OCR providers include their own document type selection UI.

Vendor-Specific Errors

Onfido

These errors are emitted via the error event when using Onfido as the IDV, OCR, or Biometrics provider. OneSDK surfaces these from Onfido’s onError callback.
For Onfido provider configuration and customization options, see Vendor Customizations.