connect-required-verification-information

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Instructions

操作说明

The human-accessible version of this documentation allows the user to select connected account fields and regions using a form, and then makes API requests to fetch and display the requirements a connected account with the selected configuration and region must provide. Follow these instructions to fetch the same information.

本文档的人工可读版本允许用户通过表单选择关联账户字段和地区，然后发起API请求来获取并显示所选配置和地区的关联账户必须提供的要求。请按照以下说明获取相同信息。

Interaction contract

交互约定

Terminology used in this document:

field

: a setup input such as

platformCountry

accountCountry

, or

capabilities

```
option
```
: a presented selectable option for a field
```
value
```
: the option the user selects, or the free-response value the user provides for a field

Every time you ask the user to provide a value for a field:

use a multiple-choice question; never stop at a plain free-form prompt or wait for raw chat input
if you need free user input, instruct the user to use the question’s free-response field
for long option lists, explicitly say that any value from the full validated list is still accepted through the free-response field
if the user already provided a valid answer in an earlier message, use that instead of asking again

本文档中使用的术语：

field

：配置输入项，例如

platformCountry

、

accountCountry

或

capabilities

```
option
```
：某个字段提供的可选选项
```
value
```
：用户选择的选项，或用户为某个字段提供的自由响应值

每次要求用户提供某个字段的值时：

使用选择题形式；绝不要停留在纯自由输入提示或等待原始聊天输入
如果需要用户自由输入，指导用户使用问题的自由响应字段
对于较长的选项列表，明确说明完整验证列表中的任何值仍可通过自由响应字段提交
如果用户在之前的消息中已提供有效答案，直接使用该答案而不是再次询问

Hard rules

硬性规则

You must follow these rules:

Ask for a field only after all of its prerequisite fields are satisfied.
Collect setup fields progressively as the flow advances.
Ask for one field at a time, or one group of fields only when they are dependency-free at that point in the flow.
- For example, ask for
```
platformCountry
```
  and
```
accountCountry
```
  separately: the platform country determines which account countries are valid, so asking both together can produce invalid combinations. But you may ask for
```
dashboardType
```
  ,
```
tosType
```
  , and
```
legalEntityType
```
  together in one group because their valid options are already known from the same response.
If there is ever a conflict between the user’s request and the validated setup, inform the user of the conflict and ask them to revise their setup choices using the Interaction contract. Keep the validated setup aligned with what the user requested without silently dropping the conflict.
Follow the Interaction contract for every user question.
When the number of available options exceeds four, always print the full validated reference list before asking the multiple-choice question so the user can see the full option space.
- When printing countries, always print the full country name followed by its code in parentheses, for example,
```
Germany (DE)
```
  .
- In the multiple-choice question, include a small set of suggested options so the user can move forward with immediate clarity. The reference list above remains the authoritative full set.
- Leave the descriptions for the country suggested options blank.
For any field with four or fewer valid options, show every valid option directly in the multiple-choice question. Do not print a separate reference list first.
Every list of selectable options shown to the user must be pre-validated against all currently known constraints before you display it.
Never display an option as selectable if you already know it will be removed, rejected, or auto-adjusted later in the flow.
- Present options that stay valid through the current flow.
Ask about
```
capabilities
```
after
```
platformCountry
```
,
```
accountCountry
```
, and the downstream validity constraints for that setup are resolved.
Only ask about
```
orrProgram
```
when it is present in the public
```
programs
```
returned for the validated setup.
If the
```
businessStructure
```
map for the chosen
```
legalEntityType
```
is empty or contains exactly one key
```
nil
```
, skip
```
businessStructure
```
. Otherwise, ask for
```
businessStructure
```
and always allow a
```
none
```
option or leave unselected as a suggested option in the multiple-choice question.
If the user decides to change an earlier choice like
```
platformCountry
```
, you must invalidate and re-check all downstream fields before continuing.
Keep the dependency chain implicit. Share the information the user needs to make progress and keep the experience simple.
Use external-facing language when talking to the user. See below to translate the internal API terminology.

您必须遵循以下规则：

仅在所有前置字段都已满足后，才询问该字段。
随着流程推进逐步收集配置字段。
一次询问一个字段，或者仅在某一阶段无依赖关系的一组字段。
- 例如，分开询问
```
platformCountry
```
  和
```
accountCountry
```
  ：平台国家决定了哪些账户国家是有效的，因此同时询问两者可能会产生无效组合。但您可以在同一组中询问
```
dashboardType
```
  、
```
tosType
```
  和
```
legalEntityType
```
  ，因为它们的有效选项已从同一响应中获知。
如果用户的请求与已验证的配置存在冲突，请告知用户冲突情况，并要求他们使用交互约定修改配置选择。保持已验证的配置与用户请求一致，不要静默忽略冲突。
对每个用户问题都遵循交互约定。
当可用选项数量超过四个时，必须在提出选择题之前打印完整的验证参考列表，以便用户查看所有选项范围。
- 打印国家时，始终打印完整的国家名称及其代码（括号内），例如
```
Germany (DE)
```
  。
