Comment obtenir des résultats fiables avec Toden
Charles Archibong, Cofondateur
Recevez les résultats Toden de manière fiable grâce à un récepteur webhook signé. Vérifiez l'exactitude des données, stockez chaque événement de façon permanente et gérez les nouvelles tentatives sans répéter l'action du client.
Points clés
- Les signatures falsifiées et périmées sont rejetées.
- Un renvoi logique déclenche une action métier.
- La récupération du récepteur survit à un redémarrage du processus.
- Les événements différés ne peuvent pas écraser un état plus récent.
- La rotation s'effectue pendant toute la période de grâce.
Recevoir Toden Résultats fiables avec un récepteur webhook signé. Vérification précise des octets, stockage durable de chaque événement et récupération des nouvelles tentatives sans répéter l'action du client.
Avant de commencer
Un point de terminaison serveur qui vérifie les signatures
Gestion durable des doublons et récupération après nouvelle tentative
Un autorisé API clé pour la récupération des résultats du serveur
Utilisez un membre de l'équipe autorisé pour cette opération. Vérifiez l'organisation et l'environnement avant de modifier un paramètre. Consultez le prix actuel avant tout paiement ou renouvellement d'abonnement. Les captures d'écran présentent un exemple d'espace de travail ou la référence d'intégration publique ; elles ne représentent pas un client réel ni un paiement effectué.
Configurer et utiliser la fonctionnalité
Étape 1 : Préparer le récepteur backend
Créer un public HTTPS Point de terminaison avec un certificat valide et sans redirection. Il doit recevoir le corps de la requête brute exact avant JSON L'intergiciel change la donne. Prévoyez une boîte de réception robuste, indexée par un identifiant d'événement logique, et un traitement en arrière-plan pour les tâches lentes. Le destinataire doit se trouver côté serveur ; un rappel du navigateur ne saurait remplacer une transmission fiable des résultats.
Référence d'intégration : Algorithme de vérification
Étape 2 : Créer le point de terminaison webhook de l’environnement
Dans Sandbox, ouvrez Développeurs → Webhooks → Ajouter un point de terminaison . Saisissez le point de terminaison. URL Choisissez la version du corps prise en charge et sélectionnez les familles d'événements gérées par votre intégration. Sélectionnez « Créer un point de terminaison » et enregistrez le secret de signature du point de terminaison affiché dans votre gestionnaire de secrets. Conservez-le séparément de votre système. API Clé. Les environnements Sandbox et Production nécessitent des points de terminaison et des secrets adaptés à leur environnement.
Référence d'intégration : séquence de tests recommandée
Étape 3 : Vérifier la signature V2 avant l’analyse
Lire X-Myaza-Signature-V2 , analyser l'horodatage signé et les candidats v1, rejeter les horodatages invalides ou expirés et vérifier HMAC - SHA256 Sur l'horodatage, un point et les octets bruts exacts. Utilisez le secret du point de terminaison et une comparaison à temps constant. Lors de la rotation, acceptez une signature valide provenant du secret de grâce actif ou non expiré. Utilisez la documentation. SDK ou un exemple de receveur plutôt qu'un format de signature inventé.
Référence d'intégration : En-têtes signés
Étape 4 : Persister dans l’événement logique avant l’accusé de réception
Après vérification de la signature, analysez le JSON Stockez l' identifiant de l'enveloppe sous une contrainte d'unicité durable. Dédupliquez les opérations métier à l'aide de cet identifiant, et non de l'identifiant de livraison. Un alias de renvoi ou de compatibilité peut gérer le même événement logique sous une autre livraison. Ne renvoyez un code 2xx qu'après une acceptation durable ; mettez en file d'attente les opérations lentes séparément. Un code 2xx rapide sans enregistrement durable peut entraîner la perte du résultat suite à une panne.
Référence d'intégration : Assertion d'idempotence
Étape 5 : Rapprocher le résultat du produit actuel
Utilisez la référence documentée du client, de la vérification, de la transaction ou de l'activité pour la famille d'événements. Distinguez clairement le statut et la vérification du statut pour les vérifications. Les événements peuvent arriver dans le désordre ; par conséquent, consultez l'état actuel de la ressource ou utilisez sa version compatible avant toute modification importante. Les champs optionnels et les types d'événements inconnus ne doivent pas entraîner le dysfonctionnement de votre système de réception. Une simple notification ne constitue pas une autorisation de déblocage de fonds.
Référence d'intégration : Assertion de commande
Étape 6 : Tester la diffusion, la relecture et la rotation
Ouvrez l' action de test du point de terminaison et envoyez un événement simulé compatible. Consultez l'historique de livraison et l'enregistrement durable du destinataire. Renvoyez l'événement et vérifiez que l'action métier se produit bien. Testez une réponse autre que 2xx, la récupération après expiration du délai, un corps de réponse altéré et une signature expirée. Utilisez la période de grâce pour effectuer une rotation des signatures et testez les deux signatures avant de supprimer la signature secrète du destinataire la plus ancienne.
Référence d'intégration : séquence de tests recommandée
Tirez le meilleur parti de cette capacité
Abonnez-vous aux familles d'événements canoniques nécessaires à votre produit plutôt qu'à chaque entrée de catalogue sans gestionnaire.
Signalez à votre équipe les échecs de livraison répétés ou les lettres non distribuées et assurez un suivi auprès des ressources actuelles.
Conservez les références exactes de la décision et l'explication de votre action afin que le support puisse prouver ce que l'application a fait.
Testez-le avant de vous y fier.
Exécutez les scénarios de test ou de simulation pris en charge pour ce produit. Si un outil est réservé à la production, vérifiez d'abord les droits d'accès et la portée, puis utilisez uniquement un test de production autorisé et préalablement validé. Une capture d'écran de la documentation ou le chargement réussi d'une page ne constituent pas un test d'intégration de bout en bout.
Les signatures falsifiées et périmées sont rejetées.
Un renvoi logique déclenche une action métier.
La récupération du récepteur survit à un redémarrage du processus.
Les événements différés ne peuvent pas écraser un état plus récent.
La rotation s'effectue pendant toute la période de grâce.
Dépannage
Les signatures échouent après l'analyse. JSON
Vérifiez les octets bruts avant l'analyse. Resérialisé JSON modifie l'entrée signée.
Un renvoi a agi deux fois
Utilisez l'identifiant logique de l'événement comme clé unique durable au lieu de deliveryId.
La livraison a été effectuée avec succès, mais le compte n'a pas été modifié.
Inspectez le traitement et la corrélation des processus métier en file d'attente. HTTP L'accouchement ne constitue pas une preuve de l'effet secondaire ultérieur.
Ouvrez les références d'installation et d'intégration
Ouvrir l'outil tableau de bord (s’ouvre dans un nouvel onglet)
Consultez le guide d'intégration (s’ouvre dans un nouvel onglet)
Retour à la page Solutions (s’ouvre dans un nouvel onglet) . Choisissez la fonctionnalité que vous souhaitez activer, puis suivez son guide.
Sources
Charles Archibong
Cofondateur
Charles Archibong est le cofondateur de Toden. Il écrit sur la vérification d'identité, les technologies financières et les aspects pratiques de la création de services numériques de confiance.
