ormuz
Accueil/Intégrations/Sumsub/Nodes/Evaluate transaction (Sumsub)
SumsubRouteurBeta

Evaluate transaction (Sumsub)

Soumet une transaction à Sumsub Transaction Monitoring et retourne une décision opérationnelle de routage, sans créer d’objet métier Ormuz.

Vue d’ensemble

Objectif

Ce node est un gate de décision sur une opération commerciale de vente ou d’achat. Il ne produit ni compliance_check, ni risk_score, ni draft à persister.

Le node pousse la transaction au KYT Sumsub, lit la décision immédiate quand elle existe, et suspend le process uniquement si Sumsub met la transaction en revue.

transaction_evaluation est la sortie métier principale : elle porte la décision, le score, les règles déclenchées et la réponse provider brute.

Le node route directement sur transaction_evaluation.decision avec les branches approved, rejected, review_required et awaiting_user.

awaiting_user n’embarque pas d’expérience hébergée dans ce node : le processus peut brancher ensuite un node dédié, par exemple sumsub.step_up_liveness.

Quand l’utiliser

  • Vous voulez contrôler une commande, une facture ou un checkout dans un processus de vente ou d’achat.
  • Vous voulez soumettre une transaction à des règles fraude, AML transactionnelle ou monitoring Sumsub sans créer un résultat de conformité par transaction.
  • Vous voulez gérer les cas de revue manuelle avec une attente provider encapsulée dans le même node.

Paramètres 5

extension_config_idRequisref(extension_config:sumsub)
Configuration Sumsub active utilisée pour évaluer la transaction.
subjectRequisContact
Participant évalué : contact, company ou applicant Sumsub déjà mappé au participant Ormuz. Utilisez sumsub.ensure_applicant pour préparer une identité absente.
transactionRequisCheckout session
Objet commercial Ormuz : checkout_session, order, invoice, purchase_order ou supplier_invoice. Le node traduit ses propriétés vers Sumsub, sans payload JSON libre.
paymentOptionnelPSP payment
Un unique paiement associé : psp_payment, payment ou supplier_payment. Il enrichit le contexte sans remplacer le montant de la transaction ; les parties, la devise et les liens disponibles sont vérifiés.
device_access_token / session_id / device_contextOptionnelobject
Contexte Device Intelligence à joindre à une transaction financière. La collecte se fait côté client avec le SDK fisherman ; le node transaction reste le point d’entrée pour les événements financiers.

Sorties 3

sumsub_transactionSumsub transaction
Transaction KYT Sumsub normalisée, corrélée par id / transaction_id au kytTxnId.
transaction_evaluationSumsub transaction evaluation
Résultat métier provider-native de l’évaluation transactionnelle. Il porte decision, score, triggered_rules, review_answer, review_status et raw_response.
selected_routeenum
Route sélectionnée par le node, dérivée de transaction_evaluation.decision.

Comportement

Soumettre la transaction

Le node résout un mapping applicant unique, vérifie le rattachement du sujet et du paiement facultatif, adapte la transaction typée, puis la soumet à Sumsub. En cas de retry, le même ID de soumission est conservé.

Router la décision immédiate

Si Sumsub retourne une décision finale, le node se termine avec selected_route: approved ou selected_route: rejected.

Attendre seulement la revue

Si Sumsub place la transaction en revue, le node suspend le process sur extension.sumsub.applicant_kyt_txn_reviewed, corrélé par kytTxnId.

Exemple de processus

Objet métier + Transaction
Évaluer une transaction (Sumsub)
Approuvé
Rejeté
Revue requise
Action utilisateur requise

Transaction Monitoring est une décision opérationnelle sur une transaction, pas une preuve de conformité persistée.