Modifier un flux de vérification sans publier de nouvelle version de l'application

Monter la vérification SDK Au lieu de décrire le flux de travail directement dans le code, un identifiant de workflow est utilisé. La configuration du flux est récupérée du serveur à chaque vérification. Lorsque vous republiez le workflow dans le tableau de bord, la prochaine vérification, sur chaque instance installée de votre application, exécute la nouvelle version. Aucune nouvelle compilation, aucune validation sur la plateforme de téléchargement, aucune mise à jour forcée.

C’est ce qui permet de durcir un seuil de correspondance faciale un mardi après-midi, ou d’ajouter une étape de vérification d’adresse pour un marché donné, sans cycle de déploiement mobile. Cela ne supprime pas complètement les déploiements, et c’est la connaissance des limites qui garantit la sécurité de cette approche.

Comment le SDK obtient sa configuration

Un montage configuré via les propriétés détermine le flux dans votre code : pays, types d’identifiants, étapes exécutées, marque, texte. Toute modification de ces éléments implique une modification du code, et sur mobile, cela signifie un aller-retour sur l’App Store suivi de semaines d’utilisation des anciennes versions par les utilisateurs.

Un support de flux de travail possède un identifiant. SDK l'envoie au serveur lors du montage :

GET /api/kyc/workflows/:workflowId
Authorization: Bearer pk_…

La réponse contient la configuration publiée, les types d'identifiants activés pour votre organisation et la marque, ainsi que les SDK construit le flux à partir de cela. Selon la documentation sur les flux de travail (s’ouvre dans un nouvel onglet) , le flux de travail doit appartenir à API L'organisation et l'environnement clés seront publiés ; tout autre résultat sera indiscernable.404 workflow_not_foundet le SDK le signale paronErrorplutôt que de faire fonctionner silencieusement un flux différent.

Dans une application React Native, l'intégration complète est :

import { MyazaKYC } from "@myazahq/kyc-sdk-react-native";

<MyazaKYC
  apiKey="pk_live_…"
  workflowId="wf_AbC123dEf456"
  userId="user_42"
  userData={{ firstName: "Jane", lastName: "Doe" }}
  metadata={{ requestId: "order_1001" }}
  onSubmit={(submission) => console.log(submission.verificationId)}
  onError={(err) => console.error(err.code, err.message)}
>
  Verify Identity
</MyazaKYC>

Les paramètres du flux de travail prévalent sur toute propriété qui se chevauche. Si vous transmettez uncountryet le flux de travail en définit un, la valeur du flux de travail est utilisée.

Ce que vous pouvez changer en republiant

Tout ce qui décrit le flux plutôt que la personne :

• Pays, types de pièces d'identité et règles de validation pour chaque pièce d'identité.

• Capturez les étapes et les éléments complémentaires : codes de contact, justificatif de domicile, etc. NFC Étapes de la puce, questionnaires, capture d'adresse, identification multiple en une seule opération.

