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:
- Display offline indicator to user
- Queue pending operations
- Listen for
network_onlineevent 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:
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.namefirst if set; fall back to parsingerror.message - Use
error.payloadfor additional context (e.g. HTTP response body, issues array) - For session creation failures,
session_data_failed_loadingfires alongsideerrorand includes the HTTPcodeandmessage - For vendor SDK load failures, handle
vendor_sdk_failed_loadingdirectly — 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:
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
- Wrap initialization in try-catch
- Generate fresh token from backend
- Retry initialization with new token
- 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.
[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:
- Call
getExpirationEpoch()to check expiration - Warn users when less than 5 minutes remaining
- If the session expires mid-flow, the user must start over — there is no refresh token mechanism
- Reinitialize SDK with a fresh token obtained from your backend
Missing Entity ID
Method:getEntityId() returns null
Description: Session hasn’t been associated with an entity yet.
Example:
- Always check for
nullbefore 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:
- Examine
checkResultsarray for specific failed checks - Review
issuesobject for detailed error information - Check
retryPagesfor screens that can be retried - 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:
- 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:
- Check
alertListfor specific actions required - Implement handlers for common action types:
additional_document_required- Upload missing documentsupload_proof_of_address- Provide address verificationdocument_expired- Upload current document
- Allow user to provide missing information
- Resubmit verification after data provided
unchecked
Property: CheckSummary.status.type
Description: No checks have been run yet.
Recovery Steps:
- Call
submit({ verify: true })orrunChecks()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 successfullyfalse- Field failed validationnull- Field was not checked
- Identify which specific fields failed (
=== false) - Prompt user to correct the failed field
- 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.high- May require manual review; checkblocklistPotentialMatchesandduplicatePotentialMatchesunacceptable- Likely verification failure; escalate to compliance team- Review
alertListfor 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.descriptionto user - Use
issue.codefor 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.- 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 inalertList 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 documentupload_proof_of_address- Provide address verification documentdocument_expired- Upload current/unexpired document
- Filter
alertListfortype === 'action' - Implement handler for each action type
- Collect required information from user
- Resubmit verification
Warnings
Type:warning
Example:
- 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:
- Review duplicate matches manually
- Verify if user already has an existing account
- If legitimate duplicate, merge or link entities via backend API
- 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:
- 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:
- Navigate user to the recommended retry pages if provided
- User can correct specific data and resubmit
- If
retryPagesis 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:
checkResultsdepends on which checks are configured. A missing entry for acheckTypetypically means that check hasn’t run yet.checkCountslists data source names that verified each personal info field — not the check results themselves (those are inpersonalChecks).
Submit Failures
Method:submit() or submit({ verify: true })
Description: Promise rejection on error.
Causes:
- Network error
- Validation error
- Server error
- Timeout
- Pass
retryOptionsexplicitly to enable automatic retries (not on by default) - Implement custom error handling in the
catchblock - Show user-friendly error messages
- 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:
individual.search() to refresh entity data from FrankieOne (fetches latest from backend). Use individual.access() for reading/writing the local entity state.
Example:
Data Not Persisted
Method:isPersisted() returns false
Description: Changes haven’t been submitted to the server yet.
Example:
- 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.
- 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
Forvendor_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
AWAITING_CONSENT
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
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.Detection Failed
Event:detection_failed
Example:
- 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
Forvendor_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.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
Detection Failed
Event:detection_failed
Example:
Device Module Errors
Forvendor_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.provideris configured - Verify
clientIDandenvironmentare set and correct - Contact FrankieOne support to verify the provider is enabled for your account
Invalid Activity Type
Scenario: Invalid activity type provided tostart()
Error Message: “Activity Type should be one of the following…”
Valid Types: REGISTRATION, LOGIN, CRYPTO_DEPOSIT, CRYPTO_WITHDRAWAL, FIAT_DEPOSIT, FIAT_WITHDRAWAL
Example:
- Use exact activity type string (case-sensitive)
- Verify spelling matches valid types
Device Data Not Appearing in Dashboard
Troubleshooting checklist:- Check environment — Verify you are checking the correct environment (sandbox vs production) in the dashboard. A mismatch here is the most common cause.
- Check clientID — Ensure the
clientIDmatches what FrankieOne has configured for your account. - Provider configured — Confirm with your FrankieOne account team that the device fingerprinting provider is enabled and configured for your account before integrating.
- CSP blockage — There is no direct client-side indicator that device data was blocked (other than the
vendor_sdk_failed_loadingevent or CSP console errors). Check browser console for blocked requests. - Success indicator — Listen for the
device_characteristics_extractedevent to confirm device data was collected client-side. If this event fires, the data was captured successfully. - 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:
- Log error for investigation
- Show user-friendly error message
- Offer page refresh or retry
- Contact support if persists
Review Events (form:review:*)
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:
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 seesmaxRetryAttemptedString.- 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:- Use OCR mode — Specify document types in the
documentsarray when creating the OCR component. The provider’s built-in selector will guide the user. - Hard code the document type — If your flow requires a specific document type, specify it directly in configuration rather than letting the user choose.
- 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 theerror 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.
Related
- API Error Codes - Backend API error codes
- Event System - Complete event reference
- Individual Module - KYC module documentation
- IDV Module - IDV module documentation
- Form Module - Form module documentation