> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 失败卡交易的计费

> 为什么一笔从未成功的卡支付仍会出现在你的结算账单上：哪些失败阶段可计费、Event Type 列如何工作、为什么失败行没有订单金额，以及如何在 Merchant Portal 中找到并导出这些交易。

大多数商户是通过一张以\*"我的账单上有一笔失败交易的手续费"\*开头的支持工单接触到这个话题的。在某些合约下这是预期行为，本页解释何时以及如何发生。

结算行上每个金额如何计算，见[结算计算详解](/docs/zh/support/settlement-calculation-explained)。报表本身见[结算报表与导出](/docs/zh/support/settlement-reports-faq)。

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

会——如果你的合约为该类失败配置了手续费。

失败交易计费是**按合约、按支付方式的设置**，不是平台级政策。结算时，Waffo 会针对具体的失败阶段在你的协议中查找手续费：

* **配置了手续费** → 该失败尝试进入结算并计费。
* **未配置手续费** → 不创建任何内容，也不计费。该交易永远不会作为结算行出现。

因此两个商户可能有完全相同的失败交易，却只有一个看到收费。如果不确定自己属于哪种情况，检查你的结算明细中是否有任何带 `Event Type`（见下文）的行——如果没有，说明你没有被按失败计费。

无论你的手续费配置如何，还有两个范围限制：

| 限制 | 详情 |
| - | - |
| 交易类型 | 仅 `PAYMENT` 交易。退款和拒付没有失败阶段计费。 |
| 失败位置 | 仅**与支付网络交互**过程中发生的失败。在到达网络之前就被 Waffo 自身校验拒绝的请求不可计费，也不带失败阶段。 |

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

恰好两个：

| 阶段 | 失败的环节 | 典型情况 |
| - | - | - |
| `AUTHENTICATION_FAILURE` | 持卡人认证步骤 | 3-D Secure 未完成或不匹配 |
| `AUTHORIZATION_FAILURE` | 认证通过后的授权步骤 | 卡被拒、已过期，或尝试出错 |

它们在合约中是独立的费用项。你可能对其中一个计费而另一个不计费，金额也可以不同。这一区分在商业上有意义，因为两个阶段在上游的成本不同：认证失败比授权失败更早被拦截。

注意顺序上的含义——一次授权失败的尝试已经成功通过了认证，因此只按 `AUTHORIZATION_FAILURE` 计费。单次尝试永远不会产生两笔失败费。

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

看 **`Event Type`** 列。它紧跟在 `Transaction Type` 之后，出现在你的结算明细导出、结算预估导出和 Portal 列表中。

| `Event Type` 值 | 含义 |
| - | - |
| `PAY_SUCCESS` | 正常的成功支付 |
| `AUTHENTICATION_FAILURE` | 认证阶段的计费失败 |
| `AUTHORIZATION_FAILURE` | 授权阶段的计费失败 |

按此列筛选或排序，就得到了该周期内按失败计费交易的完整列表。不需要另外申请单独的报表。

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

因为没有订单。没有收到任何款项，所以没有金额可报告——报告一个金额会暗示有从未流动过的资金。

在 `Event Type` 为 `AUTHENTICATION_FAILURE` 或 `AUTHORIZATION_FAILURE` 的行上，以下三列**刻意留空**：

* `Order Amount`
* `Order Currency`
* `Order Amount (Settlement Currency)`

该行*确实*携带的是手续费一侧：

| 报表 | 失败行上有值的列 |
| - | - |
| 结算明细 | `Fee Amount`、`Fee Currency`、`Fee Amount (Settlement Currency)`、`Settlement Amount` |
| 结算预估 | `Est Fee Amount`、`Est. Tax Amount`、`Tax Currency`、`Est Settlement Amount` |

因此这类行上的 `Settlement Amount` 是**负数**——它是一笔没有订单金额抵消的手续费。这是正确的解读，不是数据错误，也是一个结算周期净额可能低于你成功支付总额所暗示水平的原因之一。

如果你的对账方式是把 `Order Amount` 相加再与 `Settlement Amount` 比较，失败行会看起来像一个无法解释的差额。请把手续费列也一并相加进行对账。

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

不是。失败费是**固定金额**——没有订单金额可供百分比作用。

由此引出一个偶尔让人意外的约束：失败费的币种**必须与你在该支付方式上的支付手续费币种相同**。失败费不能以与其并列的成功支付手续费不同的币种计费。

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

每一次**尝试**都单独记录和评估。一笔前面有失败尝试的成功支付，会为成功的那次尝试产生一行成功支付——并且如果你的合约对该失败阶段定价——为每一次未成功的尝试产生一行失败。

