> ## 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 在授权阶段把决策权转发给接入机构、按结果冻结或解冻资金；在清算阶段记录资金的实际流转，并每日生成对账文件。
## 两个阶段，三个实体
一笔交易在 DCS 内部由三类记录协同表达。把它们的关系记牢，后续所有场景都只是这套模型的不同组合。
| 实体 | 阶段 | 作用 |
| --------------------- | ----- | ---------------------------------------- |
| **Authorisation（授权）** | 授权阶段 | 持卡人刷卡时的实时决策记录。批准则冻结/解冻一笔资金，本身**不产生实际扣款** |
| **Outstanding（待清算）** | 贯穿两阶段 | 连接授权与清算的桥梁。授权阶段累加冻结金额，清算阶段扣减，直至归零 |
| **Transaction（交易流水）** | 清算阶段 | 资金**实际**扣除或增加的权威凭证，是每日对账文件的数据基础 |
三者通过两个 ID 串联：授权与清算共享同一个 `outsId`（Outstanding ID），交易流水通过 `authIds` 反向关联到一笔或多笔授权。
### 阶段一：授权（资金只冻结，不扣款）
持卡人在商户刷卡、插卡或挥卡时，商户向卡组织估算一个金额并请求授权。此时**没有任何资金被真正扣除**——DCS 收到卡组织的授权请求后，会把它转发给接入机构由其实时决策，再按决策结果冻结或解冻对应金额。
授权记录的几个关键属性（完整字段见[授权指南](../how-to-use/transactions/authorization)）：
* **direction（方向）**：`OUTGOING` 冻结资金（用户付款）/ `INCOMING` 解冻资金（撤销、退款）。
* **authType（授权类型）**：`NORMAL` 普通授权 / `FORCE_AUTH` 系统补建 / `EXPIRED_RELEASE` 到期释放 / `STATUS_DIFF_RELEASE` 状态差异释放。
* **approveFlag（决策标志）**：`A` 同意（冻结资金）/ `D` 拒绝（不做资金操作）。
* **outsId**：首笔授权自动生成，后续同一笔交易的增量、撤销均通过 `originalAuthId` 复用同一个 `outsId`。
> 授权决策由接入机构掌握、并消耗其在 DCS 交纳的企业保证金。资金为何这样流转，请参阅[资金模型](./fund-model)。
### 阶段二：清算（资金实际流转）
商户在数小时到数日内向卡组织提交最终金额，进入清算。DCS 生成 **Transaction（交易流水）**，记录资金的实际扣除（`OUTGOING`）或增加（`INCOMING`），并相应扣减 Outstanding：
* 清算金额与冻结金额一致 → Outstanding 归零，交易完成。
* 两者不一致（超额/少额/分笔）→ 系统自动补建 `FORCE_AUTH` 授权补足差额，详见下文场景。
交易流水通过 `category` 字段做业务分类（`RETAIL` 普通消费 / `CASH` 取现 / `CASH_FEES` 取现手续费 / `PAYMENT` 退货退款），并通过 `multiClearInd` 标识多笔清算进度。它是每日对账文件的权威数据源。
## 一条主线，多种组合
实际业务中授权与清算不总是一一对应：商户可能追加金额、部分撤销、分多笔清算，也可能没有授权就直接清算。这些都只是「授权 → 清算」主线在 Outstanding 上的不同累加/扣减组合。DCS 共定义了 **13 个标准场景**，按机制可归为下面 9 类——区别在于 **Outstanding 怎么动**：
| 类型 | 场景 | Outstanding 怎么动 |
| ------- | ----------------------------- | --------------------------------------------------- |
| 标准 | 普通授权 → 普通清算（金额一致） | 一次累加 → 一次扣减，归零，流程完成 |
| 追加 | 增量授权（如酒店加收），多笔授权共享同一 `outsId` | 多笔授权累加到同一 Outstanding，清算时整体扣减 |
| 撤销 | 部分撤销 / 全额撤销 | `INCOMING` 反向解冻冻结额（全额撤销则无清算入账） |
| 差额 | 超额清算 / 少额清算 | 清算与冻结不等，系统补建 `FORCE_AUTH` 抹平差额 |
| 分笔 | 部分清算 → 最终清算 | 同一 Outstanding 被多笔清算逐次扣减，`multiClearInd=F` 时结清 |
| 无授权 | 强制清算 / 强制退款（线下、离线交易） | 先有清算，再补建 Auth 与 Outstanding |
| 查询 / 通知 | 查询授权（Inquiry）、卡片验证（金额 0 / 1） | 不冻结资金，Outstanding 不变动 |
| 释放 | 授权过期释放 / 状态差异释放 | `EXPIRED_RELEASE` / `STATUS_DIFF_RELEASE` 解冻未清算的冻结额 |
| 提现 | 普通清算 + 独立的提现手续费流程 | 本金与手续费两条清算分别扣减 |
> **不变量**：无论采用哪种组合，**完全清算后 Outstanding 都会归零**。这是判断对账是否完成的依据：只要某笔 `outsId` 未归零，就说明该笔交易仍有未结清的授权或清算。
每一种组合的逐步动作时序（含 authId / outsId / 金额变化的完整推演），见 [授权与清算全场景](../how-to-use/transactions/auth-and-settlement)（全 13 场景的权威推演）；其中部分 / 超额 / 多笔等最常见清算偏差的对账实操，另见 [清算场景](../how-to-use/transactions/capture-scenarios)。
## 下一步
* 想知道资金为何要冻结、企业保证金如何保障结算，请看[资金模型](./fund-model)。
* 想动手处理一笔真实授权回调，请前往 [授权指南](../how-to-use/transactions/authorization) 与 [Webhook 事件](../how-to-use/webhooks/events-and-schema)。