IDV Journey - frankieone

What it does

The IDV journey walks an applicant through camera-based document capture and a biometric selfie, extracts the document data, optionally lets the applicant review it, submits for verification, and settles with a single decision. FrankieOne assembles and maintains every screen and the transitions between them — you mount a container and read the result.

What your applicant sees

Start (off by default)

An introductory screen before the flow begins. Enable with withStart.

Welcome (off by default)

An orientation screen. Enable with withWelcome.

Consent (off by default)

Captures consent for data processing. Enable with withConsent.

Capture

Vendor-driven camera capture of the identity document and a biometric selfie.

Extraction

The captured document is processed and its data extracted. A loading screen covers this gap — see captureLoader below.

Review (off by default)

The applicant confirms or corrects the extracted data. Enable with withReview — see Review screen.

Verifying (skipped when triggerVerificationOnSubmit: false)

Verification runs against the submitted data. A loading screen covers this gap — see verifying below. With triggerVerificationOnSubmit: false, this step and its loading screen are skipped entirely — nothing is submitted for verification, and the journey settles success / captured instead.

Result

The journey settles with a JourneyResult. See Outcomes.

Example

import OneSdk, { JourneyName } from '@frankieone/one-sdk';

const oneSdk = await OneSdk({ session: { token } });

const result = await oneSdk
  .journey(JourneyName.IDV, {
    container: document.getElementById('verify'),
    withWelcome: true,
    withConsent: true,
    withReview: true,
    style: { primaryColor: '#1A6CFF' },
  })
  .start();

Options that apply

Option	Applies to idv
`container`, `withStart`, `withWelcome`, `withConsent`	yes
`withReview`	yes — toggles the review screen
`start`, `welcome`, `consent`, `review`	yes — each is the form module’s own configuration for that screen, forwarded verbatim; `review` keeps its per-country and per-state structure — see Form module: Configuration and Review screen
`result`	yes — RESULT config per screen state, see Result screens
`withResult`	yes — toggles the terminal result screen, on by default, see Screens
`captureLoader`	yes — configures the loading screen shown during capture and extraction
`verifying`	yes — configures the loading screen shown while verification runs; skipped entirely when `triggerVerificationOnSubmit: false`, since no verification runs to cover
`triggerVerificationOnSubmit`, `maxAttempts`, `logo`, `style`	yes
`simulate`, `startAt`	yes — development only; `startAt` accepts both `'CAPTURE'` and `'REVIEW'` on idv
`personal`, `document`, `retry`	no — eKYC only

See Configuration for what each option controls, and the Journey reference for the exhaustive type and default for every option.

Review screen

Setting withReview: true inserts a review screen between extraction and verification. The applicant sees the data the vendor extracted from their document and can correct it before submission proceeds — this is what catches an OCR misread before it reaches a verification check. The review option itself is not a journey concept — it’s the form module’s own configuration, forwarded verbatim. The journey does not read, validate, or reshape it, which means it keeps the form module’s per-country and per-state field structure exactly as documented there. For the actual field shapes, required properties, and how the per-country and per-state structure is built, see Form module: Configuration — this page does not repeat that structure.

oneSdk.journey(JourneyName.IDV, {
  container,
  withReview: true,
  review: {
    // form module configuration, forwarded verbatim
  },
});

On eKYC the review screen always mounts regardless of withReview; on idv and ocr it is off unless you turn it on. The review configuration applies whenever the screen mounts, whether or not withReview is set.

If the review screen’s address field uses autocomplete, that autocomplete is powered by the Google Places API and needs a googleApiKey set in the form module’s provider configuration to work — see Form module: Configuration for where it goes. Without it, address autocomplete will not work.

Requirements and caveats

The applicant needs a working camera to complete document and selfie capture.
Capture is vendor-driven. The journey abstracts over which vendor runs it, so nothing about a specific vendor’s SDK is documented here — see Outcomes for how a vendor-side failure surfaces.
Vendor selection happens outside journey() entirely, in the recipe passed to OneSdk({ recipe }) at initialization — JourneyOptions has no vendor key. journey('idv') needs recipe.idv.provider.name set, or the idv module throws No IDV provider specified in the recipe. Every journey, idv included, also needs recipe.form configured, or the form module throws Form recipe configuration is missing. See SDK Initialization for the recipe shape and Vendor Customizations for per-vendor settings.
If the review screen is enabled and its address field needs autocomplete, set googleApiKey on the form module’s provider configuration (see the note above) — this is a one-time SDK setup step, not a journey() option.

Outcomes

An idv journey settles with the same JourneyResult shape as every other flow — see Results for the full outcome and reason-code contract. One idv-specific note: because capture depends on a vendor SDK, a vendor-side failure settles the journey with outcome: 'error' and either reason: 'vendor_load_failed' (the vendor SDK failed to load) or reason: 'vendor_offline' (the vendor was unreachable once loaded). Check recoverable and error.code on both before deciding whether to offer a retry.

​What it does

​What your applicant sees

​Example

​Options that apply

​Review screen

​Requirements and caveats

​Outcomes

What it does

What your applicant sees

Example

Options that apply

Review screen

Requirements and caveats

Outcomes