pipwave-ekyc-uikit 3.1.3-beta.1 → 3.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Selfie-Only Submission: Current Error Handling (for UX)
|
|
2
|
+
|
|
3
|
+
Scope: the standalone selfie flow (selfie NOT combined with an ID document). Note: error handling is the same whether selfie is standalone or bound to ID. The only difference is which screen shows after a successful selfie.
|
|
4
|
+
|
|
5
|
+
## How a selfie gets submitted
|
|
6
|
+
|
|
7
|
+
1. Camera runs on-device face + liveness/smile detection.
|
|
8
|
+
2. Only when that check passes does the app capture the photo and make ONE API call to the server (`POST /ekyc/session/{id}/selfie`).
|
|
9
|
+
3. The server accepts or rejects it, and the app shows the matching screen.
|
|
10
|
+
|
|
11
|
+
Key point: the API is not called on every camera frame or every time the user moves. It fires once per qualifying selfie.
|
|
12
|
+
|
|
13
|
+
## What counts as an "attempt" (answering "minus per API call?")
|
|
14
|
+
|
|
15
|
+
- It is NOT a countdown shown to the user, and the app does not subtract anything.
|
|
16
|
+
- The server keeps a counter that goes UP by 1 for each selfie submission it receives (`current_attempt`). Once it reaches the server's maximum, the response tells the app to show the "Submission limit reached" screen.
|
|
17
|
+
- One attempt = one submission that reaches the server (step 2 above). Retakes in front of the camera that never pass the liveness check do NOT count.
|
|
18
|
+
- The counting lives entirely on the server. The app does not read, display, or warn about the remaining count. It only reacts once the limit is hit.
|
|
19
|
+
|
|
20
|
+
Open question for the backend team (not visible in the app code): does EVERY submission that reaches the server count as +1, or only certain ones (e.g. a blurry submission that still reached the server)? This should be confirmed so we describe the limit accurately to users.
|
|
21
|
+
|
|
22
|
+
## The 4 outcomes after a selfie is submitted
|
|
23
|
+
|
|
24
|
+
| # | Outcome | What the user sees | Can they retry? |
|
|
25
|
+
|---|---------|--------------------|-----------------|
|
|
26
|
+
| 1 | Success | Moves to the analyzing / completion screen | n/a |
|
|
27
|
+
| 2 | Attempt / session limit reached, or session expired | Full screen: "Submission limit reached. Your submission couldn't be processed as it has reached the maximum number of attempts." | No. Terminal for the session. |
|
|
28
|
+
| 3a | Blurry / overexposed selfie, retriable | Dialog: "The image is blur, please take a clear photo." Button: "Retake" | Yes. Returns to camera. |
|
|
29
|
+
| 3b | Blurry / overexposed selfie, NOT retriable | Same "image is blur" message. Button: "Proceed" | No. Sends the user to the "Submission limit reached" screen. |
|
|
30
|
+
| 4 | Any other error (access denied, validation, network, etc.) | Full screen: "Something went wrong / contact support." | No. |
|
|
31
|
+
|
|
32
|
+
## Two UX concerns worth discussing
|
|
33
|
+
|
|
34
|
+
1. The "blurry but not retriable" case (3b) is inconsistent. The message tells the user to "take a clear photo," but the only button is "Proceed," which ends the session on the limit screen. The message implies a fix; the action is a dead end. We may want a different message and button for this case.
|
|
35
|
+
2. The user never sees how many attempts remain. Attempts are counted on the server and nothing is shown until the user suddenly hits the wall (outcome 2). We may want a warning before the hard stop (e.g. "1 attempt remaining").
|
|
36
|
+
|
|
37
|
+
## Implementation dependency to be aware of
|
|
38
|
+
|
|
39
|
+
The app decides which screen to show based on a specific error code returned by the server. If the server does not tag the limit error with the expected code, the user lands on the generic "something went wrong" screen (outcome 4) instead of "submission limit reached" (outcome 2). So correct screen routing depends on the backend returning the right code.
|