> ## 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.
# 交易问题与争议
> 讲清 DeCard 托管模式下交易异议的处置路径：分清退款 / 冲正（系统自动入账）与争议 / 拒付（走运营渠道）、盗刷止损（冻结卡）、及争议回款如何回到用户独立余额。
## 📄 正文
当持卡人对一笔交易提出异议——商品未收到、金额与实际不符、或一笔本人不曾发起的盗刷——您需要一条清晰的处置路径：先做止损，再分清这究竟是会自动回款的退款/冲正、还是需要走争议的拒付。DCS 作为受新加坡金融管理局（MAS）监管的发卡机构，争议的最终裁决由卡组织（Visa/Mastercard）按其规则进行，DCS 在卡组织与接入机构之间承接受理、举证与回款。
**能力现状（请先读）**：DeCard 托管当前**没有自助的争议 / 拒付（Dispute / Chargeback）API**，也没有可由接入机构调用的退款 / 冲正接口。争议经**运营渠道**提交与跟进，自助争议 API 仍在规划中。本页讲清当前真实可用的处置路径——退款/冲正的自动回款、盗刷止损（冻结卡）、以及争议的运营提交。
***
## 先分清三件事：退款、冲正、争议
这三者常被混为一谈，但在 DeCard 托管资金流程里是完全不同的事件，处置路径也不同。其中**退款与冲正只是只读的交易分类枚举**，由系统自动入账，**不是接入机构可调用的退款/冲正接口**：
| 事件 | 谁发起 | 在 DeCard 托管里怎么体现 | 是否需要争议流程 |
| :-------------------------------- | :---------- | :------------------------------------------------------------------------------------------------ | :------- |
| **退款 / 退货（Refund）** | 商户主动退款 | 卡交易 `authType=REFUND`（QR 扫码付为 `transType=REFUND`/`REFUND_PART`）；表现为用户独立余额上的一笔入账（`free` 增加），系统自动处理 | 否 |
| **冲正 / 撤销（Reversal）** | 商户或卡组织撤销原授权 | 卡交易 `authType=REVERSAL`（QR 为 `transType=REVERSAL`）；授权阶段解冻 + 余额入账，系统自动处理 | 否 |
| **争议 / 拒付（Dispute / Chargeback）** | 持卡人对交易提出异议 | DeCard 托管无自助 API，当前经**运营渠道**提交 | 是 |
> 上表的 `EXPEND`（消费）/ `REFUND`（退货）/ `REVERSAL`（消费冲正）是 DeCard 托管卡交易接口 `authType` 字段的**只读分类枚举**（QR 扫码付侧对应 `transType` 的 `PAY` / `REFUND` / `REFUND_PART` / `REVERSAL`）。它们描述的是"系统记下来的是哪类流水"，**不存在**一个让接入机构"发起退款"或"发起冲正"的接口。
关键判断：只有当商户不配合退款、或交易本人未发起（盗刷）时，才进入争议流程。若商户已经退款，款项会自动入账到对应用户的独立余额，**不要重复发起争议**——商户退款与争议双重回款会被卡组织判定为异常。
***
## 退款 / 冲正：系统自动入账到用户独立余额
在 DeCard 托管模型下，用户资产记在**用户级独立余额**上。商户退款或交易冲正发生时：
* 资金以一笔**入账**记到对应终端用户的独立余额：可用余额 `free`（概念别名 availableBalance）增加；若涉及解冻，则冻结余额 `freeze`（frozenBalance）相应减少。
* 这一过程**由系统自动处理，无需接入机构调用任何退款/冲正接口、也无需二次分配**——这正是 DeCard 托管与池账户模式的核心区别：回款直接落到对应用户，而不是先落到接入机构的统一余额账户、再由接入机构分配给各用户。
* 在用户卡交易明细里，该笔体现为借贷方向 `debitCreditIndicator=C`（Credit，反向交易，如退货/还款）的记录；正向消费为 `D`（Debit）。
> 余额字段以接口定义为准：查询接口返回 `free` / `freeze` / `total`，`availableBalance` / `frozenBalance` 仅作概念别名；余额查询结果为**数组**，请按 `asset` 遍历。详见 [用户余额](../how-to-use/managing-transactions/user-balance)。
***
## 盗刷止损：冻结卡（DeCard 托管真实接口 `/card/v2/block`）
用户报告未授权交易（盗刷）时，第一步是**立即冻结涉事卡片**止损。这是接入机构当前可自助调用的止损动作。
> **谁做什么**
>
> * **接入机构**：①立即冻结涉事卡片止损；②按需引导用户换发新卡（DeCard 托管换卡走托管引导页，见下）；③整理证据后通过运营渠道向 DCS 提交争议受理请求。
> * **DCS**：受理后向卡组织发起争议（chargeback），跟进裁决，并将回款与进展同步给接入机构。
**冻结卡**使用 DeCard 托管接口 `POST /card/v2/block`（靠 `block` 布尔区分冻结/解冻，**不存在独立的 unfreeze/unblock 接口**；DeCard 托管路径**无** `/open-api/` 前缀）：
请求（占位脱敏，请勿写入任何真实 PII）：
```json theme={null}
{
"externalUserId": "user_xxxxxxxx",
"block": true,
"cardId": "card_xxxxxxxx",
"smsCode": "",
"emailCode": ""
}
```
| 参数 | 类型 | 必填 | 说明 |
| :--------------- | :------ | :- | :------------------------ |
| `externalUserId` | String | 是 | 渠道用户 ID |
| `block` | Boolean | 是 | `true`=冻结（止损）/ `false`=解冻 |
| `cardId` | String | 是 | 卡 ID |
| `smsCode` | String | 条件 | 短信验证码：解冻必填，冻结非必填 |
| `emailCode` | String | 条件 | 邮箱验证码，解冻时可替代短信验证码 |
成功响应（统一结构 `{code, message, messageDetail, data}`，成功码 `code = SYS_SUCCESS`）：
```json theme={null}
{
"code": "SYS_SUCCESS",
"message": "",
"messageDetail": null,
"data": false
}
```
**错误处理**：止损是与时间赛跑的操作，请为冻结请求预先准备失败兜底——
* 解冻时缺 `smsCode`/`emailCode`：补齐验证码后重试（冻结止损本身无需验证码，可立即调用）。
* 调用返回非 `SYS_SUCCESS`：以 `message` / `messageDetail` 提示为准，**不要**仅凭 HTTP 200 判定成功；重试仍失败则立即转运营渠道人工冻结，避免在被盗卡上继续承担风险。
冻结/解冻、查询卡详情与状态的完整说明，见 [卡管理 · 概述](../how-to-use/managing-cards/overview)；如需为用户换发新卡，请联系 DCS 协助处理。
***
## 盗刷处置决策流程
> 链上/链下边界：上图中"卡组织裁决—chargeback"属**链下**卡组织流程；"回款入账到用户独立余额"是 DeCard 托管账本（链下记账）动作。DeCard 托管不涉及链上抵押品/签名，不在本流程内。
***
## 争议的资金结果如何回到用户
争议一旦被卡组织判定持卡人胜诉，回款会**直接 Credit 到对应终端用户的独立余额账户**（`free` 增加），与商户退款的体现形式一致，无需接入机构二次分配：
* 在用户卡交易明细中表现为一笔借贷方向 `debitCreditIndicator=C`（Credit）的入账记录。
* 因 DeCard 托管模式下用户资产记在用户级独立余额，回款的归宿就是那个用户的余额账户——**这与池账户模式"回款先落接入机构余额账户、再由接入机构对应到终端用户"不同**。
> **对账提示**：建议在通过运营渠道跟进争议时一并记录对应的交易 ID，以便把回款入账与具体争议对应起来。
***
## 常见问题
### 用户报告一笔未授权交易（盗刷），我该做什么？
1. 立即冻结涉事卡片止损：`POST /card/v2/block`（`block=true`）。
2. 按需为用户换发新卡（可联系 DCS 协助处理）。
3. 先通过 `GET /card/v2/statements/detail` 或 `GET /card/v1/fiat/transactions` 查询该笔交易的完整详情（交易 ID、金额、币种、商户名、时间），连同卡号后四位一并整理为证据，通过运营渠道向 DCS 提交争议受理；由 DCS 向卡组织发起争议。
DeCard 托管当前**没有自助 Dispute API**，争议提交走运营渠道。
### 商户退款后，款项什么时候、退到哪里？
商户退款表现为用户卡交易里 `authType=REFUND`（QR 扫码付为 `transType=REFUND` / `REFUND_PART`）的一笔入账，由**系统自动入账到该终端用户的独立余额**（`free` 增加），无需接入机构调用任何接口或二次分配。退款到账时点取决于商户与卡组织处理进度；长期未到账可走运营渠道核查。
### 一笔交易在终端被拒，但账户里却被扣了，怎么办？
先与商户确认该笔在其系统是否已被拒。若授权未最终入账（清算），冻结的额度通常会自动释放回用户可用余额（表现为 `REVERSAL` 冲正 / 解冻），无需额外操作。详见 [清算](../how-to-use/managing-transactions/settlement) 与 [用户余额](../how-to-use/managing-transactions/user-balance)。
### 退款（`REFUND`）/ 冲正（`REVERSAL`）是我能主动调用的接口吗？
不是。`EXPEND` / `REFUND` / `REVERSAL`（以及 QR 的 `PAY` / `REFUND` / `REFUND_PART` / `REVERSAL`）都是**只读的交易分类枚举**，用于标识系统记下来的是哪类流水。没有让接入机构"发起退款/冲正"的接口；这些动作由商户/卡组织发起、系统自动入账。
### 哪些交易可以发起争议？
通常只能对**已结算**且**金额非零**的交易发起争议；待清算或零金额（验证类）交易不可争议。卡组织争议有时限（通常为交易日起 **120 天**），越接近时限被驳回风险越高，请尽早通过运营渠道提交。同一笔交易同时只应有一个进行中的争议，请勿重复提交。
### 商户已经退款了，我还要不要再发起争议？
不要。商户退款会以入账自动回到用户独立余额，再发起争议会造成双重回款，可能被卡组织判定为异常。请先确认入账是否已到账，仅在商户**拒退或长期未退**时才走争议流程。
### 谁负责处理争议？我从哪里跟进结果？
争议由 DCS 受理并向卡组织发起，结果与进展通过运营渠道（客户成功 / 运营工单）同步给您。提交时请提供最小信息：交易 ID、卡号后四位（脱敏如 `****1234`）、商户信息、异议类别与文字说明、支持性证据文件。
***
## 接入时请与 DCS 确认
以下事项请在接入时与 DCS 对齐：
* 自助争议（Dispute / Chargeback）API 的建设计划，以及运营渠道争议提交的具体形式与受理时效。
* 争议各阶段是否有可订阅的 Webhook 事件。
* 争议手续费 / 退款到账时限等面向终端用户的服务承诺。
## 下一步
* 退款/冲正的解冻与入账如何在清算中落地：[基础概念 › 交易生命周期 › 清算](../how-to-use/managing-transactions/settlement)
* 核对回款入账与用户独立余额：[使用指南 › 用户余额](../how-to-use/managing-transactions/user-balance)
* 盗刷止损所需的冻结 / 换卡操作：[使用指南 › 卡管理 · 概述](../how-to-use/managing-cards/overview)
* 身份验证与合规相关常见问题：[常见问题 › 身份验证与合规](./verification-and-compliance)
* 问题上报与支持路径：[常见问题 › 问题上报与支持路径](./escalations-and-support-paths)