AWAITING_USER : La remédiation automatique des transactions signalées (FR-1)

La partie la plus difficile de la surveillance des transactions n'est pas de détecter un paiement suspect, mais ce que vous en faites. Le refuser purement et simplement, c'est bloquer un client payant qui pourrait être parfaitement légitime. Le laisser passer, c'est accepter le risque que vous venez de signaler. La plupart des équipes résolvent cela avec une file d'attente manuelle : un analyste envoie un e-mail à l'utilisateur, attend des jours pour un document, et la transaction reste bloquée pendant tout ce temps.

L'API de surveillance des transactions de Didit dispose d'un quatrième statut conçu précisément pour combler cette lacune : AWAITING_USER. Au lieu d'une approbation ou d'un refus binaire, une transaction signalée peut être mise en pause, demander une action spécifique à l'utilisateur (revérifier son identité, fournir une preuve de fonds) et reprendre automatiquement dès qu'il la valide. La friction ne se produit que là où le risque est présent, et cela coûte le même prix de 0,02 $ par transaction que tout le reste.

Ce guide explique comment fonctionne le chemin AWAITING_USER et comment l'intégrer à votre flux.

Points clés à retenir

• AWAITING_USER est l'un des quatre statuts de transaction — avec APPROVED, IN_REVIEW et DECLINED — de sorte que la remédiation est un résultat de premier ordre, et non une solution de contournement.
• Une transaction signalée est mise en pause au lieu d'échouer, demande une action corrective à l'utilisateur et reprend automatiquement une fois l'action validée.
• L'action corrective peut être un re-KYC, le téléchargement d'une preuve de fonds, ou toute étape de vérification générée sur l'API unifiée /v3/.
• Les webhooks pilotent la boucle — transaction.status.updated se déclenche lorsque la transaction entre et quitte le statut AWAITING_USER.
• Le même statut existe dans la gestion des cas, de sorte qu'un analyste peut déplacer une alerte vers AWAITING_USER et laisser l'utilisateur la résoudre.
• 0,02 $ par transaction, sans minimum. Un re-KYC ou un contrôle AML généré pendant la remédiation est facturé à son propre tarif publié.

Ce que fait AWAITING_USER

Lorsqu'une règle se déclenche, le moteur attribue un statut. Trois des quatre sont familiers : APPROVED autorise la transaction, IN_REVIEW ouvre une alerte pour un analyste, et DECLINED la bloque. Le quatrième, AWAITING_USER, fait quelque chose de différent : il suspend la transaction et signale que l'utilisateur doit faire quelque chose avant qu'elle ne puisse être résolue.