- 在选择题中，包含一小部分建议选项，以便用户可以立即明确地继续操作。上方的参考列表仍是权威的完整集合。
- 国家建议选项的描述留空。
对于任何有四个或更少有效选项的字段，直接在选择题中显示所有有效选项。不要先打印单独的参考列表。
向用户显示的所有可选选项列表必须在显示前根据当前已知的所有约束条件预先验证。
如果您已知某个选项在后续流程中会被移除、拒绝或自动调整，绝不要将其显示为可选选项。
- 展示在当前流程中始终有效的选项。
在解决
```
platformCountry
```
、
```
accountCountry
```
以及该配置的下游有效性约束后，再询问
```
capabilities
```
。
仅当已验证配置返回的公开
```
programs
```
中包含
```
orrProgram
```
时，才询问该字段。
如果所选
```
legalEntityType
```
对应的
```
businessStructure
```
映射为空或仅包含一个键
```
nil
```
，则跳过
```
businessStructure
```
。否则，询问
```
businessStructure
```
，并在选择题中始终提供
```
none
```
选项或未选中的建议选项。
如果用户决定更改早期选择（如
```
platformCountry
```
），您必须在继续之前作废并重新检查所有下游字段。
保持依赖链隐含。向用户提供推进流程所需的信息，保持体验简洁。
与用户交流时使用对外的语言。请参考下文将内部API术语转换为对外语言。

Internal fields -> External language

内部字段 -> 对外语言

Internal field	External language
`apiVersion`	Accounts API version
`platformCountry`	Platform country
`accountCountry`	Account country
`dashboardType`	Dashboard type
`tosType`	Service agreement
`legalEntityType`	Business type
`businessStructure`	Business structure
`capabilities`	Capabilities
`orrProgram`	Requirements update
`eu2025`	Europe

内部字段	对外语言
`apiVersion`	Accounts API版本
`platformCountry`	平台国家
`accountCountry`	账户所属国家
`dashboardType`	控制台类型
`tosType`	服务协议
`legalEntityType`	业务类型
`businessStructure`	业务结构
`capabilities`	功能
`orrProgram`	要求更新
`eu2025`	欧洲

Dependency chain

依赖链

You must follow this dependency chain exactly:

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

Interpret the diagram literally:

Ask for a node only after all of its incoming dependencies are resolved.
Always ask the user for
```
apiVersion
```
first. Recommend
```
v2
```
by default.

您必须严格遵循以下依赖链：

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

按字面意思解读该图：

仅在所有传入依赖项都已解决后，才询问该节点。
始终首先询问用户
```
apiVersion
```
。默认推荐
```
v2
```
。

Inputs you eventually need

最终需要的输入

By the time you make the final requirements request, you must have validated values for all of the following fields:

```
apiVersion
```
:
```
v1
```
or
```
v2
```
```
platformCountry
```
```
accountCountry
```
```
dashboardType
```
```
tosType
```
```
legalEntityType
```
```
capabilities
```
: at least one capability must be selected

You also must have asked for the following optional fields, if they’re applicable:

businessStructure

: ask only when

legalEntityType

is not

individual

```
orrProgram
```
: ask only when present in the public
```
programs
```
list for that validated setup

在发起最终要求请求时，您必须已获取以下所有字段的验证值：

```
apiVersion
```
：
```
v1
```
或
```
v2
```
```
platformCountry
```
```
accountCountry
```
```
dashboardType
```
```
tosType
```
```
legalEntityType
```
```
capabilities
```
：必须选择至少一个功能

您还必须询问以下可选字段（如果适用）：

businessStructure

：仅当

legalEntityType

不是

individual

时询问

```
orrProgram
```
：仅当该已验证配置的公开
```
programs
```
列表中包含该字段时询问

Resolve capabilities

解析功能

Use this algorithm whenever you build or validate the capability list:

Start from

country_map[accountCountry].capabilities

Apply
```
tosType
```
rules:
- if
```
tosType=recipient
```
  , force
```
transfers
```
  and remove all other capabilities except
```
crypto_transfers
```
  , which may be available in rare cases
- if
```
apiVersion=v1
```
  and
```
crypto_transfers
```
  is selected, also include
```
transfers
```

apiVersion=v2

, drop any capability not present in

get-v2-supported-v1-capabilities

Show the user the filtered capability list. When the user explicitly asks about a filtered-out capability, clearly explain that the asked-for capability is unavailable for the current setup.
If the filtered list is empty, tell the user that no capabilities are supported for the current setup and ask them to revise earlier setup choices using the Interaction contract before making the final requirements request.
When asking about
```
capabilities
```
, print the full filtered list first, then ask a multiple-choice question that includes the most likely choice or choices based on prior user context.
If the user asks for a capability outside the filtered list, explain why it is unavailable for the current setup.

Keep the user’s requested capability visible in the conversation and explain the incompatibility directly. For example, if the user asks for
```
paypal_payments
```
, but also selected
```
v2
```
accounts, explain that
```
paypal_payments
```
is unavailable for
```
v2
```
accounts, and offer them the choice of switching to
```
apiVersion
```
```
v1
```
and choosing
```
paypal_payments
```
, or remaining with
```
apiVersion
```
```
v2
```
and choosing a different capability.

每当构建或验证功能列表时，请使用以下算法：

从

country_map[accountCountry].capabilities

开始。

应用
```
tosType
```
规则：
- 如果
```
tosType=recipient
```
  ，强制选择
```
transfers
```
  并移除所有其他功能（
```
crypto_transfers
```
  除外，在极少数情况下可能可用）
- 如果
```
apiVersion=v1
```
  且选择了
```
crypto_transfers
```
  ，则同时包含
```
transfers
```

如果

apiVersion=v2

，移除所有不在

get-v2-supported-v1-capabilities

中的功能。