所以答案取决于你的合约，但结构是明确的：最终成功不会追溯性地取消之前的失败。它们是同一订单上的独立事件，各有自己的序号，并且按尝试去重而不是按订单去重。

这是导致失败费总额超出预期的最大单一因素。一个鼓励快速重试的收银流程——或一个在短时间内连发多次尝试的绑卡重试排期——会让一次最终成交的失败次数成倍增加。如果失败计费适用于你，重试的成本不为零，重试策略就成了商业决策而不仅是转化率决策。

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

能，在你的**结算预估**数据中，它带有同样的 `Event Type` 列。失败尝试一旦被拾取就会出现在那里，并带有预估手续费，因此你可以提前计提，而不是在结算日才发现。

同样的金额隐藏规则适用：失败尝试的预估行没有订单金额，只显示 `Est Fee Amount`、`Est. Tax Amount`、`Tax Currency` 和 `Est Settlement Amount`。预估导出的限制及其数字的估算方式，见[手续费与税费处理](/docs/zh/support/fee-and-tax-treatment-faq)。

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

失败费由尝试次数驱动，因此所有的抓手都在 Waffo 的上游：

| 抓手 | 为什么有帮助 |
| - | - |
| 提交前校验卡信息 | 在客户端捕获的卡号、有效期和 CVV 格式错误永远不会到达网络，因此永远不会计费 |
| 限制每个订单的重试次数 | 每次尝试单独计费，因此一个无限制的"再试一次"按钮会把一笔丢失的销售变成多笔手续费 |
| 拉开绑卡重试的间隔 | 对刚被拒的卡立即重试很少改变结果，而每一次都算 |
| 专门关注你的认证失败率 | `AUTHENTICATION_FAILURE` 占比高往往指向可修复的集成或用户体验问题，而不是真正的拒付 |

用上文描述的 `Event Type` 拆分看两个阶段中哪个占主导。两者原因不同、对策不同，而且分布通常是一边倒的。

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

在 **Settlements → Settleable Transactions** 下。它按单笔交易粒度列出可结算交易，包括按失败计费的交易，是任何"我到底被收了什么费"问题的实际起点。

可用筛选：

| 筛选项 | 说明 |
| - | - |
| Order Id / Merchant Order Id / Payment Request Id / Merchant User Id | 组合搜索——先选标识类型，再输入值 |
| Sub Merchant Id | 仅当你有子商户时显示 |
| Order Currency | |
| Transaction Type | `PAYMENT` / `REFUND` / `CHARGEBACK` / `CHARGEBACK_ALERT` |
| Settlement Status | `UNSETTLED` / `SETTLED` |
| **Event Type** | `PAY_SUCCESS` / `AUTHENTICATION_FAILURE` / `AUTHORIZATION_FAILURE` |
| **Payment Date** | 日期范围，**上限 31 天**——选择器不允许选更宽的跨度 |

`Sub Merchant Id` 也是结果表格的第一列。

该列表支持**导出**。导出文件的字段布局与列表相同，完成的文件出现在同一页面的下载列表中而不是立即下载——导出任务的行为见[导出与报表下载](/docs/zh/support/export-center-faq)。

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

没有专门的字段。订单 API 对失败订单返回 `orderFailedReason`，告诉你*为什么*失败；它们不返回单独的认证-授权阶段标记。

你能看到该阶段的地方在**下游的结算数据中**：即上文所述报表和 Portal 列表中的 `Event Type` 列。如果你的对账需要把一笔失败费归属到某次具体尝试，请用结算明细中的订单标识做关联，而不是期望支付响应上带有阶段。

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

没有——只要该失败对你不可计费，这就是预期结果。交易列表和你的结算数据回答的是不同的问题：

| 查看位置 | 显示内容 |
| - | - |
| 交易列表 | 每一次尝试，无论成功与否，因为它是活动记录 |
| 结算数据 | 只有影响资金的内容——成功交易，以及**你的合约定价了的**失败 |

因此，一次在交易列表可见但结算中缺失的失败，意味着以下三种情况之一，都属正常：

1. 你的合约**未为**该阶段和支付方式**配置失败费**。不计费，所以不创建任何内容。
2. **该失败不是网络交互失败**——在到达网络之前就被校验拒绝，不带失败阶段。
3. \*\*该交易尚未被拾取进入结算。\*\*在断定其缺失之前，先检查结算预估数据。

反过来——一条你在交易列表中找不到的结算行——才是值得提出的真正差异。没有结算行的失败则不是。

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

只影响手续费行项。一次按失败计费的尝试：

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.