Skip to main content

What it does

The OCR journey walks an applicant through camera-based document capture, extracts the document data, optionally lets the applicant review it, and settles with a single decision — with no biometric selfie anywhere in the 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 the IDV journey: choosing between the two is a question of whether you need a selfie. If you do, use IDV; if you only need document data, use OCR.

What your applicant sees

1

Start (off by default)

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

Welcome (off by default)

An orientation screen. Enable with withWelcome.
3

Consent (off by default)

Captures consent for data processing. Enable with withConsent.
4

Capture

Vendor-driven camera capture of the identity document. No selfie step.
5

Extraction

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

Review (off by default)

The applicant confirms or corrects the extracted data. Enable with withReview.
7

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.
8

Result

The journey settles with a JourneyResult. See Outcomes.

Example

Options that apply

See Configuration for what each option controls, and the Journey reference for the exhaustive type and default for every option. The review option itself is not a journey concept — it’s the form module’s own configuration, forwarded verbatim, keeping the form module’s per-country and per-state field structure exactly as documented there. For the field shapes and how that structure is built, see Form module: Configuration.

Requirements and caveats

  • The applicant needs a working camera to complete document capture — there is no selfie step to additionally provision for.
  • Capture is vendor-driven. The journey abstracts over which vendor runs it, so nothing about a specific vendor’s SDK is documented here. Which document types an applicant can capture depends on the configured vendor’s capabilities — see OCR module and Vendor Customizations.
  • Vendor selection happens outside journey() entirely, in the recipe passed to OneSdk({ recipe }) at initialization — JourneyOptions has no vendor key. journey('ocr') needs recipe.ocr.provider.name set in the recipe. Every journey, ocr 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 withReview is enabled and its address field needs autocomplete, set googleApiKey on the form module’s provider configuration — see Form module: Configuration. Without it, address autocomplete will not work.

Outcomes

An ocr 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 extracted document data — see Reading extracted data for where that data actually is once the journey settles. One ocr-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.