> ## 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. # 交易流水 > 说明交易流水与授权、待清算记录之间的关系，以及 multiClearInd 等关键字段的含义。 ## 交易流水 无论您是要逐笔核对资金、还原一笔消费的完整时序，还是满足监管对资金流向可追溯的要求，交易流水（Transaction）都是判断资金结果的权威凭证。DCS 作为持牌发卡机构，将每一笔实际发生的资金变动记录为不可篡改的流水，并通过每日全量对账文件交付给接入机构。 交易流水只记录**资金的实际扣除与增加**，不包含授权阶段的冻结、解冻等中间状态——它是资金最终流转结果的权威记录，与授权（Authorisation）、待清算（Outstanding）共同构成完整的资金生命周期。 *** ## 它在资金生命周期中的位置 授权决定「冻结多少」，清算决定「最终扣多少」，交易流水就是清算落地后的那条记录。三者通过 ID 串联： 交易流水在资金生命周期中的位置 交易流水在资金生命周期中的位置 * 一笔交易流水通过 `outsId` 关联到待清算记录，通过 `authIds` 关联到一笔或多笔授权（多笔授权时用英文逗号分隔，如 `1111,2222`）。 * 多笔授权、增量授权、部分清算等组合场景下，授权与流水的对应关系并非一一对应。完整的组合场景（普通清算、增量、撤销、超额/少额清算、强制清算、提现等 13 种）请参阅 [授权与清算全场景](./auth-and-settlement)。 *** ## 交易方向（direction） `direction` 字段区分两类核心场景： | 取值 | 含义 | 说明 | | ---------- | -- | -------------------------------------------------- | | `OUTGOING` | 出金 | 资金从接入机构（企业主体）余额账户划出，对应用户付款；与授权阶段的冻结操作形成「决策—执行」完整流程 | | `INCOMING` | 入金 | 资金划入接入机构余额账户，对应退货/退款，确保资金流入可追溯、可核对 | *** ## 交易分类（category） `category` 字段对每笔流水做业务分类，是接入机构做业务分析与成本核算的基础维度。 | 枚举值 | 名称 | 说明 | | ------------- | ------ | ------------------------- | | `RETAIL` | 普通消费交易 | 标准卡消费交易 | | `RETAIL_FEES` | 消费交易费用 | 包括 DCC 费、贷记调整、卡片年费、补卡换卡费等 | | `CASH` | 普通取现交易 | ATM 取现等现金交易 | | `CASH_FEES` | 取现交易费用 | 包括取现手续费等 | | `PAYMENT` | 退货/退款 | 退货/退款等入金交易 | | `CHARGEBACK` | 争议退单 | 因持卡人发起争议而产生的退单 | > **取现本金与手续费如何区分？** 取现场景下，`category=CASH` 是本金，`category=CASH_FEES` 是手续费，两者分别落两条流水。提现手续费走独立的强制记账流程，详见 [授权与清算全场景 · 场景十三](./auth-and-settlement)。 > > **关于取现/提现的分类取值**：每日交易文件的 `category` 固定使用全称（如 `RETAIL` / `CASH` / `CASH_FEES` / `PAYMENT`）。`C` / `CF` / `R` 等是内部枚举 code，不会写入每日交易文件；授权侧 `transactionType` 的 `R` / `C` / `Q` / `P` 又是另一维度，请勿混用。 *** ## 多笔清算标识（multiClearInd） 同一笔授权可能被分多次清算（如商户分批发货、酒店退房分项结算）。`multiClearInd` 标识当前流水在多笔清算中的位置： | 取值 | 含义 | 接入机构处理建议 | | --- | ------------------- | --------------------------------- | | `O` | 普通单笔清算 | 一笔授权对应一笔清算，常规处理 | | `P` | 多笔清算，非最后一笔（Partial） | 仅扣减 Outstanding，**不要**据此判定授权已完全结清 | | `F` | 多笔清算完成（Final） | 最后一笔，此时才检查授权与清算的最终差额 | > 多笔清算时，请以收齐 `F` 标识的那一笔为「该授权清算完成」的判定依据。在收到 `F` 之前，同一 `authIds` 下可能还会陆续到达 `P` 流水。 *** ## 如何获取交易流水 合作伙伴自管方案中，交易流水**不提供实时单笔查询接口**，统一通过**每日全量对账文件**交付。DCS 每日为每个接入机构（Enterprise）生成一份当日全量的交易流水文件。 **接口（领取下载链接）** ``` GET /open-api/enterprise/v1/settlement-file-url ``` | 参数 | 类型 | 必填 | 说明 | | ---------- | ------ | -- | ----------------------------------------------------- | | `fileType` | String | 是 | 文件类型，交易流水传 `transaction`（授权文件传 `authorisation`），最大 20 | | `fileDate` | String | 是 | 文件日期，格式 `yyyyMMdd`，如 `20251106`，最大 8 | **响应**：返回字符串形式的文件**下载链接**（S3 临时链接，有效期较短，请领取后尽快下载）。 > **谁做什么** > > * **DCS**：每日生成全量交易流水文件，按需签发临时下载链接。 > * **接入机构**：调用本接口领取链接 → 下载文件 → 存储核对账户余额变动与实际业务是否一致。 > > **关于文件与链接**：系统默认 T+1 生成前一日的授权、交易两类文件，任务状态为 `DONE` 后可下载；具体每日运行时刻由任务平台配置。下载链接固定有效 120 秒，过期后可再次调用接口领取新的 120 秒链接，底层文件不会因链接过期而删除。 下载链接的统一获取方式与每日对账机制，另见 [交易报告](../reports/transaction-report)。 *** ## 交易流水文件字段 每行一条流水，字段以 `>` 分隔，顺序如下： | 字段 | 描述 | 补充说明 | | ---------------------------- | --------- | ----------------------------------------------------------- | | `transactionId` | 交易流水唯一 ID | 标识每笔资金变动的唯一编号 | | `direction` | 交易方向 | `OUTGOING`（出金）/ `INCOMING`（入金） | | `outsId` | 账单 ID | 关联对应的待清算（Outstanding）记录 | | `authIds` | 关联的授权 ID | 多笔授权用英文逗号分隔，如 `1111,2222` | | `enterpriseId` | 企业 ID | 标识资金变动对应的接入机构 | | `customerId` | 用户 ID | 标识交易对应的持卡人 | | `cardId` | 卡 ID | 关联发生交易的卡片 | | `pan` | 卡号 | 仅展示前六位 + 后四位，保障信息安全 | | `category` | 交易分类 | 对应上文 `category` 枚举，详见 [报告字段说明](../reports/field-dictionary) | | `currency` | 币种 | ISO 3 位货币代码 | | `amount` | 金额 | 交易涉及的资金数额（结算币种金额） | | `acquirerCurrency` | 用户请求币种 | 与实际结算币种可能存在差异 | | `acquirerAmount` | 用户请求金额 | 对应请求币种的资金数额 | | `cardAcceptorIdentification` | 商户号 | 交易涉及的商户标识 | | `cardAcceptorNameLocation` | 商户信息 | 包含商户名称与地址 | | `multiClearInd` | 清算标识 | `O` 单笔 / `P` 多笔非最后一笔 / `F` 多笔完成 | | `merchantType` | 商户类型 | 即 MCC，4 位数字 | | `createTime` | 创建时间 | 交易记录生成时间，格式 `yyyy-MM-dd'T'HH:mm:ss+08:00`（UTC+8） | | `modifyTime` | 更新时间 | 交易记录最后修改时间，格式同上 | | `merchantCountryCode` | 商户国家代码 | 3 位数字国家代码 | | `originalTransactionId` | 原交易 ID | 退款类交易填被退款的原交易 `transactionId`，非退款交易该列为空 | **示例样本** ```text theme={null} 174047198631807650000309>OUTGOING>1109862324019138561>1109862318201638913>1095041241881513984>1108391061086846977>1108449591919689729>4382140000003562>CASH>702>1.000000000000000000>>0E-18>001584054110002>>null>5399>2025-03-21T07:20:45+08:00>2025-03-21T07:20:45+08:00>840> 174047198631807650000310>OUTGOING>1109864282771689473>1109864282775883776>1095041241881513984>1108391061086846977>1108449591919689729>4382140000003562>CASH_FEES>702>1.000000000000000000>>0E-18>001584054110002>>null>5399>2025-03-21T07:24:25+08:00>2025-03-21T07:24:25+08:00>840> ``` > 上方两行恰好演示了取现场景：第一行 `CASH` 为取现本金，第二行 `CASH_FEES` 为取现手续费，两条流水共享同一卡号、同一商户。两行末尾的 `>` 后为空，因为非退款交易不带 `originalTransactionId`。 为便于存储映射，下面把上方第一行 `>` 分隔样本按相同字段名展开为一条等价的结构化记录（字段名与上方字段表一一对应）： ```json theme={null} { "transactionId": "174047198631807650000309", "direction": "OUTGOING", "outsId": "1109862324019138561", "authIds": "1109862318201638913", "enterpriseId": "1095041241881513984", "customerId": "1108391061086846977", "cardId": "1108449591919689729", "pan": "4382140000003562", "category": "CASH", "currency": "702", "amount": "1.000000000000000000", "acquirerCurrency": "", "acquirerAmount": "0E-18", "cardAcceptorIdentification": "001584054110002", "cardAcceptorNameLocation": "", "multiClearInd": "null", "merchantType": "5399", "createTime": "2025-03-21T07:20:45+08:00", "modifyTime": "2025-03-21T07:20:45+08:00", "merchantCountryCode": "840", "originalTransactionId": "" } ``` 交易流水实际**以上述 `>` 分隔的文本文件形式交付**，本 JSON 仅为字段对照示意，不代表存在某个返回 JSON 的接口。`multiClearInd` 在该样本中原值为 `null`（非取现场景下取 `O`/`P`/`F`）。 *** ## 下一步 * 理解资金从冻结到扣款的完整组合场景：[授权与清算全场景](./auth-and-settlement) * 了解每日对账文件的生成与下载机制：[交易报告](../reports/transaction-report) * 查阅交易分类枚举的权威定义：[报告字段说明](../reports/field-dictionary)