# Informations de vérification requises Identifiez les informations actuelles et futures que les comptes connectés doivent fournir en fonction de leur activité, de leur localisation et des fonctionnalités demandées. ## Instructions La version accessible aux humains de cette documentation permet à l’utilisateur de sélectionner les champs et les régions d’un compte connecté à l’aide d’un formulaire, puis d’effectuer des requêtes API pour récupérer et afficher les exigences qu’un compte connecté avec la configuration et la région sélectionnées doit respecter. Suivez ces instructions pour récupérer les mêmes informations. ### Contrat d’interaction Terminologie utilisée dans ce document : - `field` : une entrée de configuration telle que `platformCountry`, `accountCountry` ou `capabilities` - `option` : une option sélectionnable présentée pour un champ - `value` : l’option que l’utilisateur sélectionne, ou la valeur de réponse libre qu’il fournit pour un champ Chaque fois que vous demandez à l’utilisateur de fournir une valeur pour un champ : - utilisez une question à choix multiples ; ne vous arrêtez jamais à une simple invite de texte libre ou à une saisie brute dans le chat - si vous avez besoin d’une saisie libre de la part de l’utilisateur, demandez-lui d’utiliser le champ de réponse libre de la question - pour les longues listes d’options, indiquez explicitement que toute valeur figurant dans la liste validée complète reste acceptée via le champ de réponse libre - si l’utilisateur a déjà fourni une réponse valide dans un message précédent, utilisez-la au lieu de poser à nouveau la question ### Règles strictes Vous devez respecter ces règles : - Demandez un champ *uniquement* après que tous ses champs préalables ont été renseignés. - Collectez les champs de configuration progressivement au fur et à mesure que le flux avance. - Demandez un champ à la fois, ou un groupe de champs uniquement lorsqu’ils sont indépendants à ce stade du flux. - Par exemple, demandez `platformCountry` et `accountCountry` séparément : le pays de la plateforme détermine quels pays de compte sont valides. Demander les deux ensemble peut donc produire des combinaisons invalides. Mais vous pouvez demander `dashboardType`, `tosType` et `legalEntityType` ensemble dans un seul groupe, car leurs options valides sont déjà connues à partir de la même réponse. - En cas de conflit entre la demande de l’utilisateur et la configuration validée, informez-en l’utilisateur et demandez-lui de réviser ses choix de configuration à l’aide du [Contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract). Maintenez la configuration validée alignée sur la demande de l’utilisateur sans ignorer silencieusement le conflit. - Suivez le [Contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract) pour chaque question de l’utilisateur. - Lorsque le nombre d’options disponibles dépasse quatre, imprimez *toujours* la liste de référence validée complète avant de poser la question à choix multiples afin que l’utilisateur puisse voir toutes les options possibles. - Lors de l’impression des pays, imprimez toujours le nom complet du pays suivi de son code entre parenthèses, par exemple `Allemagne (DE)`. - Utilisez des pays spécifiques dans les options de sélection rapide afin que l’utilisateur puisse avancer avec une clarté immédiate. - Laissez les descriptions des options de sélection rapide des pays vides. - Pour tout champ avec un ensemble limité d’options valides, affichez toutes les options valides à l’utilisateur. - Chaque liste d’options sélectionnables présentée à l’utilisateur doit être validée à l’avance par rapport à toutes les contraintes actuellement connues avant d’être affichée. - N’affichez jamais une option comme sélectionnable si vous savez déjà qu’elle sera supprimée, rejetée ou ajustée automatiquement plus tard dans le flux. - Présentez les options qui restent valides tout au long du flux actuel. - Demandez des informations sur `capabilities` après `platformCountry`, `accountCountry`, et une fois que les contraintes de validité en aval pour cette configuration sont résolues. - Demandez *uniquement* `orrProgram` s’il est présent dans les `programs` publics renvoyés pour la configuration validée. - Si la carte `businessStructure` pour le `legalEntityType` choisi est vide ou contient exactement une clé `nil`, ignorez `businessStructure`. Sinon, demandez `businessStructure` et autorisez toujours une option `none` ou laissez la désélectionnée en tant qu’option de sélection rapide dans la question à choix multiples. - Si l’utilisateur décide de modifier un choix précédent tel que `platformCountry`, vous devez invalider et revérifier tous les champs en aval avant de continuer. - Gardez la chaîne de dépendances implicite. Partagez les informations dont l’utilisateur a besoin pour progresser et simplifiez l’expérience. - Utilisez un langage adapté à l’utilisateur lorsque vous vous adressez à celui-ci. Voir ci-dessous pour traduire la terminologie interne de l’API. #### Champs internes -> Langage externe | Champ interne | Langage externe | | --- | --- | | `apiVersion` | Version de l’API Accounts | | `platformCountry` | Pays de la plateforme | | `accountCountry` | Pays du compte | | `dashboardType` | Type de Dashboard | | `tosType` | Contrat d’utilisation du service | | `legalEntityType` | Type d’entreprise | | `businessStructure` | Structure de l’entreprise | | `capabilities` | Fonctionnalités | | `orrProgram` | Mise à jour des exigences | | `eu2025` | Europe | ### Chaîne de dépendances Vous devez suivre exactement cette chaîne de dépendances : ```mermaid flowchart TD apiVersion["apiVersion"] --> capabilities platformCountry --> accountCountry["accountCountry"] accountCountry --> dashboardType["dashboardType"] accountCountry --> tosType["tosType"] accountCountry --> legalEntityType["legalEntityType"] legalEntityType --> businessStructure["businessStructure (optional)"] accountCountry --> capabilities["capabilities"] accountCountry --> orrProgram["orrProgram (only if returned)"] tosType --> capabilities apiVersion --> capabilities dashboardType --> finalRequest["final requirements request"] apiVersion --> finalRequest platformCountry --> finalRequest accountCountry --> finalRequest tosType --> finalRequest legalEntityType --> finalRequest businessStructure --> finalRequest capabilities --> finalRequest orrProgram --> finalRequest ``` Interprétez le diagramme littéralement : - Demandez un nœud *uniquement* après que toutes ses dépendances entrantes ont été résolues. - Commencez toujours par demander `apiVersion` à l’utilisateur. Recommandez `v2` par défaut. ### Saisies dont vous aurez besoin à terme Au moment où vous effectuez la demande d’exigences finale, vous devez disposer d’une valeur validée pour : - `apiVersion` : `v1` ou `v2` - `platformCountry` - `accountCountry` - `dashboardType` - `tosType` - `legalEntityType` - `capabilities` : au moins une fonctionnalité doit être sélectionnée Vous devriez également avoir demandé les champs facultatifs suivants, si nécessaire : - `businessStructure` : ne demandez que lorsque `legalEntityType` n’est pas `individual` - `orrProgram` : ne demandez que s’il est présent dans la liste publique des `programs` pour cette configuration validée ### Résolution des fonctionnalités Utilisez cet algorithme chaque fois que vous créez ou validez la liste des fonctionnalités : 1. Commencez par `country_map[accountCountry].capabilities`. 2. Appliquez les règles `tosType` : - si `tosType=recipient`, forcez `transfers` et supprimez toutes les autres fonctionnalités à l’exception de `crypto_transfers`, qui peut être disponible dans de rares cas - avec `apiVersion=v1`, si `crypto_transfers` est sélectionnée, incluez également `transfers` 3. Avec `apiVersion=v2`, supprimez toute fonctionnalité absente de `get-v2-supported-v1-capabilities`. 4. Affichez à l’utilisateur la liste filtrée des fonctionnalités. Lorsque l’utilisateur vous interroge explicitement sur une fonctionnalité filtrée, expliquez-lui clairement que la fonctionnalité demandée n’est pas disponible pour la configuration actuelle. 5. Si la liste filtrée est vide, informez l’utilisateur qu’aucune fonctionnalité n’est prise en charge pour la configuration actuelle et demandez-lui de réviser ses choix de configuration précédents en utilisant le [contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract) avant de formuler la requête de conditions requises finale. 6. Lorsque vous vous renseignez sur les `capabilities`, imprimez d’abord la liste complète filtrée, puis posez une question à choix multiples incluant le ou les choix les plus probables en fonction du contexte propre à l’utilisateur. 7. Si l’utilisateur demande une fonctionnalité qui ne figure pas dans la liste filtrée, expliquez pourquoi elle n’est pas disponible pour la configuration actuelle. - Gardez la fonctionnalité demandée par l’utilisateur visible dans la conversation et expliquez directement l’incompatibilité. Par exemple, si l’utilisateur demande `paypal_payments`, mais a également sélectionné les comptes `v2`, expliquez que `paypal_payments` n’est pas disponible pour les comptes `v2`, et proposez-lui de passer à `apiVersion` `v1` et de choisir `paypal_payments`, ou de conserver `apiVersion` `v2` et de choisir une fonctionnalité différente. ### Flux d’agent Lorsque l’utilisateur demande quelles informations de vérification sont nécessaires, utilisez ce flux : 1. Demandez `apiVersion`. Recommandez `v2`. 2. Récupérez `https://docs.stripe.com/_endpoint/get-platform-countries` et utilisez la liste publique prise en charge pour demander `platformCountry`. 3. Récupérez `https://docs.stripe.com/_endpoint/get-v2-supported-v1-capabilities` dans le cas de `apiVersion=v2`. 4. Récupérez `https://docs.stripe.com/_endpoint/get-requirement-selections-for-platform-country?platformCountry=...` avec le `platformCountry` choisi. 5. Demandez `accountCountry` à partir des clés `country_map` renvoyées. 6. Une fois que `accountCountry` est validé, demandez : - `dashboardType` - `tosType` - `legalEntityType` 7. Une fois que `legalEntityType` a été choisi, demandez `businessStructure` si le tableau de correspondance des structures validée l’expose. 8. Résolvez et demandez les `capabilities` en utilisant [Résolution des fonctionnalités](https://docs.stripe.com/connect/required-verification-information.md#resolve-capabilities). 9. Ne demandez `orrProgram` que si la configuration validée expose un ou plusieurs programmes publics. 10. Si la configuration demandée par l’utilisateur ne correspond pas aux options valides, indiquez-lui exactement les parties non valides ou ajustées automatiquement, puis posez la question de suivi de correction à l’aide du [contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract). Gardez l’incohérence visible, basez la configuration sur la requête de l’utilisateur et poursuivez avec une question suivante structurée. 11. Ce n’est qu’une fois la configuration validée que vous pouvez appeler `https://docs.stripe.com/_endpoint/get-requirements-for-setups` avec une clé de configuration de premier niveau `account-setup-A[...]`, comprenant `account-setup-A[apiVersion]`, `account-setup-A[platformCountry]`, `account-setup-A[accountCountry]`, `account-setup-A[dashboardType]`, `account-setup-A[tosType]`, `account-setup-A[legalEntityType]`, l’option `account-setup-A[businessStructure]`, une ou plusieurs `account-setup-A[capabilities][i]`, et l’option `account-setup-A[orrProgram]`. 12. À la fin, vous devez appeler `https://docs.stripe.com/_endpoint/get-website-requirements-for-capabilities?capabilities[i]=...` et `https://docs.stripe.com/_endpoint/get-mcc-restrictions-for-capabilities?capabilities[i]=...` avec les fonctionnalités validées finales afin de rechercher des informations supplémentaires. Si l’on vous demande de comparer deux configurations ou ce qui est nécessaire pour passer de X à Y, vous devez répéter le même flux de validation de manière indépendante pour la configuration A et la configuration B avec une deuxième clé de premier niveau `account-setup-B[...]` avant d’appeler la requête de conditions requises comparables. Traitez les échecs de transport ou de construction comme des échecs de l’assistant pouvant faire l’objet de nouvelles tentatives, et réservez les conclusions de configurations non prises en charge aux cas de réussite des requêtes de récupération préalables et des validations du type d’entreprise. ### exemples curl Dans ces exemples, définissez l’hôte de la documentation sur le site public : ```bash DOCS_HOST="https://docs.stripe.com" ``` #### Utilisateur novice : « Que dois-je vérifier pour un compte connecté Stripe ? » Demandez `apiVersion`. Recommandez `v2`. Récupérez la liste publique des pays de la plateforme : ```bash curl --get "$DOCS_HOST/_endpoint/get-platform-countries" ``` Demandez à l’utilisateur quelle valeur `platformCountry` il souhaite utiliser. Récupérez ensuite les options autorisées pour ce pays par la plateforme. Cette requête vous indique ce qui est valide par la suite, et vous devez l’utiliser avant de choisir les champs en aval. Supposons que l’utilisateur a choisi `US` : ```bash curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country" \ --data-urlencode "platformCountry=US" ``` Une fois cette réponse renvoyée, collectez les choix de configuration comme décrit dans la section [Flux de l’agent](https://docs.stripe.com/connect/required-verification-information.md#agent-flow). #### Utilisateur confirmé : « J’ai une plateforme au Canada et je souhaite inscrire un compte connecté d’entreprise française pour utiliser les paiements par carte » Demandez `apiVersion`. Recommandez `v2`. ```bash # Step 1: verify the platform country is valid curl --get "$DOCS_HOST/_endpoint/get-platform-countries" # Step 2: fetch all public options for that platform country curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country" \ --data-urlencode "platformCountry=CA" ``` À partir de cette deuxième réponse, vérifiez d’abord que FR est un pays de compte valide, puis lisez : - `country_map.FR.dashboard_types` - `country_map.FR.tos_types` - `country_map.FR.entity_type_structures` - `country_map.FR.capabilities` - `country_map.FR.programs` Ensuite, confirmez que la configuration demandée par l’utilisateur correspond bien à ces options disponibles. Si l’utilisateur souhaite `apiVersion=v2`, récupérez et appliquez d’abord le filtre de fonctionnalités v2 pour le comparer aux fonctionnalités demandées par l’utilisateur : ```bash curl --get "$DOCS_HOST/_endpoint/get-v2-supported-v1-capabilities" ``` Ce n’est que lorsque la configuration demandée par l’utilisateur correspond effectivement aux options disponibles que vous pourrez appeler l’endpoint des conditions requises. L’endpoint des conditions requises attend des champs de chaîne de requête imbriqués, et non un corps JSON : ```bash curl --get "$DOCS_HOST/_endpoint/get-requirements-for-setups" \ --data-urlencode "account-setup-A[apiVersion]=v2" \ --data-urlencode "account-setup-A[platformCountry]=CA" \ --data-urlencode "account-setup-A[accountCountry]=FR" \ --data-urlencode "account-setup-A[dashboardType]=none" \ --data-urlencode "account-setup-A[tosType]=full" \ --data-urlencode "account-setup-A[legalEntityType]=company" \ --data-urlencode "account-setup-A[businessStructure]=corporation" \ --data-urlencode "account-setup-A[capabilities][0]=card_payments" ``` Puisque `.programs` est présent pour cette configuration, vous pouvez également demander à l’utilisateur s’il souhaite choisir une mise à jour des conditions requises et ajouter `--data-urlencode "account-setup-A[orrProgram]=eu-2025"` à la requête. Utilisez cette réponse pour présenter les conditions requises à l’utilisateur comme expliqué dans la section [Construction du résultat](https://docs.stripe.com/connect/required-verification-information.md#construct-the-result). Récupérez les tableaux facultatifs supplémentaires pour les fonctionnalités sélectionnées : ```bash curl --get "$DOCS_HOST/_endpoint/get-website-requirements-for-capabilities" \ --data-urlencode "capabilities[0]=card_payments" ``` ```bash curl --get "$DOCS_HOST/_endpoint/get-mcc-restrictions-for-capabilities" \ --data-urlencode "capabilities[0]=card_payments" ``` ### Lecture des réponses de l’API Utilisez `get-platform-countries` pour choisir votre `platformCountry` initial : - `platform_countries` est la liste publique des options `platformCountry` disponibles - `default_country` est le pays de départ par défaut de la page Utilisez `get-requirement-selections-for-platform-country` pour valider la configuration avant d’appeler l’endpoint principal des conditions requises : - `country_map` est la source de vérité pour déterminer quelles valeurs de champ sont valides pour cette valeur de `platformCountry` - les clés de `country_map` sont les options `accountCountry` autorisées - `country_map[ACCOUNT_COUNTRY].dashboard_types` limite `dashboardType` - `country_map[ACCOUNT_COUNTRY].tos_types` limite `tosType` - `country_map[ACCOUNT_COUNTRY].entity_type_structures` limite `legalEntityType` et la valeur `businessStructure` facultative - `country_map[ACCOUNT_COUNTRY].capabilities` limite les choix de fonctionnalités - `country_map[ACCOUNT_COUNTRY].programs` dresse seulement la liste des programmes publics d’actualisation des exigences d’inscription que vous pouvez transmettre en tant que `orrProgram` - `external_country_map` doit être ignoré Appliquez ces règles de dépendance avant d’effectuer la requête finale : - Si vous modifiez `accountCountry`, vérifiez à nouveau toutes les sélections en aval - Si vous modifiez `legalEntityType`, revérifiez `businessStructure` - Si vous modifiez `accountCountry`, `tosType` ou `apiVersion`, réexécutez [Résollution des fonctionnalités](https://docs.stripe.com/connect/required-verification-information.md#resolve-capabilities) Utilisez `get-requirements-for-setups` comme source principale de données d’exigences : - `requirements` contient le résultat de la réussite de chaque clé de configuration demandée - `validation_errors` signifie que la configuration n’était pas valide et doit être corrigée avant d’interpréter la réponse - `build_errors` signifie que l’endpoint a échoué de manière inattendue lors de la création de la synthèse ; vous devez considérer cela comme une erreur menant à un nouvel essai plutôt qu’à une conclusion opérationnelle Dans chaque résultat de configuration réussi : - `requirements[field_name]` correspond aux données d’exigence pour un seul champ brut, y compris les limites d’application, les alternatives, les métadonnées d’affichage et les annotations associées utilisées par le moteur de rendu de la documentation - `extras` contient des étiquettes lisibles par un humain et des conseils de validation pour cette exigence - `requirement_tags` contient les balises d’exigence de niveau supérieur renvoyées avec les données d’exigence - `requirement_groups` contient les données d’exigence regroupées renvoyées avec les données d’exigence Vérifiez les endpoints supplémentaires pour voir s’il y a des restrictions supplémentaires spécifiques aux fonctionnalités à présenter à l’utilisateur. - `requirements_by_capability` de l’endpoint de site web est un tableau des exigences de site web distinct qui explique les exigences que le site web du compte connecté doit satisfaire pour prendre en charge la fonctionnalité sélectionnée. Celles-ci doivent être présentées à l’utilisateur sous la forme d’un tableau distinct. - `restrictions_by_capability` de l’endpoint MCC est un tableau des restrictions MCC distinct qui explique les exigences que le MCC du compte connecté doit satisfaire pour prendre en charge la fonctionnalité sélectionnée. Si cet endpoint renvoie des restrictions, demandez à l’utilisateur quel type d’entreprise il dirige pour déterminer si l’utilisation de la fonctionnalité spécifique est interdite ou limitée pour son type d’entreprise. - Les mappages vides sont des résultats valides pour de nombreuses fonctionnalités standard et ne constituent pas des erreurs ### Construire le résultat Transformez la réponse de l’API en un ou plusieurs tableaux lisibles par un humain dans votre propre réponse à l’utilisateur, suivis de toute note explicative supplémentaire. Il s’agit de tableaux de sortie que vous créez à partir des données de réponse, et non de références à des tableaux préexistants sur la page de la documentation pour les humains. ##### Comment construire les tableaux : 1. Séparez chaque clé de champ brut en une section à l’aide de son préfixe : - `company.*` -> `company` - `documents.*` -> `documents` - `individual.*` -> `individual` - `representative.*` -> `representative` - `directors.*` -> `directors` - `owners.*` -> `owners` - `executives.*` -> `executives` - tout le reste -> `account` 2. Rendez un tableau par section non vide. Ne fusionnez pas plusieurs sections en un seul tableau. 3. Pour chaque tableau : - Utilisez le nom de la section comme titre du tableau, par exemple `Account`, `Company`, `Representative`, `Directors` ou `Owners` - Incluez les colonnes suivantes : - Titre : vide - Contenu : Nom d’affichage de la ligne, par exemple « Nom », « Date de naissance », « Adresse » - Titre : `Requirement` - Contenu : une liste à puces des champs affichés - Rendez une puce par champ affiché - Affichez chaque champ au format de code - Si un champ comporte des alternatives, conservez-les dans la même puce et affichez-les comme une disjonction, par exemple `field_a` ou `field_b` - Titre : `Verification` - Contenu : une liste à puces créée à partir de `extras[].value` - Affichez chaque entrée `extras[].value` sous forme de puce - Si `extras` est vide, laissez l’entrée vide - Titre : `Enforcement action` - Contenu : texte d’application lisible par un humain créé à partir des deux ensembles de champs de limites - Utilisez d’abord les champs de limite non vérifiés pour générer le(s) message(s) `if not provided` : - `capability_limit_amount` - `capability_limit_time` - `payment_limit_amount` - `payment_limit_time` - `payout_limit_amount` - `payout_limit_time` - Utilisez ensuite les champs de limite vérifiés pour générer le(s) message(s) `if not verified` : - `verified_capability_limit_amount` - `verified_capability_limit_time` - `verified_payment_limit_amount` - `verified_payment_limit_time` - `verified_payout_limit_amount` - `verified_payout_limit_time` - Si le montant limite ou la durée limite est `<= 0`, considérez cet impact comme immédiat. - S’il existe à la fois une limite de temps et une limite de montant pour le même impact, associez-les avec `or`. - Regroupez les impacts ayant des seuils identiques dans une seule phrase, par exemple `La fonctionnalité, les paiements et les virements seront immédiatement suspendus s’ils ne sont pas fournis.` - Si les textes `s’ils ne sont pas fournis` et `s’ils ne sont pas vérifiés` doivent être affichés, affichez d’abord les phrases `s’ils ne sont pas fournis`, puis les phrases `s’ils ne sont pas vérifiés` ; précédez la première phrase de la vérification par `De plus,` - Si aucun des ensembles de limites n’est présent, affichez `—` 4. Si deux sections partagent la même famille de définitions de lignes, elles restent des tableaux distincts. Par exemple, `representative` et `owners` utilisent tous deux la famille de définitions de lignes `person`, mais s’affichent sous forme de tableaux `Representative` et `Owners` distincts car ce sont des sections différentes. 5. Attribuez chaque section à une famille de définitions de lignes répertoriée ci-dessous au point 8. La famille de définitions de lignes contrôle uniquement la façon dont les lignes sont associées et étiquetées dans le tableau de cette section : - `account` -> `account` - `company` -> `entity` - `documents` -> `entity` - `individual` -> `person` - `representative` -> `person` - `owners` -> `person` - `executives` -> `person` - `directors` -> `person` 6. Pour chaque section ne correspondant pas à `account`, supprimez le préfixe de section avant d’associer les règles de ligne. Par exemple, associez `representative.first_name` à `first_name` et `company.address.city` à `address.city`. 7. Utilisez les définitions de lignes ci-dessous pour la famille de définitions de lignes de cette section. Créez une ligne uniquement lorsqu’au moins un champ de cette section correspond à la ligne. 8. Définitions de lignes : account : Code de catégorie de commerçant : `/business_profile.mcc/` URL : `/business_profile.(url|requirement)/` Description du produit : `/business_profile.product_description/` Téléphone du service de support : `/business_profile.support_phone/` Libellés de relevé bancaire : `/settings.payments.statement_descriptor/` - /settings.card_payments.statement_descriptor/ Adresse e-mail du service de support Konbini : `/settings.konbini_payments.support_email/` Numéro de téléphone du service de support Konbini : `/settings.konbini_payments.support_phone/` Heures d’ouverture du service de support Konbini : `/settings.konbini_payments.support_hours/` Conditions d’utilisation du service : `/^tos_acceptance\./` Conditions d’utilisation du service d’émission : `/settings\.card_issuing\.tos_acceptance\./` Nombre de travailleurs estimé : `/business_profile\.estimated_worker_count/` Revenus annuels : `/business_profile\.annual_revenue/` Compte externe : `/external_account/` Tuteur légal : `/legal_guardian\./` entity : Nom de l’entreprise : `/name$/` Nom de l’entreprise (kana) : `/name_kana/` Nom de l’entreprise (kanji) : `/name_kanji/` Adresse de l’entreprise : `/address\..*/` Adresse de l’entreprise (kana) : `/address_kana/` Adresse de l’entreprise (kanji) : `/address_kanji/` Téléphone de l’entreprise : `/phone/` Numéro fiscal de l’entreprise : `/tax_id/` Numéro d’immatriculation de l’entreprise : `/registration_number/` Numéro d’identification de l’entreprise : `/id_number/` Licence commerciale : `/company_license/` Acte constitutif : `/company_memorandum_of_association/` Preuve de propriété du compte bancaire : `/bank_account_ownership_verification/` Administrateurs fournis : `/directors_provided/` Propriétaires fournis : `/owners_provided/` Dirigeants fournis : `/executives_provided/` person : Nom : `/(first|last)_name/` Nom (kana) : `/(first|last)_name_kana/` Nom (kanji) : `/(first|last)_name_kanji/` Alias : `/full_name_aliases/` Date de naissance : `/dob\./` Adresse : `/^address\./` Adresse (kana) : `/address_kana/` Adresse (kanji) : `/address_kanji/` Adresse enregistrée : `/registered_address/` E-mail : `/email/` Téléphone : `/phone/` Sexe : `/gender/` Exposition politique : `/political_exposure/` Informations fiscales : `/ssn_last_4$/` ou `/id_number$/` Numéro d’identification secondaire : `/(id_number_secondary)/` Intitulé de poste : `/(relationship\.title)/` Relation avec l’entité juridique : `/relationship\.(?!title)/` Nationalité : `/nationality/` Passeport : `/passport/` Preuve de vie : `/proof_of_liveness/` 1. Pour `apiVersion=v2`, remplacez chaque champ affiché par `v2_field_name` et utilisez `v2_alternatives`. 2. Dans le cas de `apiVersion=v2`, si une exigence n’expose pas `v2_field_name`, omettez ce champ dans le tableau affiché. Si cela supprime tous les champs d’un groupe de lignes, omettez la ligne. Si une section devient vide, omettez ce tableau de section. ##### Comment construire le récapitulatif au format JSON : - si l’utilisateur demande un récapitulatif au format JSON des éléments obligatoires, renvoyez un objet JSON respectant exactement cette structure : ```json { "requirements": { "currently_due": [ "configuration.merchant.mcc" ], "eventually_due": [] } } ``` - renseignez `requirements.currently_due` avec les noms des champs d’exigence actuellement dus et `requirements.eventually_due` avec les noms des champs d’exigence futurs ou éventuels - pour `apiVersion=v2`, utilisez les valeurs `v2_field_name` dans les deux tableaux ; pour `apiVersion=v1`, utilisez les noms bruts des champs d’exigence - la vue des différences JSON compare uniquement les noms des exigences ; elle ne compare pas les textes de vérification, les seuils ou les métadonnées supplémentaires ### Comment répondre aux utilisateurs Lorsque vous renvoyez des résultats à l’utilisateur : - reformulez la configuration validée exacte que vous avez interrogée, y compris `apiVersion`, `platformCountry`, `accountCountry`, `dashboardType`, `tosType`, `legalEntityType`, le champ facultatif `businessStructure`, les `capabilities` sélectionnées et le champ facultatif `orrProgram` - fournissez toujours à l’utilisateur un lien contenant les paramètres de requête d’URL exacts que vous avez utilisés afin qu’il puisse consulter lui-même les exigences et vérifier vos conclusions - par exemple : `https://docs.stripe.com/_endpoint/get-requirements-for-setups?account-setup-A[platformCountry]=CA&account-setup-A[accountCountry]=FR&account-setup-A[dashboardType]=full&account-setup-A[tosType]=full&account-setup-A[legalEntityType]=individual&account-setup-A[capabilities][0]=card_payments&account-setup-A[orrProgram]=eu-2025` -> `https://docs.stripe.com/connect/required-verification-information?accountSetupKeys=account-setup-A%2Caccount-setup-B&account-setup-A%5BapiVersion%5D=v2&account-setup-A%5BplatformCountry%5D=CA&account-setup-A%5BaccountCountry%5D=FR&account-setup-A%5BdashboardType%5D=full&account-setup-A%5BtosType%5D=full&account-setup-A%5BlegalEntityType%5D=individual&account-setup-A%5BbusinessStructure%5D=undefined&account-setup-A%5Bcapabilities%5D=card_payments&account-setup-A%5BorrProgram%5D=eu-2025&account-setup-B%5BapiVersion%5D=v1&account-setup-B%5BplatformCountry%5D=US&account-setup-B%5BaccountCountry%5D=US&account-setup-B%5BdashboardType%5D=none&account-setup-B%5BtosType%5D=full&account-setup-B%5BlegalEntityType%5D=individual&account-setup-B%5BbusinessStructure%5D=undefined&account-setup-B%5Bcapabilities%5D=card_payments%2Ctransfers&account-setup-B%5BorrProgram%5D=undefined` - si un choix demandé a dû être modifié en raison de dépendances à des sélecteurs, indiquez-le explicitement avant de présenter les exigences - présentez les exigences actuellement dues séparément des exigences dues dans le futur, et étiquetez-les clairement - expliquez les puces de vérification en utilisant `extras[].value` comme source de vérité - mentionnez lorsqu’une exigence a été omise car elle ne correspondait à aucune des définitions de lignes de tableau de ce document - mentionnez lorsque les endpoints du site web ou du MCC n’ont renvoyé aucune donnée supplémentaire afin que l’utilisateur ne confonde pas cela avec un échec de récupération - si vous recevez des `validation_errors`, demandez à l’utilisateur de corriger les entrées de configuration en utilisant le [contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract) au lieu de le laisser deviner ce qu’il doit faire - si vous recevez des `build_errors`, relancez la requête. Si l’erreur persiste, informez l’utilisateur que l’endpoint d’assistance a échoué de manière inattendue