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

# 争议处理

> 持卡人对已结算交易提出异议（未收到货、金额不符、盗刷）时，当前可用的处置路径与所需信息。

## 交易争议

当持卡人对一笔已结算的交易提出异议——商品未收到、金额与实际不符、或是一笔本人不曾发起的盗刷——您需要一条清晰的处置路径，把异议提交给卡组织、拿回款项、并向用户交代进展。DCS 作为持牌发卡机构，争议的最终裁决由卡组织（Visa/Mastercard）按其规则进行，DCS 负责在卡组织与接入机构之间承接受理、举证与回款。

> 争议处理统一通过人工渠道进行（暂不提供自助争议 API）。本页说明当前可用的处理方式，包括提交运营工单、通过冻结或换卡控制盗刷损失、商户退款自动入账，以及需要提供的信息和联系渠道。

***

## 先分清三件事：退款、冲正、争议

这三者常被混为一谈，但在资金流程里是完全不同的事件，处置路径也不同：

| 事件                                | 谁发起           | 在 DCS 怎么体现                                 | 是否需要争议流程 |
| --------------------------------- | ------------- | ------------------------------------------ | -------- |
| **退款 / 退货（Refund）**               | 商户主动退款        | 一笔 `direction=INCOMING` 的交易流水自动入金，无需接入机构干预 | 否        |
| **冲正 / 撤销（Reversal）**             | 商户或卡组织撤销原授权   | 授权阶段的解冻 + INCOMING 流水，系统自动处理               | 否        |
| **争议 / 拒付（Dispute / Chargeback）** | 持卡人对已结算交易提出异议 | 通过运营 / 人工渠道处理（暂不提供自助 API）                  | 是        |

<b>关键判断</b>：只有当商户<b>不配合退款</b>、或交易<b>本人未发起（盗刷）</b>时，才进入争议流程。若商户已经退款，款项会以 INCOMING 流水自动回到接入机构余额账户，**不要重复发起争议**——商户退款与争议双重回款会被卡组织判定为异常。

> 退款/冲正如何在交易流水与授权清算中落地，详见 [授权与清算全场景](./transactions/auth-and-settlement)（场景九「强制退款」、部分撤销等）与 [交易流水](./transactions/transaction)（`direction=INCOMING`）。

***

## 当前可用：盗刷与争议的运营处置路径

接入机构遇到持卡人异议时，按以下顺序通过运营渠道处置。

### 用户报告盗刷（未授权交易）

> **谁做什么**
>
> * **接入机构**：①立即冻结涉事卡片，止损；②按需为用户换发新卡；③整理证据（交易 ID、卡号后四位、商户信息、异议说明）后，通过运营渠道向 DCS 提交争议受理请求。
> * **DCS**：受理后向卡组织发起争议（chargeback），跟进裁决结果，并将回款与进展同步给接入机构。

**第①步：立即冻结卡片**（这是接入机构当前唯一可自助调用的止损动作）

```
POST /open-api/card/v1/freeze
```

| 参数             | 类型      | 必填 | 说明                                      |
| -------------- | ------- | -- | --------------------------------------- |
| `cardId`       | String  | 是  | 卡 ID，最大长度 50                            |
| `freeze`       | Boolean | 是  | `true`=冻结（止损）/ `false`=解冻               |
| `freezeReason` | String  | 是  | 冻结原因，最大长度 20，如 `USER_FREEZE` / `NORMAL` |

> 冻结与解冻是同一个 `freeze` 接口，靠 `freeze` 布尔区分，**不存在独立的 unfreeze/unblock 接口**。卡管理操作详见 [卡片管理](./cards/card-management)。

**第②步：换发新卡**（盗刷场景应作废原卡并换发，避免持卡人在被盗卡上继续承担风险）。换卡详见 [卡片管理 · 换卡](./cards/card-management)。

**第③步：提交争议受理请求**——请通过与 DCS 约定的运营渠道（客户成功 / 运营工单）提交。需提供的最小信息：交易 ID（`transactionId`）、卡号后四位、商户信息、异议类别与文字说明、以及支持性证据文件。DCS 受理后向卡组织发起争议并跟进结果。

