Tester la vérification des comptes lors de l'inscription via l'API
Ce document prend pour acquis que vous disposez d’une bonne connaissance du processus d’inscription via l’API, de la manière de mettre à jour les comptes, ainsi que de la vérification d’identité.
Testez vos flux de vérification pour vous assurer qu’ils peuvent prendre en charge les modifications de l’état du compte (par exemple, lorsque vous activez ou désactivez les paiements). Les états du compte évoluent en général une fois que les exigences sont remplies ou lorsque les seuils de traitement ou de temps sont atteints. Les sections ci-dessous décrivent ces modifications et comment tester vos flux de vérification.
Tester les exigences initiales
Commencez par créer un nouveau compte connecté en mode test, en ajoutant un compte bancaire et en indiquant que le titulaire du compte a accepté le contrat d’utilisation du service Stripe. Stripe exige que le compte connecté accepte explicitement les Conditions d’utilisation du service Stripe pour effectuer des virements. Dans cet exemple, le business_type
est paramétré sur company
pour illustrer un scénario plus complexe et le paramètre external_account
utilise un compte de test Stripe tokenisé afin d’éviter de dévoiler des informations sensibles dans les appels à l’API.
Note
Vous devez fournir une clé API de test à partir d’un compte Stripe qui a commencé l’inscription à la plateforme Connect. La clé API de test Stripe remplie automatiquement fait échouer ces exemples de requêtes.
Vous pouvez créer un compte Connecté en utilisant les propriétés du contrôleur ou en définissant le type de compte. Dans les deux cas, vous devez spécifier le pays du compte et demander les fonctionnalités card_payments
et transfers
.
À ce stade, le compte est créé, mais les paiements et les virements sont toujours désactivés. Dans la réponse, consultez le tableau requirements.currently_due
pour savoir quelles informations vous devez recueillir :
{ "id":
, "object": "account", "requirements": { "currently_due": [ "business_profile.mcc", "business_profile.url", "company.address.city", "company.address.line1", "company.address.postal_code", "company.address.state", "company.name", "company.phone", "company.tax_id", "relationship.representative", "relationship.owner" ], ... }, ... }"{{CONNECTED_ACCOUNT_ID}}"
Utilisez ensuite l’id
de compte externe renvoyé dans la réponse pour mettre à jour le compte en y ajoutant les informations supplémentaires requises :
Une fois les informations de l’entreprise mises à jour, les exigences de type relationship
sont toujours requises dans requirements.currently_due
:
{ "id":
, "object": "account", "requirements": { "currently_due": [ "relationship.representative", "relationship.owner", ], ... }, ... }"{{CONNECTED_ACCOUNT_ID}}"
Utilisez l’API Persons pour créer le profil de la personne représentant la relation avec le compte. Dans cet exemple, nous avons créé un profil pour Jenny Rosen et l’avais identifiée en tant que représentante du compte (representative
). Nous avons également saisi un attribut facultatif title
.
Note
Pour les comptes dont le paramètre business_type a la valeur individual
, vous devez fournir au moins une propriété de type individual
(p. ex., le prénom de la personne, individual.first_name
) afin que l’objet Person soit créé automatiquement. À défaut, ou pour les comptes dont le paramètre business_type
est company
, vous devez créer chaque objet Person du compte.
Lorsque vous créez un objet Person
, la réponse inclut un hachage requirements
. Celui-ci répertorie les informations de vérification requises pour cette personne.
{ "id":
, "object": "account", "requirements": { "currently_due": [ "address.city", "address.line1", "address.postal_code", "address.state", "dob.day", "dob.month", "dob.year", "phone", "email", "relationship.executive", "ssn_last_4" ], ... }, ... }"{{CONNECTED_ACCOUNT_ID}}"
Après avoir créé un objet Person
pour votre compte externe, vous pouvez constater que l’objet Account
indique que les informations de vérification requises pour l’objet Person
ainsi créé ont été ajoutées à la liste requirements.currently_due
:
{ "id":
, "object": "account", "requirements": { "currently_due": [ "person.person_xxx.address.city", "person.person_xxx.address.line1", "person.person_xxx.address.postal_code", "person.person_xxx.address.state", "person.person_xxx.dob.day", "person.person_xxx.dob.month", "person.person_xxx.dob.year", "person.person_xxx.phone", "person.person_xxx.email", "person.person_xxx.relationship.executive", "person.person_xxx.ssn_last_4", "relationship.owner" ], ... }, ... }"{{CONNECTED_ACCOUNT_ID}}"
Utilisez l’API Update a Person pour fournir les informations de vérification demandées pour Jenny Rosen :
En configurant relationship[executive]=true
, vous confirmez à Stripe que le représentant exerce un contrôle significatif au sein de l’organisation. La page sur les informations de vérification requises aux États-Unis contient plus d’informations sur les informations de vérification des représentants d’entreprises américaines.
Une fois les informations du representative
fournies, vous devez également fournir des informations sur le propriétaire (owner
) du compte. Dans cet exemple, Kathleen Banks détient 80 % de The Best Cookie Co.
Dans notre exemple, Kathleen Banks détient moins de 100 % de The Best Cookie Co. Étant donné que vous n’avez pas défini d’autre propriétaire pour aboutir à une propriété totale de 100 %, Stripe vous demande de confirmer que vous avez fourni des informations sur tous les propriétaires requis.
À ce stade, la création de votre compte connectée est réussie si :
- Vous avez fourni toutes les informations requises (
requirements.currently_due=null
). - Les paiements sont activés pour le compte (
charges_enabled=true
). - Vous avez reçu un webhook
account.updated
de Stripe.
Seuils de test
Que vous utilisiez une inscription complète ou progressive, Stripe peut demander plus d’informations sur les comptes connectés quand différents seuils sont déclenchés. Ces seuils peuvent être déclenchés par des échecs de vérification ou des vérifications OFAC. Ils peuvent également être déclenchés par un élément de traitement ou un élément temporel. Par exemple, vous pouvez exiger plus d’informations 30 jours après la création d’un compte, ou avant si l’utilisateur atteint 1 500 dollars de paiements. Pour déterminer les informations requises et leur date d’exigibilité, référez-vous au tableau requirements.eventually_due
et à l’horodatage requirements.current_deadline
.
Dans certains cas, si les nouvelles informations ne sont pas recueillies avant une certaine date, les paiements et virements peuvent être désactivés jusqu’à ce que les informations soient recueillies. Vous pouvez déclencher ces scénarios afin de pouvoir tester ces seuils, puis recueillir les informations requises.
Seuils de déclenchement
Vous pouvez créer un paiement avec le token de vérification (tok_visa_triggerVerification
) pour déclencher un seuil de vérification générique. Cela ne bloque pas les paiements ou les virements, mais déclenche la demande pour des informations supplémentaires. Si vous écoutez le webhook account.updated
, vous pouvez vérifier :
requirements.currently_due
pour savoir quelles informations sont requises.requirements.current_deadline
pour savoir quand les informations sont requises.
Si les informations ne sont pas recueillies avant la current_deadline
, les paiements et les virements peuvent être désactivés. Pour tester les scénarios comme ceux-là, référez-vous aux sections des paiements et des virements bloqués ci-dessous.
Vous pouvez aussi déclencher des seuils de vérification spécifiques, comme lorsqu’il y a une non-correspondance des identités ou lorsqu’un seuil de l’OFAC est atteint. Tester ces seuils est bénéfique car ils se produisent souvent lorsque la vérification échoue.
Tests des paiements bloqués
Vous pouvez bloquer des paiements en créant un paiement de test avec le token blocage des paiements (tok_visa_triggerChargeBlock
). Suite à cela, vous devriez recevoir un webhook account.updated
qui montre :
charges_enabled=false
.- Les informations requises du tableau
requirements.currently_due
. - Un tableau
requirements.eventually_due
vide.
Vous pouvez ensuite mettre à jour le compte en y ajoutant les nouvelles informations. Cela déclenche un autre webhook qui indique que les paiements sont activés et que les tableaux requirements.currently_due
et requirements.eventually_due
sont tous deux vides.
Tests des virements bloqués
Vous pouvez bloquer les virements en créant un paiement de test avec le token blocage des transferts (tok_visa_triggerTransferBlock
). Suite à cela, vous devriez recevoir un webhook account.updated
qui montre :
payouts_enabled=false
.- Les informations requises du tableau
requirements.currently_due
. - Un tableau
requirements.eventually_due
vide.
Vous pouvez ensuite mettre à jour le compte en y ajoutant les nouvelles informations. Cela déclenche un autre webhook qui indique que les virements sont activés et que les tableaux requirements.currently_due
et requirements.eventually_due
sont tous deux vides.