Tester en sandbox sans dépenser de crédits
Sandbox est un mode par application où chaque fournisseur est simulé, rien n'est facturé, et vous pouvez forcer n'importe quel résultat de vérification dont vous avez besoin (approuvée, refusée ou en révision).
Sandbox est un mode sur une application, pas un interrupteur à l'intérieur de votre application en production. Créez une deuxième application en mode sandbox, utilisez sa clé API, et chaque contrôle est simulé, rien n'est facturé, et vous pouvez forcer le résultat que vous voulez. Si vous ne voyez qu'une application de production, il faut créer celle en sandbox : le mode se choisit par application.
Le sandbox de Didit équivaut aux cartes de test d'un fournisseur de paiement : il vous permet de reproduire n'importe quel résultat de vérification à la demande, sans appeler de vrais fournisseurs, sans manipuler de vraies données personnelles, et sans toucher à votre solde.
#Sandbox est un mode sur une application
C'est le point qui piège le plus de monde. Production et sandbox sont des applications distinctes au sein de la même organisation, si bien que le trafic de test et les données de production ne se mélangent jamais. Chaque application a un mode, live ou sandbox.
- Une clé appartient à une application : la clé de l'application sandbox ne peut pas toucher les sessions de production.
- Créez une clé distincte pour les tests plutôt que de réutiliser celle de production.
- Créez une deuxième application
Dans la console, ouvrez le sélecteur d'applications en haut et créez une nouvelle application. Choisissez sandbox comme mode.
- Utilisez la clé API de cette application
Récupérez la clé API sous API et Webhooks pendant que l'application sandbox est sélectionnée. Il n'existe pas de « clé de test » distincte sur une application de production : la clé est l'environnement.
- Créez-y un workflow
Les applications sandbox ont leurs propres workflows. Reconstruisez (ou copiez) le flux que vous voulez tester.
- Créez des sessions normalement
Même point de terminaison, même chemin de code. La seule différence est la clé que vous envoyez.
Si votre console ne montre qu'une application de production et aucun moyen d'en ajouter une en sandbox, demandez au support d'activer la création d'applications sandbox pour votre organisation : c'est un paramètre au niveau du compte, pas quelque chose que vous avez mal configuré.
#Ce que sandbox change, et ce qu'il ne change pas
| Sandbox | Production | |
|---|---|---|
| Fournisseurs externes | Tous simulés : aucun tiers n'est jamais appelé | Réels |
| Facturation | Jamais facturé ; la vérification de solde est ignorée | Facturé par fonctionnalité terminée |
| Limite de création de sessions | 500 par 24 heures, par application | Votre solde |
| Charge utile du webhook | "environment": "sandbox" | "environment": "live" |
| Données extraites et statut | Simulés par le scénario choisi | Dérivés de la capture réelle |
| Médias capturés | Stockés pour de vrai, exactement comme une session réelle | Stockés |
Sandbox stocke les médias qu'il capture (documents, selfie, vidéo de preuve de vie, fichiers de justificatif de domicile) exactement comme le ferait une session réelle. Le résultat est simulé, mais l'envoi est réel : utilisez donc les documents d'exemple et les données de test que propose le flux plutôt qu'un vrai document d'identité ou de vraies informations personnelles.
Comme les résultats ne dépendent jamais des pixels, une photo délibérément mauvaise ne produira pas un refus en sandbox. C'est le scénario qui décide.
#Choisir le résultat
Passez un slug de scénario comme sandbox_scenario à la création de la session, ou laissez la personne qui teste en choisir un : les sessions sandbox dans le flux hébergé affichent un sélecteur de scénario dans la carte avant le début de la capture, avec une bande de documents d'exemple sous le composant d'envoi et une bannière permanente « données de test uniquement ».
Les scénarios couvrent les résultats dont vous avez réellement besoin pour construire :
| Vous voulez tester | Scénario |
|---|---|
| Tout est approuvé | approve |
| Document expiré | decline_document_expired |
| Document illisible | decline_could_not_recognize_document |
| Échec de somme de contrôle MRZ | decline_mrz_validation |
| En dessous de l'âge minimum | decline_minimum_age |
| Correspondance faciale trop faible | decline_face_match_low_similarity |
| Attaque de présentation sur la preuve de vie | decline_liveness_attack |
| Correspondance sanctions / PEP en AML | decline_aml_hit |
| Adresse IP bloquée | decline_ip_blocklist |
| Discordance d'adresse sur le justificatif de domicile | decline_poa_address_mismatch |
| Échec d'intégrité de la puce NFC | decline_nfc_chip_not_verified |
| Aucun résultat en validation de base de données | decline_database_no_match |
| Révision manuelle nécessaire (AML) | review_aml_possible_match |
| Révision manuelle nécessaire (correspondance faciale limite) | review_face_match_borderline |
| Révision manuelle nécessaire (correspondance d'adresse partielle) | review_poa_partial_match |
| Discordance de registre en KYB | decline_kyb_registry_mismatch |
Les scénarios review_* existent pour que vous puissiez exercer tout le parcours de révision manuelle (la file d'attente de révision de la console, le webhook In Review, un réviseur approuvant ou demandant une resoumission) sans avoir besoin d'une entrée provoquant un refus.
Le catalogue en direct des scénarios et des valeurs magiques est servi par l'API
elle-même sur GET /v1/sandbox/scenarios/. Si un slug ici semble un jour obsolète,
faites confiance au point de terminaison. Référence complète :
tests en sandbox.
#Distinguer les deux dans votre propre code
Chaque webhook porte un champ environment : "sandbox" ou "live". Basez-vous sur ce champ plutôt que d'essayer de déduire l'environnement à partir de la clé, et vous ne confondrez jamais une session de test avec un vrai client.
#Ce que sandbox ne fera pas
- Il ne renverra pas de vraies données de registre pour une vraie entreprise. Le KYB en sandbox utilise des réponses de registre simulées.
- Il n'enverra pas de vrai SMS ni de vrai e-mail. La vérification téléphonique et par e-mail est simulée, donc vous ne pouvez pas utiliser sandbox pour prévisualiser la délivrabilité réelle des messages.
- Il ne consommera pas vos allocations mensuelles gratuites, ce qui signifie aussi qu'une exécution en sandbox ne vous dit rien sur les contrôles gratuits qu'il vous reste.
#Si vous avez besoin de vraies vérifications de test
Certaines choses nécessitent vraiment un appel réel : vérifier qu'un service de base de données d'un pays donné est bien provisionné pour vous, ou confirmer la remise d'un SMS à un opérateur particulier. Cela nécessite une petite recharge sur une application de production plutôt que sandbox. Demandez au support avant de dépenser pour cela, afin qu'il puisse d'abord confirmer que le service est réellement activé sur votre compte.