先明确“子钱包扩容”检查范围
子钱包扩容可以表现为新增可使用场景、增加关联商户或服务机构、扩大设备和渠道覆盖，也可能涉及钱包功能、支付权限或管理接口的调整。检查前应写清楚本次变更影响哪些用户、哪些交易类型、哪些终端，以及是否改变原有的身份核验、授权和限额规则。范围不清，后续测试容易遗漏关键路径。
公开参考材料分别涉及金融管理机构网站信息和数字钱包的一般技术结构，不能直接证明某一具体数字人民币子钱包项目的实施细节。因此，下面的要点适用于数字钱包或支付账户扩容的通用审查，具体项目仍应以其正式制度、技术方案和测试记录为准。
身份认证与授权边界
扩容后首先要确认用户是否仍能清楚识别自己正在开通或使用的子钱包，以及新增服务是否经过明确授权。应检查开户、绑定、解绑、换设备、找回和注销等流程，避免仅凭弱校验就新增支付权限。对涉及商户、平台或机构的关联关系，还要区分用户授权、机构操作权限和系统自动处理权限。
授权应遵循最小必要原则。一个子钱包可以被允许用于特定场景，并不意味着相关平台能够查看全部钱包信息、发起任意交易或长期保留操作权限。检查时应核对权限清单、授权期限、撤销方式和操作留痕，确认用户能够查询已经授予的权限，并在不再需要时方便地关闭。
交易限额、风控与异常处置
扩容可能增加交易入口、设备数量和参与机构，系统需要重新评估小额高频交易、短时间大量绑定、异地登录、设备批量切换和连续失败验证等风险信号。限额设计应与业务场景、用户身份核验强度和风险等级相匹配，并能对异常行为进行分级处理。不能只检查单笔交易，也要关注一段时间内的累计金额、次数和关联账户行为。
异常处置应覆盖提醒、拦截、人工复核、冻结、申诉和恢复等环节。用户需要知道异常提示的含义、联系方式和后续处理路径。系统还应保留必要的时间、设备、授权和处理记录，用于定位问题与复核责任，同时避免收集与风控目的无关的过多信息。
接口、设备与数据安全
子钱包扩容通常会增加系统之间的接口调用。检查重点包括接口身份校验、传输保护、重放防护、请求幂等、权限隔离和错误处理。对外部平台开放能力时，应限制可调用的功能和数据字段，并验证平台无法通过参数篡改绕过支付规则。接口日志应能关联到具体业务操作，但敏感信息应按需要进行脱敏或减少留存。
设备侧也需要重新验证安全边界。应检查新接入的手机、可穿戴设备、收款终端或应用版本是否具备安全更新、丢失处理和异常解绑能力。数字钱包的一般安全设计会关注密钥、认证凭据和交易签名等要素；在数字人民币场景中，具体实现方式应以运营机构公布的规则和技术要求为准，不能直接套用其他钱包系统的实现结论。
上线前测试与常见问题
上线前应同时做正常流程、边界条件和故障恢复测试，例如重复绑定、授权过期、网络中断、设备丢失、接口超时、重复提交和部分服务不可用。测试结果应记录场景、预期行为、实际结果、遗留问题和责任人。扩容后还应进行灰度观察，关注失败率、投诉类型、异常告警和人工处理压力，并设置可回退的变更方案。
常见问题是“新增子钱包是否等于新增独立账户”。这不能仅凭名称判断，应查看产品规则和法律关系；子钱包可能只是特定场景下的功能或关联载体。另一个问题是“开通后能否自动支付”。是否支持自动扣款、免密支付或周期性服务，取决于具体授权规则，检查时应要求展示授权内容、提醒机制、撤销入口和交易记录。
还应问清三个基本问题：用户能否看懂扩容后的权限变化，机构能否证明每次关键操作经过授权，系统能否在异常发生后及时限制影响范围。只有业务、合规、技术和客服记录能够相互对应，扩容后的风险控制才具备可核查性。