向用户显示过滤后的功能列表。当用户明确询问被过滤掉的功能时，清楚地解释该功能在当前配置下不可用。
如果过滤后的列表为空，请告知用户当前配置不支持任何功能，并要求他们在发起最终要求请求前使用交互约定修改早期配置选择。
询问
```
capabilities
```
时，先打印完整的过滤列表，然后根据用户之前的上下文提出包含最可能选择的选择题。
如果用户询问过滤列表之外的功能，解释该功能在当前配置下不可用的原因。

保持用户请求的功能在对话中可见，并直接解释不兼容性。例如，如果用户询问
```
paypal_payments
```
，但同时选择了
```
v2
```
账户，解释
```
paypal_payments
```
在
```
v2
```
账户中不可用，并提供选择：切换到
```
apiVersion
```
```
v1
```
并选择
```
paypal_payments
```
，或者保持
```
apiVersion
```
```
v2
```
并选择其他功能。

Agent flow

代理流程

When the user asks what verification information they need, use this flow:

Ask for
```
apiVersion
```
. Recommend
```
v2
```
.

Fetch

https://docs.stripe.com/_endpoint/get-platform-countries

and use the public supported list to ask for

platformCountry

Fetch

https://docs.stripe.com/_endpoint/get-v2-supported-v1-capabilities

apiVersion=v2

Fetch

https://docs.stripe.com/_endpoint/get-requirement-selections-for-platform-country?platformCountry=...

with the chosen

platformCountry

Ask for
```
accountCountry
```
from the returned
```
country_map
```
keys.

After

accountCountry

is validated, ask for:

```
dashboardType
```
```
tosType
```
```
legalEntityType
```

After
```
legalEntityType
```
is chosen, ask for
```
businessStructure
```
if the validated structure map exposes it.
Resolve and ask for
```
capabilities
```
using Resolve capabilities.
Ask for
```
orrProgram
```
only if the validated setup exposes one or more public programs.
If the user’s requested setup doesn’t match the valid options, tell them exactly which parts are invalid or auto-adjusted, then ask the correcting follow-up using the Interaction contract. Keep the mismatch visible, keep the setup grounded in the user’s request, and continue with a structured follow-up question.

Only after the setup is valid, call

https://docs.stripe.com/_endpoint/get-requirements-for-setups

with one top-level setup key

account-setup-A[...]

, including

account-setup-A[apiVersion]

account-setup-A[platformCountry]

account-setup-A[accountCountry]

account-setup-A[dashboardType]

account-setup-A[tosType]

account-setup-A[legalEntityType]

, optional

account-setup-A[businessStructure]

, one or more

account-setup-A[capabilities][i]

, and optional

account-setup-A[orrProgram]

At the end, you must call

https://docs.stripe.com/_endpoint/get-website-requirements-for-capabilities?capabilities[i]=...

and

https://docs.stripe.com/_endpoint/get-mcc-restrictions-for-capabilities?capabilities[i]=...

with the final validated capabilities to check for additional information.

If you are asked to compare two setups or are asked what is needed to update from X to Y, you must follow the validation flow for setup A with a top-level

account-setup-A[...]

key and then follow the flow again for setup B with a second top-level key

account-setup-B[...]

before calling the diffable requirements request.

Treat transport or build failures as retryable helper failures, and reserve unsupported-setup conclusions for successful prerequisite fetches and business validation results.

当用户询问需要哪些验证信息时，请使用以下流程：

询问
```
apiVersion
```
。推荐
```
v2
```
。

调用

https://docs.stripe.com/_endpoint/get-platform-countries

，使用返回的公开支持列表询问

platformCountry

。

如果

apiVersion=v2

，调用

https://docs.stripe.com/_endpoint/get-v2-supported-v1-capabilities

。

使用所选的

platformCountry

调用

https://docs.stripe.com/_endpoint/get-requirement-selections-for-platform-country?platformCountry=...

。

从返回的
```
country_map
```
键中询问
```
accountCountry
```
。

在

accountCountry

验证通过后，询问：

```
dashboardType
```
```
tosType
```
```
legalEntityType
```

在选择
```
legalEntityType
```
后，如果已验证的结构映射中包含
```
businessStructure
```
，则询问该字段。
使用解析功能解析并询问
```
capabilities
```
。
仅当已验证配置公开一个或多个公开程序时，询问
```
orrProgram
```
。
如果用户请求的配置与有效选项不匹配，请准确告知哪些部分无效或已自动调整，然后使用交互约定提出纠正性跟进问题。保持不匹配情况可见，确保配置符合用户请求，并继续提出结构化的跟进问题。

仅当配置有效后，调用

https://docs.stripe.com/_endpoint/get-requirements-for-setups

，传入顶级配置键

account-setup-A[...]

，包括

account-setup-A[apiVersion]

、

account-setup-A[platformCountry]

、

account-setup-A[accountCountry]

、

account-setup-A[dashboardType]

、

account-setup-A[tosType]

、

account-setup-A[legalEntityType]

、可选的

account-setup-A[businessStructure]

、一个或多个

account-setup-A[capabilities][i]

以及可选的

account-setup-A[orrProgram]

。

最后，必须调用

https://docs.stripe.com/_endpoint/get-website-requirements-for-capabilities?capabilities[i]=...

和

https://docs.stripe.com/_endpoint/get-mcc-restrictions-for-capabilities?capabilities[i]=...

，传入最终验证后的功能以检查额外信息。

如果您被要求对比两个配置，或者被询问从X更新到Y需要什么，您必须先为配置A遵循验证流程（使用顶级键

account-setup-A[...]

），然后为配置B再次遵循流程（使用第二个顶级键

account-setup-B[...]

