> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frankieone.com/llms.txt
> Use this file to discover all available pages before exploring further.

# eKYC Journey

> Manual data entry and document details, reviewed and submitted in one pre-assembled flow.

## 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](/docs/embedded-flows/journey/idv) and
[OCR](/docs/embedded-flows/journey/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

<Steps>
  <Step title="Start (off by default)">
    An introductory screen before the flow begins. Enable with `withStart`.
  </Step>

  <Step title="Welcome (off by default)">
    An orientation screen. Enable with `withWelcome`.
  </Step>

  <Step title="Consent (off by default)">
    Captures consent for data processing. Enable with `withConsent`.
  </Step>

  <Step title="Personal">
    The applicant enters personal details — name, date of birth, address, and similar fields.
  </Step>

  <Step title="Document">
    The applicant enters one or more identity document's details manually — no capture.
  </Step>

  <Step title="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](#review-screen) below.
  </Step>

  <Step title="Result">
    The journey settles with a `JourneyResult`. See [Outcomes](#outcomes).
  </Step>
</Steps>

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

## Example

```javascript theme={null}
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](#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](/docs/sdk-reference/form-module/configuration) and [Review screen](#review-screen) |
| `result` | yes — RESULT config per screen state, see [Result screens](/docs/embedded-flows/journey/configuration#result-screens) |
| `withResult` | yes — toggles the terminal result screen, on by default, see [Screens](/docs/embedded-flows/journey/configuration#screens) |
| `personal`, `document`, `retry` | yes — **ekyc only**, see [Personal, document, and retry](#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](/docs/embedded-flows/journey/configuration) for what each option controls, and the
[Journey reference](/docs/sdk-reference/journey#options) for the exhaustive type and default for every
option.

## Review screen

<Callout icon="circle-info" color="#1A6CFF" iconType="regular">
  The eKYC journey always mounts the review screen — `withReview` has no effect here. `review`
  configuration still applies, and is forwarded to the
  [form module](/docs/sdk-reference/form-module/configuration) verbatim.
</Callout>

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.

```javascript theme={null}
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](/docs/sdk-reference/form-module/configuration) — this
page does not repeat that structure.

<Note>
  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](/docs/sdk-reference/form-module/configuration) for where
  it goes. Without it, address autocomplete will not work. The same applies to the personal screen's
  address field.
</Note>

## 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](/docs/sdk-reference/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](/docs/embedded-flows/journey/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](/docs/sdk-reference/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](/docs/embedded-flows/journey/results) for the full outcome and reason-code contract. The
result itself carries the decision, not the entered data — see
[Reading extracted data](/docs/embedded-flows/journey/results#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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.