SumsubAction utilisateur avec décisionBeta

Verify identity (Sumsub)

Lance une vérification d’identité Sumsub pour un contact personne physique, affiche l’expérience de vérification, puis route le processus sur la décision provider.

Objet métier

Vérifier l’identité (Sumsub)

Approuvé

Rejeté

Relance

Revue requise

Applicant Sumsub

Identity check Sumsub

Vue d’ensemble

Objectif

Ce node encapsule le parcours d’identité Sumsub sans demander au concepteur du processus de manipuler directement un applicant, un token SDK ou un événement provider.

Il crée ou réutilise l’applicant Sumsub lié au sujet Ormuz, ouvre une action utilisateur de vérification, puis reprend le process lorsque Sumsub renvoie la décision applicantReviewed.

identity_check est la sortie métier principale : elle porte result, decision, review_answer, review_reject_type et les labels de rejet Sumsub.

Le node route directement sur identity_check.decision avec les branches approved, rejected, retry et review_required. Il remplace donc le couple action utilisateur + routeur dans les processus standards.

Quand le sujet est un contact persisté et que la review atteint une décision terminale, le node matérialise directement le platform.compliance_check correspondant sous sa permission d’écriture.

Quand la review Sumsub contient des signaux AML, PEP ou sanctions, le node peut matérialiser un second aml_compliance_check distinct avec check_type: aml.

Quand le sujet est un contact draft, le contrôle ne peut pas être matérialisé tant que le contact canonique n’existe pas ; la corrélation reste portée par l’onboarding_case.

scope est un périmètre métier Ormuz du contrôle conformité. Ce n’est pas un paramètre Sumsub, ni un scope d’autorisation API.

Quand l’utiliser

Vous devez vérifier l’identité d’un contact ou d’un contact_draft pendant un onboarding client.
Vous voulez utiliser un level Sumsub existant, par exemple ID only, ID + liveness ou ID + phone, sans changer le graphe de process.
Le processus doit router sur le résultat KYC avant d’approuver, de rejeter ou de relancer un dossier.

Paramètres 8

extension_config_idRequisref(extension_config:sumsub)

Configuration provider Sumsub active. Elle porte les credentials Sumsub et le secret de webhook utilisés pour ce parcours.

subjectRequisContact

Sujet métier à vérifier. Le node accepte un platform.contact persisté ou un contact draft issu de l’onboarding.

level_nameRequisstring

Nom du level Sumsub à appliquer. Le level porte le scénario métier côté Sumsub, par exemple ID only, ID + liveness ou ID + phone.

onboarding_caseOptionnelOnboarding case

Dossier d’onboarding associé au contrôle. Requis lorsque subject est un contact draft, car son identifiant sert alors de clé de corrélation Sumsub.

scopeOptionnelstring

Périmètre métier inscrit sur compliance_check.scope lorsque le contrôle est matérialisé. Gardez identity_verification sauf si vous devez distinguer plusieurs contrôles conformité pour le même sujet.

check_typeOptionnelstring

Type de contrôle à inscrire dans le compliance_check matérialisé. Valeur par défaut : kyc.

titleOptionnelstring

Titre affiché dans l’action utilisateur. Valeur par défaut : Verify your identity.

descriptionOptionnelstring

Texte d’accompagnement affiché dans l’action utilisateur.

Sorties 5

sumsub_applicantSumsub applicant

Objet provider Sumsub exposant l’applicant vérifié. Il porte l’identifiant applicant et la corrélation utilisée par la décision provider.

identity_checkSumsub identity check

Résultat métier provider-native du contrôle identité. identity_check.decision est la source des routes du node.

selected_routeenum

Route sélectionnée par le node, dérivée de identity_check.decision.

compliance_checkOptionnelCompliance check

Contrôle conformité persistant créé ou réutilisé après réception d’une décision Sumsub terminale quand le sujet est un contact persistant.

aml_compliance_checkOptionnelCompliance check

Contrôle AML persistant additionnel lorsque la review contient un signal AML, PEP, sanctions ou watchlist. La granularité provider reste dans raw_response.

Comportement

Préparer l’applicant

Le node associe le sujet Ormuz à un applicant Sumsub existant ou en crée un nouveau. Pour un contact, externalUserId vaut l’identifiant du contact. Pour un contact draft, externalUserId vaut l’identifiant de l’onboarding_case.

Afficher la vérification

Une action utilisateur est ouverte avec le contexte nécessaire au composant Sumsub. Le process reste en attente pendant que l’utilisateur complète la vérification.

Attendre la décision provider

Après soumission, le process attend l’événement extension.sumsub.applicant_reviewed correspondant à l’applicant. Les événements intermédiaires peuvent être observés, mais la décision métier vient de la review.

Router le parcours

identity_check.decision devient selected_route. approved poursuit le parcours nominal, rejected branche vers un refus final, retry relance une correction utilisateur, et review_required branche vers une revue manuelle.

Matérialiser le contrôle conformité

Lorsque Sumsub répond pour un contact persistant avec une décision terminale, le node crée ou réutilise le compliance_check canonique avec la provenance provider. Un résultat vert devient passed et un rejet final devient failed; les résultats retry restent une décision de routage et ne matérialisent pas un fait terminal.

Exemple de processus