AWAITING_USER : Remédiation Automatique pour les Transactions Signalées

Le plus difficile dans la surveillance des transactions n'est pas de détecter le paiement suspect, mais ce que vous faites ensuite. Le refuser purement et simplement, c'est bloquer un client payant qui peut être tout à fait légitime. Le laisser passer, c'est accepter le risque que vous venez de signaler. La plupart des équipes résolvent ce problème 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 l'identité, fournir une preuve de fonds — et reprendre automatiquement dès qu'elle est validée. La friction ne se produit que là où le risque est présent, et elle 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, un téléchargement de 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 sort de l'état 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 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 laisse passer 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 transfert 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 (un nouveau contrôle de vivacité, un téléchargement de 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 les choses). Aucun analyste n'a besoin de la surveiller.

Pourquoi c'est important

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

AWAITING_USER supprime ce compromis. L'utilisateur fait le travail, sur-le-champ, au point de friction — précisément lorsqu'il est motivé à le résoudre parce que sa propre transaction est en attente. Vous détectez le risque, vous conservez 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/. Lorsque l'étape est 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 grand livre 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 tarif publié : un re-KYC aux tarifs de vérification d'utilisateur, un contrôle AML sur une partie signalée à 0,20 $.

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

1. Déclencher une règle. Une transaction dépasse un seuil que votre politique considère comme devant être corrigé plutôt que refusé — par exemple, un premier transfert de grande valeur depuis un nouveau compte.
2. Pause, ne pas échouer. Le moteur renvoie AWAITING_USER au lieu de DECLINED, avec l'action requise jointe.
3. Inviter l'utilisateur. Votre application affiche l'étape corrective — une nouvelle vérification de vivacité, un téléchargement de document, une déclaration de source de fonds — et génère la session de vérification.
4. L'utilisateur la 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 par OPEN → INVESTIGATING → AWAITING_USER et est résolue une fois que l'utilisateur répond.

Cas d'utilisation

• Fintech — un premier transfert 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 transfert sortant vers un portefeuille avec une exposition élevée est mis en pause pour une déclaration de source de fonds avant le règlement.
• Prêt — un décaissement qui déclenche un signal d'identité synthétique est mis en pause pour un contrôle de vivacité re-KYC.
• Marchés — 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é de dépôt 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 acheminent 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 chacun à son utilisateur.
3. Gérez la 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.

Parce 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, de bout en bout.

Questions fréquemment posées

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 à l'utilisateur — revérification ou preuve de fonds — puis reprend automatiquement une fois que l'utilisateur l'a validée.

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/ — un contrôle de vivacité re-KYC, une revérification de document, un contrôle AML ou un téléchargement de 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.

Combien ça coûte ?

0,02 $ par transaction. L'étape de remédiation est facturée à son propre tarif — un re-KYC aux tarifs de vérification d'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 vérifiez les tarifs transparents par appel sur la page des tarifs. Lorsque vous êtes prêt, commencez gratuitement — 500 contrôles KYC gratuits chaque mois, et la surveillance des transactions à 0,02 $ par appel.