U8 Chat 虚拟卡模块 PRD

1. 业务概述

1.1 产品定位

在 U8 Chat 的资产模块内新增「银行卡」能力：用户用账户内的数字资产（USDT 等）申请一张可在全球消费的虚拟卡（Visa / Mastercard 通道），用于境外订阅、广告投放、海淘、跨境消费等场景。

产品形态参考：QQlink 的「银行卡」模块（卡列表 → 卡产品 → 持卡人 → 资料 → 证件 → 支付 → 开卡 → 卡详情 → 交易）。

1.2 系统角色与边界

边界要点：发卡系统不直接接触终端用户；用户资金由 U8 Chat 侧持有与管理，卡内余额由我方发起充值产生。

1.3 资金链路

核心原则：U8 钱包是唯一资金来源，也是唯一的回流终点。 卡模块不新建资金池，所有钱都从钱包进、回钱包出。

        ┌──────────────────────────────────────────┐
        │            U8 钱包（USDT）                │
        │   充值能力复用「资产模块」已有流程          │
        └──────────────────────────────────────────┘
             ▲             │                  ▲
   ① 链上充值 │    ② 开卡扣款        ③ 卡充值扣款 │ ④ 卡转出回流
   （已有能力）│    30 USDT           用户输入金额  │   卡内余额
             │    (10 开卡费 +               │     │
             │     20 预充值)                ▼     │
             │                        换汇 USDT→USD
             │                              │
             │                              ▼
             │                     ┌──────────────────┐
             └─────────────────────│  用户卡账户(USD) │
                                   └──────────────────┘
                                            │
                                     ⑤ 用户消费
                                            ▼
                                   第三方支付平台/商户
                                   （不在本 App 内）

五条资金路径

关键设计

• 钱包是唯一资金来源：开卡与卡充值都只从 U8 钱包扣款，不引入第二套资金入口。
• 钱包余额不足时：在开卡确认弹窗与卡充值页直接给「去充值」入口，跳转资产模块的 USDT 充值流程；卡模块不自建充值页。
• 对外统一叫「U8 钱包」，不使用「平台账户」「我方账户」等内部说法。
• 服务端记账：每次扣款先落「对用户的负债」再对外划出资金，保证账实一致。
• 资金回流：卡内未消费余额通过「卡转出」回到 U8 钱包，可再次用于开卡或充值。

2. 信息架构

2.1 入口与导航

2.2 页面清单

客户端 · 新增 24 个页面

说明：以下所有页面的字段 / 列表初始均为空，演示必须由使用者实际填写或上传，不预填任何数据。

客户端 · 改造 1 个页面

后台 · 新增 9 个界面

后台菜单归属：在现有「资产」组之后新增「银行卡」组，含上述 4 个页面。

3. 功能详述

3.1 资产首页 · 银行卡入口

• 在资产首页功能位新增「银行卡」图标 + 文案，作为第 5 个功能位。
• 未开卡：点击进入申请列表，直接引导办理。
• 已开卡：点击进入卡片首页（卡面 + 操作 + 交易记录）。
• 卡内余额不计入「我的资产」总览，卡片独立展示。

3.2 银行卡首页 / 我的卡包 / 申请列表

卡片首页（模块主页，版式参照 QQlink）

• 小眼睛只控制余额显隐，折合人民币同步隐藏；卡号脱敏与眼睛无关。
• 完整卡号与 CVV 需验证资金密码后展示，30 秒自动隐藏。
• 销卡前必须先将余额转出（余额不为 0 时按钮置灰）。
• 卡片被风控冻结时整页降级只读，隐藏操作区与底部按钮。

银行卡（无卡空态 / 可办理列表）：一张卡都没有时，从资产首页点「银行卡」直接进入本页。页面顶部是空态引导（插图 + 「还没有银行卡」+ 能力说明），下方直接列出可办理的卡产品，每张卡上带「立即申请」按钮。无卡时不展示余额、卡号、操作区与交易记录。

持卡人 · 空态：开卡流程中还没有持卡人时进入。说明「持卡人是卡面上的那个人，未通过审核不能开卡」，并提供「添加持卡人」。

