Comment tester et dépanner une intégration avec Toden
Charles Archibong, Cofondateur
Testez l'intégration complète, y compris les pannes et la récupération. Choisissez le modèle de test compatible avec la famille d'API que vous utilisez, puis examinez l'enregistrement Toden et le comportement de votre application.
Points clés
- Toutes les branches de décision atteignent leur chemin d'application prévu.
- Les réponses perdues et les événements répétés ne créent aucun effet de duplication.
- Les termes « en attente » et « indisponible » restent distincts.
- Les éléments fixes restent clairement étiquetés.
- Les allégations fondées uniquement sur la production nécessitent des preuves concrètes.
Testez l'intégration complète, y compris les pannes et la récupération. Choisissez le dispositif pris en charge pour le API famille que vous utilisez, puis inspectez les deux Toden l'enregistrement de et le comportement de votre application.
Avant de commencer
Un scénario Sandbox pris en charge ou un échantillon étiqueté
Utilisez la famille de points de terminaison appropriée et SDK version
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 : Associer le produit, l’hôte et les identifiants
Choisissez Sandbox et enregistrez le API La famille que vous testez est la suivante : la vérification d'identité utilise l'hôte et la clé de test documentés de l'API /api/kyc. Risk Intelligence utilise son hôte et sa clé secrète Sandbox /api/v1. Identity Hub possède son propre contrat /api/identity. Ne déplacez pas les champs de requête entre les familles et n'en déduisez pas que chaque requête Sandbox est gratuite. Les scénarios Risk Intelligence explicites ne sont pas facturables ; les requêtes ordinaires peuvent utiliser la tarification configurée.
Référence d'intégration : Sandbox
Étape 2 : Choisissez un scénario de vérification pris en charge
Ouvrez le guide Sandbox et identifiants de test et sélectionnez un identifiant correspondant au pays et au type de document. Par exemple, l'identifiant nigérian. BVN Les résultats se terminant par 01 sont validés et 04 génèrent une incohérence de selfie. Les résultats basés uniquement sur des documents nécessitent un identifiant de document. Utilisez le scénario publié ou la substitution prise en charge ; les numéros d'identité réels sont refusés par le contrat de vérification Sandbox.
Référence d'intégration : Référence de scénario
Étape 3 : Utiliser le simulateur pour les parcours de risque pris en charge
Ouvrez Développeurs → Simulateur dans l'environnement de test. Sélectionnez un scénario compatible et vérifiez son éligibilité. Les scénarios verrouillés ou nécessitant une configuration doivent respecter leurs prérequis affichés ; ne supprimez pas une barrière pour les exécuter. Les configurations de règles de voyage requièrent une politique compatible publiée séparément. L'exécution d'un scénario déterministe prouve son fonctionnement contrôlé, et non une connexion réelle avec un fournisseur ou un échange institutionnel réel.
Référence d'intégration : Configurer les règles de voyage du bac à sable
Étape 4 : Tester indépendamment le récepteur signé
Créez le point de terminaison webhook Sandbox et utilisez les tests pour simuler un événement pris en charge. Vérifiez la signature par rapport aux octets bruts et enregistrez son identifiant logique. Testez un renvoi, une signature invalide, une signature expirée et une défaillance du récepteur. Les exemples d'identifiants générés illustrent le format ; ils ne sont pas réutilisables. API ressources pour un appel de récupération ultérieur.
Référence d'intégration : Luminaires pilotés par catalogue
Étape 5 : Exercices sur l'incertitude et l'ordonnancement
Simulez une perte de réponse après l'acceptation d'une requête, puis réessayez l'opération exacte avec ses références et sa clé d'idempotence d'origine lorsque le contrat le permet. Retardez ou réorganisez les notifications acceptées et mettez à jour l'état actuel. Testez un résultat en attente et indisponible séparément d'un refus. Inspectez le Toden Enregistrez et conservez l'état durable de votre application pour détecter les doublons ou les modifications d'accès incorrectes.
Référence d'intégration : Assertion de commande
Étape 6 : Tenir un registre concret de l'état de préparation à la production
Consignez les scénarios testés, la décision prévue, la décision observée, l'action du système en arrière-plan et les preuves de récupération. Vérifiez la compatibilité. SDK Versions, récupération des autorisations et appareils représentatifs. Configurez le flux de travail de production, les clés et le récepteur uniquement une fois les exigences métier et fonctionnelles satisfaites. Supprimez les champs de scénario réservés au bac à sable. Un test local réussi ou un exemple de score ne reflète pas le comportement réel des clients.
Référence d'intégration : Liste de contrôle pour la mise en production
Tirez le meilleur parti de cette capacité
Conservez les spécifications sous la même forme que les contrats publics afin que votre suite de tests détecte les modifications de champs et de versions.
Tester les décisions finales tardives pour les flux de travail qui dépendent d'une présélection, de personnes clés ou de leur présence.
Attribuez aux défaillances opérationnelles un message sécurisé pour le client et une procédure de rétablissement interne plutôt que de demander au demandeur de réparer une panne de service.
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.
Toutes les branches de décision atteignent leur chemin d'application prévu.
Les réponses perdues et les événements répétés ne créent aucun effet de duplication.
Les termes « en attente » et « indisponible » restent distincts.
Les éléments fixes restent clairement étiquetés.
Les allégations fondées uniquement sur la production nécessitent des preuves concrètes.
Dépannage
Ma véritable identité a été rejetée dans le bac à sable.
Utilisez un identifiant de test publié. La vérification en environnement isolé ne valide pas les numéros d'identité réels.
Un scénario de simulateur est verrouillé.
Respectez les conditions préalables affichées concernant la politique ou les équipements contrôlés.
Impossible de récupérer une ressource d'exemple.
Les exemples du catalogue illustrent des formes ; leurs identifiants ne sont pas des ressources stockées actives.
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.
