Additional info about verification session statuses
What are session statuses?
Verification session status indicate the progress of the verification session, indicating the stage where the session currently is. Veriff notifies about the following stages, sending a descriptive label and a session code:
started(7001)submitted(7002)approved(9001)declined(9102)resubmission_requested(9103)expired(9104)abandoned(9104)review(9121)
Fetch session status
The session status is available in the verification.status parameter in:
Decision webhook payload
POST /sessions[↗] response
GET /sessions/{sessionId}/attempts[↗] response
GET sessions/{sessionId}/decision[↗] response
→ See also the Meanings of various verification statuses and decisions[↗] article in Veriff Knowledge Base for more info (you need to log in to Veriff Customer Portal to access the article).
Verification session status codes
The session status codes indicate the progress of the verification session, indicating the stage where the end-user’s verification process currently is.
This info is sent back in:
actionandcodestrings in the event webhookverification.statusandverification.codestrings in the decision webhook
Status | Code | Sent via | What does this mean? |
|---|---|---|---|
| 7001 | Event webhook | The end-user has started their session and landed in Veriff’s verification flow. No decision is available yet. |
| 7002 | Event webhook | End-user’s required data has been submitted. No decision is available yet. |
| 9001 | Decision webhook | Positive: end-user was verified. The verification process is complete. Accessing the |
| 9102 | Decision webhook | Negative: end-user has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the end-user could not be verified. You should investigate the session further and read the Granular reason codes (table). If you decide to give the end-user another try, you need to create a new session using the POST /sessions endpoint. |
| 9103 | Decision webhook | Resubmission has been requested. The verification process has not been completed. Something was missing from the end-user, and they need to go through the flow once more. The same You can investigate the session further and read the Granular reason codes (table). |
| 9104 | Decision webhook | Verification has been expired because the end-user never accessed the verification (a session will expire 7 days after having been created unless it gets a conclusive decision before that). The verification process is complete. If you decide to give the end-user another try, you need to create a new session using the POST /sessions endpoint. |
| Verification has been abandoned because the end-user started the verification session but never finished it (a session will expire 7 days after having been created unless it gets a conclusive decision before that). The verification process is complete. If you decide to give the end-user another try, you need to create a new session using the POST /sessions endpoint. | ||
| 9121 | Decision webhook | This status is issued whenever the automation engine could not issue a conclusive decision and the verification session needs to be reviewed by a human on your side. Note that in order to receive this status, it must be specifically configured and enabled for you integration. |
Responses 9001, 9102, 9121 and 9104 are conclusive responses. The session is closed and the sessionURL is not available for the end-user.
Response 9103 is an inconclusive response. The session remains open until you receive one of the above conclusive responses. The session is re-opened for the end-user, accepting a new attempt.
→ See the Meanings of various verification statuses and decisions[↗] article in Veriff Knowledge Base for more info (you need to log in to Veriff Customer Portal to access the article)
Status: resubmission_requested
If you are using the API solution, then when the verifications receive the resubmission_requested status from Veriff, it is strongly advised that you inform the end-user about the reasons for the verification failure and provide suggestions on how to improve their next attempt. This communication can be conducted through email, SMS, and/or within your platform to ensure better visibility.
For resubmitted verification attempts where certain elements were missing or the quality of the submission was subpar, a new attempt is generated and made available through the same session URL. It is important to use the same session URL for verification attempts made by the same end-user.
Status: review
This status is not sent by default. You need to have an agreement with Veriff to receive it, and it must be configure for you integration.
The review status means that somebody from your end should take a look at the session and decide to approve or decline the end-user.