），再调用可对比的要求请求。

将传输或构建失败视为可重试的辅助失败，仅在成功完成前置请求和业务验证后才得出不支持配置的结论。

curl examples

curl示例

In these examples, set the docs host to the public site:

bash

DOCS_HOST="https://docs.stripe.com"

在这些示例中，将文档主机设置为公开站点：

bash

DOCS_HOST="https://docs.stripe.com"

Naive user: “What do I need to verify for a Stripe connected account?”

新手用户：“我需要为Stripe关联账户提供哪些验证信息？”

Ask for

apiVersion

. Recommend

v2

Fetch the public platform-country list:

bash

curl --get "$DOCS_HOST/_endpoint/get-platform-countries"

Ask the user which

platformCountry

value they want to use. Then, fetch the allowed options for that platform country. This request tells you what is valid next, and you must use it before choosing downstream fields. For example, if the user chose

US

bash

curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country" \
  --data-urlencode "platformCountry=US"

After that response returns, collect setup choices as described in the Agent flow section.

询问

apiVersion

。推荐

v2

。

获取公开的平台国家列表：

bash

curl --get "$DOCS_HOST/_endpoint/get-platform-countries"

询问用户要使用的

platformCountry

值。然后，获取该平台国家的允许选项。此请求会告知您下一步的有效选项，您必须在选择下游字段前使用该请求。例如，如果用户选择

US

：

bash

curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country" \
  --data-urlencode "platformCountry=US"

在收到该响应后，按照代理流程部分的描述收集配置选择。

Smart user: “I have a CA platform, and I want to onboard a FR company connected account to use card payments”

资深用户：“我有一个加拿大平台，想开户一个法国公司关联账户以使用卡支付功能”

Ask for

apiVersion

. Recommend

v2

bash

undefined

询问

apiVersion

。推荐

v2

。

bash

undefined

Step 1: verify the platform country is valid

步骤1：验证平台国家是否有效

curl --get "$DOCS_HOST/_endpoint/get-platform-countries"

Step 2: fetch all public options for that platform country

步骤2：获取该平台国家的所有公开选项

curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country"
--data-urlencode "platformCountry=CA"


From that second response, first verify that FR is a valid account country, then read:

- `country_map.FR.dashboard_types`
- `country_map.FR.tos_types`
- `country_map.FR.entity_type_structures`
- `country_map.FR.capabilities`
- `country_map.FR.programs`

Then, confirm the user’s requested setup actually matches those available options.

If the user wants `apiVersion=v2`, first fetch and apply the v2 capability filter to compare against the user’s requested capabilities:

```bash
curl --get "$DOCS_HOST/_endpoint/get-v2-supported-v1-capabilities"

Only when the user’s requested setup actually matches those available options, then call the requirements endpoint.

The requirements endpoint expects nested query-string fields, not a JSON body:

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"

Optionally, since

.programs

is present for this configuration, you can ask the user if they would like to choose a requirements update and add

--data-urlencode "account-setup-A[orrProgram]=eu-2025"

to the request.

Use this response to present the requirements to the user as explained in the Construct the result section.

Fetch the optional supplemental tables for the selected capabilities:

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"

curl --get "$DOCS_HOST/_endpoint/get-requirement-selections-for-platform-country"
--data-urlencode "platformCountry=CA"


从第二个响应中，首先验证法国是否为有效的账户国家，然后读取：

- `country_map.FR.dashboard_types`
- `country_map.FR.tos_types`
- `country_map.FR.entity_type_structures`
- `country_map.FR.capabilities`
- `country_map.FR.programs`

然后，确认用户请求的配置是否与这些可用选项匹配。

如果用户想要`apiVersion=v2`，先获取并应用v2功能过滤器，以对比用户请求的功能：

```bash
curl --get "$DOCS_HOST/_endpoint/get-v2-supported-v1-capabilities"

仅当用户请求的配置与这些可用选项匹配后，才调用要求端点。

要求端点期望嵌套的查询字符串字段，而非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"

可选地，由于此配置中存在

.programs

，您可以询问用户是否要选择要求更新，并在请求中添加

--data-urlencode "account-setup-A[orrProgram]=eu-2025"

。

使用此响应按照构建结果部分的说明向用户展示要求。

获取所选功能的可选补充表格：

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"

Read the API responses

读取API响应

Use

get-platform-countries

to choose your initial

platformCountry

```
platform_countries
```
is the public list of available
```
platformCountry
```
options
```
default_country
```
is the page’s default starting country

Use

get-requirement-selections-for-platform-country

to validate the setup before you call the main requirements endpoint:

```
country_map
```
is the source of truth for which field values are valid for that
```
platformCountry
```
value
the keys of
```
country_map
```
are the allowed
```
accountCountry
```
options

country_map[ACCOUNT_COUNTRY].dashboard_types

constrains

dashboardType

country_map[ACCOUNT_COUNTRY].tos_types

constrains

tosType

country_map[ACCOUNT_COUNTRY].entity_type_structures

constrains

legalEntityType

and optional

businessStructure

country_map[ACCOUNT_COUNTRY].capabilities

constrains capability choices

```
country_map[ACCOUNT_COUNTRY].programs
```
lists the only public ORR programs you may pass as
```
orrProgram
```
```
external_country_map
```
should be ignored

Apply these dependency rules before making the final request:

if you change
```
accountCountry
```
, re-check all downstream selections
if you change
```
legalEntityType
```
, re-check
```
businessStructure
```
and all downstream selections
if you change
```
accountCountry
```
,
```
tosType
```
, or
```
apiVersion
```
, re-run Resolve capabilities

