Skip to main content

​
What is Session Journey

Session Journey is a dashboard feature that gathers every event that occurred from the moment a user entered the live form until the final outcome (approved, rejected, or pending), grouped chronologically as a single submission unit. Each event is collected from both the frontend (behavior observed on the user’s screen) and the backend (verifications and decisions executed on the server). This lets you trace back “why this user was blocked at this step” and “what the rejection or pending reason was.”
Unlike the Event Log, which tracks admin activity and deletion history, Session Journey focuses on the verification progress of a single submission.

​
Session status

In the Session Journey list, each submission shows its progress at a glance through its session status. This status is a different value from the final KYC decision (approved, rejected, or pending); it indicates how far the journey has progressed.
StatusMeaning
IN_PROGRESSIn progress — has not yet reached a final outcome
COMPLETEDCompleted — the user finished the journey to the end (the outcome may be approved, rejected, or pending)
DROPPEDDropped off — the user left without completing (did not reach the final outcome page)
ERRORError — left the normal flow, e.g., via an error page
COMPLETED only means “the journey was completed to the end”; it does not mean “approved.” Always confirm the final approved, rejected, or pending status with the BE decision events (APPROVED, REJECTED, PENDING).

​
Key cautions when interpreting

Events are listed chronologically, but in reality many verifications run concurrently.Just because events appear top to bottom on the screen does not mean “the earlier event caused the later one.” For example, ID document recognition, liveness, and age verification run almost simultaneously, and the display order merely reflects minute differences in when each was recorded. Judge causality from each event’s result value and user impact, not from the order.

​
Frontend (FE) and backend (BE) events

Session Journey events fall into two types depending on their source.
SourceMeaningExamples
FE (frontend)Observed signals about the screens and actions the user sawScreen entry, camera activation, error page entry
BE (backend)Actual verification, decision, and finalization executed on the serverID document recognition, face comparison, final approval/rejection
The actual basis for blocking or rejection is always BE events. FE events (e.g., ERROR_PAGE_VIEWED, FINAL_PAGE_VIEW) are merely observations that the user reached that screen; the final outcome must be confirmed with the BE decision events (APPROVED, REJECTED, PENDING) of the same submission.FE and BE sometimes record the same action as a pair. For example: FRONT_SESSION_START (FE) ↔ SESSION_CREATED (BE), CREATE_FLOW (an API call from an FE screen) ↔ FLOW_ID_ISSUED (BE processing result). FE shows “what the screen did,” while BE shows “how the server decided.”

​
Stages of the journey

The Session Journey broadly flows through three segments: Pre-checks → Main → Post.
1

Pre-checks — Entry and policy checks

The gating (Guard) stage before the main verification, including session creation and token, duplicate, IP, and device checks. If a user is stopped in this segment, they cannot enter ID document capture and are blocked (BLOCKED).
2

STEP1 — ID document verification

ID document-related verifications run simultaneously, including document capture, OCR recognition, liveness, age, expiration, and blacklist checks. On success, a submission (Submission) is created.
3

Pre-STEP2 — Account verification (optional)

Occurs only in projects that require account-based verification, such as 1-won transfers or account holder name lookups.
4

STEP2 — Selfie/face verification

Face-related verifications run simultaneously, including selfie liveness, face comparison, duplicate, government authenticity checks, and custom policies.
5

Final decision and notification

All verification results are aggregated to finalize the submission as approved, rejected, or pending, and the result is notified via webhook and email.
6

Post — Result page

The user reaches the result page and the journey ends.

​
The three final decisions

When the Main segment ends, the submission is always finalized as one of the following three.

APPROVED

Passed all verifications and was automatically approved. No separate reason.

REJECTED

Rejected due to verification/policy failure or exceeding the retry limit. The reason is distinguished by the reason value.

PENDING

Automatic judgment is held and manual review is required. The reason is distinguished by the reason value.
For the specific reason codes of rejection and pending, see the “Final decision reasons” table in the Session Journey event reference.

​
Interpreting error causes

Each event shows a User impact. This value indicates what impact the user actually experienced, so it is the first thing to check when interpreting an error.
User impactMeaning
NONENo impact (normal progress or a record-keeping event)
BLOCKEDBlocked — the normal flow was interrupted
RETAKEPrompts a retake or retry
PENDINGPending — awaiting manual review
REJECTEDRejected — finalized as a final rejection
APPROVEDApproved
COMPLETEDThe relevant step is completed
The order for interpreting errors: ① First check the final decision events (APPROVED, REJECTED, PENDING) and their reason → ② Find the BE verification events that caused a BLOCKED or RETAKE impact at the same step → ③ Use FE observation events to additionally confirm the screen the user saw. Do not read top to bottom in the displayed order.
For the full list of events and their meanings, see the Session Journey event reference.