Test de bout en bout d'une intégration de vérification dans un environnement de test.

Testez tous les résultats que votre code gérera, y compris les échecs, en les provoquant délibérément un par un avec les identifiants de test du bac à sable. Toden Dans l'environnement de test, les derniers chiffres d'un identifiant de test publié déterminent le scénario : vérifié, introuvable, selfie non concordant, document expiré, erreur du fournisseur, etc. Aucun service externe n'est requis et aucun frais n'est facturé ; vous pouvez donc exécuter la matrice complète autant de fois que vous le souhaitez.

Testez ensuite votre récepteur de webhook seul, avec des événements simulés signés, des renvois et une réponse en échec. La plupart des bogues d'intégration découverts après le lancement se situent dans les chemins d'échec et le récepteur, et non dans le chemin nominal testé manuellement par tous.

Comment fonctionne le bac à sable

Le mode bac à sable est sélectionné par le préfixe de clé :pk_test_pour les SDK clients,sk_test_pour votre backend. Selon le guide du bac à sable (s’ouvre dans un nouvel onglet) , trois règles s'appliquent :

• Seuls les identifiants de test publiés sont acceptés. Un numéro d'identification réel est rejeté lors de la soumission.422 only_test_ids_allowed, afin que les véritables numéros d'identification ne figurent pas dans vos données de test.

• Les résultats sont faux. Les données biographiques, les photos officielles, les extraits de documents et les résultats de bases de données sont préenregistrés. Aucune base de données gouvernementale ni aucun autre service externe n'est consulté.

• Aucun frais ne sera facturé , même en cas de crédit insuffisant.

Les identifiants de test contournent également la liste blanche des types d'identifiants de votre organisation, ce qui permet à une nouvelle organisation de commencer les tests immédiatement.

L'environnement de test et l'environnement de production sont distincts : les clés, les vérifications, les points de terminaison webhook et la configuration ne sont pas partagés entre eux. Tout ce que vous configurez dans l'environnement de test doit être reproduit en production.

Comment un identifiant de test détermine le résultat

Un identifiant de test est composé de zéros suivis du numéro de scénario, ce qui lui permet de rester valide pour son type d'identifiant. Pour un Nigérian BVN :

00000000001  → verified
00000000002  → not_found
00000000004  → selfie_mismatch
00000000012  → provider_error

Chaque type d'identifiant possède son propre format pour une même idée :A00000001pour un passeport nigérian,GHA-000000001-0pour une carte ghanéenne,00000001Pour une carte d'identité nationale kényane, modifiez les derniers chiffres pour changer de scénario. Le tableau complet des 24 scénarios et le format de chaque type de carte d'identité se trouvent dans le guide.

Un vérifié BVN Testez depuis votre serveur, en suivant l'exemple documenté :

curl -X POST https://api.toden.co/api/kyc/verify \
  -H "Authorization: Bearer pk_test_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "country": "NG",
    "idType": "bvn",
    "idNumber": "00000000001",
    "userData": { "firstName": "Chidi", "lastName": "Okafor", "dateOfBirth": "1990-04-12" },
    "metadata": { "requestId": "test-001" }
  }'

Pour les identifiants de documents, le bac à sable ne lit jamais l'image. Laissez le SDK Le flux de documents utilise par défaut le dispositif vérifié, ou choisissez un scénario en transmettant l'ID de test du document.idNumber, Par exempleA00000007pour un passeport périmé.

Les résultats à tester, regroupés selon le comportement de votre code

Vingt-quatre scénarios, c'est plus que ce dont la plupart des intégrations ont besoin pour être testées individuellement. Regroupez-les selon la branche de votre code qu'ils atteignent :

Certains scénarios suivent les paramètres de votre flux de travail, ce qui est utile car cela teste votre configuration plutôt qu'une réponse fixe. Les scénarios 5 et 6 échouent par défaut, mais vérifiez avecdataMatch: falseLorsque votre flux de travail enregistre ces informations d'identité au lieu de générer une erreur. Les scénarios 22 et 23 suivent votre restriction d'âge : le scénario 22 renvoie une date de naissance légèrement en dehors de vos limites, le scénario 23 ne renvoie aucune date, et les deux sont vérifiés dans un flux de travail sans restriction d'âge. Le scénario 24 suit vos paramètres de correspondance entre le selfie et la photo imprimée sur un document, et est vérifié lorsque votre flux de travail n'utilise pas cette photo pour la pièce d'identité.