Use

get-requirements-for-setups

as your main source of requirement data:

```
requirements
```
contains the successful result for each requested setup key
```
validation_errors
```
means the setup was invalid and must be corrected before you interpret the response
```
build_errors
```
means the endpoint failed unexpectedly while building the summary; you must treat this as retryable rather than as a business conclusion

Within each successful setup result:

```
requirements[field_name]
```
is the requirement data for a single raw field, including enforcement limits, alternatives, display metadata, and related annotations used by the docs renderer
```
extras
```
contains human-readable labels and validation guidance for that requirement
```
requirement_tags
```
contains top-level requirement tags returned alongside the requirements data
```
requirement_groups
```
contains grouped requirement data returned alongside the requirements data

Check the supplemental endpoints to see if there are any additional capability-specific restrictions to present to the user.

```
requirements_by_capability
```
from the website endpoint is a separate website requirements table that explains requirements the connected account’s website must meet to support the selected capability. These should be presented to the user as a separate table.
```
restrictions_by_capability
```
from the MCC endpoint is a separate MCC restrictions table that explains requirements the connected account’s MCC must meet to support the selected capability. If this endpoint returns any restrictions, ask the user what kind of business they are running to determine whether their business type is prohibited or restricted from using the specific capability.
Empty maps are valid results for many standard capabilities and are not necessarily errors.

使用

get-platform-countries

选择初始的

platformCountry

：

```
platform_countries
```
是可用
```
platformCountry
```
选项的公开列表
```
default_country
```
是页面的默认起始国家

使用

get-requirement-selections-for-platform-country

在调用主要求端点前验证配置：

```
country_map
```
是该
```
platformCountry
```
值对应的字段值有效性的权威来源
```
country_map
```
的键是允许的
```
accountCountry
```
选项

country_map[ACCOUNT_COUNTRY].dashboard_types

限制

dashboardType

country_map[ACCOUNT_COUNTRY].tos_types

限制

tosType

country_map[ACCOUNT_COUNTRY].entity_type_structures

限制

legalEntityType

和可选的

businessStructure

country_map[ACCOUNT_COUNTRY].capabilities

限制功能选择

```
country_map[ACCOUNT_COUNTRY].programs
```
列出了可作为
```
orrProgram
```
传递的唯一公开ORR程序
```
external_country_map
```
应被忽略

在发起最终请求前应用以下依赖规则：

如果更改
```
accountCountry
```
，重新检查所有下游选择
如果更改
```
legalEntityType
```
，重新检查
```
businessStructure
```
和所有下游选择
如果更改
```
accountCountry
```
、
```
tosType
```
或
```
apiVersion
```
，重新运行解析功能

使用

get-requirements-for-setups

作为要求数据的主要来源：

```
requirements
```
包含每个请求配置键的成功结果
```
validation_errors
```
表示配置无效，必须先纠正才能解释响应
```
build_errors
```
表示端点在构建摘要时意外失败；您必须将其视为可重试而非业务结论

在每个成功的配置结果中：

```
requirements[field_name]
```
是单个原始字段的要求数据，包括执行限制、替代方案、显示元数据和文档渲染器使用的相关注释
```
extras
```
包含该要求的可读标签和验证指导
```
requirement_tags
```
包含与要求数据一起返回的顶级要求标签
```
requirement_groups
```
包含与要求数据一起返回的分组要求数据

检查补充端点，查看是否有任何特定于功能的额外限制需要向用户展示。

网站端点返回的
```
requirements_by_capability
```
是一个独立的网站要求表格，解释了关联账户的网站必须满足哪些要求才能支持所选功能。这些应作为独立表格展示给用户。
MCC端点返回的
```
restrictions_by_capability
```
是一个独立的MCC限制表格，解释了关联账户的MCC必须满足哪些要求才能支持所选功能。如果该端点返回任何限制，请询问用户其业务类型，以确定其业务类型是否被禁止或限制使用特定功能。
对于许多标准功能，空映射是有效的结果，不一定表示错误。

Construct the result

构建结果

Transform the API response into one or more human-readable tables in your own reply to the user, followed by any additional explanatory notes. These are output tables that you construct from the response data, not references to pre-existing tables on the human docs page.

将API响应转换为一个或多个可读表格，包含在您给用户的回复中，后面附上任何额外的解释说明。这些是您根据响应数据构建的输出表格，而非引用人工文档页面上已有的表格。

How to construct the tables:

如何构建表格：

Split each raw field key into a section using its prefix:

```
company.*
```
->
```
company
```
```
documents.*
```
->
```
documents
```
```
individual.*
```
->
```
individual
```
```
representative.*
```
->
```
representative
```
```
directors.*
```
->
```
directors
```
```
owners.*
```
->
```
owners
```
```
executives.*
```
->
```
executives
```
anything else ->
```
account
```

Render one table per non-empty section. Do not merge multiple sections into one table.
For each table:
- use the capitalized section name as the table heading, for example
```
Account
```
  ,
```
Company
```
  ,
```
Representative
```
  ,
```
Directors
```
  , or
```
Owners
```
- Include the following columns:
  - Heading: blank
    - Content: Row display name, for example “Name”, “Date of birth”, or “Address”
  - Heading:
```
Requirement
```
    - Content: a bulleted list of displayed fields
    - Render one bullet per displayed field
    - Render each field in code format
    - If a field has alternatives, keep them in the same bullet and render them as a set of options, for example
      field_a` or `field_b
  - Heading:
