SumsubAction utilisateur avec décisionBeta

Step-up liveness (Sumsub)

Demande une preuve de présence Sumsub ciblée sur un applicant existant, puis route le processus sur la décision de l’action.

Objet métier

Step-up présence (Sumsub)

Approuvé

Rejeté

Relance

Revue requise

Applicant Sumsub

Action applicant Sumsub

Vue d’ensemble

Objectif

Ce node sert aux contrôles renforcés ponctuels : reconfirmer que la personne est présente avant une opération sensible, sans rejouer tout le parcours d’identité.

Il crée une applicant action Sumsub sur l’applicant déjà lié au contact, ouvre le WebSDK sur cette action, puis attend extension.sumsub.applicant_action_reviewed.

liveness_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 liveness_check.decision avec les branches approved, rejected, retry et review_required.

Quand la décision liveness est terminale, le node matérialise directement le platform.compliance_check correspondant avec check_type: liveness sous sa permission d’écriture.

Quand l’utiliser

Vous avez déjà vérifié l’identité du contact avec Sumsub et vous voulez une re-vérification légère au moment d’un risque.
Vous devez protéger une opération sensible, par exemple un payout élevé, un changement de moyen de paiement ou une action administrateur critique.
Vous voulez corréler la décision sur l’action précise, pas seulement sur l’applicant global.

Paramètres 7

extension_config_idRequisref(extension_config:sumsub)

Configuration provider Sumsub active.

subjectRequisContact

Contact personne physique concerné. Le node exige un contact persistant, car le step-up réutilise un applicant Sumsub existant.

sumsub_applicantOptionnelSumsub applicant

Applicant Sumsub à utiliser directement. Si absent, le node le retrouve via le mapping provider du contact.

level_nameRequisstring

Nom du level Sumsub de type applicant action configuré pour le liveness step-up.

onboarding_caseOptionnelOnboarding case

Dossier métier à rattacher au compliance_check matérialisé.

scopeOptionnelstring

Périmètre métier du contrôle. Valeur par défaut : step_up.

external_action_idOptionnel avancéstring

Identifiant externe envoyé à Sumsub pour l’action. Par défaut, Ormuz génère un identifiant stable depuis l’instance de process et le node.

Sorties 5

sumsub_applicantSumsub applicant

Applicant Sumsub réutilisé pour créer l’action.

sumsub_applicant_actionSumsub applicant action

Action Sumsub créée pour ce contrôle ponctuel. Sa paire object/id sert à corréler la reprise asynchrone.

liveness_checkSumsub liveness check

Résultat métier provider-native du contrôle de présence. liveness_check.decision est la source des routes du node.

selected_routeenum

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

action_compliance_checkOptionnelCompliance check

Contrôle liveness persistant créé ou réutilisé après décision terminale de l’action Sumsub.

Comportement

Réutiliser l’applicant

Le node prend l’applicant fourni ou retrouve celui du contact via extension_object_mappings. S’il n’existe pas, le processus doit d’abord passer par un parcours d’identité.

Créer l’action ciblée

Ormuz crée une applicant action Sumsub avec un externalActionId stable et génère un token WebSDK scopé sur cette action.

Attendre la décision

Après soumission utilisateur, le process attend extension.sumsub.applicant_action_reviewed corrélé à sumsub_applicant_action.id.

Router le parcours

liveness_check.decision devient selected_route. approved poursuit l’opération sensible, rejected la bloque, retry relance le step-up, et review_required branche vers une revue manuelle.

Matérialiser le contrôle

Une décision terminale est matérialisée comme compliance_check canonique avec provenance provider. GREEN devient passed et RED FINAL devient failed; RED RETRY reste une route de reprise et ne matérialise pas un fait terminal.

Exemple de processus