Passer au contenu principal

​
Workflow API d’onboarding individuel

Utilisez cette carte pour connecter la politique KYC individuelle à la référence API générée actuelle. Suivez la ressource actuelle à chaque étape plutôt que d’implémenter les étiquettes orientées politique comme une machine à états API.

​
Carte du workflow

​
1. Créer le client individuel

Créez le client avec POST /v3/customers. Stockez l’id de client renvoyé et lisez la ressource actuelle avec GET /v3/customers/{customerId}.

​
2. Découvrir et demander une capacité éligible

Lisez GET /v3/customers/{customerId}/capabilities/supported. Sélectionnez une variante uniquement lorsque sa disponibilité et son éligibilité actuelles autorisent la requête, puis utilisez POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​
3. Lire la capacité et les applications actuelles

Lisez GET /v3/customers/{customerId}/capabilities/{capabilityId} et GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications. Suivez les ids de tâche ouverts actuels plutôt que d’assumer la disponibilité d’après une réponse antérieure. Pour les capacités bancaires named, un client dispose d’un dossier d’application par banque, partagé entre les capacités compatibles. Consultez Applications partagées par banque pour les codes de réponse, selectedApplicationId et la liste des applications du client.

​
4. Récupérer le détail de la tâche actuelle

Listez les tâches client avec GET /v3/customers/{customerId}/tasks. Récupérez la surface d’action autorisée avec GET /v3/customers/{customerId}/tasks/{taskId}. Le détail de la tâche peut exposer des URL de sessions hébergées de première partie et les exigences actionnables actuelles. Utilisez sa révision et son statut actuels. Dans les tâches d’intake qui acceptent la soumission directe, les exigences éligibles déjà étayées par le profil du client ou par des documents téléversés passent automatiquement en revue. Construisez les formulaires à partir des métadonnées de chaque exigence. Consultez Afficher les exigences.

​
5. Compléter les sessions hébergées ou soumettre les réponses de tâche

Lorsque le détail de la tâche fournit une session hébergée, ne retournez que les données de session requises à votre client et gardez la clé API dans votre backend. Lorsque la tâche nécessite des réponses, créez une tentative complète immuable avec POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Lisez une soumission actuelle et son résultat public avec GET /v3/customers/{customerId}/tasks/{taskId}/submissions/{submissionId}.

​
6. Téléverser des documents uniquement lorsque demandé

Téléversez des documents uniquement lorsque la tâche actuelle les demande. Utilisez POST /v3/customers/{customerId}/documents, puis placez l’id de document renvoyé dans la réponse de document applicable.

​
7. Récupérer à nouveau les ressources actuelles

Récupérez à nouveau le client, la capacité, les applications et la tâche actuels après chaque événement ou action. Utilisez leurs derniers états, raisons, exigences et ids de tâche ouverts pour sélectionner l’étape suivante.

​
Carte des opérations générées

​
Politique et conseils d’implémentation

Le KYC simplifié, standard et renforcé sont des niveaux politiques. Ils ne remplacent pas les états actuels de capacité, d’application, de tâche, de soumission, d’exigence ou de session hébergée. Pour les détails d’implémentation, suivez le guide d’onboarding individuel, Capacités et tâches, et le guide des documents d’intégration.