Accéder directement au contenu
Créez un compte ou connecter-vous
Logo de la documentation Stripe
/
Demander à l'assistant IA
Créez un compteConnectez-vous
Démarrer
Paiements
Revenus
Plateformes et marketplaces
Gestion de fonds
Ressources pour les développeurs
API et SDKAide
Aperçu
Démarrer avec Connect
    Fonctionnement de Connect
    Connect et l’API Accounts v2
    Plateformes et marketplaces SaaS
    Gestion des risques avec Connect
    Comprendre la notion de marchand officiel
    Migrer vers les propriétés du contrôleur de comptes
    Comparer les configurations de plateforme SaaS pour Accounts v1 et Accounts v2
    Prochaines modifications des exigences
    Guide de démarrage rapide sur l'inscription des utilisateurs
Concevoir votre intégration
Principes de base de l'intégration
Exemples d'intégration
Gestion de compte
Inscrire des comptes
Configurer les dashboards des comptes
Fonctionnalités et exigences en matière d’informations
Utiliser les types de comptes connectés
Traitement des paiements
Accepter des paiements
Effectuer des virements vers des comptes
Administration de plateforme
Gérer votre plateforme Connect
Formulaires fiscaux pour votre plateforme Connect
États-Unis
Français (France)
AccueilPlateformes et marketplacesGet started with Connect

Prochaines mises à jour des exigences

Découvrez les modifications apportées aux informations de vérification requises et leur impact sur votre intégration avec Stripe.

Les mises à jour des exigences de ce guide font référence aux propriétés de l’API Accounts v1. Vous pouvez voir les propriétés correspondantes de l’API Accounts v2 dans Informations de vérification requises en sélectionnant v2 dans la liste déroulante API Accounts et la mise à jour souhaitée dans la liste déroulante Mise à jour des exigences.

Les réglementations en matière de paiement contribuent à prévenir les délits tels que le blanchiment d’argent, la fraude et l’évasion fiscale. Les autorités de régulation financière du monde entier appliquent les exigences Connaître votre client (KYC) afin de s’assurer que Stripe collecte, vérifie et conserve les informations d’identité de certains types d’entreprises et des personnes qui les possèdent, les contrôlent ou les dirigent en dernier ressort. Ces exigences sont fréquemment mises à jour par les autorités de régulation des services financiers, les réseaux de cartes et d’autres institutions financières.

Ce guide fournit un aperçu des changements à venir et met en évidence les changements les plus importants. Pour obtenir la liste complète des exigences, consultez la page Informations de vérification requises.

Si vous utilisez un flux établi basé sur une API pour inscrire vos comptes connectés, vous devez mettre à jour votre intégration pour gérer toutes les modifications des exigences. En savoir plus sur les options d’onboarding Connect et la migration de vos flux d’intégration et de correction basés sur une API vers des flux hébergés ou intégrés par Stripe.

Dernière mise à jour : 23 février 2026

Comprendre les changements apportés aux exigences en matière de vérification

Afin de se conformer aux réglementations de l’Autorité de conduite financière (FCA) du Royaume-Uni et de la Banque centrale d’Irlande (CBI), Stripe met à jour ses exigences en matière de vérification de la connaissance du client ainsi que des bénéficiaires effectifs finaux (BEF) et des administrateurs.

Si vos comptes connectés exercent leurs activités dans l’un des pays répertoriés, vous devrez peut-être mettre à jour votre flux d’inscription des utilisateurs. Le fait de ne pas effectuer les mises à jour requises perturbera l’accès de vos comptes connectés aux paiements et aux services financiers.

Pour en savoir plus sur les changements et leurs raisons, consultez l’article d’assistance sur les nouvelles exigences de conformité.

Les changements à venir concernent les comptes connectés dans les pays suivants :

Allemagne
Autriche
Belgique
Bulgarie
Chypre
Croatie
Danemark
Espagne
Estonie
Finlande
France
Gibraltar
Grèce
Hongrie
Irlande
Islande
Italie
Lettonie
Liechtenstein
Lituanie
Luxembourg
Malte
Norvège
Pays-Bas
Pologne
Portugal
République tchèque
Roumanie
Royaume-Uni
Slovaquie
Slovénie
Suède
Suisse

Mises à jour permanentes

Stripe continuera de mettre à jour l’API pour prendre en charge la collecte de ces exigences jusqu’au 1er avril 2026.

Choisir une approche d’intégration

Stripe recommande d’utiliser l’inscription des utilisateurs hébergée par Stripe ou intégrée pour collecter les exigences en matière d’entreprise et de vérification d’identité. Ces options nécessitent moins de ressources pour leur mise en œuvre et leur maintenance que l’inscription des utilisateurs via l’API. Le tableau suivant décrit les principales différences :

  • Inscription des utilisateurs hébergée par Stripe: Recommandé Envoyez les comptes vers un flux hébergé par Stripe pour soumettre les informations requises.
  • Inscription des utilisateurs intégrée: Recommandé Intégrez des composants d’inscription des utilisateurs fournis par Stripe permettant aux comptes de soumettre des informations directement à Stripe depuis votre application.
  • API d’inscription des utilisateurs: Créez et gérez un flux d’inscription des utilisateurs personnalisé à l’aide des API de Stripe.
Inscription des utilisateurs hébergée par StripeInscription des utilisateurs intégréeInscription des utilisateurs via l’API
Idéal pourPlateformes qui souhaitent que Stripe s’occupe de l’inscriptionPlateformes qui souhaitent disposer d’un flux d’intégration intégré à l’application et adapté à leur marqueDes plateformes qui ont besoin d’un contrôle total et qui peuvent le créer et le maintenir.
Premier effort de mise en œuvre3 à 4 semaines d’ingénierie3 à 4 semaines d’ingénierie30 à 40 semaines d’ingénierie
Efforts continus pour répondre aux mises à jour des exigencesTraitement automatique assuré par StripeTraitement automatique assuré par StripeNécessite une surveillance proactive des changements à venir, ainsi que des ressources techniques pour mettre à jour le flux d’inscription des utilisateurs pour chaque changement
PersonnalisationInterface hébergée par Stripe avec adaptation à la marque de la plateformeComposant hautement personnalisable qui gère les accès via l’application de la plateforme.La plateforme conçoit, développe et assure la maintenance de l’interface
Effort visant à soutenir d’autres paysTraitement automatique assuré par StripeTraitement automatique assuré par StripeNécessite des ressources techniques pour mettre à jour le flux d’inscription des utilisateurs pour chaque pays supplémentaire

