先明确讨论对象和证据范围
“招行数字钱包活动方案的功能边界怎么确认”首先涉及对象识别：数字钱包具体指哪项产品，活动通过什么入口开展，方案对应哪个版本。名称相近不代表账户体系、支付方式或优惠规则相同。本文仅讨论通用确认方法，不认定招行存在某个特定活动，也不确认其具体功能。
W3C的Payment Request API文本介绍网页支付交互；中国人民银行新闻索引列出新闻入口，并非该活动的业务说明。两者不能共同证明招行某个钱包活动的参与资格、优惠额度或上线状态。具体结论需要对应活动规则和产品说明支撑。
区分支付交互与实际资金处理
Payment Request API的作用是规范商户、用户代理与支付方式提供方之间的交互。商户可以声明支持的支付方式并提供交易金额等信息，浏览器等用户代理协助呈现支付请求。创建新支付方式、直接对接支付处理机构，不属于这项规范的范围。
因此，能够展示支付界面，不等于已经完成扣款、清算或结算；取得支付响应，也不能直接等同于优惠发放成功。方案应分别写清界面展示、支付处理、订单确认和权益发放由谁负责，避免把不同环节合并成一个“支付成功”。
将活动能力拆成可核对的条目
建议把需求分为活动展示、资格判断、优惠计算、支付发起、结果确认、权益发放和售后处理。每项分别记录适用条件、输入信息、输出结果、责任方及确认依据，并标明已确认、待确认或不在本次范围内。
例如，“页面显示优惠”与“订单实际享受优惠”应分开描述。优惠是否需要领取、能否叠加、退款后如何处理，都应由对应活动规则明确；没有证据时应保留为待确认项，不能依据通用接口能力作推断。
适用条件应明确到具体环境
技术规范描述的能力不等于所有使用环境均支持。确认方案时，应逐项核对网页或应用入口、目标设备与浏览器、商户接受的支付方式，以及所需的接入条件。不能仅凭规范中的示例认定某家银行或某款钱包已经完成适配。
个人信息需求也应单独列明：每个环节需要哪些信息、用于什么目的、由谁处理。接口存在某个可选字段，不意味着活动必须采集该信息，更不等于已经获得使用授权。
常见问题与验收标准
支付完成是否必然获得活动权益？不能直接这样认定。支付结果与活动资格、权益发放是不同判断，应分别核对规则和结果依据。央行新闻入口能否证明活动获得认可？仅凭新闻索引不能得出这一结论，更不能推导出具体产品承诺。
最终可把功能边界整理为验收清单：正常流程能完成什么，用户取消、请求超时、结果重复通知及退款时如何处理，哪些问题需要交由支付服务方或活动运营方确认。对仍缺乏依据的功能明确标注，不把计划能力写成既有能力。