### 商户应退未退 / 退款迟迟未到

先确认商户是否已发起退款（INCOMING 流水是否到账）；若商户拒绝退款或退款长期未落地，再按上述运营路径提交争议。

***

## 争议的资金结果如何回到接入机构

争议一旦被卡组织判定接入机构（持卡人）胜诉，回款会以一笔入金落到接入机构余额账户：

* 在对账文件中表现为一笔 `direction=INCOMING` 的记录，并携带 `category: CHARGEBACK` 标识争议交易，可据此机读识别，通过每日对账文件交付。
* 回款会以一笔 `direction=INCOMING` 入金落到接入机构的**余额账户**；可根据争议交易 Id 回查原交易，把回款对应到具体终端用户与具体争议。

> **对账提示**：争议回款凭 `category: CHARGEBACK` 即可与普通商户退款区分。建议您在通过运营渠道跟进争议时一并记录对应的交易 ID，作为辅助核对手段。

***

## 跟一个盗刷 case 走一遍

把上面的处置路径放进真实时间线。案例：持卡人深夜在您的 App 报告一笔本人未发起的 89.99 USD 消费，该笔交易已清算。

| 时间      | 事件     | 您做什么                                                                                                 | 用什么做                                                                     |
| ------- | ------ | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| D0 深夜   | 用户申告盗刷 | 核实流水：找到该笔 `direction=OUTGOING` 的已清算交易，记下 `transactionId` 与商户信息                                       | 交易流水 / 每日交易报告                                                            |
| D0 深夜   | 立即止损   | 冻结涉事卡片                                                                                               | `POST /open-api/card/v1/freeze`，`freeze=true`、`freezeReason=USER_FREEZE` |
| D1      | 恢复用卡   | 为用户作废原卡、换发新卡（盗刷卡不应解冻复用）                                                                              | [卡片管理 · 换卡](./cards/card-management)                                     |
| D1      | 提交争议   | 整理最小材料包：`transactionId`、卡号后四位、商户名称、异议类别与说明、支持性证据，经约定运营渠道提交 DCS                                       | 运营工单 / 客户成功渠道                                                            |
| D1 之后   | DCS 受理 | DCS 向卡组织发起 chargeback，进展经运营渠道同步                                                                      | —                                                                        |
| 数周后（裁决） | 胜诉回款   | 某日对账文件中出现一笔 `direction=INCOMING`、`category=CHARGEBACK` 的入金；据此识别为争议回款，并按争议交易 Id 回查原交易，把回款对应回这个用户与这笔争议 | 每日交易报告                                                                   |

两条经验：

* **D0 的冻结动作决定损失边界**：争议裁决需要数周，但盗刷卡上的后续消费从冻结那一刻起就被阻断——这是全流程中唯一分秒必争的步骤，也是当前唯一可自助 API 完成的步骤。
* **回款凭 `category: CHARGEBACK` 认领**：争议回款在对账文件中携带 `category: CHARGEBACK` 标识，可机读识别并按争议交易 Id 回查原交易；D1 提交时记下的 `transactionId` 与预期金额可作为辅助核对手段。

***

## 提交争议时的实用提醒

为提高受理与胜诉效率，提交争议时请注意以下几点：

* 通常只能对**已结算**且**金额非零**的交易发起争议；待清算或零金额（验证类）交易不可争议。
* 卡组织争议有时限（通常为交易日起 **120 天**），越接近时限被驳回风险越高，请尽早提交。
* 同一笔交易同时只应有**一个进行中的争议**，请勿重复提交。
* 若商户在争议期间已直接退款，款项会以 INCOMING 流水自动回到接入机构余额账户，此时无需再走争议流程。

***

## 下一步

* 理解退款 / 冲正如何在资金流程中自动落地：[授权与清算全场景](./transactions/auth-and-settlement)
* 核对 INCOMING 回款的逐笔记录：[交易流水](./transactions/transaction)
* 盗刷止损所需的冻结 / 换卡操作：[卡片管理](./cards/card-management)
* 了解现有 Webhook 事件类型：[Webhook 事件与数据结构](./webhooks/events-and-schema)