# Informations de vérification requises Déterminez les exigences actuelles et futures en matière de renseignements que les comptes connectés doivent fournir en fonction de leur entreprise, de leur emplacement et des capacités demandées. ## Instructions La version accessible aux utilisateurs de cette documentation permet de sélectionner les champs et les régions des comptes connectés au moyen d’un formulaire, puis d’effectuer des requêtes API pour récupérer et d’afficher les exigences qu’un compte connecté correspondant à la configuration et à la région sélectionnées doit satisfaire. Suivez les instructions ci-dessous pour récupérer les mêmes renseignements. ### Contrat d’interaction Terminologie utilisée dans ce document : - `champ` : une entrée de configuration comme `platformCountry`, `accountCountry` ou `capabilities` - `option` : une option sélectionnable présentée pour un champ - `valeur` : l’option sélectionnée par l’utilisateur, ou la valeur de réponse libre fournie par l’utilisateur 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 à format libre ou n’attendez pas une saisie brute par clavardage - si vous avez besoin d’une réponse libre de l’utilisateur, demandez-lui d’utiliser le champ de réponse libre de la question - pour les longues listes d’options, précisez explicitement que toute valeur de la liste complète validée est toujours acceptée dans 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 de nouveau la question ### Règles strictes Vous devez suivre ces règles : - Demander un champ *uniquement* après que tous ses champs préalables ont été remplis. - Collecter progressivement les champs de configuration au fur et à mesure que le flux avance. - Demander un champ à la fois, ou un groupe de champs uniquement lorsqu’ils sont libres de dépendances à ce stade du flux. - Par exemple, demander séparément `platformCountry` et `accountCountry` : le pays de la plateforme détermine quels pays de compte sont valides, il est donc possible de générer des combinaisons non valides en demandant les deux en même temps. Mais vous pouvez demander ensemble `dashboardType`, `conditions d’utilisation du service` et `legalEntityType` dans un même 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 l’alignement de la configuration validée avec ce que l’utilisateur a demandé, sans omettre 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 est supérieur à quatre, imprimer *toujours* la liste de référence complète validée avant de poser la question à choix multiples afin que l’utilisateur puisse voir l’espace des options au complet. - Lorsque vous imprimez des pays, imprimer toujours le nom complet du pays suivi de son code entre parenthèses, p. ex., `Allemagne (DE)`. - Utiliser des pays précis dans les options de sélection rapide pour que l’utilisateur puisse avancer d’emblée de manière claire. - Laisser vides les descriptions des options de sélection rapide par pays. - Pour tout champ comportant un petit ensemble d’options valides, affichez à l’utilisateur chaque option valide. - Chaque liste d’options sélectionnables affichée à l’utilisateur doit être préalablement validée par rapport à toutes les contraintes actuellement connues avant d’être affichée. - Ne jamais afficher une option comme pouvant être sélectionnée si vous savez déjà qu’elle sera supprimée, rejetée ou ajustée automatiquement plus tard dans le flux. - Présenter les options qui restent valides tout au long du flux actuel. - Demander les `fonctionnalités` une fois que `platformCountry`, `accountCountry` et les contraintes de validité en aval de cette configuration ont été résolues. - Demander `orrProgram` *uniquement* lorsqu’il est présent dans le domaine public des `programs` renvoyés pour la configuration validée. - Si la carte `businessStructure` pour le `legalEntityType` choisi est vide ou contient exactement une clé `nil`, passer le champ `businessStructure`. Autrement, demander l’information du champ `businessStructure` et autoriser toujours l’option `none` laisser l’option non 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 antérieur comme `platformCountry`, vous devez invalider et revérifier tous les champs en aval avant de poursuivre. - Maintenir la chaîne de dépendance implicite. Partager l’information dont l’utilisateur a besoin pour progresser et faire en sorte que l’expérience reste simple. - Utiliser un langage adapté aux communications externes lorsque vous parlez avec l’utilisateur. 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 | | `conditions d’utilisation du service` | Contrat d’utilisation du service | | `legalEntityType` | Type d’entreprise | | `businessStructure` | Structure de l’entreprise | | `Capacités :` | Capacités | | `orrProgram` | Mise à jour des exigences | | `eu2025` | Europe | ### Chaîne de dépendance Vous devez suivre exactement la chaîne de dépendance ci-dessous : ```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éter le diagramme de façon littérale : - Demander un nœud *uniquement* après que toutes ses dépendances entrantes ont été résolues. - Demander toujours à l’utilisateur de fournir d’abord la valeur `apiVersion`. Recommander la valeur `v2` par défaut. ### Données dont vous aurez besoin à un certain stade Au moment de faire la dernière requête concernant les exigences, vous devez disposer d’une valeur validée pour : - `apiVersion` : `v1` ou `v2` - `platformCountry` - `accountCountry` - `dashboardType` - `conditions d’utilisation du service` - `legalEntityType` - `fonctionnalité` : au moins une fonction doit être sélectionnée Si nécessaire, vous auriez également dû demander les champs optionnels suivants : - `businessStructure` : demander seulement lorsque `legalEntityType` n’est pas `particulier` - `orrProgram` : demander seulement s’il est présent dans la liste publique `programs` pour cette configuration validée ### Résoudre les capacités Utiliser cet algorithme chaque fois que vous créez ou validez la liste des capacités : 1. Commencer par `country_map[accountCountry].capabilities`. 2. Appliquer les règles `conditions d’utilisation du service` : - si `tosType=recipient`, forcer `transfers` et supprimer toutes les autres capacités, à l’exception de `crypto_transfers`, qui peut être disponible dans de rares cas - si `apiVersion=v1` et que `crypto_transfers` est sélectionné, inclure également `transfers` 3. Si `apiVersion=v2`, supprimer toute capacité non présente dans `get-v2-supported-v1-capabilities`. 4. Afficher à l’utilisateur la liste filtrée des capacités. Lorsque l’utilisateur demande explicitement une capacité filtrée, expliquer clairement que la capacité demandée n’est pas disponible pour la configuration actuelle. 5. Si la liste filtrée est vide, informer l’utilisateur qu’aucune capacité n’est prise en charge pour la configuration actuelle et lui demander de revoir ses choix de configuration précédents à l’aide du [contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract) avant d’effectuer la requête finale des exigences. 6. Lorsque vous posez des questions sur les `capacités`, afficher d’abord la liste complète filtrée, puis poser une question à choix multiples qui inclut le ou les choix les plus probables en fonction du contexte antérieur de l’utilisateur. 7. Si l’utilisateur demande une capacité qui ne figure pas dans la liste filtrée, expliquer pourquoi elle n’est pas disponible pour la configuration actuelle. - Gardez la capacité demandée par l’utilisateur visible dans la conversation et expliquer l’incompatibilité directement. Par exemple, si l’utilisateur demande `paypal_payments`, mais a également sélectionné les comptes `v2`, expliquer que `paypal_payments` n’est pas disponible pour les comptes `v2`, et lui offrir le choix de passer à `apiVersion` `v1` et de choisir `paypal_payments`, ou de conserver `apiVersion` `v2` et de choisir une capacité différente. ### Flux de l’agent Lorsque l’utilisateur demande quelles informations de vérification sont nécessaires, utilisez ce flux : 1. Demander `apiVersion`. Recommander `v2`. 2. Récupérer `https://docs.stripe.com/_endpoint/get-platform-countries` et utilisez la liste des pays pris en charge publics pour demander le `platformCountry`. 3. Récupérer `https://docs.stripe.com/_endpoint/get-v2-supported-v1-capabilities` si `apiVersion=v2`. 4. Récupérer `https://docs.stripe.com/_endpoint/get-requirement-selections-for-platform-country?platformCountry=...` à l’aide du `platformCountry` choisi. 5. Demander `accountCountry` à partir des clés `country_map` retournées. 6. Une fois `accountCountry` validé, demander : - `dashboardType` - `conditions d’utilisation du service` - `legalEntityType` 7. Une fois `legalEntityType` choisi, demander `businessStructure` si la carte de structure validée l’expose. 8. Résoudre et demander des `capacités` en utilisant [Résoudre les capacités](https://docs.stripe.com/connect/required-verification-information.md#resolve-capabilities). 9. Demander `orrProgram` seulement si la configuration validée expose au moins un programme publics. 10. Si la configuration demandée par l’utilisateur ne correspond pas aux options valides, indiquer précisément quelles parties sont invalides ou ajustées automatiquement, puis poser la question de suivi corrective à l’aide du [contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract). Garder le décalage visible, maintenir la configuration fondée sur la demande de l’utilisateur et poursuivre avec une question de suivi structurée. 11. Seulement après que la configuration a été validée, appeler `https://docs.stripe.com/_endpoint/get-requirements-for-setups` avec une clé de configuration de niveau supérieur `account-setup-A[...]`, y compris `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’optionnel `account-setup-A[businessStructure]`, au moins un `account-setup-A[capabilities][i]` et l’optionnel `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 capacités validées finales pour vérifier les informations supplémentaires. S’il vous est demandé de comparer deux configurations ou ce qu’il faut pour mettre à jour de X à Y, vous devez répéter le même flux de validation indépendamment pour la configuration A et la configuration B avec une deuxième clé de niveau supérieur `account-setup-B[...]` avant d’appeler la requête d’exigences différenciables. Traiter les échecs de transport ou de construction comme des échecs d’assistance avec possibilité de nouvelle tentative, et réserver les conclusions de configuration non prise en charge aux récupérations préalables réussies et aux résultats de validation commerciale. ### Exemples cURL Dans ces exemples, définir l’hôte de la documentation sur le site public : ```bash DOCS_HOST="https://docs.stripe.com" ``` #### Utilisateur novice : « Quelles informations dois-je vérifier pour un compte connecté Stripe? » Demander `apiVersion`. Recommander `v2`. Obtenez la liste publique des pays de la plateforme : ```bash curl --get "$DOCS_HOST/_endpoint/get-platform-countries" ``` Demande’ à l’utilisateur quelle valeur de `platformCountry` il souhaite utiliser. Ensuite, récupérer les options autorisées pour ce pays de 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 ait choisi `US` : ```bash curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country" \ --data-urlencode "platformCountry=US" ``` Une fois cette réponse retournée, collecter 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 avancé : « J’ai une plateforme CA, et je veux inscrire un compte connecté d’entreprise FR pour utiliser les paiements par carte » Demander `apiVersion`. Recommander `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érifier d’abord que FR est un pays de compte valide, puis lire : - `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, confirmer que la configuration demandée par l’utilisateur correspond bien à ces options disponibles. Si l’utilisateur souhaite `apiVersion=v2`, récupérer et appliquer d’abord le filtre de capacité v2 pour comparer avec les capacités demandées par l’utilisateur : ```bash curl --get "$DOCS_HOST/_endpoint/get-v2-supported-v1-capabilities" ``` Seulement lorsque la configuration demandée par l’utilisateur correspond à ces options disponibles, appeler le point de terminaison des exigences. Le point de terminaison des exigences 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" ``` En option, puisque `.programs` est présent pour cette configuration, vous pouvez demander à l’utilisateur s’il souhaite choisir une mise à jour des exigences et ajouter `--data-urlencode "account-setup-A[orrProgram]=eu-2025"` à la requête. Utiliser cette réponse pour présenter les exigences à l’utilisateur comme expliqué dans la section [Construire le résultat](https://docs.stripe.com/connect/required-verification-information.md#construct-the-result). Obtenir les tables supplémentaires facultatives pour les capacité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" ``` ### Lire les réponses de l’API Utiliser `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 Utiliser `get-requirement-selections-for-platform-country` pour valider la configuration avant d’appeler le point de terminaison d’exigences principal : - `country_map` est la source de vérité pour les valeurs de champ qui sont valides pour cette valeur `platformCountry` - les clés de `country_map` sont les options `accountCountry` autorisées - `country_map[ACCOUNT_COUNTRY].dashboard_types` contraint `dashboardType` - `country_map[ACCOUNT_COUNTRY].tos_types` contraint `tosType` - `country_map[ACCOUNT_COUNTRY].entity_type_structures` contraint `legalEntityType` et facultatif `businessStructure` - `country_map[ACCOUNT_COUNTRY].capabilities` limite les choix de capacités - `country_map[ACCOUNT_COUNTRY].programs` répertorie les seuls programmes ORR publics pouvant être transmis en tant que `orrProgram` - `external_country_map` doit être ignoré Appliquer ces règles de dépendance avant de formuler la requête finale : - si vous modifiez `accountCountry`, vérifiez de nouveau toutes les sélections en aval - si vous modifiez `legalEntityType`, vérifiez de nouveau `businessStructure` - si vous modifiez `accountCountry`, `conditions d’utilisation du service` ou `apiVersion`, exécuter de nouveau [Resolve capabilities](https://docs.stripe.com/connect/required-verification-information.md#resolve-capabilities) Utiliser `get-requirements-for-setups` comme source principale de données relatives aux exigences : - `requirements` contient le résultat de la réussite pour 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 le point de terminaison a échoué de manière inattendue lors de la construction du résumé; vous devez traiter cette erreur comme une erreur réitérable plutôt que comme une conclusion métier Dans chaque résultat de configuration réussi : - `requirements[field_name]` correspond aux données des exigences pour un seul champ brut, y compris les limites d’application, les alternatives, les métadonnées d’affichage et les annotations connexes utilisées par le moteur de rendu de la documentation - `extras` contient des étiquettes lisibles par une personne et des conseils de validation pour cette exigence - `requirement_tags` contient des balises d’exigence de niveau supérieur renvoyées avec les données sur les exigences - `requirement_groups` contient les données sur les exigences groupées renvoyées avec les données sur les exigences Vérifier les points de terminaison supplémentaires pour voir s’il y a d’autres restrictions propres aux capacités à présenter à l’utilisateur. - `requirements_by_capability` du point de terminaison du site Web est un tableau des exigences du site Web distinct qui explique les exigences que le site Web du compte connecté doit respecter pour prendre en charge la capacité sélectionnée. Ces exigences doivent être présentées à l’utilisateur dans un tableau distinct. - `restrictions_by_capability` du point de terminaison du code de catégorie de marchand (MCC) est un tableau des restrictions du code de catégorie de marchand distinct qui explique les exigences que le code de catégorie de marchand du compte connecté doit respecter pour prendre en charge la fonctionnalité sélectionnée. Si ce point de terminaison renvoie des restrictions, posez des questions à l’utilisateur sur le type d’entreprise qu’il dirige pour déterminer si son type d’entreprise est interdit ou limité quant à l’utilisation de la capacité en question. - Les mappages vides sont des résultats valides pour de nombreuses capacités standard et ne constituent pas des erreurs ### Construire le résultat Transformer la réponse de l’API en au moins un tableau lisible par une personne dans votre propre réponse à l’utilisateur, suivis de toute note explicative supplémentaire. Il s’agit de tableaux de sortie que vous construisez à partir des données de la réponse, et non de références à des tableaux préexistants sur la page de la documentation destinée aux humains. ##### Comment construire les tableaux : 1. Répartir chaque clé de champ brut dans une section à l’aide de son préfixe : - `company.*` -> `company` - `documents.*` -> `documents` - `individual.*` -> `individual` - `representative.*` -> `representative` - `directors.*` -> `directors` - `owners.*` -> `owners` - `executives.*` -> `executives` - tout autre élément -> `account` 2. Présenter un tableau pour chaque section non vide. Ne pas regrouper plusieurs sections dans un seul tableau. 3. Pour chaque tableau : - utiliser le nom de la section comme en-tête de tableau, par exemple `Account`, `Company`, `Representative`, `Directors` ou `Owners` - Inclure les colonnes suivantes : - En-tête : vide - Contenu : Nom d’affichage de la ligne, par exemple « Nom », « Date de naissance », « Adresse » - En-tête : `Exigence` - Contenu : une liste à puces de champs affichés - Afficher une puce par champ affiché - Afficher chaque champ dans le formatage de code - Si un champ comporte des solutions de rechange, les conserver dans la même puce et les présenter sous forme de disjonction, par exemple `field_a` ou `field_b` - En-tête : `Vérification` - Contenu : une liste à puces à partir de `extras[].value` - Présenter chaque entrée `extras[].value` sous forme de puce - Si `extras` est vide, laisser l’entrée vide - En-tête : `Action d’application` - Contenu : texte d’application lisible par une personne à partir des deux ensembles de champs de limites - Utiliser d’abord les champs de limite non vérifiés pour générer les messages `si non fournis` : - `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 les messages `si non vérifié` : - `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 un montant limite ou une durée limite est `<= 0`, traiter cet impact comme immédiat - S’il existe à la fois une limite de temps et une limite de montant pour le même impact, les joindre avec `ou` - Regrouper les impacts ayant des seuils identiques en une seule phrase, par exemple `Les fonctions, les paiements et les versements seront suspendus immédiatement s’ils ne sont pas fournis.` - S’il existe à la fois le texte `si non fourni` et `si non vérifié`, afficher d’abord la ou les phrases `si non fourni`, puis la ou les phrases `si non vérifié`; précéder la première phrase de vérification de `De plus,` - Si aucun des ensembles de limites n’est présent, afficher `—` 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 toutes deux la famille de définitions de lignes `person`, mais elles s’affichent sous forme de tableaux `Representative` et `Owners` distincts parce qu’il s’agit de sections différentes. 5. Attribuer 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 mises en correspondance 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 toute section autre que `account`, supprimer le préfixe de la section avant d’appliquer les règles de correspondance des lignes. Par exemple, faites correspondre `representative.first_name` à `first_name` et `company.address.city` à `address.city`. 7. Utiliser les définitions de lignes ci-dessous pour la famille de définitions de lignes de cette section. Créer 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 marchand : `/business_profile.mcc/` URL : `/business_profile.(url|requirement)/` Description du produit : `/business_profile.product_description/` Numéro de téléphone du service d’assistance : `/business_profile.support_phone/` Libellés de relevé de compte : `/settings.payments.statement_descriptor/` - /settings.card_payments.statement_descriptor/ Adresse de courriel du service d’assistance Konbini : `/settings.konbini_payments.support_email/` Numéro de téléphone du service d’assistance Konbini : `/settings.konbini_payments.support_phone/` Heures d’ouverture du service d’assistance Konbini : `/settings.konbini_payments.support_hours/` Conditions d’utilisation du service : `/^tos_acceptance\./` Conditions d’utilisation du service de l’émissioncard_payments : `/settings\.card_issuing\.tos_acceptance\./` Nombre estimé de travailleurs : `/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 d’identification fiscale de l’entreprise : `/tax_id/` Numéro d’inscription 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 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/` Pseudonymes : `/full_name_aliases/` Date de naissance : `/dob\./` Adresse : `/^address\./` Adresse (kana) : `/address_kana/` Adresse (kanji) : `/address_kanji/` Adresse enregistrée : `/registered_address/` Courriel : `/email/` Téléphone : `/phone/` Genre : `/gender/` Exposition politique : `/political_exposure/` Informations fiscales : `/ssn_last_4$/` ou `/id_number$/` Numéro d’identification secondaire : `/(id_number_secondary)/` Titre 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`, remplacer chaque champ affiché par `v2_field_name` et utiliser `v2_alternatives`. 2. Si `apiVersion=v2` et qu’une exigence n’expose pas `v2_field_name`, omettre ce champ du tableau rendu. Si cela supprime tous les champs d’un groupe de lignes, omettre la ligne. Si une section devient vide, omettre le tableau de cette section. ##### Comment construire le résumé de style JSON : - si l’utilisateur demande un résumé JSON des éléments requis, retourner un objet JSON de cette forme exacte : ```json { "requirements": { "currently_due": [ "configuration.merchant.mcc" ], "eventually_due": [] } } ``` - remplir `requirements.currently_due` avec les noms des champs d’exigences qui sont actuellement dus et `requirements.eventually_due` avec les noms des champs d’exigences qui sont futurs ou éventuels - pour `apiVersion=v2`, utiliser les valeurs de `v2_field_name` dans les deux tableaux; pour `apiVersion=v1`, utiliser les noms bruts des champs d’exigence - la vue des différences JSON compare uniquement les noms des exigences; elle ne compare pas le texte de vérification, les seuils ou les métadonnées supplémentaires ### Comment répondre aux utilisateurs Lorsque vous retournez des résultats à l’utilisateur : - réitérer la configuration validée exacte que vous avez interrogée, y compris `apiVersion`, `platformCountry`, `accountCountry`, `dashboardType`, `tosType`, `legalEntityType`, `businessStructure` facultatif, `capabilities` sélectionnées et `orrProgram` facultatif - fournir toujours à l’utilisateur un lien contenant les paramètres de requête d’URL exacts que vous avez utilisés afin qu’il puisse voir les exigences par lui-même 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 des dépendances des sélecteurs, dites-le explicitement avant de présenter les exigences - présenter les exigences actuellement dues séparément des exigences éventuellement dues et des exigences futures, et les étiqueter clairement - expliquer les puces de vérification en utilisant `extras[].value` comme source de vérité - mentionner lorsqu’une exigence a été omise parce qu’elle ne correspondait à aucune des définitions de lignes de tableau de ce document - mentionner lorsque les points de terminaison du site Web ou du code de catégorie de marchand n’ont retourné 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`, demander à l’utilisateur de corriger les entrées de configuration à l’aide du [contrat d’interaction](https://docs.stripe.com/connect/required-verification-information.md#interaction-contract) au lieu de deviner - si vous recevez des `build_errors`, réessayer la requête et indiquer à l’utilisateur que le point de terminaison d’aide a échoué de manière inattendue si l’erreur persiste