我的卡：先展示当前持有的卡（产品名、卡号脱敏、余额、主卡标识），下方为「添加银行卡」入口（带「还可申请 N 张 · 上限 3 张」提示），右上角 ＋ 同效。一张卡都没有时展示空态 + 添加入口。

可办理的卡产品：作为列表直接嵌在「银行卡（无卡空态 / 可办理列表）」页内，每张产品卡展示产品名、卖点、开卡费与起充门槛，卡内带「立即申请」小按钮；点卡片信息区进入卡产品详情（完整费率与权益 + 底部「立即申请」主按钮）。

层级关系：卡片首页「卡+」→ 我的卡（看卡 + 加卡）→ 添加银行卡 → 可办理列表（卡上点「立即申请」）→ 判断持卡人 → 开卡申请页 → 支付 → 开卡成功。

两条硬规则：

1. 「立即申请」有两个入口，触发同一动作：① 可办理列表的卡片上有小按钮（快捷路径）；② 卡产品详情页底部有主按钮（看完费率后的决策入口）。不是两条流程，点击后都走「判断持卡人 → 确认开卡弹窗」。
2. 「申请列表」只放我的申请记录，从 ☰ 更多菜单独立进入，开卡流程任何一步都不应跳到申请列表。

申请列表：顶部显示「已有 N 张，还可申请 M 张（上限 3 张）」；下方为我的申请记录（审核中 / 已通过 / 已拒绝 + 拒绝原因）与「申请新卡 · 可办理的银行卡」。

办理第二张卡的入口：卡片首页右上角「卡+」→ 我的卡 →「添加银行卡」（右上角 ＋ 亦可）。统一先落到「我的卡」，让用户看到现有卡片，再决定加卡。

3.3 卡产品详情 / 办理

展示内容：

• 卡面大图 + 产品名
• 核心卖点（绑卡支付、支持场景：Apple Pay / 支付宝 / 微信 / 订阅类等）
• 费用与门槛（具体数值）：

• 「立即申请」主按钮

3.4 持卡人管理

• 持卡人是独立实体，一个用户可管理多个持卡人（参考 QQlink，持卡人可增减、可切换）。
• 列表：持卡人姓名、证件类型、状态（待完善 / 已完善 / 审核中 / 已通过）。
• 操作：新增持卡人、编辑、设为默认。
• 「添加持卡人」进入资料填写。

3.5 持卡人资料填写

字段采集原则

1. 只采集 THPay Ⅰ类卡开卡接口中标记为必填（M）或条件必填（C）的字段，接口没有的一律不采集。
2. 所有字段初始为空，不预填任何示例数据——原型演示与真机一致，用户必须实际逐项填写。
3. 任一必填项为空时「下一步」置灰，不允许跳过用户的实际操作步骤。
4. 用户在资料页填写的英文姓 / 名会回显到卡面、开卡申请页与卡信息页，保证前后一致。

① 身份信息

② 证件信息

身份证与护照在接口中使用同一组字段，区别只在 documentType 与上传的影像。

③ 联系方式

④ 开卡密码

• 使用 THPay 提供的公钥 RSA 加密后提交，禁止明文传输，我方不保存明文。

⑤ 证件影像（条件必填 C）

⑥ 明确不采集的字段

• 底部提示：「请确保所填信息真实有效，如因虚假信息导致开卡失败，将由您自行承担。」
• 保存后进入证件上传。

⑦ 对外文案规范（品牌隔离）

客户端界面只放用户需要的信息：上游名称、接口字段名、审计/幂等/对账/回调等技术术语、合规条款、PRD 章节引用，一律不出现。 这些内容只允许出现在后台系统、内部文档与本 PRD 中。

⑧ 页面底部不放免责提示块

「请确保所填信息真实有效…」这类提示不放在资料页底部；如需披露，放在开卡协议或支付确认环节。

3.6 证件类型选择

• 弹层选择：身份证 / 护照；选择后「资料填写」与「证件上传」两页联动变化（见 3.5 / 3.7）。
• 证件类型须与账号实名信息一致，不一致时提示先完成实名变更。
• 一期仅支持身份证与护照；港澳台居民来往内地通行证、外国人永久居留证列入二期。

3.7 证件影像上传

