What the applicant sees

The applicant-facing flow runs on the verify app at verify.<region>.<apex>. 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/<short-code>. 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) 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: their name, date of birth, address, and (optionally) phone.

The name is asked as separate answers, so no part of it has to be guessed from another: their family name exactly as printed on their ID, their first name, any middle names, and a suffix such as Jr. The middle-name and suffix boxes appear once the first name is filled in and the applicant moves to the next field, because most applicants need neither. Whatever the applicant types into one box is kept as one answer and is never split on spaces, so a first name like Mary Ann stays a single answer. A person with one name puts it in the family name and leaves the given-name boxes empty.

Workflow templates with FCRA-regulated background checks or watchlist screening surface the disclosures inline before submit. A credit_history check goes further and asks the applicant to authorize the report on its own screen, because a credit report cannot be pulled on an unspoken authorization. See Background checks and FCRA.

Identity capture

Five check types render a screen for the applicant: collect_user_info, id_verification, custom_form, esign, and credit_history. 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.

When the workflow template turns on Allow photo upload, the screen that starts capture offers an upload option beside the camera, and the applicant can supply an existing photo of the document instead of photographing it. The uploaded photo runs the same checks as a photographed one, and the verification records which way the document arrived so a reviewer can see it. Upload covers the document only: if the workflow template also runs a biometric face check, that step still uses the camera. See Document upload.

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. So does the credit_history report itself: the applicant fills in its screens, and the report is ordered from the name and date of birth captured in collect_user_info plus the address history the applicant enters on the credit screens.

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 drives. Real camera capture and biometrics apply to live mode only.

Reading and signing a document

When the workflow template includes an esign check, the applicant reaches a signing screen at whatever position you gave the check. It always runs after the identity-information step, because the document’s fields are filled from the details collected there.

What the applicant does, in order:

1. Reads the document. It renders inline, on the same page. If you turned on the read-through requirement, the Finish button stays off until the applicant reaches the end. The electronic-records notice is reachable from the More actions menu for as long as the signing session is live.
2. Adopts a signature, and agrees to use electronic records in the same act. The applicant selects the signature line in the document, types their full legal name and picks a signature style. The dialog states the electronic-records agreement and links to the full notice, so confirming it records both the agreement and the adopted signature. There is no separate consent screen or checkbox, and no signature can be applied without that agreement on record. The notice is versioned and hashed, and the version and hash are recorded with the signature. The signature is adopted once and applies wherever a signature is needed on that document.
3. Confirms their age, if you set a minimum. The step uses a date of birth already on file where there is one, and falls back to a confirmation checkbox where there is not.
4. Selects Finish to sign, or declines. Declining asks for a short reason and ends the check. It is a normal outcome, not an error.

Afterward the applicant can download the signed PDF from the same screen, and, if you left the emailed copy switched on, the platform emails them a sealed copy. Two more controls are on the signing screen for as long as the signing session is live, and they are the applicant’s rights rather than support requests:

• Withdraw consent. Before signing, this ends the signing session with nothing signed and tells you the applicant stopped using electronic records. It does not request a paper copy; that is the separate control below. If a signature already exists, the signed document stands, the withdrawal is still recorded, and you are still told.
• Request a paper copy. At no charge. The request comes to you.

The platform renders both controls on the hosted journey and inside the signing experience embedded in your own site. If you embed it, you must not hide or suppress them while they are on screen. Once the ceremony has ended neither control is rendered, on either surface: what the applicant keeps is the download control, any emailed sealed copy, and the notice they read, which names the route for that window (contact you). Every other outcome the applicant can land on, including an expired signing window and a document that changed while it was open, states what happened and gives a next step on the same screen.

For what these signatures are and are not in legal terms, see Electronic signatures. To author the document, see Documents applicants sign.

Authorizing a credit report

When the workflow template includes a credit_history check, the applicant reaches an authorization screen at the position you gave the check. It always runs after the identity-information step, because the report is ordered against the name and date of birth collected there.

The applicant works through four screens, in this order:

1. Authorization. The screen states what is being requested and what it is used for, together with any notice text you wrote. Nothing is requested until the applicant authorizes it.
2. Address history. The applicant accounts for where they have lived over the months you asked for. A period with no address is recorded as such rather than invented: the applicant marks it as no fixed address, time spent outside the countries the check covers, something they cannot recall, or something they prefer not to state. The most recent address is what decides which country the report is ordered in.
3. Identity and title. A title, names the applicant has used before if you asked for them, and a national identifier if you ask for one. The identifier is labeled for the applicant’s own country, which is why this screen runs after the address screen rather than before it.
4. Review. The applicant checks what they entered, then submits.

The applicant is not shown a credit result at any point. When they submit, they move on to the next step and the report resolves in the background, the same way an identity document does.

The three outcomes that are not errors

Each of these ends the step on its own explanation, with the next action written on the same screen. None of them is a dead end and none of them charges you.

What happened	What the applicant sees	What happens to the verification
The applicant does not authorize the report	The screen is headed “You did not authorize a credit history check” and says nothing was ordered and nothing was charged, that the step is left open, and that they can reload the step if they change their mind or go back to the verification page.	Nothing is ordered and the step is not submitted. The link stays valid and the verification stays resumable, so this is a deliberate non-submission rather than a terminal state: the applicant can come back to the step and authorize. The verification does not complete on its own in the meantime, and the credit step shows as unfinished on the applicant detail page. See Track a verification for where to see that, and Send an invite if you want to send a fresh link.
The applicant’s address is outside the countries the check covers	The screen is headed “A credit history check is not available for your address” and says these checks can only be run in some countries, that this does not stop the rest of the verification, and offers a control to go back and continue with the remaining steps.	No report is ordered. The check lands on the outcome you chose in If the applicant lives outside the countries we can check: held for review, or recorded as passed with the reason shown to the reviewer.
The report has not come back when the applicant finishes	Nothing extra. The applicant reaches the “Submission received” screen as usual.	The verification moves to processing and the credit outcome lands when the report arrives. See Completion and the “complete” screen.

If the screen itself fails, for example the form cannot load or the applicant’s session has expired while they were filling it in, the applicant gets a plain-language message and a way to retry or restart the step rather than a blank panel.

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

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/<code>?o=<otl> 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 for additional locales.

For terminology, see the Glossary.