Identification flow

Available testbots for automated case handling

In the Sandbox environment, there are a number of testbots available for testing purposes. They can be triggered by adding the corresponding keywords in the fields for "firstName" or "lastName". Capitalization is not being regarded which means that the trigger can be set either through "xtesthappy", "Xtesthappy" or "XTESTHAPPY".

Using testbots also allows testers to use fabricated identification documents to go through the process.

Keyword	Effect on the verification	Identification status	Status reason
xtesthappy	Automatical verification	VERIFICATION_CONFIRMED	SUCCESS_DATA_CHANGED
xtestfraud	Fraud case confirmed	VERIFICATION_REJECTED	FRAUD_SUSPICION_CONFIRMED
xtestabortident	Abort ident case	IDENTIFICATION_FAILED	ABORTED
xtestcanceled	Reject – Cancel flow	IDENTIFICATION_FAILED	CANCELED
xtestcheckpending	Force check pending	VERIFICATION_PENDING	CHECK_PENDING

xtesthappy

Triggers the confirmation of the verification and can be used to go through the identification/verification process and proceed to the signing.

Identification status-flow:

• SCHEDULED

• INITIALIZED

• VERIFICATION_PENDING

• VERIFICATION_CONFIRMED

xtestfraud

Triggers the rejection of the verification and can be used to simulate a potential fraud case. A rejected case cannot be restarted, the status "VERIFICATION_REJECTED" is final.

Identification status-flow:

• SCHEDULED

• INITIALIZED

• VERIFICATION_PENDING

• VERIFICATION_REJECTED

  • "ubiIdStatusDetails": "WARNING_MANIPULATED_PHOTO"

xtestabortident

Causes the identification case to switch to the status "ABORTED" and can be used to simulate a case that is being abandoned by the enduser.

Identification status-flow:

• SCHEDULED

• INITIALIZED

• VERIFICATION_PENDING

  • "ubiIdStatusReason": "CHECK_PENDING"   

xtestcanceled

Triggers the cancellation of the identification with the reason "ID_BLURRY" and can be used go through the identification/verification process and proceed to the signing.

In case that the Bot for the cancellation flow is being set through "xtestcanceled", the Status will switch to IDENTIFICATION_FAILED at which point the enduser is being presented with the option to retry the flow. If a retry is being done, the case will end up in IDENTIFICATION_FAILED again since the initial values will not change and the cancellation bot is triggered for each retry.

Identification status-flow:

• SCHEDULED

• INITIALIZED

• VERIFICATION_PENDING

• IDENTIFICATION_FAILED

  •     "ubiIdStatusReason": "CANCELED",
        "ubiIdStatusDetails": "ID_BLURRY"

xtestcheckpending

Causes the case to get "stuck" at the status "CHECK_PENDING". This bot can be used to force this status, which could appear in the productive environment due to low quality of the captured data. In the productive environment, an agent would verify the case and cause the status to switch to "VERIFICATION_REJECTED", "VERIFICATION_CONFIRMED" or "VERIFICATION_CANCELED". In the Sandbox environment this is a final status. The bot can be used to ensure that the status-handling is done properly on customer side for cases with "CHECK_PENDING".

Identification status-flow:

• SCHEDULED

• INITIALIZED

• VERIFICATION_PENDING

  • "ubiIdStatusReason": "CHECK_PENDING"