> ## 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.

# 拒付字段参考

> 用于在商户 Portal 和结算对账单中读懂拒付的字段词典：四种 CHARGEBACK Event Type 及其正负方向、Compulsory Channel Review 标志、客户争议与拒付时间线的每个事件、哪些事件会增加未读计数、拒付 CSV 导出的 26 列、Dispute Amount 如何得出、拒付手续费币种，以及每日争议报告中的 Alert Status 取值。

本页是
[拒付与争议 FAQ](/docs/zh/support/chargeback-faq) 背后的字段词典——流程如何运作、该做什么请看那一页；当您在 Portal、CSV 或结算明细行中看到某个值、需要知道它的含义时，请看本页。证据的选择见
[拒付证据指南](/docs/zh/support/chargeback-evidence-guide)。

## 我的结算明细里有一行 `CHARGEBACK`，Event Type 有哪些？资金是进还是出？

对于拒付变动，`Transaction Type` 始终为 `CHARGEBACK`。**`Event Type`** 列告诉您该行是扣款还是退回，以及它承载的是金额、手续费，还是两者都有：

| `Event Type` | 触发原因 | 该行的订单金额 | 该行的手续费 | 结算金额 |
| - | - | - | - | - |
| `FIRST_CB_PRE_DEDUCT` | 针对您发起的一次拒付（第一周期） | 争议金额 | 拒付手续费 | **负数**——`−(amount + fee)` |
| `FIRST_CB_AMOUNT_REFUND` | 第一周期以您胜诉结案 | 争议金额 | 零 | **正数**——`+amount` |
| `SECOND_CB_PRE_DEDUCT` | 发起第二周期（预仲裁） | **零**——金额不会被二次扣除 | 拒付手续费 | **负数**——仅 `−fee` |
| `SECOND_CB_AMOUNT_REFUND` | 第二周期以您胜诉结案 | 争议金额 | 零 | **正数**——`+amount` |

看模式而不是看金额，才是可靠的读法：`*_PRE_DEDUCT` 总是扣钱，`*_AMOUNT_REFUND` 总是退钱，手续费只会出现在 `PRE_DEDUCT` 行上。因此一个开案、升级、最终胜诉的案件，会在不同结算日期产生三到四行独立的 `CHARGEBACK` 记录——而不是一行净额。

哪些案件状态会产生哪种事件：

| 触发结算事件时的案件状态 | Event Type |
| - | - |
| `ACTION_REQUIRED`、`EVIDENCE_REQUIRED`、`UNDER_REVIEW`、`SECOND_CYCLE_RESPONSE_REQUIRED` | 对应周期的 `PRE_DEDUCT` |
| `CASE_WON`、`SETTLED`、`CANCELED` | 对应周期的 `AMOUNT_REFUND` |
| `CASE_LOST` | `PRE_DEDUCT`——金额归持卡人，不会退回任何款项 |

请注意 `CASE_LOST` 的后果：没有单独的"败诉"事件。您在开案时已经被扣款，因此败诉不会产生新的行——没有 `AMOUNT_REFUND` 行*就是*败诉。时间和结算日规则见
[拒付与争议 FAQ](/docs/zh/support/chargeback-faq)。

较早的记录可能带有空的 `Event Type`。这些记录早于此细分方式，且始终是扣款。

## 拒付详情页上的 `Compulsory Channel Review` 是什么？

`compulsoryChannelReview` 是案件上的一个 true/false 标志，返回给 Portal，记录支付侧是否强制要求对该案件进行其自身的审核。拒付创建时该值为 **true**；通过应用内投诉流程发起的客户争议创建时该值为 **false**。

请把它当作对结果预期的提示：为 true 时，案件由审核方裁决，您的提交是该审核的输入，而不是案件的解决方式。为 false 时，直接与客户解决案件是一个切实可行的选项，而关闭争议就是记录该解决结果的方式。

真正决定**关闭**操作是否可用的是案件状态，而不是这个标志：在 `EVIDENCE_REQUIRED`、`ACTION_REQUIRED` 和 `UNDER_REVIEW` 状态下可以关闭，`ESCALATED` 状态的案件不能关闭。因此如果关闭按钮是灰色的，请先检查状态。

## 客户争议时间线里每个事件是什么意思？

时间线记录 11 种事件值。不在此列表中的都不是时间线事件。