```
Verification
```
    - Content: a bulleted list built from
      extras[].value
    - Render each
      extras[].value
      entry as one list item
    - If
      extras
      is empty, leave the entry blank
  - Heading:
```
Enforcement action
```
    - Content: human-readable enforcement text built from both sets of limit fields
    - First use the unverified limit fields to generate the
      if not provided
      message(s):
      - capability_limit_amount
      - capability_limit_time
      - payment_limit_amount
      - payment_limit_time
      - payout_limit_amount
      - payout_limit_time
    - Then use the verified limit fields to generate the
      if not verified
      message(s):
      - verified_capability_limit_amount
      - verified_capability_limit_time
      - verified_payment_limit_amount
      - verified_payment_limit_time
      - verified_payout_limit_amount
      - verified_payout_limit_time
    - If any limit amount or limit time is
      <= 0
      , treat that impact as immediate
    - If both a time limit and an amount limit exist for the same impact, join them with
      or
    - Group impacts with identical thresholds into a single sentence, for example
      Capability, payments, and payouts will be paused immediately if not provided.
    - If both
      if not provided
      and
      if not verified
      text exist, render the
      if not provided
      sentence(s) first and then the
      if not verified
      sentence(s); prefix the first
      if not verified
      sentence with
      Also,
    - If neither set of limits is present, render
      —
If two sections share the same row-definition family, they still remain separate tables. For example,
```
representative
```
and
```
owners
```
both use the
```
person
```
row-definition family, but they render as separate
```
Representative
```
and
```
Owners
```
tables because they are different sections.
Assign each section to one of the row-definition families listed below in the
```
Row definitions
```
step. The row-definition family only controls how rows are matched and labeled inside that section’s table:
- ```
account
```
  ->
```
account
```
- ```
company
```
  ->
```
entity
```
- ```
documents
```
  ->
```
entity
```
- ```
individual
```
  ->
```
person
```
- ```
representative
```
  ->
```
person
```
- ```
owners
```
  ->
```
person
```
- ```
executives
```
  ->
```
person
```
- ```
directors
```
  ->
```
person
```
For every non-
```
account
```
section, strip the section prefix before matching row rules. For example, match
```
representative.first_name
```
as
```
first_name
```
and
```
company.address.city
```
as
```
address.city
```
.
Use the row definitions below for that section’s row-definition family. Create a row only when at least one field in that section matches the row.
Row definitions:

account: Merchant category code:

/business_profile.mcc/

URL:

/business_profile.(url|requirement)/

Product description:

/business_profile.product_description/

Support phone:

/business_profile.support_phone/

Statement descriptors:

/settings.payments.statement_descriptor/

/settings.card_payments.statement_descriptor/ Konbini support email address:

/settings.konbini_payments.support_email/

Konbini support phone number:

/settings.konbini_payments.support_phone/

Konbini support hours:

/settings.konbini_payments.support_hours/

/^tos_acceptance\./

Issuing terms of service:

/settings\.card_issuing\.tos_acceptance\./

Estimated worker count:

/business_profile\.estimated_worker_count/

Annual revenue:

/business_profile\.annual_revenue/

External account:

/external_account/

Legal guardian:

/legal_guardian\./

entity: Company name:

/name$/

Company name (kana):

/name_kana/

Company name (kanji):

/name_kanji/

Company address:

/address\..*/

Company address (kana):

/address_kana/

Company address (kanji):

/address_kanji/

Company phone:

/phone/

Company tax ID:

/tax_id/

Company registration number:

/registration_number/

Company ID number:

/id_number/

Trade license:

/company_license/

Memorandum of Association:

/company_memorandum_of_association/

Proof of bank account:

/bank_account_ownership_verification/

Directors provided:

/directors_provided/

Owners provided:

/owners_provided/

Executives provided:

/executives_provided/

person: Name:

/(first|last)_name/

Name (kana):

/(first|last)_name_kana/

Name (kanji):

/(first|last)_name_kanji/

Aliases:

/full_name_aliases/

Date of birth:

/dob\./

Address:

/^address\./

Address (kana):

/address_kana/

Address (kanji):

/address_kanji/

Registered address:

/registered_address/

Email:

/email/

Phone:

/phone/

Gender:

/gender/

Political Exposure:

/political_exposure/

Tax information:

/ssn_last_4$/

/id_number$/

Secondary ID number:

/(id_number_secondary)/

Job title:

/(relationship\.title)/

Relationship with legal entity:

/relationship\.(?!title)/

Nationality:

/nationality/

Passport:

/passport/

Proof of liveness:

/proof_of_liveness/

For
```
apiVersion=v2
```
, replace each displayed field with
```
v2_field_name
```
and use
```
v2_alternatives
```
.
If
```
apiVersion=v2
```
and a requirement doesn’t expose
```
v2_field_name
```
, omit that field from the rendered table. If that removes every field from a row group, omit the row. If a section becomes empty, omit that section table.

根据前缀将每个原始字段键拆分为不同部分：

```
company.*
```
->
```
company
```
```
documents.*
```
->
```
documents
```
```
individual.*
```
->
```
individual
```
```
representative.*
```
->
```
representative
```
```
directors.*
```
->
```
directors
```
```
owners.*
```
->
```
owners
```
```
executives.*
```
->
```
executives
```
其他 ->
```
account
```

每个非空部分渲染一个表格。不要将多个部分合并到一个表格中。
对于每个表格：
- 使用大写的部分名称作为表格标题，例如
```
Account
```
  、
