总结
支付成功率是指虚拟商店中尝试支付的款项获得授权的比例。该指标因统计口径不同（如按所有尝试次数、仅购买行为或到达发卡行的交易）而存在差异。本文通过示例解析了三种统计方法，引用了 Stripe 的定义，并提供了在电子表格中持续追踪该比率的常规方法。
支付成功率的计算公式看似简单：批准交易数 ÷ 尝试交易数。但核心难点在于“除数”的界定。根据统计的是客户发起的总尝试次数、实际购买行为，还是仅到达发卡行（Issuing Bank）的交易，同一周的销售数据可能得出三个截然不同的结果。本文将展示这三种计算方法及示例，并结合支付处理商 Stripe 的定义，介绍一套标准化的数据追踪流程。
为什么同一周会出现三种不同的比率？
以下为一个假设情景：某商店一周内记录了 1,000 笔信用卡支付订单。因输入错误或卡片被拒等原因，部分客户重新尝试，共产生 1,150 次支付请求。商店反欺诈工具在将请求发送至发卡行前，拦截了其中 50 次高风险交易。最终，900 笔订单获得批准。
| 计算方式 | 计算公式 | 结果 |
|---|---|---|
| 按客户发起的尝试次数 | 900 ÷ 1,150 | 78.3% |
| 按到达发卡行的尝试次数 | 900 ÷ 1,100（1,150 - 商店拦截的50次） | 81.8% |
| 按购买行为（仅统计每笔购买的最终结果） | 900 ÷ 1,000 | 90% |
这三个数值均正确，但回答的问题不同，不可直接横向对比。若商店未统一统计口径，仅凭报告中“正常值为90%”的经验判断，可能会误判自身运营状况。
每种统计口径对应的决策场景
ConnectWeek 认为，不同账户指标服务于不同的业务决策：
- 按客户发起的尝试次数：反映客户体验摩擦度。多次重试通常意味着表单设计混乱、输入错误率高或客户在被拒后仍坚持支付。
- 按到达发卡行的尝试次数：隔离发卡行决策因素。便于与支付服务商沟通，区分银行侧拒绝与商店自身风控限制。
- 按购买行为：反映最终成交效率。这是评估收入转化最直接的指标。
注：第一种与第二种计数的差值即为商店自行拦截的部分。在支付公司后台中，第二种计数还可能排除买家身份验证失败的案例。关于拦截优质客户的成本，可参考反欺诈误报相关文章。
Stripe 如何定义费率及处理重复尝试
Stripe 在其英文文档“接受度分析（Acceptance Analysis）”页面中明确了相关定义（ConnectWeek 于 2026年10月8日查阅）。该页面区分了两种核心费率：
- 支付成功率（Payment Success Rate）：卡网络授权的收费次数 ÷ 通过 Stripe 发送的唯一支付尝试次数。分母包含 3DS 验证失败、被阻止、被发卡行拒绝及已授权的尝试；仅排除无效 API 调用（Invalid API Calls，即商店与 Stripe 集成错误导致的拒绝）。
- 授权率（Authorization Rate）：发卡行授权的支付次数 ÷ 发送到卡网络进行授权的唯一尝试次数。分母不包含无效调用、3DS 验证失败和被阻止的支付，因为这些失败发生在授权请求发送至发卡行之前。
文档示例：103,000 个支付请求减去 3,000 个无效调用剩 100,000 个；再减去 1,000 个验证失败和 1,000 个被阻止请求，98,000 个到达卡网络，其中 93,000 个获授权。据此计算：支付成功率为 93%（93,000/100,000），授权率为 94.9%（93,000/98,000）。
针对同一购买的重复尝试，Stripe 提供两种算法：总费率计算所有尝试（含重复）；去重费率仅考虑最终结果。例如一笔支付失败两次后第三次成功，总费率为 33.3%（1/3），去重费率为 100%（1/1）。
此外，Stripe 建议分析唯一拒付案例时排除后续新尝试，以更清晰呈现授权率。需注意，其他支付服务商的定义可能不同，建议查阅其官方文档。
向支付服务商确认的四个关键问题
在对比任何费率数据前，ConnectWeek 建议先核实以下信息：
- 后台数字统计的是“尝试次数”还是“购买次数”？
- 被反欺诈系统拦截的尝试是否计入分母？
- 买家身份验证失败是否计入分母？
- 该数据是否混合了信用卡与其他支付方式？
最后一点尤为重要，因为每种支付方式的链路独特。建议按支付方式分别读取批准率，而非仅看单一汇总数字。关于信用卡销售涉及的角色，请参考网关、收单行及子收单行相关文章。
Excel 数据追踪常规操作
以下为 ConnectWeek 建议的每周付款导出分析流程：
1. 固定主账户，切勿混用。追踪销售额时使用“按购买计算”账户；追踪体验摩擦时使用“按客户尝试次数”账户。严禁跨周期切换统计口径。
2. 保存本周四个基础数据。即：购买量、尝试次数、到达发卡行次数、批准购买量。保留原始数据以便后续灵活重算任意比率。
3. 计算“每笔购买尝试次数”。如前例 1,150÷1,000=1.15。若该值上升，说明客户需频繁重试或存在非正常尝试（如盗刷测试）。即使整体比率不变，此指标波动也值得警惕。
4. 仅在总数异常时分组下钻。高价值分组包括：支付方式、订单金额区间、设备类型（移动端/PC）、拒付原因。拒付原因细分可参考结账批准率相关文章。
5. 记录本周变更事项。如反欺诈规则调整、营销活动受众变化、支付服务商更换等。若无变更记录，比率波动将无法归因。
三种常见的账单误读
ConnectWeek 总结了以下高频误区：
- 盲目庆祝因尝试减少而提升的比率：若商店在二次发送前拦截了同一卡片请求，到达发卡行的比率虽上升，但并未带来额外批准订单。前提是这些被拦截请求确实多为无效交易。
- 误将商店风控归咎于银行：若账户包含被商店反欺诈拦截的尝试，收紧风控规则会导致比率下降，但这并非发卡行拒付所致。
- 过早解读月末数据：Stripe 提示，在无重复计算的情况下，当月最后几天的比率可能暂时偏低，因为部分新尝试尚未完成全流程。
通过率仅衡量支付环节，支付前流失的客户不在此列。关于客户流失的关键节点，详见“转化型结账流程”文章。为达成月度订单目标，请结合转化率与客单价，参考“店铺为实现订单目标所需访问量计算”模型。
来源与方法论（最后更新：2026年10月8日）
- Acceptance Analysis（含支付成功率、授权率、总通过率及去重后通过率计算示例）—— Stripe 官方文档
- Chargebacks（拒付率跟踪；首次拒付与新尝试区分）—— Stripe 官方文档
- 1,000笔交易假设案例、三种统计方式、四个核查问题、阅读常规及常见误读 —— ConnectWeek 自编（非官方文本）
常见问题
虚拟商店的支付批准率多少算合理？
Stripe 文档未提供参考基准值。商店数据只能与相同统计口径的数据对比（按尝试次数、按到达发卡行次数或按购买次数）。ConnectWeek 建议以自身历史数据为基准，保持每周对比且始终使用同一账户。
客户的重新尝试是否计入批准率？
取决于统计方式。Stripe 文档中，“总批准率”包含同一购买的所有尝试；“无重复批准率”则合并重复尝试，仅看最终结果。例如一笔支付失败两次后第三次成功，总批准率为 33.3%，无重复批准率为 100%。
被反欺诈系统拦截的支付是否算作拒绝？
视具体指标而定。在 Stripe 文档中，“支付成功率”的分母包含被 Radar 等工具拦截的请求；而“授权率”则排除此类拦截，因其发生在授权请求发送至卡组织之前。其他服务商规则可能不同，请以官方文档为准。
为什么支付服务商后台显示的批准率与商店表格不同？
最常见原因是分母定义不一致。后台可能统计“尝试次数”且排除了反欺诈拦截案例，而表格可能统计“购买次数”且包含了拦截案例。排查差异前，请先确认双方各自的统计口径。