En savoir plus sur les options d’onboarding Connect et la migration de vos flux d’onboarding et de rectification basés sur des API vers des flux hébergés ou intégrés par Stripe.

Les modifications que vous apportez à votre flux d’inscription des utilisateurs dépendent de la manière dont vous collectez les informations relatives à l’inscription des utilisateurs. En plus de mettre à jour votre flux d’inscription des utilisateurs, mettez à jour votre documentation interne et externe si nécessaire, et préparez vos équipes d’assistance à répondre aux questions sur les mises à jour.

Si vous utilisez l’inscription des utilisateurs hébergée par Stripe ou intégrée, vous n’avez pas besoin de mettre à jour votre intégration pour vous préparer à ces mises à jour des exigences. Cependant, vous pouvez informer vos comptes connectés que Stripe pourrait demander des informations d’identité nouvelles ou mises à jour lorsque les exigences changeront.

Vue d’ensemble de l’intégration API

Si vous choisissez de ne pas migrer vers l’inscription des utilisateurs hébergée ou intégrée par Stripe, vous devez traiter les mises à jour suivantes :

  • Vérification de la connaissance du client (KYC)
  • Vérification du lien entre le bénéficiaire effectif final (BEF) et l’administrateur
  • Exigences en matière d’immatriculation des entreprises aux Pays-Bas (KvK)
  • Nouveaux codes d’erreur

Chronologie actualisée

La chronologie suivante présente les étapes clés de ces changements. Veillez à mettre à jour et à tester votre intégration le plus tôt possible afin d’éviter tout problème lorsque les nouvelles exigences entreront en vigueur.

DateÉtape importanteDescription
Octobre 2025Commencer la planification de l’intégrationLes premières mises à jour de l’API sont disponibles. Vérifiez ce guide et les modifications apportées pour commencer à planifier vos mises à jour d’intégration.
Février 2026Vérifiez les comptes concernés et testez vos mises à jour d’intégration.Stripe fournit une estimation du nombre de vos comptes connectés concernés. Commencez à tester votre parcours d’onboarding mis à jour.
Mars 2026Début du déploiement de future_requirements (onboarding via l’API)Pour les plateformes utilisant l’onboarding API, Stripe commence à ajouter les nouvelles exigences à future_requirements pour les comptes nouveaux et existants.
1er avril 2026Nouvelles exigences pour les comptes connectés dont le type de l’entreprise est individualAssurez-vous que votre flux d’onboarding mis à jour est prêt à collecter les nouvelles exigences pour les comptes dont le type d’entreprise est individual. Bien que Stripe invalidera les nouvelles exigences au fil du temps, nous ne garantissons pas la date d’entrée en vigueur pour un compte donné. Votre flux mis à jour doit être fonctionnel pour les comptes individual avant le 1er avril.
1er mai 2026Nouvelles exigences pour les comptes connectés dont le type de l’entreprise est companyAssurez-vous que votre flux d’onboarding mis à jour est prêt à collecter les nouvelles exigences pour les comptes dont le type d’entreprise est company. Bien que Stripe invalidera les nouvelles exigences au fil du temps, nous ne garantissons pas la date d’entrée en vigueur pour un compte donné. Votre flux mis à jour doit être fonctionnel pour les comptes company avant le 1er mai.
Avril 2026 – début juillet 2026De nouvelles exigences s’appliquent actuellement aux comptes existantsLes nouvelles exigences sont déployées sur les comptes connectés existants pendant cette période. Utilisez votre flux d’inscription des utilisateurs mis à jour pour les collecter le cas échéant.
Juillet – octobre 2026Dates d’échéance des nouvelles exigencesPour éviter les restrictions, les exigences mises à jour pour chaque compte doivent être vérifiées avant la date d’échéance de ce compte.

Vérification de type connaître votre client (KYC)

Stripe renforce notre processus de vérification de l’identité, ce qui pourrait obliger certains de vos comptes connectés à fournir des informations supplémentaires. Nous ajoutons également d’autres options à l’API pour la vérification des informations.

Les entités suivantes doivent fournir des informations KYC vérifiables :

  • Personne morale (pour les entrepreneurs individuels et les sociétés unipersonnelles) ;
  • Représentant du compte
  • BEF et administrateurs (pour les comptes jugés à haut risque par le modèle de risque de Stripe).

Méthodes de vérification supplémentaires

Vous pouvez améliorer les taux de réussite de la vérification en utilisant les méthodes suivantes en plus des informations saisies standard :

  • Vérification nationale d’identité : Recommended Collectez un numéro national d’identité dès le départ pour augmenter les taux de vérification en première passe.
  • Stripe Identity : capture de selfies et de documents pour les comptes dont la vérification automatique échoue.
  • Chargement de pièces supplémentaires : soumettre des pièces d’identité ou des justificatifs d’adresse pour vérifier manuellement.

Stripe Identity Recommandé

Vous pouvez tenter de vérifier les comptes connectés dont la vérification automatique a échoué à l’aide de Stripe Identity. Identity fonctionne en capturant un selfie et une pièce d’identité. La plupart des pays européens prennent en charge Stripe Identity, et les taux de réussite varient selon les pays.

Créez une session de vérification de l’identité et utilisez le paramètre personne_liée pour soumettre les exigences en matière de documents et de preuve_de_vie pour la personne. Vous pouvez vérifier les résultats à l’aide de l’API ou du Dashboard.

Vérification de l’identité nationale Version bêta publique

Dans les pays concernés par cette mise à jour, vous pouvez améliorer la vérification d’un représentant de compte connecté en fournissant son numéro d’identification national en plus de son nom, de sa date de naissance, de son adresse et de sa nationalité.

À l’heure actuelle, la vérification prend uniquement en charge les numéros d’identification nationaux suivants.

PaysType de pièce d’identité nationale
DanemarkRegistre central des personnes (CPR)
ItalieCodice Fiscale (code fiscal)
PologneNuméro PESEL
EspagneDocumento Nacional de Identidad (DNI)
SuèdePersonnummer (numéro d’identification personnel)

Vous pouvez fournir des numéros d’identification nationaux uniquement pour les comptes connectés dans les pays concernés par cette mise à jour. Par exemple, vous pouvez fournir le numéro d’identification d’un citoyen espagnol agissant en tant que représentant pour un compte connecté en Autriche, mais vous ne pouvez pas fournir le numéro d’identification d’un citoyen espagnol agissant en tant que représentant pour un compte connecté aux États-Unis.

