Skip to main content
大多数商户是通过一张以*“我的账单上有一笔失败交易的手续费”*开头的支持工单接触到这个话题的。在某些合约下这是预期行为，本页解释何时以及如何发生。 结算行上每个金额如何计算，见结算计算详解。报表本身见结算报表与导出。

​
一笔失败的卡交易会向我收费吗？

会——如果你的合约为该类失败配置了手续费。 失败交易计费是按合约、按支付方式的设置，不是平台级政策。结算时，Waffo 会针对具体的失败阶段在你的协议中查找手续费：
  • 配置了手续费 → 该失败尝试进入结算并计费。
  • 未配置手续费 → 不创建任何内容，也不计费。该交易永远不会作为结算行出现。
因此两个商户可能有完全相同的失败交易，却只有一个看到收费。如果不确定自己属于哪种情况，检查你的结算明细中是否有任何带 Event Type（见下文）的行——如果没有，说明你没有被按失败计费。 无论你的手续费配置如何，还有两个范围限制：

​
哪些失败阶段可计费，区别是什么？

恰好两个： 它们在合约中是独立的费用项。你可能对其中一个计费而另一个不计费，金额也可以不同。这一区分在商业上有意义，因为两个阶段在上游的成本不同：认证失败比授权失败更早被拦截。 注意顺序上的含义——一次授权失败的尝试已经成功通过了认证，因此只按 AUTHORIZATION_FAILURE 计费。单次尝试永远不会产生两笔失败费。

​
如何分辨我的哪些交易是按失败计费的？

看 Event Type 列。它紧跟在 Transaction Type 之后，出现在你的结算明细导出、结算预估导出和 Portal 列表中。 按此列筛选或排序，就得到了该周期内按失败计费交易的完整列表。不需要另外申请单独的报表。

​
为什么失败行没有订单金额？

因为没有订单。没有收到任何款项，所以没有金额可报告——报告一个金额会暗示有从未流动过的资金。 在 Event Type 为 AUTHENTICATION_FAILURE 或 AUTHORIZATION_FAILURE 的行上，以下三列刻意留空：
  • Order Amount
  • Order Currency
  • Order Amount (Settlement Currency)
该行确实携带的是手续费一侧： 因此这类行上的 Settlement Amount 是负数——它是一笔没有订单金额抵消的手续费。这是正确的解读，不是数据错误，也是一个结算周期净额可能低于你成功支付总额所暗示水平的原因之一。 如果你的对账方式是把 Order Amount 相加再与 Settlement Amount 比较，失败行会看起来像一个无法解释的差额。请把手续费列也一并相加进行对账。

​
失败费是按某个基数的百分比收取的吗？

不是。失败费是固定金额——没有订单金额可供百分比作用。 由此引出一个偶尔让人意外的约束：失败费的币种必须与你在该支付方式上的支付手续费币种相同。失败费不能以与其并列的成功支付手续费不同的币种计费。

​
我的客户重试后最终支付成功了，那些失败也向我收费了吗？

每一次尝试都单独记录和评估。一笔前面有失败尝试的成功支付，会为成功的那次尝试产生一行成功支付——并且如果你的合约对该失败阶段定价——为每一次未成功的尝试产生一行失败。 所以答案取决于你的合约，但结构是明确的：最终成功不会追溯性地取消之前的失败。它们是同一订单上的独立事件，各有自己的序号，并且按尝试去重而不是按订单去重。 这是导致失败费总额超出预期的最大单一因素。一个鼓励快速重试的收银流程——或一个在短时间内连发多次尝试的绑卡重试排期——会让一次最终成交的失败次数成倍增加。如果失败计费适用于你，重试的成本不为零，重试策略就成了商业决策而不仅是转化率决策。

​
我能在结算日之前看到失败费吗？

能，在你的结算预估数据中，它带有同样的 Event Type 列。失败尝试一旦被拾取就会出现在那里，并带有预估手续费，因此你可以提前计提，而不是在结算日才发现。 同样的金额隐藏规则适用：失败尝试的预估行没有订单金额，只显示 Est Fee Amount、Est. Tax Amount、Tax Currency 和 Est Settlement Amount。预估导出的限制及其数字的估算方式，见手续费与税费处理。

​
我能做什么来减少失败费？

失败费由尝试次数驱动，因此所有的抓手都在 Waffo 的上游： 用上文描述的 Event Type 拆分看两个阶段中哪个占主导。两者原因不同、对策不同，而且分布通常是一边倒的。

​
在 Merchant Portal 的哪里能找到这些交易？

在 Settlements → Settleable Transactions 下。它按单笔交易粒度列出可结算交易，包括按失败计费的交易，是任何”我到底被收了什么费”问题的实际起点。 可用筛选： Sub Merchant Id 也是结果表格的第一列。 该列表支持导出。导出文件的字段布局与列表相同，完成的文件出现在同一页面的下载列表中而不是立即下载——导出任务的行为见导出与报表下载。

​
能在支付 API 上拿到失败阶段吗？

没有专门的字段。订单 API 对失败订单返回 orderFailedReason，告诉你为什么失败；它们不返回单独的认证-授权阶段标记。 你能看到该阶段的地方在下游的结算数据中：即上文所述报表和 Portal 列表中的 Event Type 列。如果你的对账需要把一笔失败费归属到某次具体尝试，请用结算明细中的订单标识做关联，而不是期望支付响应上带有阶段。

​
我在交易列表里能看到那次失败，但结算里没有，是漏了什么吗？

没有——只要该失败对你不可计费，这就是预期结果。交易列表和你的结算数据回答的是不同的问题： 因此，一次在交易列表可见但结算中缺失的失败，意味着以下三种情况之一，都属正常：
  1. 你的合约未为该阶段和支付方式配置失败费。不计费，所以不创建任何内容。
  2. 该失败不是网络交互失败——在到达网络之前就被校验拒绝，不带失败阶段。
  3. **该交易尚未被拾取进入结算。**在断定其缺失之前，先检查结算预估数据。
反过来——一条你在交易列表中找不到的结算行——才是值得提出的真正差异。没有结算行的失败则不是。

​
失败交易除了手续费之外还影响别的吗？

只影响手续费行项。一次按失败计费的尝试：
  • 不产生订单金额，因此不进入你的 Order Amount 合计；
  • 不在订单金额上产生支付手续费、VAT 或 WHT——失败费就是全部费用；
  • 确实以负数形式计入你的结算金额，如上所述；
  • 按交易日期对应的正常结算日结算，与其他任何可结算交易一样。