registerUser 使用你已持有的用户档案数据为其开通 Fluz 账户——无需跳转、无需托管表单、无需让用户再次输入姓名和出生日期。
所处环节
注册是入驻流程中的一个步骤,且是可选的——你也可以把整个流程交给组件来完成。
当你已经持有干净的档案数据且不希望用户重复输入时,请自行注册用户。如果你只会收集姓名、出生日期和联系方式然后转交给 Fluz,请改用内嵌组件——这能将收集过程纳入 Fluz 的合规范围。
API 路径的完整步骤如下:
1
注册
使用姓名、手机号、邮箱与出生日期调用
registerUser。2
验证
使用
verifyUserInformation 进行 KYC,或向用户发放证件验证链接。→ 用户 KYC 验证3
获取授权
用户向你的应用授予作用域。→ 面向客户端的 OAuth 授权流程
4
运营
生成用户访问令牌,并代表其调用 API。→ 认证
该 mutation
error 是一个对象(RegisterUserError),不是字符串——请务必选择其子字段 code 和 message。仅请求裸 error 将无法编译。参数
姓名应与用户用于验证的身份证件一致——不一致将会在后续的 KYC 中以失败形式体现,且较注册时的报错更难排查。
会创建什么
一个完整的 Fluz 账户:用户记录、他们的钱包与余额,以及其奖励资格。在账户验证并使用前,无需额外配置。处理响应
Success
Failure
“已被使用”是路由信号,而非错误
AUTH-0026(手机号)和 AUTH-0027(邮箱)意味着该人已经拥有 Fluz 账户。这是一种正常且可预期的结果——Fluz 账户不以你的应用为作用域,因此任何曾经通过任一应用或消费者产品使用过 Fluz 的人,都已存在。
把这当作失败是此处最常见的集成错误。正确做法是停止创建账户,转而请求访问其现有账户:将用户送入 OAuth 授权流程,或打开一个组件。他们登录已有账户并授权给你。
将“注册→回退”的路径设计成常态,而非异常分支,这样在规模化时依然清晰可控。
重试与重复
如果调用超时或连接中断,注册很可能已经成功。随后对同一请求进行重试会返回AUTH-0026——这与你的用户本就已有账户的情形无法区分。
只要你对这两种情况采取相同处理,这种不确定性是无害的:**在超时时重试一次,并将 AUTH-0026 / AUTH-0027 路由到授权流程,而非错误状态。**无论是你刚创建的账户还是原本已存在的账户,最终都会被授权,这正是你期望的结果。你绝不能在用户首次提供手机号时向其展示“手机号已被使用”。
注册之后
已注册账户尚未完成验证。用户在能动用资金前,你需要:- 身份验证。 将你持有的 SSN 与地址传给
verifyUserInformation,或为用户发放证件验证链接。→ 用户 KYC 验证 - 授权授予。 仅注册并不赋予你代表其行动的权限——这是另一个独立且明确的步骤。→ 面向客户端的 OAuth 授权流程
- 绑定你的自有标识。 在授权时传入
external_id,此后你就能用你的用户 ID 来定位此人。→ 管理外部引用 ID
数据处理
你将传输姓名、出生日期、邮箱和手机号——这组信息可识别真实个人。请通过 TLS 从你的服务器发送,避免写入日志与错误跟踪负载,且不要在客户端可见的响应中回显。 注意,尤其是出生日期,在多数法域受身份数据监管;调用成功后,该数据在你侧仍属敏感信息。若你不希望持有这些数据,这正是选择组件的理由——Fluz 在其自身合规范围内收集,你无需接触。错误码
环境
根据你的环境指向 GraphQL 主机——staging 使用https://transactional-graph.staging.fluzapp.com/api/v1/graphql,production 使用 https://transactional-graph.fluzapp.com/api/v1/graphql。注册权限按应用授予,因此生产应用需要单独启用。→ 部署到生产环境
切勿在 staging 注册真实用户。→ Staging 与正式环境
后续步骤
用户 KYC 验证
验证你刚创建的账户。
授权流程
获得代表其行动的权限。
外部引用 ID
使用你的自有用户 ID 来定位他们。
内嵌组件
将整个入驻流程交给 Fluz。