先明确“数字钱包”要解决什么问题
深圳市数字钱包的功能边界怎么确认，第一步不是罗列页面按钮，而是明确钱包服务的目标对象、使用场景和业务责任。需要回答：钱包是用于身份凭证管理，还是用于发起支付、保存支付工具、领取权益，或者同时承担这些功能。不同目标会带来不同的账户体系、认证强度、数据处理和运营责任。
尤其要避免把“数字身份”“支付账户”“支付工具”和“商户收款页面”混为一体。一个系统可以为支付流程提供身份认证，也可以调用外部支付方式，但这并不意味着它自然拥有支付清算、商户受理或政府身份管理等全部能力。
用五层模型划定范围
可以将功能拆成五层：第一层是身份与账户，包括注册、身份核验、账户绑定、登录和账户恢复；第二层是认证与授权，包括密码、设备凭证、多因素认证，以及用户是否确认某次操作；第三层是钱包资产或支付工具管理，例如展示可用方式、绑定或解绑工具、生成支付请求；第四层是交易协同，包括金额、币种、订单信息、支付结果和异常状态传递；第五层是运营与治理，包括权限、日志、隐私保护、风控、投诉处理和数据留存。
NIST数字身份指南的相关范围集中在身份核验、注册、认证器管理、认证协议、联邦及相关断言等环节。它适合帮助项目确认“谁在什么强度下证明了什么”，但不能单独证明某个深圳项目可以经营某类支付业务。支付资格、数据处理和具体业务许可仍需依据适用的法律法规、监管要求及项目合同核实。
区分钱包自身能力与支付方式能力
Payment Request API的核心定位，是让商户、用户代理和支付方式提供方围绕支付请求进行协作。商户描述订单和应付金额，用户选择并确认支付方式，支付方式提供方或支付处理组件完成相应处理。该接口本身并不创建新的支付方式，也不等同于直接接入支付处理机构。
因此，若深圳市数字钱包采用类似的前端支付协同思路，边界应明确写成：钱包负责展示可用方式、收集必要的交易信息、触发用户确认并接收规定格式的结果；支付工具的认证、扣款、清算、退款或争议处理由相应的支付方式提供方承担，除非项目另有明确且合规的业务安排。
形成可审查的边界清单
建议为每项功能建立“输入—处理—输出—责任方—异常处理”记录。例如，身份核验要写清核验材料来自哪里、核验结果保存多久、失败后如何恢复；支付确认要写清用户确认的对象、金额是否可变、支付结果由谁返回；绑定支付工具要写清钱包保存的是完整敏感信息、令牌还是仅为引用标识。
同时制作数据流图和责任矩阵，标记钱包、用户、商户、身份服务方、支付方式提供方及运营方之间的数据交换。凡是涉及个人信息、身份凭证、支付凭证、未成年人使用、跨系统登录或高风险操作的功能，都应单独列出认证要求、最小化采集原则、访问控制、审计和撤销机制。
适用条件与常见问题
如果钱包只承担身份登录和支付请求编排，重点是身份 assurance、认证器生命周期、授权确认、接口安全和结果校验；如果钱包还保存余额、管理资金或直接处理支付交易，边界就会扩大，必须另行核实相应的业务资质、资金安全、清算安排和消费者保护要求。不能因为使用了标准接口，就推导出业务合规性。
常见问题一：登录成功是否等于支付授权？不等于，支付通常还需要针对具体金额、收款方和交易内容进行明确确认。问题二：展示支付结果是否等于扣款成功？不等于，应以约定的权威结果和可核验状态为准。问题三：接入身份联邦是否代表钱包掌握真实身份全部信息？不一定，实际范围取决于断言内容、权限和数据共享约定。
用验收问题反向确认边界
在立项和验收时，可要求每项功能回答六个问题：谁发起操作；钱包处理什么；哪些步骤由外部服务完成；用户确认的具体对象是什么；失败、撤销和重复提交如何处理；产生哪些数据以及谁负责保护。若某项能力无法明确责任主体，或同时承担身份、支付和资金管理却没有清晰的授权依据，就应先缩小范围或补充合规与安全设计。
最终形成的边界文件应包括功能清单、角色责任矩阵、数据流图、接口约定、认证与授权规则、异常流程和不在范围内的事项。这样既能避免把通用身份技术标准误当成地方项目结论，也能让产品、技术、运营和合规团队对钱包究竟“能做什么、不能做什么”保持一致。