1. 潜在买家是否看到了可购买的产品？
比较完整且口径一致的时间段，把公开产品页、专题页与运营后台、商户后台、支付页面分开。内部人员、QA 和已有商户不应自动算作新客户。历史内部访问无法识别时，应说明限制，而不是声称已全部剔除。
检查真实销售页的语言、产品演示、价格与购买按钮。浏览量不是购买按钮点击数；没有点击埋点应写“未知”，不能写“零”。匿名访客若没有有效关联证据，不能逐人连接申请或订单，也不能用不同范围的总数计算看似精确的转化率。
2. 购买按钮是否抵达正确的 Checkout？
在桌面和手机上沿当前公开销售链接检查，不提交付款。核对对应 Store、商品、有效 Price、金额和币种。已发布但未放到销售页的链接、旧套餐入口或点击后无提示的按钮，都可能在支付处理之前阻断购买。
API 接入需要区分“点击了按钮”与“成功创建了 session”，保留脱敏 request/session ID 和服务端响应；Hosted 链接则核对实际目标页及错误提示。只修复已定位的入口问题，不为通过测试而改变审批条件或随意新增正式价格。
3. 买家停在俄罗斯付款流程的哪一步？
分别记录 Checkout 打开、付款方式选择、进入银行确认、服务端最终付款结果。俄罗斯央行对 SBP 的介绍包括二维码、链接、按钮等付款方式，买家需要核对收款方和金额后确认。这只是通用买家流程，不代表所有 Store 都已开通对应能力。
以具体 Store 获批的付款方式和计费模式为准。一次性 RUB 付款成功不代表已开通自动续费。待处理、失败、过期与已付款必须分开；结果不明时先核对原订单，不要直接让买家再付一次。浏览器返回成功页或截图，不能单独作为付款事实。
4. 是付款已确认，但数字权益没有交付吗？
从已验证的付款事件追溯同一订单和客户，再核对许可证、下载权限、积分或有效期记录。验证签名和订单身份，对重复事件进行幂等处理。HTTP 200 只能说明接口返回了响应，不能证明用户已经收到权益。
人工交付也应有负责人和关联订单的完成记录。分析工具中的 purchase 事件是另一层测量：Yandex 文档说明电商事件数据，Google 文档说明交易 ID 去重。浏览器分析事件的有无，都不能替代真实付款和交付记录。
5. 什么才算第一笔真实客户订单？
将证据区分为真实客户购买、内部/QA/sandbox/受控付款测试，以及信息不足待核实。仅有 paid、Live session 或未标记为测试，均不足以下结论。应结合订单、付款事件、测试标记和实际客户业务背景判断；未核实的交易不计入已证实商业首单。
Checkout 发布、商户确认已开始营业、付款与交付完成是不同里程碑。后续退款单独记录，不抹除原付款历史。本诊断清单不要求每个商户上线前必须真实扣款，也不增加额外审批环节。
6. 联系支持时，最小证据包应包含什么？
提供发生时间及时区、Test/Live 模式、对应 Store 和商品/Price 引用、脱敏 order/session/event/request ID、预期与实际现象，以及最后已确认的步骤。必要时附购买页地址和脱敏错误截图，并说明权益是否实际到账、能否不付款重现问题。
不要通过普通工单或邮件发送密钥、完整付款凭证或身份证件。结果不明的付款应先与约定支持联系人核实，再决定下一步。先改善已观察到的薄弱环节，再增加投放；如果尚无目标访客抵达有效购买入口，就还不能证明支付失败。