• 身份证：正面（人像面）+ 反面（国徽面），两张。
• 护照：护照资料页（含照片、姓名、护照号、签发国、有效期与机读区）；签证页 / 居留页选填。
• 单张 ≤ 10MB；上传前做清晰度与完整性校验；校验失败可重传。
• 合规要求：影像加密存储、访问审计、明确保存期限与删除机制。
• 复用 U8 Chat 现有实名资料，仅补充采集证件影像（身份证正反面 / 护照资料页），不重复采集已有字段。

3.8 提交与审核

• 提交后进入审核中态，页面展示申请单号、提交时间、预计时长。
• 状态流转：审核中 → 已通过 / 已拒绝。
• 被拒：展示可读原因；资料问题支持修改后重新提交，无需重新付费。
• 超时未出结果：触发人工介入提示。

3.9 开卡信息确认

展示：卡产品、持卡人、开卡费、预充值金额（如有）、合计应付。

• 「确认」进入支付。

3.10 开卡支付

• 支付方式：U8 钱包——对外统一叫「U8 钱包」，文案不绑定具体币种；复用资产模块已有账户体系，不新接支付通道。
• 钱包余额不足时：「去支付」按钮替换为「钱包余额不足，去充值」，点击跳转资产模块的 USDT 充值流程。
• 展示：订单金额、支付方式、可用余额。
• 支付验证：系统级验证（面容 ID / 密码 / 资金密码）。
• 余额不足 / 支付失败：给出明确错误与重试入口。

3.11 开卡结果

• 成功：提示「开卡成功」→ 卡片自动加入「我的卡」→ 结果页只保留一个按钮「查看我的卡」（→ 卡片首页）。
• 不要放两个指向同一目标的按钮：早期设计里同时有「查看卡详情」与「返回银行卡列表」，两者落点相同且标签与实际页面不符，属冗余且会误导用户。
• 失败：说明原因与资金处理方式（是否退回、退回路径、时效）。
• 审核中：展示申请单号与预计时长。

3.12 卡信息（查看卡详情）

从卡片首页点「查看此卡详情 ›」或右上角进入，集中展示卡片全部属性。

敏感信息展示规则（核心）

卡号、有效年月、CVV 是绑卡的关键数据，泄露即可被他人盗绑，因此默认三项全部不展示：

复制卡号不是独立功能：只有在校验通过、完整卡号展示期间，卡号右侧才出现复制小图标（⧉）；掩码状态下不提供任何复制入口。整卡模块不设独立的「复制卡号」按钮。复制动作与查看动作一并记入审计日志。 复制图标只出现在卡片首页与卡信息页；交易详情页只用于查账，不提供复制。

• 唯一入口：卡片首页的「CVV 查看」按钮。
• 验证方式：邮箱验证码（6 位数字，发送至已绑定邮箱），不再使用资金密码。
• 三项必须同时展示、同时隐藏，不允许只放开其中一项。
• 验证通过后展示 30 秒自动隐藏。
• 验证码 60 秒内可重发、有效期 5 分钟、连续错误 5 次锁定 30 分钟。
• 未绑定邮箱时先引导绑定；邮箱绑定流程列二期补充（见附录）。
• 所有查看动作写审计日志：谁、何时、查看了哪张卡。
• 小眼睛只控制余额显隐，与卡号 / 有效年月 / CVV 无关。

验证方式的分工：查看敏感信息走邮箱验证码（信息泄露风险）；支付与销卡走资金密码 / 生物识别（交易授权风险）。两者不混用。

3.13 卡充值（三步：充值 → 换汇确认 → 结果）

• 拆成三个页面：① 卡充值（选卡 + 输金额）→ ② 换汇确认（换汇独立页面）→ ③ 充值结果。
• 换汇确认页必须同屏展示：换汇方向（USDT → USD）、参考汇率、换汇点差、充值手续费、预计入卡金额。
• 汇率免责：卡充值接口不含汇率字段，汇率由 THPay 内部按当日结算；页面必须写明「实际入卡金额以发卡系统当日结算汇率为准，差额多退少补」。
• 顺序：用户资金入我方账 → 我方充值至发卡系统 → 换汇 → 主账户 → 调卡充值接口 → 主账户扣款 → 卡账户增加 → 回调确认。
• 必须先开卡成功才能充值。
• 回调幂等；回调超时进入对账队列。
• 限额：单笔下限 20 USDT、单日上限 5,000 USDT、单卡余额上限 5,000 USD。

