The applicant-facing flow runs on the verify app at `verify..`. It is theme-aware and uses the snapshot's effective branding, so the applicant sees your colors and brand name throughout. The interface ships in English. ## Arrival The applicant clicks the link from your invite (or scans the QR code). The verify app validates the invite link and 302-redirects to a "Start verification" interstitial at `/start/`. The interstitial shows your brand name, a subtitle, and a single button. Tapping the button consumes the invite link (see [How an invite link works](/guides/verification/one-time-links)) and mints a journey cookie. A scanner that GET-followed the link earlier never burned the token. ## Consent and disclosures Once the journey starts, the applicant steps through the checks in the workflow template's snapshot. The first applicant-rendered step is usually **Collect user information**: legal name, date of birth, address, and (optionally) phone. Workflow templates with FCRA-regulated background checks or watchlist screening surface the disclosures inline before submit. See [Background checks and FCRA](/guides/verification/reviewer-background-checks-fcra). ## Identity capture The applicant-rendered surfaces today are `collect_user_info` and `id_verification`. When a workflow template includes `id_verification`, the applicant photographs a government-issued document with the device camera inside an embedded capture frame. The interface coaches framing in real time (move closer, move back, hold steady, reduce glare, find a brighter spot, or flip to the correct side), so a poor first shot is corrected on the spot rather than failing silently. A driver's license or national ID card captures a front and a back; a passport captures the front only. The QR hand-off is available here too: an applicant who started on a desktop can scan the on-screen code to continue capturing on a phone camera, and the desktop page stays in sync. The other check types that run server-side (`watchlist`, `background_us_criminal`, and `background_global`) run using the data collected in `collect_user_info`. E-sign exists as a schema placeholder but does not render a screen in the current release. ## Selfie and liveness When the workflow template's `id_verification` check has a biometric mode enabled, the applicant completes a face check right after the document capture, in the same frame: - **Selfie mode** prompts the applicant to take a quick selfie. The face is matched against the photo on the document. - **Liveness mode** runs a short guided face scan: the applicant follows on-screen prompts to confirm a real, present person is in front of the camera, then the captured face is matched against the document. The challenge is movement-based: there are no flashing lights, so it carries no photosensitivity warning. Both modes ask for camera permission first. If the applicant declines, times out, or hits a transient error, the screen shows a specific, plain-language message and a **Try again** button, never a dead end. A failed attempt re-enters the step within the configured retry budget. When the biometric mode is `none`, no face check is shown and the flow is document-only. In **test mode** the document capture, selfie, and liveness steps are simulated entirely in the browser: there is no camera prompt, no real document upload, and no biometric capture. The applicant advances through stand-in screens and the result is the synthetic verdict the verification's [Expected outcome](/guides/verification/create-a-verification#expected-outcome-test-mode) drives. Real camera capture and biometrics apply to live mode only. ## Security checks during verification When a workflow has fraud screening switched on, the platform quietly checks device and network signals while the applicant completes their steps. This runs in the background: it does not add a screen, ask the applicant for anything, or end their journey with an error. The only thing the applicant may notice is a short, plain-language security notice: "To help keep your account secure, we check device and network signals during verification." It is informational, and the applicant completes the same verification either way. You control whether this runs per workflow (see [Add fraud signals to a workflow](/guides/workflows/workflow-templates-fraud-rules)). ## Resuming after a drop-off The applicant can close their browser mid-journey and return to the original link. The verify app detects the journey cookie on the next `/v/?o=` hit and routes straight to `/` (no re-consume), picking up at the next unfinished step. If the cookie has expired or the device has lost it, the applicant lands on the branded `/expired` page. They can self-service a fresh link as long as the verification is not in a terminal state. ## Completion and the "complete" screen When the applicant submits the last rendered step, the workflow may still have invisible checks running. Two redirects are possible: - **Eager complete.** Rendered steps are done; remaining checks run in the background. The journey redirects to `/complete`; the applicant sees "Submission received" with your brand name. Status moves to `processing`, then `completed`. - **Awaiting gate.** A gated server-side check must resolve before the next rendered step (failed document re-prompt, OFAC hit, step-up). The applicant stays in-session with a neutral processing fallback until the gate resolves. The applicant never sees a "trouble completing" message just because invisible checks run. ## Supported devices and browsers The flow targets modern mobile and desktop browsers. The QR-code hand-off assumes the applicant scans on a phone and continues there; journey state is keyed by short code, so the hand-off works without the cookie following. The interface is English-only (`en`). Track [Applicant language](/guides/faq/applicant-language) for additional locales. For terminology, see the [Glossary](/glossary).