Didit n'envoie pas d'e-mail au changement de statut - configurez un webhook pour prévenir votre backend aussitôt, et vérifiez la signature avant de traiter.
Un webhook est une requête HTTP que Didit envoie à votre URL quand quelque chose change. Ajoutez une destination sous Développeurs → Webhooks, souscrivez aux événements que vous voulez (il n'y a aucun caractère générique, listez-les tous), enregistrez le secret de signature, et vérifiez la signature avant de traiter quoi que ce soit.
Didit ne vous envoie pas d'e-mail quand une session passe en revue ou est refusée. Pour savoir au moment où un statut change, sans recharger la console, configurez un webhook : une URL sur votre serveur vers laquelle Didit envoie automatiquement la mise à jour.
Les webhooks sont le schéma d'intégration recommandé. Interroger périodiquement l'endpoint de décision fonctionne comme solution de repli, mais c'est plus lent, cela consomme plus de requêtes, et cela manque des événements qui ne sont livrés que par webhook : les modifications de données faites par un réviseur, les changements de statut de transaction, et les changements au niveau des entités.
#Le configurer
- Développeurs → Webhooks
Ouvrez l’application et l’environnement Live ou Sandbox concernés, puis Développeurs et Webhooks.
- Ajouter un endpoint
Cliquez sur Ajouter un endpoint, renseignez son URL HTTPS et un nom, puis choisissez les événements. Gardez v3, la version recommandée, sauf pour maintenir une ancienne intégration. Vérifiez et confirmez.
- Enregistrer le secret de signature
Chaque endpoint possède son secret de signature masqué. Cliquez sur Afficher et confirmez votre identité ; il est remasqué sous 60 secondes. Conservez-le dans la configuration du serveur. Contactez le support si Afficher est désactivé. Développeurs → Webhooks.
- Envoyer un événement de test
Envoyez un test signé pour vérifier l’endpoint, la signature et le traitement sans lancer de vérification réelle.
#Les événements auxquels vous pouvez souscrire
Il n'y a aucun caractère générique : listez chaque famille d'événements que vous voulez. Les répartir sur plusieurs destinations est possible et souvent plus propre.
| Événement | Se déclenche quand |
|---|---|
status.updated | Le statut d'une session KYC ou KYB change. Celui que vous voulez presque certainement |
data.updated | Les données de vérification sont modifiées après la création : un réviseur corrige un champ |
user.status.updated | Un utilisateur consolidé passe entre ACTIVE, FLAGGED et BLOCKED |
user.data.updated | Le profil, les compteurs ou les identifiants d'un utilisateur consolidé changent |
business.status.updated | Une entreprise consolidée change de statut |
business.data.updated | Les données d'une entreprise consolidée changent |
transaction.created | Une transaction est créée et son verdict initial est prêt |
transaction.status.updated | Le statut d'une transaction change par la suite |
travel_rule.status.updated | Le statut d'un échange Travel Rule change |
Il n'existe pas de session.status.updated ni de kyc.completed. Si vous vous
êtes abonné à un nom qui n'est pas dans cette liste, vous ne recevrez rien, et
cela ressemblera exactement à un échec de livraison. Vérifiez le nom d'abord.
#Ce que votre endpoint devrait faire
- Vérifier la signature avant tout le reste. Hachez avec HMAC le corps de requête brut, jamais une version re-sérialisée du JSON analysé, car re-sérialiser change les octets et la signature ne correspondra pas. Utilisez une comparaison en temps constant.
- Renvoyer un 2xx rapidement. Faites le travail lourd de façon asynchrone, après avoir répondu.
- Être idempotent. Basez-vous sur l'id de l'événement, ou sur id de session + statut + type de webhook. Les nouvelles tentatives et les doublons arrivent.
- Gérer chaque statut qui vous intéresse, y compris ceux qui arrivent longtemps après l'intégration : une session approuvée peut plus tard passer en revue via le monitoring AML continu.
- HTTPS uniquement. Les endpoints en HTTP simple ne sont pas pris en charge.
#Nouvelles tentatives
Pour une réponse 5xx ou 404, Didit réessaie deux fois, après environ une minute puis quatre minutes. Un délai dépassant 5 secondes ou un échec de connexion ne déclenche pas de nouvelle tentative automatique. Utilisez Renvoyer dans Livraisons après correction ; un échec définitif produit une alerte.
Ne supposez pas que chaque webhook sera reçu. Après une interruption, renvoyez les livraisons ou consultez la décision de chaque session dont vous n’avez pas reçu le résultat.
#Derrière un pare-feu ou un WAF
Didit livre depuis l'IP statique 18.203.201.92 avec un user agent DiditWebhook/2.0. Si votre périphérie bloque les clients inconnus (la posture par défaut de Cloudflare, par exemple), autorisez cette IP pour le nom d'hôte destinataire, sinon les livraisons échoueront avant d'atteindre votre code.
#Vous n'avez pas encore de backend ?
Vous pouvez toujours surveiller les résultats manuellement dans la section Verifications de la console pendant que vous en construisez un, ou utiliser un lien de vérification sans code en attendant.
#Prochaines étapes
- Quand un webhook n'arrive pas : quand un webhook n'arrive jamais
- Comprendre ce que signifie chaque statut une fois arrivé : ce que signifie chaque statut de session
- Référence technique complète, incluant des exemples de code de vérification de signature : Webhooks
Toujours bloqué ? Parlez à un humain.
Indiquez l'ID de votre organisation et l'ID de la session concernée.