| 事件 | 出现时机 | 您要做什么 |
| - | - | - |
| `CREATE_DISPUTE` | 针对某笔支付发起了争议 | 阅读原因，决定抗辩、回复还是退款 |
| `MERCHANT_SUBMIT_EVIDENCE` | 您提交的证据已被接受；案件进入 `UNDER_REVIEW` | 无需操作——等待审核 |
| `MORE_EVIDENCE_REQUIRED` | 被要求提供更多材料；案件回到 `EVIDENCE_REQUIRED` | 上传补充材料 |
| `DISPUTE_ESCALATED` | 同一笔支付上发起了拒付；此记录停止推进 | 转而处理关联的拒付 |
| `CLOSE_DISPUTE` | 案件已关闭——由您或由审核方关闭 | 无需操作，除非客户再次投诉 |
| `NOTIFY_OVERDUE` | 案件被标记为即将到达证据截止时间 | 在截止时间前提交 |
| `EXPIRED` | 证据截止时间已过 | 案件**仍可处理**——见下文关于过期的问题 |
| `USER_RESPONSE` | 客户在争议对话中回复了 | 阅读；有必要时回复 |
| `PLATFORM_RESPONSE` | 审核方发来了回复 | 阅读；通常会指明缺少什么 |
| `MERCHANT_RESPONSE` | 您自己的回复已发布 | 无需操作 |
| `USER_CREATE_COMPLAINT` | 客户再次发起投诉——这就是使 `CLOSED` 案件重新打开的事件 | 回应；案件回到打开状态 |

## 拒付时间线里每个事件是什么意思？

14 种事件值，与客户争议的集合不同：

| 事件 | 出现时机 | 您要做什么 |
| - | - | - |
| `CREATE_DISPUTE` | 拒付已创建 | 阅读 `reasonCode`、`reason` 和 `expiryDateTime`；决定抗辩还是接受 |
| `MERCHANT_SUBMITS_EVIDENCE` | 您提交的证据已被接受 | 等待 |
| `AUTO_SUBMITS_EVIDENCE` | 根据您配置的处理策略，已自动代您提交证据 | 核对提交了什么——您已被记录为进行了抗辩 |
| `MORE_EVIDENCE_REQUIRED` | 审核后被要求提供补充材料 | 在截止时间前上传 |
| `NOTIFY_OVERDUE` | 案件被标记为即将到达截止时间 | 提交或接受 |
| `MERCHANT_ACCEPTED_DISPUTE` | 您接受了该案件 | 无需操作——此操作不可撤销 |
| `MERCHANT_WON_DISPUTE` | 裁决对您有利 | 预期会有一行 `AMOUNT_REFUND` 结算记录 |
| `MERCHANT_LOST_DISPUTE` | 裁决对您不利 | 本周期无后续操作；可能会有第二周期 |
| `CHARGEBACK_SETTLED` | 案件在正常流程之外和解 | 金额退回，手续费保留 |
| `CHANNEL_CLOSE_DISPUTE` | 发起方撤回了案件 | 金额退回，手续费保留 |
| `CHARGEBACK_EXPIRED` | 截止时间前未回应 | 无需操作——金额不会退回 |
| `ESCALATED_TO_2ND_CYCLE` | 案件升级到预仲裁 | 现在已存在一条新的第二周期记录；处理那一条 |
| `CREATE_SECOND_CYCLE_DISPUTE` | 第二周期记录已创建 | 抗辩或接受；第二周期**不接受任何证据文件** |
| `MERCHANT_DEFENDS_SECOND_CYCLE` | 您选择在第二周期抗辩 | 在此之前请了解仲裁风险 |

`AUTO_SUBMITS_EVIDENCE` 和 `CREATE_SECOND_CYCLE_DISPUTE` 是两个可以在您没有任何操作的情况下出现的事件。如果您设置了统一的处理策略，就是在这里看到它已触发。

## 哪些时间线事件会增加未读计数？

恰好三个，且三个都是收到的消息而不是状态变化：

* `USER_RESPONSE`
* `PLATFORM_RESPONSE`
* `USER_CREATE_COMPLAINT`

您自己的 `MERCHANT_RESPONSE` 不会增加计数，任何状态变化、任何证据提交或任何截止时间事件也都不会。因此未读计数永远表示*有人对您说了什么*，而不是*案件发生了什么*——一个案件可以一路走到最终状态而计数器从未变动。不要把计数器当作活动指标；请看时间线。

## 怎么导出我的拒付明细？它会走报表 Tab 吗？

拒付列表有自己的导出功能，与大多数 Portal 导出不同，它是**直接同步下载**：点击时文件直接流式传输到您的浏览器，**任何报表 Tab 中都不会出现任务行**。如果您在
[导出与报表下载](/docs/zh/support/export-center-faq)中找它，是找不到的——那一页覆盖的是排队导出，而这个导出不排队。

文件名为：

```
chargebacks_{merchant id}_{from}_{to}.csv
```

