Skip to main content

​
概述

Fluz KYB（Know Your Business）允许你的平台在自有 UI 中将企业接入 Fluz 轨道。通过一小组操作你将：
  1. 确定该实体从事的企业类别与子类别，
  2. 提交法律实体信息——法定名称、组织形式、税号、注册州、法定地址，以及账户的预期用途——连同最终受益所有人名单，
  3. 为需要的所有者完成身份验证，及
  4. 将产生的 KYB 案件跟踪至通过或被拒。
提交本身是一个单一的 mutation，registerBusiness。它会立即返回一个 accountId，同时 kybStatus 为 SUBMITTED。
注册表示通过校验，不等于审批。 success 响应仅确认载荷通过了校验并已开启 KYB 案件。它并不意味着企业已获批。请将集成构建为在状态批准之前，不尝试为账户入金或发行卡片。

​
企业账户能解锁什么

一旦 KYB 获批，企业账户可用于平台的商业功能：
  • 企业消费账户与余额
  • 商业虚拟卡，包括批量发卡
  • 授权用户与卡级别的消费控制
  • 卡片、转账与报销的审批流程
  • 企业级别的交易报告与费用注释

​
何时使用这些端点

当你希望在自有 UI 中收集实体与所有权数据，而不是将用户引导到 Fluz 托管的体验时，使用该流程。若你更希望由 Fluz 托管资料收集与文档上传，请联系你的客户经理，了解基于组件的上手方案。

​
KYB 流程

​
分步说明

1

步骤 0 — 满足前置条件

这些不属于流程的一部分，但都必须在调用 registerBusiness 前成立。每行链接到下文详情。见前置条件
2

确定企业类别与子类别

调用 getBusinessCategories，让用户选择一个类别及其下的某个子类别。
3

如适用，上传授权签字人文件

仅当申请人持股少于 25% 且 非控制人时需要。先上传文档，然后将返回的 URL 传入 authorizedSignerDocumentUrl。见提交企业文件。
4

提交 registerBusiness mutation

在一次调用中发送完整的实体信息、所有权声明，以及每位所有者。校验错误会在载荷内返回——见响应详情。
5

让剩余所有者完成验证

读取 getBusiness 查看每位所有者的预期验证方式与当前进度。对于走文档验证路径的所有者，使用 requestOwnerDocumentVerificationLink 生成链接并发送给他们。被邀请的所有者会由 Fluz 发送邮件，自行完成验证。
6

等待 KYB 决策，然后配置上线

申请会进入审核中。将该状态展示给你的用户，而非暗示已经上线。一旦状态变为 APPROVED，创建消费账户并发行卡片。

​
端到端时序

​
前置条件

​
应用权限范围

在 Fluz 仪表板为你的应用选择 REGISTER_BUSINESS 权限范围。每个 KYB 操作都需要它，而令牌只能携带你的应用已配置可请求的范围。见 Application Scopes。 订阅 KYB_STATUS_UPDATE webhook 也需要相同的范围。

​
申请人授权

申请人必须已为你的应用完成 OAuth 授权，且该授权需覆盖你的应用所请求的每个企业范围。若你后来新增了范围，现有用户必须重新授权后方可注册企业——否则注册会以 AUTH-0008 失败。

​
申请人必须已通过 CIP 验证

Bearer 令牌标识的是申请人：提交申请的用户。名单中必须恰有一位所有者与该令牌用户的邮箱（不区分大小写）或电话号码匹配，且该所有者不可标记为 isInvited: true。 KYB 验证的是企业及“其他”所有者，不会验证申请人本人，因此申请人必须事先达到已验证状态。你为其发送的 isUsPerson 值决定适用的检查： 身份验证在 KYB 之外进行，使用 VERIFY_KYC 范围，通过 verifyUserInformation、verifyUserPrefillInformation，或 requestDocumentVerificationLink。见身份验证（KYC）。若该人尚无 Fluz 账户，请先使用 registerUser 创建。

​
每位用户一次只能有一个进行中的申请

在现有申请仍未关闭时，用户不能发起新的注册——否则返回 BS-0007。
不提供幂等键，也没有取消进行中申请的 API。被拒的申请不会留下任何记录，可以重新提交，但成功的申请会阻止用户在其解决前再次注册。请在提交前做好校验，若案件似乎停滞，请联系你的客户经理并提供 accountId。

​
访问令牌

每个操作需要特定账户类型的 Bearer 令牌：
使用 generateUserAccessToken 生成 Mint Bearer 令牌——参见 API 参考的 Authentication 章节。

​
KYB 状态生命周期

SUBMITTED 只会由 registerBusiness 返回。getBusiness 报告三值状态，注册后立即读取会显示为 PENDING——两者描述的是同一时刻，只是用词不同。

​
跟踪申请

有两种方式将申请跟踪至最终状态。选择与你的基础设施契合的方式；许多集成使用 webhook 获得低延迟，并偶尔读取以做对账。
在 Fluz 仪表板订阅 KYB_STATUS_UPDATE 事件：注册你的回调 URL 并选择该事件。你的应用需要 REGISTER_BUSINESS 范围才能订阅。当企业的 KYB 状态发生变化时，Fluz 会向你的端点发起 POST。
需要处理两点：
  • 将投递视为至少一次。 让你的处理器具备幂等性，以 accountId 加 newStatus 作为幂等键。
  • 你可能会收到 previousStatus 等于 newStatus 的事件。 案件在内部状态间移动，但对外呈现的状态相同。将这些视为 no-op。
负载仅携带企业状态——不包含所有者名单。当你需要查看每位所有者的进度时，调用 getBusiness。
审核通常在一到两个工作日内完成，但若被要求补充资料，或某位所有者尚未完成身份验证，时间可能更长。若案件似乎停滞，请联系你的客户经理并提供 accountId，而非重新提交——第二次提交会被 BS-0007 拦截。

​
使用 externalReferenceId 标识企业

Fluz 通过在注册时生成的 UUID accountId 来标识企业。externalReferenceId 则是一个可选标识符，由你提供，便于你用自有系统里该客户的 ID 与 Fluz 交互。 在 registerBusiness 时一次性传入：
它会被存储到企业账户上，并带来三点益处：
  • 无需存储 Fluz ID 即可铸造令牌。 可按引用而非 userId 与 accountId 来铸造企业账户访问令牌。
  • Webhook 关联。 该引用会出现在每个 KYB_STATUS_UPDATE 事件中，因此无需查表即可将事件匹配到你的记录。
该字段为可选。若你省略，一切仍可正常工作——只是需要你自行存储 accountId，而无论如何你都应这么做。

​
规则

每个企业使用一个唯一值。 一个引用只能指向一个企业账户，因此在两个企业间复用同一值会导致第二次注册失败。请基于你的主键生成，而不要使用可复用的信息（如邮箱地址）。
此处涉及两个不同的引用，容易混淆。你的访问令牌已携带的引用用于定位申请人的现有授权；而 registerBusiness 输入中的引用 会被写入新的企业账户。二者用途不同。

​
相关页面

注册企业

registerBusiness mutation：完整参数参考、所有权规则与错误码。

企业类别

获取 mutation 所需的类别与子类别 ID。

提交企业文件

上传授权文件并响应 KYB 的补件请求。

企业 KYB 状态

读取 KYB 状态与每位所有者的验证进度。

所有者验证链接

为所有者生成可分享的身份验证链接。

注册客户

创建将作为申请人的 Fluz 用户。