Disponibilité de la carte d'identité nationale

Cette intégration sera disponible en production lorsque les exigences mises à jour deviendront des exigences futures. Utilisez l’exemple suivant pour tester votre intégration.

Mettre en œuvre la vérification de l'identité nationale à l'aide de l'API

L’exemple suivant illustre l’inscription d’un nouveau compte connecté avec les nouvelles exigences.

Remarque

Les différences ci-dessous n’affectent que l’API Accounts v1, et non v2.

Étape 1 : créer un compte connecté

Une fois les nouvelles exigences mises en place, créez des comptes connectés comme d’habitude. D’ici là, créez de nouveaux comptes connectés en mode test afin d’activer le nouveau comportement KYC.

Déclenchez ce comportement en modifiant deux parties de votre appel de création de compte :

  1. Ajoutez l’en-tête experimental_onboarding_preview=v2.
  2. Soumettez capabilities[card_payments][preview]=true.

Une fois le compte créé, une nouvelle chaîne d’exigences representative.nationality s’affiche. Cela indique que vous pouvez créer un représentant de compte et transmettre la nationalité.

// Creating a connected account in Spain > curl https://api.stripe.com/v1/accounts \ -u sk_test_123 \ -H "Stripe-Version: 2025-08-27.basil;experimental_onboarding_preview=v2" \ -d 'type'='custom' \ -d 'country'='ES' \ -d 'capabilities[card_payments][requested]'='true' \ -d 'capabilities[card_payments][preview]'='true' \ -d 'capabilities[transfers][requested]'='true' { "id": "acct_1Nv0FGQ9RKHgCVdB", ... "requirements": { "past_due": [ ... "representative.nationality", ... ] } ... }

Étape 2 : créer un représentant du compte

Après avoir créé le compte connecté, créez un représentant du compte.

> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/persons \ -u sk_test_123: \ -d first_name=John \ -d last_name=Doe { "id": "person_1N9XNb2eZvKYlo2CjPX7xF6B", ... }

Étape 3 : soumettre la nationalité

Après avoir créé un représentant de compte, la nationality apparaît en tant que past_due. Collectez ce champ pour que Stripe puisse déterminer si le représentant est admissible au recouvrement id_number.

> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { ... "requirements": { "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", ...other person requirements... "person_1N9XNb2eZvKYlo2CjPX7xF6B.nationality" ] } ... }

Une fois la nationalité collectée, si la personne se trouve dans un pays admissible, vous verrez les paramètres past_due et alternatives, ce qui indique que la collecte d’une pièce d’identité nationale est recommandée, mais non obligatoire.

> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/persons/person_1N9XNb2eZvKYlo2CjPX7xF6B \ -u sk_test_123: \ -d nationality=ES > curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { "requirements": { "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", ...other person fields... ], "alternatives": [ { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", ...other person fields... ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" ] } ] } }

Étape 4 : rassembler les champs restants relatifs au représentant commercial

Collectez des attributs supplémentaires sur les personnes, y compris un numéro d’identification national, pour lancer la vérification KYC programmatique.

> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/persons/person_1N9XNb2eZvKYlo2CjPX7xF6B \ -u sk_test_123: \ -d 'id_number'='74362315-A' \ ...other person fields...

Étape 5 : les champs saisis sont mis en attente de vérification