Forcer les résultats et le timing

Deux dérogations sont effectuéesmetadataet sont ignorés en production :

• sandboxOutcomeforce tout scénario indépendamment de l'ID de test, par exemple"sandboxOutcome": "selfie_mismatch"Utile lorsque le parcours documentaire du SDK ne collecte pas de numéro d’identité.

• sandboxDelayMscontrôle la durée de la vérification, de 0 à 60 000 millisecondes, avec une valeur par défaut d’environ 1 200.

Utilisez le délai à bon escient. Réglez-le sur 0 pour des tests automatisés rapides. Réglez-le sur plusieurs dizaines de secondes pour tester un aspect souvent négligé : ce que votre application affiche pendant l’attente, si l’utilisateur peut quitter l’écran et y revenir, et si un webhook lent bloque l’écran.

"metadata": {
  "requestId": "test-slow-002",
  "sandboxOutcome": "document_expired",
  "sandboxDelayMs": 30000
}

Pendant que vous y êtes, soumettez la même choserequestIddeux fois. Vous devriez recevoir la vérification existante, et non une seconde, car c'est ce comportement dont dépend votre logique de nouvelle tentative.

Mettez la décision à l'épreuve, pas seulement les vérifications.

Si votre flux de travail comporte des règles de décision, les vérifications ne constituent que la moitié de la solution. Exécutez chaque scénario à l'aide du flux de travail sandbox publié et confirmez le résultat attendu par votre politique : aselfie_mismatchqui devrait être examiné arrive commein_review, pasdeclinedN'oubliez pas queverification.completedreflète uniquement les vérifications ; le verdict du flux de travail suit.verification.status_updatedet votre système dorsal devrait réagir à cela.

La vérification des entreprises dispose de ses propres environnements de test. Tout numéro d'enregistrement est accepté et renvoie à un environnement vérifié.RC0000001est vérifié etRC0000002n'a pas été trouvé, et la société test dispose d'un ensemble de personnes clés chargées de faire preuve de diligence raisonnable.

Tester séparément le récepteur webhook

Créez un point de terminaison webhook de test et utilisez le simulateur sur sa page. Ce dernier envoie un échantillon réaliste et correctement signé de n'importe quel événement via le chemin de livraison réel, sans effectuer de vérification. Le guide de test des webhooks (s’ouvre dans un nouvel onglet) recommande une séquence ; les étapes permettant de détecter la plupart des bogues sont les suivantes :

1. Confirmez que le récepteur vérifie la signature V2 sur le corps brut et renvoie2xxrapidement.

2. Renvoyez une livraison depuis le tableau de bord et confirmez que l'effet secondaire se produit une seule fois, car votre déduplication est basée sur l'ID de l'événement.

3. Retournez un non-2xxRépondre temporairement et confirmer qu'une nouvelle tentative est prévue.

4. Faites tourner le secret et vérifiez que les deux signatures sont acceptées pendant la période de grâce.

5. Délivrez deux événements dans le désordre et vérifiez que votre gestionnaire se termine toujours dans le bon état.

Avant de passer aux touches live

Les médias téléchargés sous un identifiant de test sont conservés pendant trois jours, puis remplacés par un espace réservé. Par conséquent, évitez de créer ultérieurement des tests dépendant des images originales. Une fois la matrice validée, le guide des environnements (s’ouvre dans un nouvel onglet) indique les exigences de production :

1. Votre profil d'entreprise est approuvé pour la production. En attendant, les demandes de vérification et de mise en ligne sont rejetées.business_not_approved.

2. Vous avez créé des clés actives : publiables pour le client, secrètes pour les résultats du backend.

3. Vous avez enregistré les points de terminaison webhook de production et vérifié leurs signatures.

4. Votre solde créditeur est approvisionné et un seuil de solde faible a été défini.

5. Vous avez remplacé les clés de test par des clés de production.

Ajoutez un élément de votre choix : indiquez le SDK à l'ID de votre flux de travail de production, étant donné que les flux de travail sont limités à un seul environnement.

Effectuez une vérification complète en production avant de déployer le flux auprès des clients. L'environnement de test (sandbox) permet de vérifier que votre code gère tous les cas de figure ; ce premier test en production confirme que la configuration copiée est bien celle prévue.