3.14 卡转出 / 提现

去向二选一：

• 选择「银行卡」时需填：持卡人、银行卡号、开户行。
• 卡内未消费余额转出至我方账户（对应发卡系统「卡转出」）。
• 必须向用户明确披露：转出后资金停留在平台内，不能直接提现至银行卡。
• 存在未清算授权时不允许全额转出（需保留冻结金额）。
• 销卡是用户可自主执行的动作（QQlink 已把销卡放在卡片首页），与后台风控的「冻结」严格区分。
• 销卡前必须先完成转出；余额不为 0 时销卡按钮置灰。销卡不可恢复，需资金密码二次确认。

3.15 交易记录与交易详情

列表：按时间倒序；支持筛选（币种 / 类型 / 日期区间）；空态展示。

详情字段：

两个阶段必须分开展示：授权（冻结）与结算（落账）是两条记录，金额可能不同。

3.16 本期范围界定

本期核心是两件事：开卡 + 出示卡信息。配套保留余额管理（充值 / 换汇）、账单查询与资金退出（转出 / 销卡）。

⚠️ 不做 3DS 交易确认的风险（需评估）

3DS 是发卡方在境外网站支付时触发的安全验证。接口 3DS信息确认（/v1/openapi/card/3ds/confirm）Ⅰ类卡明确支持，且需要持卡人在我方 App 内确认（通过 / 拒绝），验证码由 WebHook 下发。

本期不做意味着：境外网站支付一旦触发 3DS 挑战，无人可确认，该笔交易直接失败。

影响大小取决于渠道策略：

• 若对大部分境外交易强校验 3DS → 影响大，用户会认为「卡不能用」
• 若仅部分商户 / 部分金额触发 → 影响有限，可放二期

建议：联调阶段先向对方确认「3DS 触发比例、是否可配置豁免」。若触发比例高，建议把 3DS 提到一期。

该能力已完成设计（见下方附件说明），如确认需要可直接启用，无需重新设计。

附：3DS 交易确认设计（备查） 流程：收单行触发 → 对方 WebHook 下发 validateCode → 我方推送站内消息 → 用户在 App 内核对商户 / 金额 / 卡号尾号 / 验证码 → 确认或拒绝 → 我方回传 cardNo + validateCode + status（1 通过 / 2 拒绝）。 规则：有效期 5 分钟，超时自动失败且不影响卡内余额；用户不在线走站内消息 + 推送；同一笔重复确认必须幂等；全部动作留审计日志。

3.17 开卡申请：持卡人判断

点产品卡上的「立即申请」后，必须先判断当前账号有没有持卡人：

• 创建持卡人与申请银行卡是两个独立动作，中间必须有「持卡人创建成功」页做分隔，不能一步跳进开卡流程。
• 确认开卡弹窗内容：卡产品 + 持卡人 + 开卡费 + 预充值 + 应付合计 + 支付方式 + 可用余额 + 取消 / 去支付。
• 确认开卡弹窗内卡产品行只做展示，不绑定任何跳转（避免误触发返回上一页）。
• 后续再开卡（第二张）时已有持卡人，直接进开卡申请页，不再出现持卡人空态。

3.18 首次使用完整流程（新用户从零到有卡）

这是新用户的完整链路，也是评审演示的主线：

• 第 4 步是必须的：没有持卡人不允许开卡，不能跳过。
• 第 7 步完成后持卡人即建立，先到持卡人创建成功页（第 8 步）；由用户主动「去申请银行卡」再发起开卡，此后再次开卡不再出现持卡人空态。
• 二次开卡（办理第二张卡）：卡片首页「卡+」→ 我的卡 →「添加银行卡」→ 可办理列表 → 卡上「立即申请」→ 已有持卡人，直接进开卡申请页。

4. 状态机

4.1 卡片状态（用户可见 4 态）

发卡系统返回的状态枚举需映射到上述 4 态，映射表在联调后补全。

4.2 其他状态

