> ## 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 负责发卡、把网络的授权请求安全转发给您、并在您批准后完成清算与对账；**额度规则与风控逻辑始终留在接入机构手中**。
作为持牌、自有 BIN 的发卡机构，DCS 把这套「授权决策权交还给您」的能力做成了可直接接入使用的基础设施，无需您自建发卡资质或卡组织连接。
## 一句话理解授权转发
> **额度由接入机构掌握，授权由接入机构决策。**
* **额度规则与授权决策权在接入机构**。每位持卡人能花多少、由谁批准、是否放行，由接入机构按自有额度规则定义与决策；DCS 按您的决策，在转发与清算过程中完成资金占用与结算记录，保证双方对账一致。
* **DCS 持有您交纳的企业保证金**，为 DCS 按 T+1 向卡组织结算提供资金保障；它与单笔授权的额度决策相互独立。
* **每一笔消费，DCS 把决定权交给您**。持卡人刷卡时，DCS 会就这笔授权向接入机构的 `authUrl` 发起一次通知，由接入机构返回「同意 / 拒绝」。
这正是与 DeCard 托管模式的根本区别：在 DeCard 托管模式下，额度规则与授权决策都由 DCS 代为执行；在合作伙伴自管模式下，**额度规则与每一笔授权的决策权都回到接入机构手里**，DCS 负责安全转发、清算与资金兑付保障。
## 授权一笔消费时发生了什么
下图是一笔普通消费（`direction=OUTGOING`）在合作伙伴自管模式下的完整流程：
关键点：
* **决策在接入机构**：示意图第 3–5 步完全发生在接入机构内部。是否放行、按什么规则放行（额度、单笔上限、商户/MCC 黑名单等），DCS 不参与、也不存储这些规则。
* **DCS 的角色是「安全传递通道」**：DCS 负责把授权请求加密转发给您、把您的决策加密回传给卡组织，并保证消息真实可信（详见下文加密机制）。
* **保证金是企业级资金垫付**：DCS 占用的是接入机构的企业保证金，确保 DCS 能在 T+1 准时向卡组织结算；它是企业层面的结算保障，与单笔授权的额度决策相互独立。资金如何流转见 [资金模型](./fund-model)。
## 授权决策怎么传回 DCS
接入机构在 `authUrl` 收到通知后，按业务规则给出 `responseCode` 并回传。取值来自[授权转发通知数据结构](../how-to-use/transactions/authorization)：
| responseCode | 含义 |
| ------------ | -------- |
| `"00"` | 同意 |
| `"01"` | 拒绝，资金不足 |
| `"11"` | 拒绝，交易不允许 |
| `"21"` | 拒绝，无响应 |
拒绝时请返回明确的 `responseCode`，便于双方对账时区分拒绝原因。
实时应答与事后记录的对应关系固定为：`responseCode=00` 记录为 `approveFlag=A`；`01`、`11`、`21` 以及其他非 `00` 结果记录为 `approveFlag=D`。`responseCode` 是接入机构的同步应答，`approveFlag` 用于授权结果 Webhook 与每日授权报告。
## 不是每条授权都来自实时刷卡
授权记录除了实时消费，还有系统补建与释放等场景。接入机构在转发通知与每日授权报表里都会见到 `authType` 字段（详见[关于授权枚举](../how-to-use/transactions/authorization)）：
| authType | 名称 | 说明 |
| --------------------- | ------ | ---------------------------------------- |
| `NORMAL` | 普通授权 | 渠道实时授权回调产生，涵盖消费、增量、撤销、退款、提现、查询等实时场景 |
| `FORCE_AUTH` | 强制授权 | 系统自动补建：清算时无对应授权（如离线交易），或清算金额与冻结金额不一致需补差额 |
| `EXPIRED_RELEASE` | 到期释放 | 授权超时未结算，渠道通过结算文件通知释放已冻结资金 |
| `STATUS_DIFF_RELEASE` | 状态差异释放 | 渠道因超时拒绝授权但系统侧已批准，状态不一致时的对账修正 |
接入机构在账本里维护持卡人额度时，需要把这几类记录都纳入考虑（例如收到 `EXPIRED_RELEASE` 时应释放此前冻结的额度）。
## 授权转发的安全前提
授权决策权交给接入机构，意味着这条转发通道必须双向可信。DCS 采用 **RSA-2048 + SHA256withRSA 双向签名与加密**，没有额外的 AES/IV 加密层：
* **DCS → 接入机构**：核心授权字段用**接入机构的 RSA 公钥**加密、用 **DCS 的 RSA 私钥**加签，加密结果放入请求体 `data.encryptedData`，签名放入请求头 `X-Auth-Signature`。
* **接入机构 → DCS**：响应用 **DCS 的 RSA 公钥**加密、用**接入机构的 RSA 私钥**加签，放入响应体 `encryptData` 与 `signature`。
请求侧的 `data.encryptedData` 是 15 个授权业务字段序列化后的整体密文（包含授权、用户、卡、金额、商户/MCC 与交易类型等），不是只加密 `authId`、`direction`、`currency`、`amount` 四项。
接入前需具备的前提：
* 已开通企业（Enterprise），并配置 `authUrl`（授权通知地址）与 `externalPublicKey`（接入机构 RSA 公钥）——**谁做：接入机构**配置、**DCS** 登记
* 已设置授权转发通知 IP 白名单——**谁做：接入机构**提供、**DCS** 放行
* 已成功申请至少一张卡
> 加密细节、密钥生成（openssl）、生产公钥获取与 IP 白名单配置，见 [鉴权指南](../integration-resources/authentication) 与 [授权与授权转发通知](../how-to-use/transactions/authorization)。
## 这套模式适合谁
* 已有自有用户体系与额度/风控逻辑，希望**保留授权决策权**的交易所、钱包、平台方
* 希望以企业保证金统一保障结算、并自行掌握每位持卡人额度与授权决策的接入机构
* 希望以最小成本接入持牌发卡能力、把卡组织连接与清算交给 DCS 的团队
## 下一步
理解了「额度在您、授权在您」之后，建议先看 [资金模型](./fund-model) 弄清企业保证金与 T+1 兑付的关系，再到 [授权与授权转发通知](../how-to-use/transactions/authorization) 按任务实现 `authUrl` 的接收、解密、决策与回传。