Skip to main content
消费账户始终在调用方的账户上创建——无法在他人的账户上创建。您可以做的是先创建消费账户,然后将授权用户记录为其所有者,以便该账户有具名负责人。 不同于createVirtualCardcreateUserCashBalance接受authUserId。所有权是一个单独的第二次调用:使用assignObjectOwner并传入objectType: SPEND_ACCOUNTS
所有权是元数据,不是访问权限。分配所有者会记录谁对某个消费账户负责。它本身并不会授予该人从账户中消费的能力。实际的访问权限仍然取决于用户的账户角色(UACRoleType)与在该消费账户上授予的条目级访问权限两者中较高者。分配所有者并且确保该用户的角色赋予了您实际期望的访问权限。

前置条件

1

授权用户已存在且为 ACTIVE

使用addAuthorizedUser添加,并确认返回的statusACTIVEPENDING的指派不能用作所有者——用户必须先接受邀请。
2

您的令牌同时携带两个 scope

createUserCashBalance需要MANAGE_PAYMENTassignObjectOwner需要MANAGE_SUBUSERS。单个 Bearer 令牌需要同时具备二者才能端到端完成此流程。
3

您已获得授权用户的 userId

assignObjectOwneruserId为键,而非authUserId。参见下文解析 userId

步骤 1 — 创建消费账户

像平常一样创建消费账户。它会在调用方的账户上创建,且不附带所有者。
保存返回的userCashBalanceId。该值将在步骤 3 中作为objectId使用。
为账户设置能标识所有者的昵称。所有权元数据不会在所有列表视图中展示,因此使用类似于"Ada — Field Ops"的昵称,可以在getUserCashBalances中无需额外查询就让账户一目了然。

解析 userId

assignObjectOwner接收授权用户的**userId——即底层用户记录。这与addAuthorizedUserauthorizedUsers返回的authUserId**不同,后者标识的是 UAC 的角色指派。 AuthorizedUser类型目前尚未暴露userId。当前文档化的获取方式如下:
切勿在需要userId的地方传入authUserId。二者同为UUID,该变更不会被类型错误捕获——您将得到失败或错向的所有权分配。

步骤 2 — 将授权用户指派为所有者

受限访问

此变更需要携带MANAGE_SUBUSERS scope 的 Bearer 令牌。

参数

assignObjectOwner仅能为尚无所有者的对象指派所有者。如果该消费账户已存在所有者,调用不会覆盖——请改用transferObjectOwner

示例响应

响应字段


重新分配所有权

通过transferObjectOwner迁移所有权,该接口接收原始指派产生的objectOwnerId,而非消费账户 ID。
新所有者必须是同一账户上的用户。当某位授权用户离开团队而其消费账户需要移交他人时,请调用此接口——移除授权用户并不会重新分配其所拥有的对象。

全流程

添加授权用户,为其创建消费账户,并将其记录为账户所有者。 步骤 1 — 添加授权用户。
仅在statusACTIVE后继续。 步骤 2 — 创建消费账户。
步骤 3 — 指派授权用户为所有者。
步骤 4 — 充值。 消费账户初始余额为 0。可通过depositCashBalance向其存入资金,或使用transferInternalBalance从其他消费账户转入资金,目标为新的userCashBalanceId

TypeScript


错误码


授权用户概览

角色、状态,以及授权用户的完整生命周期。

为授权用户创建虚拟卡

使用authUserId代表授权用户发行一张卡。

消费账户概览

创建、读取、编辑与关闭消费账户。

移除授权用户

当访问被撤销时,已拥有对象会发生什么。