journey() options by what they control — screens, branding, attempts, and verification
timing — rather than listing them flow by flow. For the exhaustive option table, including types and
defaults, see the Journey reference.
Everything on this page is set in your own code and ships with your app — there’s no request to
FrankieOne to change it. The journey still owns the verification flow itself, so this configuration can
reshape how it looks and reads, but it cannot break the underlying verification behaviour.
Screens
withStart, withWelcome, withConsent, and withReview toggle optional screens on. All four are off
by default. withResult is the exception — it toggles the terminal result screen, and is on by
default.
eKYC always mounts the review screen, so
withReview has no effect there. The review configuration
(see pass-through configuration below) still applies on eKYC — the screen
just can’t be switched off.
withResult is opt-out, unlike the other three toggles above: the terminal result screen already
renders today, so defaulting it off would be a silent breaking change for every existing integration.
Set it to false and the host owns the ending instead — start() resolves as soon as the outcome is
known, nothing is mounted, and the container is emptied on settlement, so you can reuse the element
immediately without calling destroy() yourself. It governs the terminal screen only — the PARTIAL
data-correction retry card (see Result screens below) is part of the review path and
is disabled with withReview: false, not this option.
Branding
Thestyle object controls the visual identity of the mounted flow:
style.logo takes precedence over a top-level logo — set both and style.logo wins.
These rules are scoped to the mount element and reverted on teardown, so a journey is safe to mount
inside an existing design system without leaking styles onto the rest of the page.
Attempts
maxAttempts sets the retry budget. It defaults to 3 — one attempt plus two data corrections.
Exhausting the budget settles the journey with declined / attempts_exhausted. That’s a decline, not
an error — check result.outcome and result.reason rather than expecting a thrown or error result.
Retries are internal to the journey; the host never loops on start() itself.
Verification
triggerVerificationOnSubmit controls whether the journey submits for verification itself. It applies
to idv and ocr only.
Setting it to false means the journey never calls submit: it captures, saves the data against the
entity, and settles success / captured so you can run verification yourself, server-side, on your own
schedule. The verifying loading screen (Pass-through configuration
below) only ever covers a submit that actually runs — with false, there is no submit to cover, so
that screen is skipped entirely.
It does not apply to ekyc, and TypeScript rejects it there. The ekyc review screen does its own
submit-and-verify, so there is no separate submit for the flag to switch off.
Result screens
result carries the form module’s own RESULT configuration, keyed by which card is showing. Name
only the states you want to change, and only the keys you want to replace — everything else keeps
the SDK’s default.
SUCCESS, PENDING, FAIL, PROVIDER_ERROR, TIMEOUT and PARTIAL. The first
five are endings. PARTIAL is the data-correction retry card, shown mid-journey — it is not
affected by withResult, and its CTA is always visible because clicking it is what starts the retry.
state is the journey’s to set: the outcome decides which card renders, so a state key in your
config is ignored.
CTAs change when the journey settles
Without acta, a card is non-interactive and start() resolves as soon as it renders. Give a
state a cta and that state resolves on the click instead — so result: { SUCCESS: { cta } } means
a successful journey waits for the applicant to acknowledge it, while a declined one still resolves
on render. Configure a CTA on every state you want that behaviour on.
Pass-through configuration
Nine keys are forwarded verbatim to the form module — the journey does not read, validate, or reshape them. Each one is documented in full on Form module: Configuration, never here.review in particular keeps its own per-country and per-state structure. The journey forwards it
verbatim — it is never flattened or translated on the way through.
Full option reference
For the completeJourneyOptions table — every option, its type, and its default — see
Journey reference: Options.