进入 Checkout 却没支付：先排故障，再谈优化

Checkout→Purchase 异常下跌时，第一动作是排除交易故障，不是改按钮文案。 到达结账的人已经有较强意图，支付不可用、地址规则错误、最终总价突变、验证信息不清或失败后无法恢复，都会直接阻塞成交。这些问题不需要 A/B 测试才有修复资格。

先做判断

先区分三种状态：用户主动放弃、用户无法继续、购买已完成但事件未记录。订单后台、支付状态和分析事件要交叉核对。若订单存在而 Purchase 缺失，这是测量问题；若支付尝试有明确失败，则是交易或风控问题；只有路径技术可用、价格透明后，才讨论认知摩擦。

若上一步就没有发起结账，先看购物车四类摩擦诊断；若要系统复现并留证，使用Cart 与 Checkout 证据验收剧本。

诊断框架

第一段：可达性。 从真实 PDP 和 Cart 进入 Checkout，覆盖主要市场、设备和登录状态。检查循环跳转、空白页、地区限制、库存变化与会话过期。若只在后台预览或特定测试链接成功，不能证明顾客路径可用。

第二段：最终总价。 记录商品小计、折扣、运费、税费、关税提示与最终应付金额出现的时点。用户在最后一步才看到显著变化，属于透明度问题。目标不是把费用藏晚，而是尽早给可理解的区间、门槛与适用条件。

第三段：表单。 检查访客是否能按业务允许的方式结账，字段是否必要，地址格式、自动填充、键盘和错误提示是否适配主要市场。错误信息要指出哪个字段、为什么错、怎么改；提交后才清空全表，是高风险摩擦。

第四段：支付。 按实际启用的支付方式、币种、国家和设备建立矩阵。看到支付 Logo 不等于可支付；需要确认方式真正出现、可选择、授权结果正确、失败理由可读。钱包跳转、三方验证、浏览器返回和重复点击都要测试，避免重复订单或死循环。

第五段：恢复与回读。 模拟一次校验失败或取消支付，确认购物车、地址、折扣和价格仍在，用户可重试或切换方式。完成后核对订单、支付状态、确认页、通知和 Purchase 事件只出现一次。支付成功但通知延迟，与支付失败是不同故障，不能合并描述。

常见误判

• 后台显示支付方式就代表顾客可用：市场、币种、设备、风控与账户状态都会改变实际可见性。
• Checkout 流失高就缩短按钮文字：总价或支付故障不会因文案更短而消失。
• 测试模式成功等于真实交易成功：真实授权、钱包、税费与风险校验可能不同。
• Purchase 没触发就是没订单：必须与订单和支付真源交叉核对。
• 只测试一次成功路径：失败恢复和切换支付往往才暴露真正阻塞。

验证清单

• 订单真源、支付状态与分析 Purchase 是否一致且去重。
• 主要市场、币种、设备和访客状态是否覆盖。
• 最终总价各组成项是否在用户决定前透明出现。
• 必填字段、地址格式、错误提示和自动填充是否可用。
• 实际启用的支付方式是否在对应条件下可见并可授权。
• 取消、失败、返回和重试后是否保留购物车与输入。
• 成功后订单、确认页、通知和事件是否完成回读。
• 证据是否经过脱敏，不保存卡号、完整地址或个人身份信息。

如果订单确实完成但 Purchase 仍然缺失或重复，停止改 Checkout，转到转化追踪验收证据链排查测量层。

适用边界

本诊断只用于获得授权的自有商店测试。支付、税费、关税、地址和平台可编辑范围会随国家、套餐、提供商及版本变化，具体步骤必须在执行当日核对官方资料。不要为测试制造不可撤销订单、绕过风控或采集真实顾客敏感信息；无法安全完成真实支付时，应明确证据只到沙盒或配置可见性，而不是声称已打通真实收款。