Quickstart

IDKit steps will trigger when IDV module’s mount method is called. For that reason it is expected that mount is called immediately by the host application.

A typical sequence to use IDVerse IDKit with OneSDK is as follows:

// 1. Generate authentication token
const token = await generateTokenUsingMachineToken();

// 2. Configure session
const sessionConfig = { 
  session: { 
    token, 
    appReference: "your-app-name",  // Required for UI styling
    persist: true                   // Enable session persistence
  }
};

// 3. Initialize and mount
const oneSdk = await OneSdk(sessionConfig);
const idvFlow = oneSdk.flow("idv");
idvFlow.mount("container-id");

How It Works

1. Initialization

1. Your application generates a unique customer reference URL (e.g., /onboarding/[customer_reference])
2. Your backend creates a machine session with this reference
3. OneSDK initializes using the session data session.persist (storing the session details in browser cache for 1 hour) and session.appReference
4. The IDV module mounts and redirects to IDKit's verification interface

2. Verification Flow

1. User completes identity verification on IDKit's interface
2. FrankieOne then records the verification status
3. User returns to your application
4. The IDV module processes results and emits appropriate events
   1. idv.mount will request the FrankieOne backend to check if a prior success flag has been stored. If it has, it will skip initalisation.
   2. idv.mount will then request FrankieOne backend service to proceed with the IDV Processing.
   3. idv.mount will then emit “results”, or another of the events described in Events/Outcomes.

Important Implementation Notes

Session Persistence

As IDKit requires browser redirects, OneSDK implements session persistence to maintain state:

• Sessions are stored in local storage for 1 hour
• Persisted data includes:
  • Session ID
  • Entity identification
  • Flow state
  • Unprocessed data

Mounting Considerations

• The mount point parameter is required for API consistency but isn't used for rendering
• You can use an orphaned element if needed:

const container = document.createElement("div");
idvFlow.mount(container);

UI/UX Implications

1. Browser Navigation
   1. URL changes during verification process
   2. Users will see IDKit's domain during verification
2. UI Customization: the host application has no control over the theme of the vendor UI, and any customisations need to be done directly with IDKit:
   1. Styling is controlled via appReference in session config
   2. Direct UI modifications should be coordinated with IDKit

Event Handling

The IDV module emits various events during the verification process. Implement handlers for:

• Verification completion
• Error scenarios
• User cancellation
• Progress updates

idvFlow.on("results", (results) => {
  // Handle verification results
});

Best Practices

1. Call mount() immediately after initialization
2. Always enable session persistence (session.persist: true)
3. Implement proper error handling for network issues and timeouts
4. Store customer reference for session recovery
5. Test the complete flow, including redirects and session restoration

Troubleshooting

Common issues and solutions:

• Session expiration (1-hour limit)
• Missing appReference
• Incorrect mount implementation
• Redirect handling errors