eKYC Journey - frankieone

What it does

The eKYC journey walks an applicant through manual data entry — personal details and document details typed into form fields — reviews what was entered, submits for verification, and settles with a single decision. There is no camera capture and no vendor SDK anywhere in this flow. FrankieOne assembles and maintains every screen and the transitions between them — you mount a container and read the result. That’s the entire distinction from IDV and OCR: those flows capture a document (and, for IDV, a selfie) through a vendor SDK. eKYC collects the same categories of information — personal details and document details — through form fields instead, with no vendor involved.

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.

Personal

The applicant enters personal details — name, date of birth, address, and similar fields.

Document

The applicant enters one or more identity document’s details manually — no capture.

Review (always on)

The applicant confirms or corrects everything entered so far, before submission. Unlike idv and ocr, this screen always mounts — see Review screen below.

Result

The journey settles with a JourneyResult. See Outcomes.

There is no capture step and no vendor anywhere in this order.

Example

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

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

const result = await oneSdk
  .journey(JourneyName.EKYC, {
    container: document.getElementById('verify'),
    withWelcome: true,
    withConsent: true,
  })
  .start();

Options that apply

Option	Applies to ekyc
`container`, `withStart`, `withWelcome`, `withConsent`	yes
`withReview`	no — review always mounts, see Review screen
`start`, `welcome`, `consent`, `review`	yes — each is the form module’s own configuration for that screen, forwarded verbatim; `review` still applies even though `withReview` has no effect here, keeping 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
`personal`, `document`, `retry`	yes — ekyc only, see Personal, document, and retry
`captureLoader`, `verifying`	no — there is no vendor capture to cover with a loading screen
`triggerVerificationOnSubmit`	no — TypeScript rejects it here. The review screen does its own submit-and-verify, so there is no separate submit for the flag to switch off
`maxAttempts`, `logo`, `style`	yes
`simulate`, `startAt`	yes — development only; `startAt: 'CAPTURE'` is a no-op on ekyc (no capture step), `'REVIEW'` mounts the review form immediately

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

Review screen

The eKYC journey always mounts the review screen — withReview has no effect here. review configuration still applies, and is forwarded to the form module verbatim.

On idv and ocr, withReview switches the review screen on or off. On eKYC there is nothing to switch — the applicant always reviews their personal and document details before submission, and setting withReview: true or false makes no difference. The review option itself is unaffected by this: it’s the form module’s own configuration, forwarded verbatim whenever the screen mounts, which on eKYC is every run.

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

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.

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. The same applies to the personal screen’s address field.

Personal, document, and retry

Three additional pass-through keys apply to eKYC only:

Key	Controls
`personal`	The personal-details screen — which fields are collected and how they’re laid out.
`document`	The document-details screen — which document types are accepted, how many, and their per-country field structure.
`retry`	The screen shown when the applicant needs another attempt at data correction.

All three are form module configuration, forwarded verbatim — the journey does not read, validate, or reshape them. See Form module: Configuration for the full field shapes, including how document accepts a per-document, per-country field structure. How many attempts an applicant gets before the journey settles as declined is controlled by maxAttempts, not by retry itself — see Configuration: Attempts.

Requirements and caveats

No camera is required — every field is typed, not captured, so there is no vendor SDK to load and nothing camera-related to provision for.
eKYC needs only recipe.form configured at OneSdk({ recipe }) — the form module throws Form recipe configuration is missing without it. Unlike idv and ocr, eKYC needs no vendor provider in the recipe, because it runs no vendor capture. See SDK Initialization for the recipe shape.
If the personal or review screen’s 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 ekyc journey settles with the same JourneyResult shape as every other flow — see Results for the full outcome and reason-code contract. The result itself carries the decision, not the entered data — see Reading extracted data for where that data actually is once the journey settles. One ekyc-specific note: because there is no vendor capture, a settled error result won’t carry vendor_load_failed or vendor_offline in practice — those reasons describe a vendor SDK failing to load or respond, and eKYC never loads one. Failures here surface through the other error reasons instead.

​What it does

​What your applicant sees

​Example

​Options that apply

​Review screen

​Personal, document, and retry

​Requirements and caveats

​Outcomes

What it does

What your applicant sees

Example

Options that apply

Review screen

Personal, document, and retry

Requirements and caveats

Outcomes