```
Company
```
  、
```
Representative
```
  、
```
Directors
```
  或
```
Owners
```
- 包含以下列：
  - 标题：空白
    - 内容：行显示名称，例如“姓名”、“出生日期”或“地址”
  - 标题：
```
Requirement
```
    - 内容：显示字段的项目符号列表
    - 每个显示字段对应一个项目符号
    - 每个字段使用代码格式渲染
    - 如果字段有替代方案，将它们放在同一个项目符号中，并渲染为选项集合，例如
      field_a`或`field_b
  - 标题：
```
Verification
```
    - 内容：从
      extras[].value
      构建的项目符号列表
    - 每个
      extras[].value
      条目对应一个列表项
    - 如果
      extras
      为空，留空该条目
  - 标题：
```
Enforcement action
```
    - 内容：从两组限制字段构建的可读执行文本
    - 首先使用未验证限制字段生成“如果未提供”的消息：
      - capability_limit_amount
      - capability_limit_time
      - payment_limit_amount
      - payment_limit_time
      - payout_limit_amount
      - payout_limit_time
    - 然后使用已验证限制字段生成“如果未验证”的消息：
      - verified_capability_limit_amount
      - verified_capability_limit_time
      - verified_payment_limit_amount
      - verified_payment_limit_time
      - verified_payout_limit_amount
      - verified_payout_limit_time
    - 如果任何限制金额或限制时间
      <= 0
      ，则视为立即生效
    - 如果同一影响同时存在时间限制和金额限制，使用
      或
      连接
    - 将具有相同阈值的影响分组为一个句子，例如“如果未提供，功能、支付和提现将立即暂停。”
    - 如果同时存在“如果未提供”和“如果未验证”的文本，先渲染“如果未提供”的句子，然后渲染“如果未验证”的句子；第一个“如果未验证”的句子前加上“此外，”
    - 如果两组限制都不存在，渲染
      —
如果两个部分属于同一行定义系列，它们仍需作为单独的表格。例如，
```
representative
```
和
```
owners
```
都使用
```
person
```
行定义系列，但它们分别渲染为
```
Representative
```
和
```
Owners
```
表格，因为它们是不同的部分。
将每个部分分配到以下“行定义”步骤中列出的行定义系列之一。行定义系列仅控制该部分表格内的行匹配和标签方式：
- ```
account
```
  ->
```
account
```
- ```
company
```
  ->
```
entity
```
- ```
documents
```
  ->
```
entity
```
- ```
individual
```
  ->
```
person
```
- ```
representative
```
  ->
```
person
```
- ```
owners
```
  ->
```
person
```
- ```
executives
```
  ->
```
person
```
- ```
directors
```
  ->
```
person
```
对于所有非
```
account
```
部分，在匹配行规则前去掉部分前缀。例如，将
```
representative.first_name
```
匹配为
```
first_name
```
，将
```
company.address.city
```
匹配为
```
address.city
```
。
使用该部分行定义系列的以下行定义。仅当该部分中至少有一个字段匹配该行时，才创建该行。
行定义：

account: 商户类别代码:

/business_profile.mcc/

URL:

/business_profile.(url|requirement)/

产品描述:

/business_profile.product_description/

支持电话:

/business_profile.support_phone/

对账单描述符:

/settings.payments.statement_descriptor/

/settings.card_payments.statement_descriptor/ 便利店支持电子邮件地址:

/settings.konbini_payments.support_email/

便利店支持电话号码:

/settings.konbini_payments.support_phone/

便利店支持时间:

/settings.konbini_payments.support_hours/

服务条款:

/^tos_acceptance\./

发卡服务条款:

/settings\.card_issuing\.tos_acceptance\./

预计员工人数:

/business_profile\.estimated_worker_count/

年收入:

/business_profile\.annual_revenue/

外部账户:

/external_account/

法定监护人:

/legal_guardian\./

entity: 公司名称:

/name$/

公司名称（假名）:

/name_kana/

公司名称（汉字）:

/name_kanji/

公司地址:

/address\..*/

公司地址（假名）:

/address_kana/

公司地址（汉字）:

/address_kanji/

公司电话:

/phone/

公司税号:

/tax_id/

公司注册号:

/registration_number/

公司ID号:

/id_number/

营业执照:

/company_license/

公司章程:

/company_memorandum_of_association/

银行账户证明:

/bank_account_ownership_verification/

提供董事信息:

/directors_provided/

提供所有者信息:

/owners_provided/

提供高管信息:

/executives_provided/

person: 姓名:

/(first|last)_name/

姓名（假名）:

/(first|last)_name_kana/

姓名（汉字）:

/(first|last)_name_kanji/

别名:

/full_name_aliases/

出生日期:

/dob\./

地址:

/^address\./

地址（假名）:

/address_kana/

地址（汉字）:

/address_kanji/

注册地址:

/registered_address/

电子邮件:

/email/

电话:

/phone/

性别:

/gender/

政治关联:

/political_exposure/

税务信息:

/ssn_last_4$/

或

/id_number$/

次要ID号:

/(id_number_secondary)/

职位:

/(relationship\.title)/

与法律实体的关系:

/relationship\.(?!title)/

国籍:

/nationality/

护照:

/passport/

活体证明:

/proof_of_liveness/

对于
```
apiVersion=v2
```
，将每个显示字段替换为
```
v2_field_name
```
并使用
```
v2_alternatives
```
。
如果
```
apiVersion=v2
```
且某个要求未公开
```
v2_field_name
```
，则从渲染表格中省略该字段。如果这移除了行组中的所有字段，则省略该行。如果某个部分变为空，则省略该部分表格。

