Intégration du SDK ou lien hébergé : choisir le mode d’intégration de la vérification

Intégrer le SDK Lorsque la vérification a lieu au sein de votre produit, à un moment où l'utilisateur y accède dans sa session, envoyez un lien externe. Lorsqu'elle a lieu en dehors de celui-ci (par exemple, un agent de crédit qui demande des documents, un commerçant qui est intégré par e-mail ou un client invité à revérifier ses informations plusieurs mois après son inscription), envoyez un lien externe. C'est la règle générale, et la plupart des équipes finissent par avoir besoin des deux.

Ce qui rend ce choix économique, c'est la création unique du flux sous forme de workflow publié . Une intégration le monte par son identifiant, un lien exécute le même instantané publié, et les contrôles, la marque et les règles de décision sont identiques. Vous choisissez une interface de diffusion, et non un second flux de vérification à maintenir.

Quelle est la différence réelle entre les deux ?

Les deux parcours aboutissent au même résultat. Le candidat finalise la capture, la plateforme traite la vérification de manière asynchrone et votre système reçoit le résultat via un webhook (s’ouvre dans un nouvel onglet) ou une requête d'état. La différence réside dans l'élément qui initie le processus et dans les actions contrôlées par votre code.

C'est la dernière ligne qui pose souvent problème. Avec un workflow, aucune modification de code n'est nécessaire pour ajuster le flux. Sans workflow, l'intégration implique de spécifier le pays, les types d'identifiants et les options d'activation/désactivation des étapes via les propriétés, et chaque modification entraîne l'établissement d'une nouvelle version.

Quand le SDK L'intégration est le bon choix.

Intégrez cette fonctionnalité lorsque la vérification fait partie d'un parcours que vous contrôlez et que l'utilisateur est déjà connecté. Une application de portefeuille qui vérifie l'utilisateur avant son premier transfert, ou une plateforme de vente qui vérifie les vendeurs avant leur première annonce, en sont de bons exemples.

Vous obtenez trois choses qu'un lien ne peut pas vous offrir.

Fonctions de rappel dans votre propre code.SDK appelsonSubmitavec unverificationIdDès que la vérification est créée, vous pouvez déplacer l'utilisateur vers un écran d'attente sans attendre un webhook.onErrorsignale des défaillances techniques (réseau, autorisation d'accès à la caméra, type d'identifiant désactivé) avec une stabilitécode.

Compatibilité native avec les appareils. Les SDK React Native et Flutter (s’ouvre dans un nouvel onglet) lisent les puces Passport via NFC et exécuter la fonction de surveillance en direct sur l'appareil. Les navigateurs ne peuvent pas communiquer avec une puce de passeport, donc le web SDK L'écran de la puce n'apparaît que dans l'aperçu du générateur de tableau de bord.

Une identité que vous possédez déjà. Vous réussissez.userIdetuserDataà partir de votre session, la vérification est donc liée à un compte connu et le nom que vous possédez est comparé au document.

Un élément web minimal intégré, tiré de SDK documentation:

<MyazaKYC
  apiKey="pk_live_…"
  workflowId="wf_AbC123dEf456"
  userId="user_42"
  metadata={{ requestId: "order_1001" }}
  onSubmit={(s) => console.log(s.verificationId)}
/>

Les coûts sont réels, mais modestes. Vous ajoutez une dépendance, vous la maintenez à une version égale ou supérieure aux versions minimales requises.workflowId(web 2.2.0, React Native 2.1.0, Flutter 2.2.0 ou version ultérieure), et sur React Native, vous avez besoin d'une version de développement personnalisée car le SDK code natif des navires.

Quand un lien hébergé est le bon choix

Envoyez un lien lorsque la personne à vérifier n'est pas connectée à votre application au moment où vous en avez besoin. Voici quelques exemples :

• Un prêteur commercial en recouvrement KYC De la part d'un réalisateur qui ne s'est jamais connecté à quoi que ce soit.

• Une équipe opérationnelle revérifie le document d'un client qui a expiré.

• Une plateforme sans application mobile, qui vérifie les utilisateurs arrivant par e-mail.

• Un canal partenaire sur lequel il est totalement impossible de distribuer du code.

Il existe deux types de liens, et choisir entre eux est plus important que de choisir entre un lien et une intégration.

Liens vers les sessions par candidat

Lorsque vous savez qui doit vérifier, créez une session depuis votre serveur avecPOST /api/kyc/sessions (s’ouvre dans un nouvel onglet)et une clé secrète :

curl "https://api.toden.co/api/kyc/sessions" \
  -H "Authorization: Bearer $MYAZA_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflowId": "wf_AbC123dEf456",
    "externalUserId": "user_42",
    "userData": { "firstName": "John", "lastName": "Doe" }
  }'

La réponse comporte unurlqui appartient à ce candidat. Il est à usage unique et traçable jusqu'à votre compte.externalUserIdet est dépensé une fois soumis, donc le transmettre à une deuxième personne ne fonctionne pas. Vous pouvez transmettreemailpour que le lien soit envoyé en votre nom, ou transmettez-le vous-même.