两个日期均为 UTC+8 的 `YYYYMMDD`，来自您所应用的创建时间筛选。导出遵循您当前的列表筛选条件，因此先筛选，再导出。

## 拒付 CSV 导出里有哪些列？

26 列，顺序如下：

| # | 表头 | 内容 |
| - | - | - |
| 1 | `Chargeback Id` | 案件 id |
| 2 | `Life Cycle` | `FIRST_CYCLE` 或 `SECOND_CYCLE` |
| 3 | `Relevant Chargeback Id` | 另一周期的案件 id |
| 4 | `Original Order Id` | Waffo 为争议订单分配的 id |
| 5 | `Original Payment Request id` | 您对该订单的支付请求 id |
| 6 | `Subscription Request` | 您的订阅请求 id，用于订阅案件 |
| 7 | `Related Subscription Id` | Waffo 的订阅 id，用于订阅案件 |
| 8 | `Merchant User Id` | 您为买家分配的 id |
| 9 | `Merchant Order Id` | 您的订单 id |
| 10 | `Merchant Id` | 您的 MID |
| 11 | `Sub Merchant Id` | 子商户 MID，如您使用 |
| 12 | `Chargeback Amount` | **针对您**的争议金额，以订单币种计——见下文 |
| 13 | `Chargeback Currency` | 第 12 列的币种 |
| 14 | `Chargeback Reason Code` | 案件的原因码 |
| 15 | `Chargeback Reason` | 原因文本 |
| 16 | `Transaction Type` | `CHARGEBACK` |
| 17 | `Country/Region` | 支付所在国家 |
| 18 | `Payment Method Type` | 例如 `CREDITCARD` |
| 19 | `Payment Method` | 所使用的具体支付方式 |
| 20 | `Chargeback Status` | 案件状态 |
| 21 | `Settlement Status` | 该资金变动是否已进入结算——见下文 |
| 22 | `Created Datetime(UTC+8)` | 案件创建时间 |
| 23 | `Updated Datetime(UTC+8)` | 案件最后变更时间 |
| 24 | `Expiry Datetime(UTC+8)` | 证据截止时间 |
| 25 | `Chargeback Fee Amount` | 记在该案件上的拒付手续费 |
| 26 | `Chargeback Fee Currency` | 第 25 列的币种——您配置的手续费币种，见下文 |

每个表头都是唯一的，因此按表头文本解析是安全的。请注意，对于相同的值，导出文件中写的是 **Chargeback**，而 Portal 详情页写的是 **Dispute**——第 12 列和第 25 列分别是争议金额和手续费，不是两个金额。

## 第 21 列显示案件尚未结算，钱到底扣了没扣？

这正是 `Settlement Status` 的用途，当案件状态与您的银行余额不一致时，就该看这一列。

`Chargeback Status` 和 `Settlement Status` 回答的是不同的问题，变化的时间也不同：

| 列 | 回答的问题 |
| - | - |
| `Chargeback Status` | 案件在审核方那边处于什么阶段 |
| `Settlement Status` | 由此产生的资金变动是否已经经过结算 |

拒付在开案时就记到您的账上，但只有在**原支付订单已结算**之后才会出现在结算对账单中，因为它复用该订单的结算汇率。因此一个案件可能停在 `ACTION_REQUIRED`、金额已记账、而 `Settlement Status` 仍显示未结算——扣款即将到来，在原订单的结算日或其后的下一个结算日。请把这一列与上文的 `Event Type` 表配合使用，来核对某一具体的 `CHARGEBACK` 行。

## 为什么 `Dispute Amount` 和持卡人争议的金额不一样？

因为它们是两个不同的数字，Portal 展示给您的是您这一侧的数字。

支付侧发起的金额以原交易的**支付币种**计价。您看到的 `Dispute Amount`——也就是实际从您账上扣除的金额——是**商户份额，以订单币种表示**：

1. 原支付中任何买家侧手续费由 Waffo 承担，而不是由您承担，并且不计入您的可争议余额。
2. 您在争议金额中的份额，按您在买家支付金额中所占的比例计算，任何余数由 Waffo 承担。
3. 该份额换算为订单币种后**向下取整（FLOOR）到 2 位小数**，因此该数字永远不会向不利于您的方向进位。不足一分的余数留给 Waffo。

值得了解的后果：

* 在跨币种订单上，您的 `Dispute Amount` 不会等于支付侧报出的数字，这个差异不是错误。
* 如果订单已经部分或全部退款，您剩余的可争议余额会更低，您的份额以此为上限。
* 您的 `Dispute Amount` 永远不会超过订单金额。

