📄 正文
无论您是交易所、钱包还是平台方，在合作伙伴自管模式下，您都可以完整掌握每一位持卡人的可用额度，并对每一笔消费实时做出批准或拒绝的决策。DCS 负责发卡、把网络的授权请求安全转发给您、并在您批准后完成清算与对账；额度规则与风控逻辑始终留在接入机构手中。 作为持牌、自有 BIN 的发卡机构，DCS 把这套「授权决策权交还给您」的能力做成了可直接接入使用的基础设施，无需您自建发卡资质或卡组织连接。一句话理解授权转发
额度由接入机构掌握，授权由接入机构决策。
- 额度规则与授权决策权在接入机构。每位持卡人能花多少、由谁批准、是否放行，由接入机构按自有额度规则定义与决策；DCS 按您的决策，在转发与清算过程中完成资金占用与结算记录，保证双方对账一致。
- DCS 持有您交纳的企业保证金，为 DCS 按 T+1 向卡组织结算提供资金保障；它与单笔授权的额度决策相互独立。
- 每一笔消费，DCS 把决定权交给您。持卡人刷卡时，DCS 会就这笔授权向接入机构的
authUrl发起一次通知，由接入机构返回「同意 / 拒绝」。
授权一笔消费时发生了什么
下图是一笔普通消费（direction=OUTGOING）在合作伙伴自管模式下的完整流程：
- 决策在接入机构：示意图第 3–5 步完全发生在接入机构内部。是否放行、按什么规则放行（额度、单笔上限、商户/MCC 黑名单等），DCS 不参与、也不存储这些规则。
- DCS 的角色是「安全传递通道」：DCS 负责把授权请求加密转发给您、把您的决策加密回传给卡组织，并保证消息真实可信（详见下文加密机制）。
- 保证金是企业级资金垫付：DCS 占用的是接入机构的企业保证金，确保 DCS 能在 T+1 准时向卡组织结算；它是企业层面的结算保障，与单笔授权的额度决策相互独立。资金如何流转见 资金模型。
授权决策怎么传回 DCS
接入机构在authUrl 收到通知后，按业务规则给出 responseCode 并回传。取值来自授权转发通知数据结构：
实时应答与事后记录的对应关系固定为：
responseCode=00 记录为 approveFlag=A；01、11、21 以及其他非 00 结果记录为 approveFlag=D。responseCode 是接入机构的同步应答，approveFlag 用于授权结果 Webhook 与每日授权报告。
不是每条授权都来自实时刷卡
授权记录除了实时消费，还有系统补建与释放等场景。接入机构在转发通知与每日授权报表里都会见到authType 字段（详见关于授权枚举）：
接入机构在账本里维护持卡人额度时，需要把这几类记录都纳入考虑（例如收到
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 白名单配置，见 鉴权指南 与 授权与授权转发通知。
这套模式适合谁
- 已有自有用户体系与额度/风控逻辑，希望保留授权决策权的交易所、钱包、平台方
- 希望以企业保证金统一保障结算、并自行掌握每位持卡人额度与授权决策的接入机构
- 希望以最小成本接入持牌发卡能力、把卡组织连接与清算交给 DCS 的团队
下一步
理解了「额度在您、授权在您」之后，建议先看 资金模型 弄清企业保证金与 T+1 兑付的关系，再到 授权与授权转发通知 按任务实现authUrl 的接收、解密、决策与回传。