先明确讨论对象与适用范围
招行数字钱包活动方案的功能边界怎么确认，首先要明确“数字钱包”对应什么产品、使用哪个入口，以及方案覆盖哪些业务环节。本文解释通用的需求确认方法，不对招行某项具体活动的功能作出认定。
W3C的Payment Request API描述了网站、浏览器与支付方式之间的交互，并将创建新支付方式、直接对接支付处理机构排除在规范范围之外。因此，通用支付接口规范不能作为银行钱包活动能力的证明。
把活动规则与支付能力分开确认
活动规则需要回答谁能参加、哪些订单适用、优惠如何计算、何时生效，以及取消或退款后如何处理。支付能力则需要回答支持哪些支付方式、如何发起请求、怎样取得处理结果。两部分应分别核实，再说明它们如何衔接。
例如，页面能够展示优惠后的金额，只能说明展示环节具备相应设计；优惠资格是否成立、优惠是否实际生效，仍需业务规则和处理结果支持。需求中应写清每个判断由哪个系统负责，避免把页面展示等同于业务完成。
按完整流程标出责任交接
可以按活动展示、资格判断、金额计算、支付发起、结果确认、优惠兑现和售后处理梳理流程。每个环节记录输入信息、负责系统、输出状态与异常处理方式；尚未取得依据的能力标记为待确认。
支付请求返回响应后，还应明确后续由谁处理或验证交易。不能仅凭用户确认支付、页面跳转或关闭提示，就把订单认定为最终成功。具体确认机制应以实际支付服务的接口约定为准。
用可核对的材料落实边界
具体项目的确认依据应包括对应活动规则、产品说明、接口文档，以及相关责任方确认的需求记录。中国人民银行新闻栏目索引提供的是新闻条目入口，不能据此确认某个银行钱包的参与条件、优惠机制或接口权限。
功能清单可逐项写明适用条件、所需能力、依据、责任方和验收标准。例如，若方案涉及退款后的优惠处理，应明确全额退款与部分退款分别如何处理；规则缺失时，应保留为待确认事项，不能自行补成既定功能。
常见问题与验收要点
支持网页支付接口，是否就支持钱包活动？不能据此判断。接口交互、活动资格和优惠兑现分别需要对应依据；实际使用还取决于浏览器、支付方式及接入环境。
支付成功是否代表优惠已经到账？需要看活动规则和兑现机制。如果两个环节分别处理，方案就应分别定义状态、查询方式与异常责任。验收时除正常流程外，还应覆盖取消、失败、重复通知和退款等情形，逐项检查结果是否符合已确认的规则。