• La méthode de la présence (gestes, séquence flash d'écran ou les deux).

• Image de marque, textes de consentement et textes de vente.

• Des politiques telles que les limites d'âge et la manière dont sont traitées les informations d'identité qui ne correspondent pas.

• Le graphe de décision (s’ouvre dans un nouvel onglet) : quels résultats sont approuvés, lesquels sont soumis à un examen, lesquels sont refusés.

Voici un exemple hypothétique de ce type de changement qui devient courant : un organisme de prêt constate une série d'erreurs de correspondance entre les selfies dues à un mauvais éclairage et souhaite les examiner plutôt que de les refuser. Il ajoute une règle dans l'outil de création, la teste dans l'environnement de test et republie l'application. Chaque version déployée de l'application appliquera cette nouvelle règle dès la prochaine vérification.

Qu'est-ce qui doit encore être publié ?

Cinq éléments résident dans votre code ou votre binaire, et aucune republication ne peut les déplacer.

Données par utilisateur. userId,userDataetmetadataCe sont des valeurs d'exécution. Un flux de travail est un modèle partagé par tous ceux qui l'exécutent ; il ne peut donc pas les contenir.

Les fonctions de rappel et le traitement des résultats par votre application. Comment vous gérez ces fonctions.onSubmit,onErroret le webhook sur votre serveur, c'est votre code.

SDK versions. Un flux de travail ne peut utiliser que les fonctionnalités installées. SDK comprend. Les minimums documentés pourworkflowIdsont 2.2.0 pour le web SDK La version 2.1.0 est utilisée pour React Native et la version 2.2.0 pour Flutter. Les versions web et React Native antérieures ignorent l'identifiant et fonctionnent uniquement avec les props ; il convient donc de vérifier en premier lieu si l'intégration d'un workflow semble ne rien faire.

Fonctionnalités et autorisations natives. La lecture d'une puce de passeport nécessite React Native ou Flutter. SDK Un navigateur ne peut pas effectuer cette opération. La capture d'adresse sur iOS nécessite les chaînes de caractères d'utilisation de la localisation dans votre application, sans quoi la demande d'autorisation échouera. Si vous prévoyez d'ajouter une étape nécessitant une autorisation native, veuillez l'accorder au préalable.

L'identifiant du workflow lui-même. Les workflows sont limités à un environnement ; vos workflows de test et de production sont donc différents. Conservez cet identifiant dans la configuration plutôt que de le coder en dur : ainsi, le passage à un nouveau workflow nécessitera une modification de la configuration et non du code.

Pourquoi la modification des flux en direct reste sûre

Modifier le contenu d'un tableau de bord pour chaque utilisateur peut sembler risqué. Quatre propriétés du versionnage des flux de travail permettent de gérer cette situation.

Les brouillons sont indépendants de la version en production. Modifier un flux de travail publié ne modifie que son brouillon. Les intégrations continuent de lire le dernier instantané publié jusqu'à ce que vous en publiiez un nouveau.

Chaque publication est versionnée. Chaque publication incrémente le numéro de version et ajoute une entrée d'historique immuable que vous pouvez consulter ou à partir de laquelle vous pouvez effectuer une restauration. En cas de problème lors d'une modification, vous restaurez une version connue, sans avoir à en reconstruire une.

Les travaux en cours ne sont pas déplacés. Le lien de session par candidat conserve la configuration publiée, figée lors de sa création ; une republication ne modifie donc jamais un lien déjà présent dans la boîte de réception d'un utilisateur. Une exécution de décision est liée à sa version initiale, de sorte qu'un graphe plus strict n'entraîne pas une nouvelle décision pour une application en cours de traitement.

Chaque résultat est attribuable. Chaque vérification enregistre l'identifiant du flux de travail et la version exécutée ; ces deux informations apparaissent dans les webhooks de vérification.workflowIdetworkflowVersionConservez les deux exemplaires. Dans six mois, si quelqu'un vous demande pourquoi une demande a été approuvée selon des critères moins stricts, cette version vous indiquera précisément quelles règles ont été appliquées.

Une limitation intentionnelle : la portée d’un flux de travail, c’est-à-dire ce qu’il vérifie (par exemple, une vérification d’adresse uniquement ou une réauthentification faciale), est modifiable jusqu’à sa première publication, puis verrouillée, car les vérifications et les liens dépendent déjà de la signification de cet identifiant. Pour modifier la portée, créez une copie avec la portée définie, qui sera créée comme un nouveau brouillon sous un nouvel identifiant de flux de travail.

Déploiement d'un changement

Une modification du flux de travail est répercutée sur chaque utilisateur lors de sa prochaine vérification, ce qui est très efficace et évite un déploiement progressif par version d'application. Considérez une publication comme un déploiement :

1. Apportez la modification au flux de travail du bac à sable et testez chaque chemin concerné avec les identifiants de test publiés.

2. Vérifiez que chaque branche du graphe de décision se termine par un statut et que les autorisations natives de chaque nouvelle étape sont déjà présentes dans votre application déployée.

3. Appliquez la même modification au flux de production et publiez.

4. Consultez les premiers résultats parworkflowVersion: taux d'approbation, d'examen et de refus, et volume de la file d'attente pour les examens.

5. En cas de problème, restaurez la version précédente à partir de l'historique et publiez-la.

6. Signalez les changements à votre équipe d'assistance ; les utilisateurs remarqueront une nouvelle étape avant même que vos tableaux de bord ne la détectent.

La règle générale

Si le document décrit le flux, intégrez-le au workflow et modifiez-le par publication. S'il décrit la personne, l'appareil ou le traitement d'un résultat par votre application, il doit être intégré au code et mis à jour à chaque nouvelle version. Concevez l'intégration une seule fois autour d'unworkflowId, gardez votre SDK relativement à jour, et la plupart des versions qui étaient auparavant publiées le sont désormais.