How to construct the JSON-style summary:

如何构建JSON格式摘要：

if the user asks for a JSON summary of required items, return a JSON object in this exact shape. Each array holds zero or more field names:

json

{
  "requirements": {
    "currently_due": [
      "configuration.merchant.mcc",
      "company.name",
      "representative.first_name"
    ],
    "eventually_due": [
      "business_profile.url"
    ]
  }
}

Do not use ellipses (

...

) or placeholder strings in the output — list every field name explicitly.

this shape is a derived summary for comparison and display. It is not a raw Accounts API response.
If
```
apiVersion=v2
```
, inform the user that this JSON is for information only, and doesn’t match the shape of a real API response.
derive each field’s due bucket from the requirement’s limit fields in the
```
get-requirements-for-setups
```
response:
- treat a field as
```
currently_due
```
  when any unverified limit amount or time is
```
<= 0
```
  , or any verified limit amount or time is
```
<= 0
```
- otherwise treat it as
```
eventually_due
```

populate

requirements.currently_due

and

requirements.eventually_due

from those derived buckets

do not add a separate
```
future_requirements
```
bucket. Regulatory or ORR-driven future changes are modeled through
```
orrProgram
```
setup selection and A/B setup comparison, not through a third due array
for
```
apiVersion=v1
```
, use the raw requirement field names in both arrays
for
```
apiVersion=v2
```
, use
```
v2_field_name
```
values in both arrays
If
```
apiVersion=v2
```
, omit fields that have no
```
v2_field_name
```
the JSON diff view compares requirement names only; it doesn’t diff verification text, thresholds, or supplemental metadata

如果用户要求所需项目的JSON摘要，返回以下精确格式的JSON对象。每个数组包含零个或多个字段名称：

json

{
  "requirements": {
    "currently_due": [
      "configuration.merchant.mcc",
      "company.name",
      "representative.first_name"
    ],
    "eventually_due": [
      "business_profile.url"
    ]
  }
}

输出中不要使用省略号(

...

)或占位符字符串——明确列出每个字段名称。

此格式是用于对比和显示的派生摘要。它不是原始Accounts API响应。
如果
```
apiVersion=v2
```
，告知用户此JSON仅用于参考，与真实API响应的格式不匹配。
根据
```
get-requirements-for-setups
```
响应中的要求限制字段，将每个字段分配到相应的到期类别：
- 当任何未验证限制金额或时间
```
<= 0
```
  ，或任何已验证限制金额或时间
```
<= 0
```
  时，将字段视为
```
currently_due
```
- 否则视为
```
eventually_due
```

从这些派生类别中填充

requirements.currently_due

和

requirements.eventually_due

不要添加单独的
```
future_requirements
```
类别。监管或ORR驱动的未来变更通过
```
orrProgram
```
配置选择和A/B配置对比建模，而非通过第三个到期数组
对于
```
apiVersion=v1
```
，在两个数组中使用原始要求字段名称
对于
```
apiVersion=v2
```
，在两个数组中使用
```
v2_field_name
```
值
如果
```
apiVersion=v2
```
，省略没有
```
v2_field_name
```
的字段
JSON差异视图仅对比要求名称；不对比验证文本、阈值或补充元数据

How to respond to users

如何回复用户

When you return results to the user:

restate the exact validated setup you queried, including

apiVersion

platformCountry

accountCountry

dashboardType

tosType

legalEntityType

, optional

businessStructure

, selected

capabilities

, and optional

orrProgram

always provide the user with a link containing the exact URL query parameters you used so they can view the requirements themselves and verify your conclusions

for example:

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&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

when comparing two setups, include
```
account-setup-B
```
in the page URL only if you validated and queried setup B

if any requested choice had to be changed because of selector dependencies, say so explicitly before presenting the requirements
present currently due requirements separately from eventually due requirements, and label them clearly
explain verification bullets using
```
extras[].value
```
as the source of truth
mention when a requirement was omitted because it matched none of the table row definitions in this document
mention when website or MCC endpoints returned no supplemental data, so the user doesn’t mistake that for a fetch failure
if you receive
```
validation_errors
```
, ask the user to correct the setup inputs using the Interaction contract instead of guessing
if you receive
```
build_errors
```
, retry the request; if the error persists, tell the user the helper endpoint failed unexpectedly

向用户返回结果时：

重述您查询的精确验证配置，包括

apiVersion

、

platformCountry

、

accountCountry

、

dashboardType

、

tosType

、

legalEntityType

、可选的

businessStructure

、所选的

capabilities

以及可选的

orrProgram

始终向用户提供包含您使用的精确URL查询参数的链接，以便他们可以自行查看要求并验证您的结论

示例：

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&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

对比两个配置时，仅当您验证并查询了配置B，才在页面URL中包含
```
account-setup-B
```

如果任何请求的选择因选择器依赖关系而被更改，请在展示要求前明确说明
将当前到期的要求与最终到期的要求分开展示，并清晰标注
使用
```
extras[].value
```
作为权威来源解释验证项目符号
提及因不符合本文档中的表格行定义而被省略的要求
提及网站或MCC端点未返回补充数据，以免用户误以为是获取失败
如果收到
```
validation_errors
```
，请要求用户使用交互约定纠正配置输入，而非猜测
如果收到
```
build_errors
```
，重试请求；如果错误持续，告知用户辅助端点意外失败