Les visiteurs d'une page hébergée sur un ordinateur se voient proposer un code QR « Continuer sur votre téléphone » pour les étapes de prise de vue, de sorte qu'un lien envoyé par courriel à une personne utilisant un ordinateur portable parvient tout de même à être filmé. (Le Web) SDK possède la même fonction de transition sur ordinateur de bureau, contrôlée par sondeviceHandoffoption.)

Deux détails à prendre en compte. Le lien cesse d'accepter un nouveau départ àexpiresAt24 heures pour les flux individuels et 7 jours pour les flux métier, sauf si le workflow définit sa propre durée de vie de session. La configuration utilisée par le demandeur correspond à l'instantané publié lors de la création du lien ; une republication ne modifie donc jamais un lien déjà présent dans la boîte de réception d'un utilisateur.

Liens partagés hébergés

Chaque flux de travail publié peut également être activé en tant que flux de travail public. URL Ce système permet à de nombreuses personnes d'ouvrir le lien, chaque visite déclenchant sa propre vérification. Il convient à une campagne ou à un code QR sur un comptoir, où l'on ignore véritablement qui se présentera. Le compromis réside dans l'attribution : le lien ne renvoie à aucun utilisateur de votre système, vous devez donc justifier les résultats d'une autre manière. La régénération du lien depuis la page du flux de travail supprime l'ancienne méthode. URL Vous pouvez immédiatement intervenir si le message se propage plus largement que prévu. Si vous connaissez la personne, optez pour une séance.

La voie du milieu : un lien hébergé dans votre application

Certaines équipes souhaitent que la page soit hébergée par nos soins mais ouverte dans leur propre application mobile, généralement pour éviter une dépendance native. Cela fonctionne. Ouvrez la session.urldansreact-native-webview,webview_flutterou une iframe, et la page signale sa progression à l'hôte sous forme d'événements de liens hébergés (s’ouvre dans un nouvel onglet) :ready,started,step,submitted,completed,erroretclosed.

<WebView
  source={{ uri: session.url }}
  onMessage={(event) => {
    const message = JSON.parse(event.nativeEvent.data);
    if (message.source !== 'myaza-kyc') return;
    if (message.type === 'submitted') {
      navigation.replace('VerificationPending', { id: message.verificationId });
    }
  }}
/>

Connaissez les limites avant de faire votre choix. NFC La lecture de la puce, les vérifications de présence en arrière-plan et la disponibilité immédiate ne sont pas disponibles dans une WebView. Les événements contiennent des identifiants, des noms d'étapes et des codes d'erreur, jamais aucune information saisie par l'utilisateur ; ils servent uniquement à l'affichage dans votre interface et ne constituent pas un enregistrement. Le verdict est toujours obtenu via votre webhook ou un sondage d'état.

Dans une iframe, ajoutez l'origine de votre page comme unoriginParamètre de requête. La page envoie des événements uniquement lorsque le navigateur confirme qu'il s'agit bien de la page intégrant le contenu, et n'envoie rien dans le cas contraire.

Une décision travaillée

Prenons l'exemple d'un organisme de crédit à la consommation fictif disposant d'une application mobile et d'une équipe commerciale terrain. Les nouveaux clients effectuent une vérification au sein de l'application avant leur premier prêt ; l'application intègre donc React Native. SDK avec un flux de travail publié qui inclut la lecture de la puce du passeport. Les agents de terrain intègrent les traders sur les marchés qui n'ont pas encore installé l'application ; le système crée donc une session par trader avec l'identifiant principal du trader commeexternalUserIdet l'agent envoie le lien par SMS Les clients dont l'identifiant expire ultérieurement reçoivent un nouveau lien de session de la part du service des opérations.

Un seul flux de travail pourrait gérer les trois, ou le prêteur pourrait opter pour un flux de travail plus léger pour les liens de terrain. Dans tous les cas, chaque résultat aboutit au même gestionnaire de webhook, identifié parverificationIdet portant les propres intérêts du prêteurexternalUserId.

La règle de décision

1. Créez le flux sous forme de workflow publié avant de choisir une surface.

2. Si l'utilisateur est connecté à votre produit au moment de la vérification, intégrez le SDK Utilisez un natif SDK si vous avez besoin NFC Lecture de la puce.

3. Si la vérification a lieu en dehors de votre produit et que vous connaissez la personne, créez une session par candidat depuis votre système.

4. N’utilisez un lien partagé que si vous ne savez pas qui l’ouvrira, et prévoyez comment vous attribuerez les résultats.

5. Si vous souhaitez une page hébergée dans votre application, ouvrez la session. URL dans une WebView et écouter les événements de lien hébergé, en acceptant la perte de lecture de la puce et de la vivacité native.

6. Quel que soit votre choix, considérez le webhook comme la source de vérité et le signal côté client comme une indication.