Concrètement : un virement déclenche une règle de valeur ou de vélocité élevée, le moteur renvoie AWAITING_USER, votre application invite l'utilisateur à effectuer l'étape demandée (une nouvelle vérification de vivacité, le téléchargement d'un document, une déclaration de source de fonds), et la session de vérification est renvoyée à la plateforme. Une fois l'étape validée, la transaction est réévaluée et passe à APPROVED (ou est escaladée si les nouvelles preuves aggravent la situation). Aucun analyste n'a besoin de la surveiller.

Pourquoi c'est important

Les refus catégoriques sont coûteux. Chaque blocage faussement positif est un client légitime frustré, un ticket de support, et souvent un compte résilié. Mais laisser passer les paiements signalés est la façon dont les entreprises finissent par subir des mesures d'exécution. La solution conventionnelle — une file d'attente de remédiation manuelle — échange un coût contre un autre : du temps d'analyste, des délais lents et une transaction bloquée pendant des jours.

AWAITING_USER élimine ce compromis. L'utilisateur fait le travail, sur le moment, au point de friction — exactement quand il est motivé à le résoudre parce que sa propre transaction est en attente. Vous détectez le risque, vous gardez le client, et vous ne payez pas un analyste pour courir après un document. C'est la différence entre un contrôle de conformité qui vous coûte des clients et un autre qui fait discrètement son travail.

Détails techniques

Une transaction que le moteur achemine vers la remédiation revient avec le statut AWAITING_USER et les règles qui l'ont déclenchée :

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Vous réagissez en invitant l'utilisateur et en générant l'étape de vérification sur l'API unifiée /v3/. Une fois l'étape terminée, un webhook vous informe que la transaction a progressé :

# webhook payload: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks. Abonnez-vous à transaction.created et transaction.status.updated. L'événement de mise à jour du statut se déclenche à la fois lorsque la transaction entre dans AWAITING_USER et lorsqu'elle en sort — ainsi votre registre et votre interface utilisateur restent synchronisés sans sondage.

Prix. 0,02 $ par transaction. L'étape de remédiation elle-même est facturée à son propre tarif publié : un re-KYC aux tarifs de vérification de l'utilisateur, un contrôle AML sur une partie signalée à 0,20 $.

La boucle de remédiation, étape par étape

1. Déclenchement d'une règle. Une transaction dépasse un seuil que votre politique considère comme devant être remédié plutôt que refusé — par exemple, un premier virement de grande valeur depuis un nouveau compte.
2. Mise en pause, pas d'échec. Le moteur renvoie AWAITING_USER au lieu de DECLINED, avec l'action requise jointe.
3. Invite de l'utilisateur. Votre application affiche l'étape corrective — une nouvelle vérification de vivacité, le téléchargement d'un document, une déclaration de source de fonds — et génère la session de vérification.
4. L'utilisateur valide. L'utilisateur termine l'étape dans le même flux dans lequel il se trouvait déjà.
5. Reprise automatique. La transaction est réévaluée avec les nouvelles preuves et passe à APPROVED — ou est escaladée à IN_REVIEW/DECLINED si les preuves augmentent le risque. Un webhook transaction.status.updated informe votre backend dans les deux cas.

Étant donné que le même état AWAITING_USER existe dans la gestion des cas, un analyste travaillant sur une alerte IN_REVIEW peut également la renvoyer à l'utilisateur au lieu de la résoudre lui-même — l'alerte passe de OPEN → INVESTIGATING → AWAITING_USER et est résolue une fois que l'utilisateur répond.

Cas d'utilisation

• Fintech — un premier virement de grande valeur depuis un compte récemment intégré est mis en pause pour une preuve de fonds plutôt que de bloquer le client.
• Crypto — un virement sortant vers un portefeuille présentant une exposition élevée est mis en pause pour une déclaration de source de fonds avant d'être réglé.
• Prêt — un décaissement qui déclenche un signal d'identité synthétique est mis en pause pour une vérification de vivacité re-KYC.
• Places de marché — un paiement de vendeur qui déclenche une règle de vélocité est mis en pause pour une revérification avant le déblocage des fonds.
• iGaming — un pic de vélocité des dépôts est mis en pause pour un contrôle renforcé, qui sert également de point de contact pour le jeu responsable.

Comment s'intégrer à Didit

1. Décidez de votre politique de remédiation. Dans la console métier, définissez quelles règles doivent être acheminées vers AWAITING_USER au lieu de DECLINED, et quelle action corrective chacune demande.
2. Envoyez les transactions. POST /v3/transactions/ lorsque l'argent circule, avec un transaction_id stable et des vendor_data liant chaque transaction à son utilisateur.
3. Gérez la mise en pause. Lorsqu'une transaction renvoie AWAITING_USER, invitez l'utilisateur et générez l'étape de vérification sur l'API /v3/.
4. Écoutez la reprise. Réagissez à transaction.status.updated pour libérer ou maintenir la transaction une fois que l'utilisateur a validé l'étape.

Étant donné que tout est sur l'API unifiée /v3/, le KYC de remédiation qu'une transaction signalée génère est le même KYC que celui que vous utilisez pour intégrer les utilisateurs — une plateforme d'identité et de fraude unique, de bout en bout.

Foire aux questions

Qu'est-ce que AWAITING_USER ?

C'est l'un des quatre statuts de transaction. Au lieu d'un refus catégorique, une transaction signalée est mise en pause et demande une action de l'utilisateur — revérification ou preuve de fonds — puis reprend automatiquement une fois que l'utilisateur la valide.

La transaction reprend-elle d'elle-même ?

Oui. Une fois l'étape demandée validée, la transaction est réévaluée et passe automatiquement à APPROVED — ou est escaladée si les nouvelles preuves augmentent le risque. Un webhook transaction.status.updated se déclenche lors du changement.

Quelle peut être l'étape corrective ?

Toute étape de vérification sur l'API unifiée /v3/ — une vérification de vivacité re-KYC, une revérification de document, un contrôle AML ou le téléchargement d'une preuve de fonds.

Un analyste doit-il être impliqué ?

Non. La boucle de remédiation automatique fonctionne sans analyste. Mais le même état AWAITING_USER existe dans la gestion des cas, de sorte qu'un analyste peut également renvoyer une alerte à l'utilisateur s'il le souhaite.

Quel est le coût ?

0,02 $ par transaction. L'étape de remédiation est facturée à son propre tarif — un re-KYC aux tarifs de vérification de l'utilisateur, un contrôle AML à 0,20 $.

Prêt à commencer ?

Lisez l'aperçu de la surveillance des transactions dans la documentation, découvrez comment cela s'intègre au reste de la plateforme sur la page produit de la surveillance des transactions, et consultez les tarifs transparents par appel sur la page des tarifs. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, et la surveillance des transactions à 0,02 $ par appel.