5. 接口映射（对接 THPay 商户开放平台）

5.1 THPay 官方接口清单（共 15 个，已逐一核对）

5.2 我方业务 → 接口映射

鉴权：RSA2048 私钥签名（SHA256withRSA → BASE64）写入请求头 x-access-token，另附 appId。

5.5 ⛔ 阻塞项：资金出卡的接口是否存在

「卡转出」是本方案中对用户资金安全的唯一保障。如果它不存在，用户的钱就是单向流入、无法取出——这属于产品能不能上的问题，不是优化项。

必须向 THPay 取得书面答复的四个问题

在得到答复前，「卡转出」与「提现到银行卡」两条路径均按"未证实"处理：

• 客户端可以先按设计稿实现，但上线前必须验证
• 若转出接口不存在，需重新评估产品可行性（用户资金无法退出）

补充澄清：文档中 Ⅰ类卡交易类型里的 「4 取现」 指用卡在 ATM 取现，与"提现到银行卡"不是一回事，不要混淆。

5.3 交易类型与状态（Ⅰ类卡）

交易类型（6 种）：1 充值/抵押、2 消费、3 退款、4 取现、5 赎回、6 管理费

交易状态（7 种）：1 成功、2 失败、3 处理中、4 已入账、5 未入账、6 支付失败、7 取消

客户端交易列表的状态文案需覆盖这 7 种，其中「已入账 / 未入账」要明确区分，避免用户误判。

5.4 官方接口清单中未覆盖的两项能力

以下两项在公开 API 文档中不存在对应接口，但业务上需要，须向 THPay 索取：

6. 数据模型（关键实体）

7. 非功能需求

8. 关键决策与建议

以下 16 项已在原型与本文档中按建议方案落地。如与业务判断不一致，请在评审时指出即可调整。

需向 THPay 取得书面确认的事实项

以下为对方侧事实，不影响本方案成立（模型已按保守口径计入），在合同签署前一并确认：

• 技术支持费 2,000 USD 的计费周期（月度 / 一次性）
• Visa 保证金 10,000 USD 的退还条件与时限
• 跨境费 2% 与交易手续费的商户分成机制
• 开卡时效与历史拒绝率
• 国家 / 省 / 市字典接口的提供方式与更新频率
• 卡片申请费 6,500 / 卡面设计费 3,000 / 年度项目费 3,000 是否适用于纯虚拟卡
• 「卡转出 / 赎回」接口文档（最高优先级）：客服称卡账户支持转出，但公开 API 清单无此接口；Ⅰ类卡交易类型里有「5 赎回」，需索取定义与接口
• 主账户能否对外出金：客服称「主账户仅支持充值不支持转出」，若属实则用户无法提现到银行卡
• 汇率获取方式：卡充值接口不传汇率，需确认能否提供下单前的参考汇率（否则客户端只能展示"预计入卡"）
• 提现到银行卡的可行性：主账户是否支持对外出金、出金通道与时效

9. 设计规范（Token，取自 Figma「iOS规范」）

9.1 颜色

浅色模式

暗黑模式

9.2 字体

• 字体族：PingFang SC（苹方）
• 行高 = 字号 + 6

10. 后台（运营 / 风控）功能清单

客户端只保留用户能自主执行的动作；风控、审核、资金调整、对账均为后台能力。 注：现有 Figma 文件（U8 Chat 2.0）中的 Web 端为 Web 客户端，不含后台设计，本章功能需从零设计。

10.1 开卡与 KYC 审核

10.2 卡片管理

10.3 持卡人管理

10.4 资金管理

10.5 交易管理

10.6 对账与差错

10.7 风控与配置

10.8 权限与审计

附：待补充内容

• 卡面视觉设计（需设计出图，含浅色 / 暗黑两套卡面）
• 全部错误码 → 用户可读文案映射表
• 测试用例（正常流程 / 支付失败 / 开卡被拒 / 回调幂等 / 对账差异 / 并发操作）
• 开卡、充值、转出的端到端埋点方案
• 邮箱绑定与管理流程（二期）：绑定 / 换绑 / 验证码校验、邮箱可用性校验、未绑定时的引导路径
• 敏感信息查看的审计报表（按人、按卡、按次）