Skip to main content

Overview

The Device module provides device fingerprinting capabilities through third-party fraud detection providers. It collects device characteristics and behavioral data to help identify and prevent fraudulent activities. Device fingerprinting works by analyzing hardware, software, and behavioral patterns to create a unique device identifier. This helps detect anomalies, prevent account takeover, and identify suspicious activity patterns.

Initializing the Module

The Device module is created using the component() factory method:

Module Options

All options are passed during module initialization:

Activity Types

The activity type helps the fraud detection provider apply appropriate risk assessment rules: Example with all options:

Recipe Configuration

The Device module requires provider configuration in your recipe:

Recipe Options

Supported Providers

Each provider has different capabilities, data collection methods, and geographic coverage. Visit the provider’s website to understand their specific features and limitations.

Methods

start()

Begins the device fingerprinting process.
This method:
  1. Loads the provider’s SDK asynchronously
  2. Initializes a fingerprinting session
  3. Begins collecting device characteristics
  4. Emits events as data is collected
Returns: void - The method does not return a value. Use events to track progress. Example:

on()

Registers an event listener.
See Events section for available events.

off()

Removes an event listener.

Events

The Device module emits events throughout the fingerprinting lifecycle:
Provider-Specific Behavior: Event emissions and data structures may vary by provider. Not all providers emit all events. Always test with your chosen provider to understand which events are emitted and when.

configuration_loaded

Emitted when the recipe configuration has been loaded and validated.
Parameters:

vendor_sdk_loaded

Common Event: This event is emitted by all vendor-based modules (IDV, OCR, Biometrics, Device).
Emitted when the provider’s SDK has been successfully loaded.
Parameters:

vendor_sdk_failed_loading

Common Event: This event is emitted by all vendor-based modules (IDV, OCR, Biometrics, Device).
Emitted when the provider’s SDK fails to load.
Parameters:

session_data_generated

Emitted when a fingerprinting session has been created with the provider.
Parameters:

activity_started

Emitted when an activity type has been set or updated.
Parameters:

device_characteristics_extracted

Emitted when device characteristics have been collected by the provider.
Parameters:

completed

Emitted when the fingerprinting process is complete.
Parameters:

Complete Example

Best Practices

  1. Initialize Early
    • Create the device component as early as possible in your user flow
    • Device data collection improves with more time to gather signals
  2. Handle SDK Loading Failures
    • Always listen for vendor_sdk_failed_loading events
    • Have a fallback flow if device fingerprinting fails
    • Don’t block user progress on fingerprinting completion
  3. Set Activity Type Appropriately
    • Use the most specific activity type for your use case
    • Update activity type when user action changes (registration → transaction)
    • Accurate activity types improve fraud detection accuracy

Common Issues

Provider SDK fails to load

Problem: vendor_sdk_failed_loading event is emitted. Possible causes:
  • Network connectivity issues
  • Content Security Policy (CSP) blocking the provider’s SDK
  • Invalid provider configuration (wrong clientID or environment)
Solution:
  • Check your CSP headers allow the provider’s domain
  • Verify your clientID and environment are correct
  • Check browser console for detailed error messages
  • Contact FrankieOne support to verify your account configuration

Configuration validation error

Problem: Module throws an error during initialization: “Your account is missing the environment configuration…” Cause: The recipe configuration is missing required provider details. Solution:
  • Ensure recipe.deviceCharacteristics.provider.name is set
  • Ensure recipe.deviceCharacteristics.provider.environment is set
  • Ensure recipe.deviceCharacteristics.provider.clientID is set
  • Contact FrankieOne support if you don’t have these values

Invalid activity type

Problem: Error thrown: “Activity Type should be one of the following…” Cause: An invalid activity type was provided. Solution:
  • Use only the supported activity types: ‘REGISTRATION’, ‘LOGIN’, ‘CRYPTO_DEPOSIT’, ‘CRYPTO_WITHDRAWAL’, ‘FIAT_DEPOSIT’, ‘FIAT_WITHDRAWAL’
  • Check for typos in activity type strings
  • Ensure you’re using the exact string values (case-sensitive)

Device data not appearing in dashboard

Problem: Fingerprinting completes but data doesn’t appear in FrankieOne 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 in your recipe matches what FrankieOne has configured for your account.
  3. Provider configured — Confirm with your FrankieOne account team that the device fingerprinting provider is enabled 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 device_characteristics_extracted to confirm device data was captured client-side. If this event fires, data collection succeeded.
  1. Timeline — How quickly device data appears in the dashboard depends on the vendor. Contact your FrankieOne account team for expected timing.