按比例拆分本身——某一争议中多少由您承担、多少由 Waffo 承担——是一项资金规则，不是自助设置；如果某个具体案件对不上，请联系客服。

## 我的拒付手续费是什么币种？不是 USD。

拒付手续费币种来自**您的**商户配置，而不是全局默认值，并且会随 `feeAmount` 一起以 `feeCurrency` 返回在案件上。它不保证与您的结算币种一致，也不保证是 USD。

当手续费币种与您的结算币种不同时，手续费会在结算时按该次结算的结算侧汇率换算为结算币种——与该次结算的其余部分使用相同的汇率基准，而不是开案当天锁定的汇率。两个币种相同时不发生换算。

因此，如果您的对账单显示了一笔您未预料到的币种的拒付手续费，那是您配置的手续费币种体现出来了。手续费金额本身是合同条款——见
[拒付与争议 FAQ](/docs/zh/support/chargeback-faq)。

## 怎么找出快要到期的案件？

拒付列表和客户争议列表都有一个**即将到期**筛选项，返回证据截止时间在未来 **3 天**内的未结案件。这是按截止时间分拣的受支持方式；每个案件仍带有自己的
`expiryDateTime`，对单个案件而言该值是权威的。

## 证据截止时间过了会怎样？

两种案件类型的表现不同，这也是二者之间最常被误读的差异：

| | 客户争议 | 拒付 |
| - | - | - |
| 截止时刻发生什么变化 | 仅一个单独的**过期状态**列从 `ACTIVE` 变为 `EXPIRED` | 案件**状态本身**变为 `EXPIRED` |
| 截止之后的案件状态 | 不变——仍为 `EVIDENCE_REQUIRED` / `ACTION_REQUIRED` / `UNDER_REVIEW` | `EXPIRED`，最终状态 |
| 还能提交吗？ | **可以**——案件仍可处理 | 不能 |
| 资金 | 不受过期本身影响 | 争议金额不会退回 |

因此，过期的客户争议是一次提醒，而不是关上的门：请提交迟到的材料并继续处理案件。过期的拒付则是败诉。当您在时间压力下给队列排优先级时，拒付的截止时间才是硬性的。

每个案件的时限由支付侧设定，并以
`expiryDateTime` 随案件送达——没有统一的 Waffo 全局时限，也不是从交易日期推算的，因此请始终逐案读取该值而不要自行计算。

## 每日争议报告里的 `Alert Status` 取值是什么意思？

如果您开通了拒付预警，每日争议报告会带一个预警附件。`Alert Status` 是预警案件的整体阶段：

| `Alert Status` | 含义 | 需要您处理吗？ |
| - | - | - |
| `PROCESSING` | 案件正在处理中 | 否 |
| `MANUAL PROCESSING` | 案件遇到异常，正**在 Waffo** 由人工处理 | **否**——尽管名字如此 |
| `PROCESSED` | 已发起退款并回应了预警；最终确认仍待完成 | 否 |
| `FAILED` | 最终状态：案件无法完成 | 仅当 Waffo 联系您时 |
| `EXPIRED` | 最终状态：案件在收到后 72 小时内未到达最终状态 | 否 |

**`MANUAL PROCESSING` 不是指"由您人工处理"。** 这是该报告中最常被误读的一个值：它表示 Waffo 把该案件从自动化路径中拿出来了。如果确实需要您做什么，会直接联系您。

附件报告的是预警案件的阶段及其退款；它不会展示 `MANUAL PROCESSING` 案件背后的内部处理步骤，因此除了"非自动化，正在处理中"之外，无需对该值做更多解读。

## `Refund Status` 是什么？Alert ID 长什么样？

同一附件中的 `Refund Status` 只跟踪由预警触发的那笔退款：

| `Refund Status` | 含义 |
| - | - |
| `PROCESSING` | 退款已提交，尚未确认 |
| `SUCCESS` | 退款已完成 |
| `FAILED` | 退款未完成 |

`FAILED` 的退款并不表示预警被忽略了——这正是会被人工接手的情况，所以 `MANUAL PROCESSING` 和 `FAILED` 退款经常出现在同一行。

Alert ID 的格式类似 `CBA-00-20251125-00003`：固定的 `CBA` 前缀、一个两位数字段、日期，以及一个序号。就某个具体预警联系客服时，请引用完整字符串。当预警与订阅相关时，附件中还会带有订阅 id。

预警对某笔订单完成退款后，您自己对该订单发起的退款请求会被拒绝并返回 `A0039`——其含义以及预警费用如何计费，见[拒付与争议 FAQ](/docs/zh/support/chargeback-faq)。


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