Une fois que vous avez fourni les données saisies, les champs apparaissent à l’état pending_verification d’une nouvelle manière :

  • Les champs saisis entrent dans pending_verification plutôt que dans verification.document et verification.additional_document. Cela indique que les champs saisis sont en cours de vérification.
  • L’exigence id_number peut passer à l’état de pending_verification si elle est fournie, même si elle n’apparaît que dans alternative_fields_due et jamais dans past_due ou currently_due.
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/ -u sk_test_123: { "requirements": { "pending_verification": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.city", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.line1", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.postal_code", "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.day", "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.month", "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name" ], } }

Étape 6 : gérer les erreurs de vérification

Dans de nombreux cas, une fois que les champs ont été saisis dans pending_verification, le représentant transmet la KYC et le processus est terminé.

Si la vérification échoue, Stripe renvoie des informations supplémentaires pour vous aider à déterminer les étapes suivantes.

Il y a deux changements importants.

Plusieurs alternatives

Dans le hachage des exigences, vous verrez plusieurs alternatives. Chacune d’entre elles représente une piste à explorer pour vos utilisateurs.

Par exemple, si le nom et la date de naissance correspondent mais que le nom et l’adresse ne correspondent pas, votre compte connecté dispose de plusieurs moyens pour résoudre le problème :

  1. Ils peuvent vérifier le nom et l’adresse, puis saisir à nouveau ces informations pour corriger d’éventuelles erreurs.
  2. Ils peuvent vérifier que les informations saisies ne contiennent pas le numéro de téléphone, le nom, l’adresse et l’id_number, et saisir à nouveau les informations correctes.
  3. Ils peuvent charger un document correspondant à leur nom et à leur adresse
  4. Ils peuvent compléter Stripe Identity

Ces quatre chemins apparaissent sous la forme de champs de type past_due et d’alternatives :

> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { "requirements": { // 1. They can check the information they've entered for dob, name, and address, and re-enter the correct information. "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*", ], "alternatives": [ // 2. They can check the information they entered for dob, name, address and id_number and re-key correct information. { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*", ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" ] }, // 3. They can upload document that matches their name and address { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.verification.additional_document" ] }, // 4. They can complete Stripe Identity { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*" ], "person_1N9XNb2eZvKYlo2CjPX7xF6B.proof_of_liveness" ] }, ] } }

Erreurs sur les champs saisis Auparavant, si une erreur de vérification se produisait lors du traitement des champs saisis, les champs du document passaient à l’état past_due et des erreurs apparaissaient sur ceux-ci. À l’avenir, les champs saisis revenaient à l’état past_due. Les champs comme id_number restaient dans alternative_fields_due.

Par exemple, si le nom, la date de naissance et l’adresse sont initialement past_due, et qu’après soumission, le nom et la date de naissance correspondent alors que le nom et l’adresse ne correspondent pas, alors le nom et l’adresse reviennent à l’état past_due tandis que la date de naissance est supprimée.

Dans ce cas, des erreurs apparaissent dans les champs past_due et alternative_fields_due.

> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { "requirements": { "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternatives": [ { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" ] }, { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.proof_of_liveness" ] }, { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.verification.additional_document" ] } ] "errors": [ { "code": "verification_failed_keyed_in_mismatch", "reason": "Identity information could not be verified." "requirement": "person_1N9XNb2eZvKYlo2CjPX7xF6B.name" }, { "code": "verification_failed_keyed_in_mismatch", "reason": "Identity information could not be verified." "requirement": "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" }, { "code": "verification_failed_keyed_in_mismatch", "reason": "Identity information could not be verified." "requirement": "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" } ] } }

Vérification des relations pour les BEF et les administrateurs

Stripe améliore son processus de vérification des bénéficiaires effectifs finaux (BEF) et des administrateurs. La réglementation européenne exige la vérification de la relation entre les BEF et les administrateurs et l’entité juridique.

  • BEF : Un entrepreneur individuel qui possède ou contrôle (directement ou indirectement) plus de 25 % d’une entité juridique (par exemple, des sociétés, des sociétés de capitaux, des SARL et des sociétés en nom collectif).
  • Administrateur : Membre du conseil d’administration ou cadre supérieur responsable de la gestion d’une entreprise (par exemple, PDG, directeur des opérations, directeur général).

Le tableau suivant présente les relations qui doivent être vérifiées pour chaque type d’entité juridique :

Type d’entité juridiqueRelations à vérifierRemarque
Entreprise, société, LLC, société de personnesBEF s’il y en a, sinon, administrateursRoyaume-Uni uniquement : les BEF et les administrateurs
Association à but non lucratifReprésentantsLes organisations à but non lucratif n’ont normalement pas de BEF.
Agence gouvernementale, entité gouvernementale, particulier, entrepreneur individuel, société cotée en bourseN/AVérification d’identité uniquement

Vérifier les informations concernant les bénéficiaires effectifs (UBO) et les directeurs

Stripe tente de vérifier le lien de la personne en comparant les principales caractéristiques de cette personne avec celles de l’entité juridique.

EntitéPropriétés clés
Personne
  • Prénom
  • Nom
  • Numéro d’identification
Entité juridique
  • Nom
  • Adresse
  • Numéro fiscal
  • Numéro de TVA
  • Numéro d’immatriculation

Une vérification réussie peut nécessiter uniquement la correspondance d’un sous-ensemble des informations.

Stripe tente de vérifier les liens de la manière suivante :

MéthodeDescriptionExigences types
Fournisseur tiersSi un fournisseur tiers est disponible, Stripe tente automatiquement de vérifier l’ensemble des liens sur le compte.
  • owners.first_name
  • owners.last_name
  • company.tax_id
Document officielVous pouvez fournir un document « Attestation de bénéficiaires effectifs » pour les propriétaires et un document « Preuve d’immatriculation » pour les directeurs. Les documents acceptés varient selon le pays.
  • owners.first_name
  • owners.last_name
  • company.name
  • company.address.line1
  • company.address.city
  • company.address.state
  • documents.proof_of_ultimate_beneficial_ownership
Attestation numériqueVous pouvez utiliser les modèles PDF suivants pour fournir des attestations numériques relatives aux liens :
  • Modèle d’attestation numérique de bénéficiaires effectifs
  • Modèle d’attestation numérique du directeur
  • owners.id_number
  • company.tax_id
  • documents.proof_of_ultimate_beneficial_ownership
  • documents.proof_of_ultimate_beneficial_ownership.signer

Identifier les exigences de vérification des liens à l’aide de l’API

Lorsque vous récupérez les exigences d’un Account, les options de vérification principales et alternatives correspondent à des combinaisons d’informations clés et de méthodes de vérification disponibles. Dans la plupart des cas, il existe au moins trois options pour vérifier les propriétaires effectifs ou les directeurs.

Le code suivant présente un exemple de compte connecté comportant des exigences relatives aux propriétaires. Les options proposées ainsi que leur ordre peuvent varier d’un compte à l’autre.

// Example with owner requirements > curl https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: { "id": "acct_1234", "past_due": { // third-party provider option "currently_due": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.tax_id" ], "alternatives": [ { "original_fields_needed": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.tax_id" ], // official document option "alternative_fields_needed": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.name", "company.address.line1", "company.address.state", "company.address.city", "documents.proof_of_ultimate_beneficial_ownership.files" ], }, { "original_fields_needed": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.tax_id" ], // digital attestation option "alternative_fields_needed": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.name", "company.address.line1", "company.address.state", "company.address.city", "documents.proof_of_ultimate_beneficial_ownership.files", "documents.proof_of_ultimate_beneficial_ownership.signer" ], } ] } }

Vérifier les directeurs au lieu des propriétaires

Si un compte connecté est autorisé à fournir des directeurs à la place des propriétaires, il inclut des options alternatives pour vérifier les directeurs. Si vous vérifiez les directeurs, vous devez néanmoins attester que vous avez fourni 0 attestations de bénéficiaires effectifs.

L’exemple suivant présente un compte connecté autorisé à vérifier les directeurs au lieu des propriétaires :

// Example with owner requirements > curl https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: { "id": "acct_1234", "past_due": { // third-party provider option for owners "currently_due": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.tax_id" ], "alternatives": [ ..., { "original_fields_needed": [ "owners.first_name", "owners.last_name", "company.owners_provided", "company.tax_id" ], // third-party provider option for directors "alternative_fields_needed": [ "directors.first_name", "directors.last_name", "company.directors_provided", "company.owners_provided", "company.tax_id" ], } ] } }

Si vous fournissez les informations relatives aux directeurs et attestez avoir fourni 0 attestations de bénéficiaires effectifs, les exigences principales continuent d’indiquer des exigences relatives aux propriétaires. Vous pouvez fournir des informations sur les bénéficiaires effectifs si elles deviennent disponibles.

L’exemple suivant présente un compte connecté avec une attestation de 0 attestations de bénéficiaires effectifs :

// Example with owner requirements > curl https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: { "id": "acct_1234", "past_due": { // third-party provider option for owners "currently_due": [ "owners.first_name", "owners.last_name", // company.owners_provided is no longer a requirement "company.tax_id" ], "alternatives": [ ..., { "original_fields_needed": [ "owners.first_name", "owners.last_name", "company.tax_id" ], // third-party provider option for directors "alternative_fields_needed": [ "directors.first_name", "directors.last_name", "company.directors_provided", "company.tax_id" ], } ] } }

Gestion des erreurs

Les erreurs liées aux exigences relatives aux propriétaires et aux directeurs peuvent inclure les valeurs de code suivantes, en plus des erreurs courantes d’incohérence entre le document et les informations fournies.

CodeDescription
verification_missing_ownersLe Account ne comporte pas les informations relatives aux propriétaires effectifs identifiés par un fournisseur tiers ou figurant dans un document ou une attestation numérique.
verification_missing_directorsLe Account ne comporte pas les informations relatives aux directeurs identifiés par un fournisseur tiers ou figurant dans un document ou une attestation numérique.
verification_data_not_foundUn fournisseur tiers n’a pas pu trouver d’informations relatives à l’entreprise.

Vous pouvez parfois résoudre ces erreurs en mettant à jour les informations relatives à l’entreprise. Toutefois, dans la plupart des cas, vous devez orienter le compte connecté vers la voie de téléversement de documents ou vers la voie d’attestation numérique.

Lorsque Stripe identifie des propriétaires ou des directeurs manquants, une API en version bêta privée peut, dans certains cas, fournir des données les concernant. Le compte connecté peut utiliser ces données pour créer les Persons manquantes.

Mettre en place l'attestation numérique pour la vérification des BEF et des administrateurs à l'aide de l'API

Disponibilité

L’API Accounts v2 ne prend pas encore en charge l’attestation numérique.

L’exemple suivant montre comment effectuer une attestation numérique pour la vérification du BEF ou de l’administrateur.

  1. Récupérez le compte pour identifier les documents d’attestation requis.

    // Check for UBO attestation requirement > curl https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: // Response showing UBO attestation { "id": "acct_1234", "requirements": { "past_due": [ "documents.proof_of_ultimate_beneficial_ownership.files", "documents.proof_of_ultimate_beneficial_ownership.signer", ], "errors": [] } } // Or for directors & officers requirement { "id": "acct_1234", "requirements": { "past_due": [ "documents.proof_of_registration.files", "documents.proof_of_registration.signer" ], "errors": [] } }

L’option relative aux exigences d’attestation numérique peut apparaître comme option principale ou comme alternative à une autre option. Les options proposées ainsi que leur ordre peuvent varier d’un compte à l’autre.

  1. Générez un PDF à l’aide du modèle et demandez à une personne autorisée de le signer numériquement.

  2. Chargez le document d’attestation signé à l’aide de l’API File.

    curl -X POST https://files.stripe.com/v1/files \ -u sk_test_123: \ -F purpose=account_requirement \ -F file=@signed_attestation.pdf // Response { "id": "file_1234567890", "object": "file", "purpose": "account_requirement" }
  3. Soumettez le document en indiquant l’identifiant de la Person représentant le signataire.

    // For UBO attestation curl -X POST https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: \ -d "documents[proof_of_ultimate_beneficial_ownership][files][]=file_1234567890" \ -d "documents[proof_of_ultimate_beneficial_ownership][signer][person]=person_xyz" // For D&O attestation curl -X POST https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: \ -d "documents[proof_of_registration][files][]=file_1234567890" \ -d "documents[proof_of_registration][signer][person]=person_xyz"

Exigences de validation des signataires

Qui peut signer les attestations

  • Représentants du compte
  • Propriétaires d’entreprise (propriété de plus de 25 %)
  • Directeurs et dirigeants
  • Autres membres autorisés du compte

Important : le signataire doit être une personne réelle associée au compte. Seules les personnes ayant un lien documenté avec l’entité juridique peuvent signer des documents d’attestation.

Gestion des erreurs

L’attestation numérique introduit des scénarios d’erreur spécifiques que vous devez gérer :

Signataire non valide

Se produit lorsque le signataire n’est pas associé au compte ou ne dispose pas des autorisations nécessaires.

{ "requirements": { "errors": [{ "requirement": "documents.proof_of_ultimate_beneficial_ownership.files", "code": "invalid_signator", "reason": "Unauthorized attestation signer. The signer must have a documented relationship with the legal entity." }, { "requirement": "documents.proof_of_ultimate_beneficial_ownership.signer", "code": "invalid_signator", "reason": "Unauthorized attestation signer. The signer must have a documented relationship with the legal entity." }] } }

Document rejeté

Se produit lorsque le document téléchargé est illisible ou incorrect.

{ "requirements": { "past_due": ["documents.proof_of_registration.files"], "errors": [{ "requirement": "documents.proof_of_registration.files", "code": "verification_document_failed_other", "reason": "Your team can contact Stripe to learn more about why identity verification failed." }] } }

Signataire soumis sans fichiers

Erreurs API lors de l’envoi du signataire sans fichiers

{ "error": { "code": "invalid_signator", "message": "signer.person can only be provided when a file is also provided", "type": "invalid_request_error" } }

Étapes suivantes

  1. Mettez à jour votre intégration afin de collecter un signataire lors de l’utilisation de documents d’attestation.
  2. Implémentez la gestion des erreurs pour les nouveaux codes d’erreur spécifiques aux attestations.
  3. Formez votre équipe support aux nouvelles exigences en matière d’attestation.

Pré-remplir les informations relatives au BEF et à l’administrateur Version bêta privée

Vous pouvez également intégrer une API qui détecte et pré-remplit par voie programmatique les UBO ou les directeurs associés à une entité juridique. Le compte connecté peut vérifier la relation en confirmant les informations détectées au lieu de par le biais du chargement de documents ou d’une attestation numérique.

Cette méthode peut augmenter les taux de vérification et réduire la complexité, mais elle ne fonctionne pas pour tous les comptes. Vous devez tout de même gérer les chargements de documents ou les attestations numériques pour les comptes pour lesquels Stripe ne peut pas préremplir leurs relations.

Si vous souhaitez préremplir le formulaire de vérification UBO ou directeur, inscrivez-vous pour exprimer votre intérêt ci-dessous.

Inscription des entreprises néerlandaises (KvK) - conditions requises

À partir de 2026, nous appliquons des exigences plus strictes en matière de type d’entreprise pour les comptes des Pays-Bas (NL) afin d’assurer la conformité avec les réglementations néerlandaises. Cela affecte spécifiquement la façon dont nous collectons le KvK (Kamer van Koophandel), le numéro d’immatriculation unique à 8 chiffres exigé pour les entreprises aux Pays-Bas.

Ce qui change

  • Le statut d’entrepreneur individuel n’est plus pris en charge
  • Le type de l’entreprise exerçant sous le statut d’individual n’est plus pris en charge pour les comptes néerlandais. Cela affecte: les comptes existants et les nouveaux comptes aux Pays-Bas avec les statuts business_type: "individual" et business_type: "sole_proprietorship"

    Pourquoi cela est important : aux Pays-Bas, chaque entreprise doit fournir un numéro KvK (attribué par la Chambre de commerce). Notre type de l’entreprise« entrepreneur individuel » ne collecter pas de KvK, ce qui la rend non conforme.

  • Nouveau code d’erreur : unsupported_business_type
  • Les comptes dont le type de l’entreprise n’est pas valide voient apparaître une nouvelle erreur dans leurs exigences :

    // Account with unsupported business type { "id": "acct_123", "business_type": "individual", "country": "NL", "requirements": { "past_due": ["business_type"], "errors": [{ "requirement": "business_type", "code": "unsupported_business_type", "reason": "Business type isn't supported in merchant country. 'individual' isn't a supported business type in country NL." }] } }

  • Collecter les inscriptions au KvK pour les comptes non constitués en société
  • Les comptes néerlandais existants et nouveaux présentant les types et structures d’entreprise suivants doivent fournir leur enregistrement auprès de la KvK.

    • business_type: "company" et business_structure: "unincorporated_partnership"
    • business_type: "non_profit" et business_structure: "unincorporated_non_profit"

    Pourquoi est-ce important ? Les comptes non constitués en société ne sont actuellement pas tenus de fournir un numéro KvK, ce qui enfreint les exigences de conformité néerlandaises. Toutes les entreprises néerlandaises doivent fournir leur numéro d’enregistrement KvK.

    Solution

    Pour les comptes existants

    Les comptes néerlandais existants avec le statut de individual doivent être mis à jour vers une company avec une structure de société unipersonnelle sole_proprietorship, pour rester en conformité lorsque nous commençons à déployer cette nouvelle exigence :

    // Update existing account curl -X POST https://api.stripe.com/v1/accounts/acct_123 \ -u sk_test_123: \ -d "business_type=company" \ -d "company[structure]=sole_proprietorship" \ -d "company[tax_id]=12345678" // KvK number // Successful response { "id": "acct_123", "business_type": "company", "company": { "structure": "sole_proprietorship", "tax_id": "12345678" }, "requirements": { "past_due": [], // business_type requirement resolved "errors": [] } }

    Pour la création d’un nouveau compte

    Toute tentative de création d’un compte néerlandais avec un statut en tant que individual renvoie l’erreur unsupported_entreprise_type.

    // This will fail curl -X POST https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -d "country=NL" \ -d "type=custom" \ -d "business_type=individual" // Response { "id": "acct_123", "business_type": "individual", "country": "NL", "requirements": { "past_due": ["business_type"], "errors": [{ "requirement": "business_type", "code": "unsupported_business_type", "reason": "Business type isn't supported in merchant country. 'individual' isn't a supported business type in country NL." }] } // Correct approach curl -X POST https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -d "country=NL" \ -d "type=custom" \ -d "business_type=company" \ -d "company[structure]=sole_proprietorship"

    Structures d’entreprises prises en charge pour NL

    Pour les comptes néerlandais, utilisez les combinaisons de type de l’entreprise suivantes :

    Type d’entrepriseStructureKvK requis
    companysole_proprietorshipOui
    companyincorporated_partnershipOui
    companyunincorporated_partnershipOui
    companyprivate_corporationOui
    companypublic_corporationOui
    non_profitStructures diversesOui

    Impact sur les fonctionnalités

    Les fonctionnalités des comptes présentant une erreur unsupported_business_type seront limitées jusqu’à ce que le type de l’entreprise soit mis à jour :

    { "capabilities": { "card_payments": "inactive", "transfers": "inactive" }, "requirements": { "disabled_reason": "requirements.past_due", "past_due": ["business_type"] } }

    Les comptes qui n’ont pas fourni leur inscription KvK verront leur fonctionnalité de paiement par carte card_payments limitée jusqu’à ce que ces informations soient fournies :

    { "capabilities": { "card_payments": "inactive" }, "requirements": { "disabled_reason": "requirements.past_due", "past_due": ["company.tax_id"] } }

    Calendrier des migrations

    • Maintenant : le nouveau code d’erreur unsupported_business_type est actif
    • Lorsque les exigences futures seront déployées : les comptes existants doivent commencer la rectification
    • 30 septembre 2026 : tous les comptes néerlandais doivent être conformes

    Liste de contrôle d’implémentation

    Pour les plateformes avec des comptes connectés néerlandais :

    1. Vérifier les comptes existants
    // Find affected accounts const accounts = await stripe.accounts.list({ limit: 100, // Filter for NL accounts in your system }); const affected = accounts.data.filter(a => a.country === 'NL' && a.business_type === 'individual' );
    1. Mettre à jour les flux de création de compte

      • Supprimer l’option individual pour les comptes NL
      • Par défaut pour l’company avec sole_proprietorship
      • Collecter le numéro KvK (entreprise.tax_id)
    2. Gérer le nouveau code d’erreur

    if (account.requirements.errors.some(e => e.code === 'unsupported_business_type')) { // Prompt user to update business type // Guide them to select appropriate structure // Collect KvK number }
    1. Communiquez avec les comptes connectés concernés

      • Expliquez pourquoi le changement est nécessaire
      • Fournir des conseils sur la sélection de la bonne structure de l’entreprise
      • Aidez-les à repérer leur numéro KvK

    Test

    Testez votre implémentation avec les scénarios suivants :

    // Test updating to valid business type const updated = await stripe.accounts.update('acct_test_123', { business_type: 'company', company: { structure: 'sole_proprietorship', tax_id: '12345678' // Test KvK } });

    Considérations supplémentaires

    Entrepreneurs individuels

    Aux Pays-Bas, même les travailleurs indépendants doivent s’immatriculer en tant qu’entreprise (eenmanszaak) et obtenir un numéro KvK. Ils doivent sélectionner company → sole_proprietorship.

    Comment trouver le numéro KvK des comptes connectés

    Le numéro KvK figure sur leur certificat d’enregistrement à la Chambre de commerce (uittreksel Kamer van Koophandel).

    Compatibilité descendante

    Dans les anciennes versions de l’API, unsupported_business_type apparaît comme invalid_value_other avec un champ detailed_code contenant l’erreur spécifique.

    Nouveaux codes d’erreur

    verification_data_not_found

    Le nouveau code d’erreur verification_data_not_found peut apparaître dans le tableau requirements.errors de l’objet Account. Cette erreur indique que Stripe n’a pas pu récupérer les informations (telles que les données UBO ou directeur/dirigeant) auprès de fournisseurs de vérification tiers à l’aide des informations d’entité juridique connues du compte connecté. Cela peut se produire pour plusieurs raisons, mais c’est souvent parce que le compte a saisi leurs informations de manière incorrecte.

    Cette erreur de « données introuvables » est distincte des codes d’erreur de vérification existants :

    • verification_missing_owners : indique que le compte ne contient pas de propriétaires connus.
    • verification_failed_keyed_match : indique une incohérence entre les informations soumises et les sources de vérification.
    // Example: verification_data_not_found error { "requirements": { "errors": [{ "requirement": "owners", "code": "verification_data_not_found", "reason": "Stripe was unable to retrieve ownership or director information from third-party providers based on the current legal entity details. Verify that the business information on the account is correct." }] } }

    Pour gérer cette erreur, invitez le compte connecté à vérifier et corriger les informations relatives à son entité juridique (dénomination entreprise, numéro d’immatriculation, adresse). S’il met à jour ses informations, Stripe tente automatiquement de les vérifier à nouveau.

    Si les informations du compte sont correctes ou si Stripe ne peut toujours pas vérifier les informations mises à jour, utilisez une méthode de vérification manuelle telle que le chargement de documents ou l’attestation numérique.

    Test

    Vous pouvez créer des comptes de test à utiliser lors du développement et des phases de test de votre intégration. Les comptes de test permettent de simuler différents résultats de vérification, afin d’observer comment l’API renvoie les exigences et les erreurs pour chaque scénario.

    Les exemples suivants vous aident à anticiper les prochaines évolutions des exigences réglementaires dans l’Union européenne. Pour en savoir plus sur les tests liés à Connect, consultez la documentation Tester Stripe Connect.

    Créer un compte de test

    Créez un Account de test en envoyant une requête POST à l’API Accounts à l’aide de votre clé secrète en environnement de test.

    Pour accéder aux nouvelles exigences avant leur déploiement sur les comptes en mode non test, définissez un en-tête activant une version bêta de l’API, activez la fonctionnalité expérimentale d’aperçu de l’onboarding, puis activez la version bêta privée lors de la demande d’une fonctionnalité. Par exemple :

    curl https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -H "Stripe-Version: 2026-01-28.preview;experimental_onboarding_preview=v2" \ -d 'type'='custom' \ -d 'country'='ES' \ -d 'capabilities[card_payments][requested]'='true' \ -d 'capabilities[card_payments][preview]'='true' \ -d 'capabilities[transfers][requested]'='true' \ -d 'capabilities[transfers][preview]'='true'

    Les exemples ci-dessous montrent comment simuler différentes situations en utilisant des valeurs qui déclenchent des réponses spécifiques pour les comptes de test.

    Tester un Compte appartenant à un entrepreneur individuel

    Cet exemple crée un compte qui ne nécessite pas de vérification des relations, car le type d’entité juridique est défini sur individual.

    Créez un compte de test en suivant les instructions précédentes, puis définissez les informations de base relatives à l’entreprise :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=individual \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com"

    La réponse inclut les exigences de base pour un entrepreneur individuel. Vous pouvez répondre à ces exigences en créant un représentant :

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true"

    La définition de la date de naissance sur 1901-01-01 déclenche une vérification d’identité réussie en mode test. Pour d’autres valeurs permettant de simuler des résultats spécifiques, consultez Dates de naissances de test. De la même manière, définir la première ligne de l’adresse sur la chaîne address_full_match déclenche une vérification réussie de l’adresse. Pour d’autres valeurs de simulation, consultez Adresses commerciales de test.

    La réponse montre que les exigences de l’entrepreneur individuel sont devenues en attente. Si vous attendez quelques instants et récupérez le Account, vous pouvez voir que ces exigences ont été satisfaites :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123

    Les seules exigences restantes concernent le compte bancaire (external_account) et les Conditions d’utilisation du service (TOS). Pour effacer les exigences des Conditions d’utilisation du service, définissez le hachage tos_acceptance du Account :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "tos_acceptance[date]=1540248693" \ -d "tos_acceptance[ip]=10.0.0.1"

    Pour effacer les exigences du compte bancaire, créez un compte bancaire de test pour le Account. Spécifiez un numéro de compte bancaire de test en fonction de son pays :

    curl https://api.stripe.com/v1/accounts/acct_test_123/external_accounts \ -u sk_test_123: \ -d "external_account[object]=bank_account" \ -d "external_account[account_number]=ES0700120345030000067890" \ -d "external_account[country]=ES" \ -d "external_account[currency]=EUR"

    Tester un Compte appartenant à une entreprise

    Cet exemple crée un compte soumis aux exigences de vérification des relations, car le type d’entité juridique est défini sur company.

    Spécificités régionales
    Royaume-Uni

    Le Royaume-Uni exige la vérification à la fois des bénéficiaires effectifs finaux (UBO) et des dirigeants. Si vous disposez de comptes connectés dans Le Royaume-Uni, veillez à tester les comptes dont le pays est défini sur GB.

    Créez un compte de test en suivant les instructions précédentes, puis définissez les informations de base relatives à l’entreprise :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=company \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com" \ -d "company[name]=Test company" \ -d "company[phone]=628123456787" \ -d "company[address][line1]=address_full_match" \ -d "company[address][city]=Madrid" \ -d "company[address][postal_code]=28009" \ -d "company[address][country]=ES" \ -d "company[tax_id]=000000000"

    La définition du numéro d’identification fiscale 000000000 déclenche une vérification réussie de l’entreprise. Pour d’autres valeurs permettant de simuler des résultats spécifiques, consultez Numéros d’identification fiscale de test pour les entreprises.

    Indiquez ensuite un représentant.

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Adam" \ -d "last_name=" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true" \ -d "relationship[title]=CEO"

    Une fois le processus de vérification du représentant terminé, vous pouvez voir les exigences restantes avec une requête GET :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123:

    Les exigences du tableau requirements.currently_due répertorient les informations dont nous avons besoin sur les propriétaires du Account. Le tableau requirements.alternatives peut inclure des informations facultatives que vous pouvez fournir pour répondre à certaines exigences. Par exemple :

    { "alternative_fields_due": [ "company.owners_provided", "documents.proof_of_ultimate_beneficial_ownership.files", "owners.first_name", "owners.last_name" ], "original_fields_due": [ "company.owners_provided", "owners.first_name", "owners.last_name" ] }

    Vous pouvez fournir les champs répertoriés dans alternative_fields_due comme autre moyen de satisfaire aux exigences de la liste original_fields_due correspondante. Dans cet exemple, alternative_fields_due inclut les propriétés dans original_fields_due, plus documents.proof_of_ultimate_beneficial_ownership.files. Cela signifie que les informations initiales sont obligatoires, mais que vous avez également la possibilité de fournir un document attestant de la propriété effective afin de faciliter le processus de vérification.

    Pour répondre aux exigences relatives aux propriétaires, créez deux personnes et marquez-les comme propriétaires. Les noms figurant dans cet exemple sont des valeurs codées en dur pour les comptes de test qui utilisent le numéro fiscal 000000000.

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[owner]=true" curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Louis" \ -d "last_name=Martin" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[owner]=true"

    Indiquez que vous avez créé tous les propriétaires du Account en définissant entreprise.owners_provided sur true :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[owners_provided]=true"

    Le traitement de cette demande supprime toutes les exigences relatives aux propriétaires du Account.

    Tester le recours à la vérification par document

    Les exigences relatives aux propriétaires d’un Account continuent d’apparaître dans currently_due (ou dans pending_verification si une vérification est en cours) jusqu’à ce que la vérification soit réussie.

    En cas d’échec de la vérification, l’une des options consiste à téléverser un document. Cet exemple montre comment procéder à l’aide de l’API.

    Créez un compte de test en suivant les instructions précédentes, puis définissez les informations de base de l’entreprise. Définissez le numéro fiscal sur 222221001, ce qui déclenche l’échec de la vérification propriétaire.

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=company \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com" \ -d "company[name]=Test company" \ -d "company[phone]=628123456787" \ -d "company[address][line1]=address_full_match" \ -d "company[address][city]=Madrid" \ -d "company[address][postal_code]=28009" \ -d "company[address][country]=ES" \ -d "company[tax_id]=222221001"

    Indiquez ensuite un représentant :

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true" \ -d "relationship[title]=CEO"

    Ensuite, créez un propriétaire :

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Adam" \ -d "last_name=Smith" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[owner]=true"

    Indiquez que vous avez terminé de créer des propriétaires en définissant entreprise.owners_provided sur true :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[owners_provided]=true"

    If you examine the Account, you can see that the owner requirements remain and the requirements.errors array contains an entry with a requirement of owners and a code of verification_data_not_found. That means Stripe wasn’t able to verify the owners using the provided company information.

    Si vous recevez cette erreur pour un Account réel, vérifiez que vous avez saisi les informations relatives à la bonne entité juridique. Dans cet exemple, nous partons du principe que les informations sont correctes et que vous devez fournir un document pour les vérifier.

    Pour un Account réel, utilisez l’API Files pour téléverser un document, puis mettez à jour le Account à l’aide du token renvoyé dans la réponse. Pour cet exemple, utilisez le token de test file_relationship_document_success.

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "documents[proof_of_ultimate_beneficial_ownership][files][]"=file_relationship_document_success

    Quelques instants après la mise à jour du Account, vous pouvez récupérer les exigences actuelles et constater que les exigences relatives aux propriétaires ont été levées.

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123:

    Tester une entreprise sans propriétaire applicable

    Si une entreprise ne compte aucun propriétaire détenant plus de 25 % des parts, Stripe exige alors les informations relatives au dirigeant. Cet exemple montre comment fournir les informations du dirigeant.

    Créez un compte de test en suivant les instructions précédentes, puis définissez les informations de base de l’entreprise. Définissez le numéro fiscal sur 000000000, ce qui déclenche la réussite de la vérification entreprise.

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=company \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com" \ -d "company[name]=Test company" \ -d "company[phone]=628123456787" \ -d "company[address][line1]=address_full_match" \ -d "company[address][city]=Madrid" \ -d "company[address][postal_code]=28009" \ -d "company[address][country]=ES" \ -d "company[tax_id]=000000000"

    Indiquez ensuite un représentant :

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true" \ -d "relationship[title]=CEO"

    Pour indiquer que l’entreprise ne compte aucun propriétaire pertinent, définissez company.owners_provided sur true sans créer de propriétaires. Pour réutiliser un Account de test existant comportant déjà des propriétaires, vous pouvez supprimer tous les propriétaires existants.

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[owners_provided]=true"

    Le tableau requirements.alternatives contient un ensemble de propriétés relatives au dirigeant, proposées comme alternative aux propriétés des propriétaires. Le processus de création d’un dirigeant est très similaire à celui de création d’un propriétaire :

    curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Adam" \ -d "last_name=Smith" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[director]=true" \ -d "relationship[title]=President"

    Indiquez que vous avez terminé de créer des dirigeants en définissant entreprise.directors_provided sur true :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[directors_provided]=true"

    Pour simuler une vérification de relation réussie, définissez entreprise.name sur la chaîne match_name_relationships :

    curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[name]=match_name_relationships"

    Autres scénarios de test

    Les tests suivants sont également utiles :

    • Une entité de type non_profit, qui nécessite une vérification directeur (la vérification UBO n’est pas une option).
    • Satisfaire aux exigences de vérification du dirigeant au moyen d’un document.
    • Entreprises au Royaume-Uni nécessitant à la fois la vérification des bénéficiaires effectifs (UBO) et la vérification des dirigeants.

    Voir aussi

    • Inscription Connect pour les comptes Custom
    • Solutions d’inscription pour les comptes Custom
    • Mettre des comptes à jour
    • Gérer la vérification d’identité avec l’API
    • Test de vérification d’identité pour les comptes Custom
    Cette page vous a-t-elle été utile ?
    OuiNon
    • Besoin d'aide ? Contactez le service Support.
    • Consultez notre log des modifications.
    • Des questions ? Contactez l'équipe commerciale.
    • LLM ? Lire llms.txt.
    • Propulsé par Markdoc