Développeurs
Gérez votre produit en fonction de son statut et du résultat, et stockez `checkStatus` à côté pour l'explication. Associez chacune des dix valeurs de statut à un état de votre système et récupérez le statut le plus récent via `verification.status_updated` ou par interrogation.
Développeurs
Attribuez un identifiant de requête (requestId) à chaque vérification logique, enregistrez-le avant l'envoi de la requête et réutilisez-le à chaque nouvelle tentative. Un identifiant de requête déjà utilisé permet de récupérer la vérification existante au lieu d'en créer et d'en facturer une seconde.
Développeurs
Intégrez la clé publique dans votre application et conservez la clé secrète sur votre serveur. Une clé publique permet de lancer une vérification et de lire un statut minimal, jamais de données d'identité. Prévoyez donc une éventuelle fuite et limitez-en les conséquences.
Développeurs
Utilisez les identifiants de test sandbox publiés, dont les derniers chiffres déterminent le résultat, pour gérer chaque résultat que votre code doit traiter, puis testez votre récepteur webhook avec des événements simulés signés avant de passer aux clés réelles.
Mises à jour des produits
Montez le SDK avec un ID de flux de travail ; la configuration du flux est alors récupérée du serveur à chaque vérification. La republication modifie les étapes, les contrôles, les copies et les règles de décision pour la vérification suivante, sans nécessiter de nouvelle version de l'application.
Mises à jour des produits
Une fois la vérification terminée, le graphe de décision du flux de travail collecte les résultats, parcourt les branches correspondant à un ensemble fermé de champs et aboutit à l'approbation, à la vérification ou au refus. Le résultat détermine la décision à prendre envers le client sans modifier les résultats des vérifications.
Développeurs
Considérez la soumission comme le début d'un processus, et non la fin d'une requête. Affichez un état « en attente » indexé par l'identifiant de vérification, mettez-le à jour via des webhooks et autorisez plusieurs changements d'état.
Développeurs
Vérifiez la signature V2 sur les octets de la requête brute, rejetez les horodatages en dehors de la fenêtre de relecture, enregistrez l'ID de l'événement sous une contrainte unique avant d'effectuer tout travail et ne renvoyez 2xx qu'une fois que l'événement est stocké de manière durable.
Développeurs
Intégrez le SDK lorsque la vérification a lieu au sein de votre produit ; envoyez un lien hébergé par candidat lorsqu’elle a lieu en dehors. Dans tous les cas, utilisez un flux de travail publié afin que le choix porte sur la diffusion et non sur le flux lui-même.
Risques et conformité
Ces trois lois traitent les données biométriques comme une catégorie particulière. Le Nigéria nomme les images faciales et limite le traitement des données sensibles aux motifs légaux. Le Kenya considère le traitement biométrique comme présentant un risque élevé, et la loi POPIA l'interdit sauf autorisation. Prévoyez un fondement juridique, une analyse d'impact relative à la protection des données (AIPD) et une minimisation des risques.
Risques et conformité
Les signaux relatifs à l'appareil et à l'adresse IP décrivent le combiné et la connexion, et non l'utilisateur. Les émulateurs et les adresses IP de centres de données constituent des alertes importantes ; les appareils partagés, la vitesse du signal IP et la localisation IP sont des indices faibles. Utilisez-les comme confirmation et ne vous fiez à la localisation IP qu'au niveau du pays.
Mises à jour des produits
Lorsqu'une connexion semble suspecte, ne prenez pas de risques. Laissez la session se poursuivre avec des droits limités et exigez une preuve que seule la personne vérifiée peut fournir, comme un selfie récent correspondant à son inscription, avant tout paiement, changement de bénéficiaire ou réinitialisation de mot de passe.
