Skip to main content

​
📄 正文

在合作伙伴自管模式下，您掌握每位持卡人的消费额度并决定每笔授权；DCS 负责发卡、清算与结算。本页重点说明两个概念：授权冻结与清算扣款先后发生，以及 DCS 按 T+1 兑付、您按 T+X 回补保证金的节奏。 理解了这两点，您就能正确设计自己的账本，既不会重复冻结用户资金，也不会让企业保证金在结算前被耗尽。

​
两类资金：用户钱包与企业保证金

合作伙伴自管模式下有两笔互不相同的资金，请始终分开看待：
关键：用户额度规则由接入机构维护，每一笔授权能否通过，由接入机构自己根据用户额度规则决策（这正是「授权转发」的含义，详见授权转发模型）。接入机构批准后，DCS 侧会校验您的企业保证金是否足额——availableAmount 不足时，授权将被拒绝。
企业保证金的实时余额可通过企业账户余额接口查询，响应包含三个金额字段：
接口：GET /open-api/enterprise/v2/enterprise-balance（按 cardProfileId 查询）。明细见 GET /open-api/enterprise/v1/enterprise-balance-record。

​
资金模型一：两段债——授权冻结，清算扣款

一笔刷卡消费在资金上不是「一次性扣款」，而是先后发生的两段。这是与「钱包直接扣余额」最本质的区别。
授权冻结与清算扣款的两笔账授权冻结与清算扣款的两笔账
  • 第一段·授权（Authorisation）：持卡人刷卡时，卡组织实时发来授权请求。DCS 转发给接入机构，由接入机构按其用户额度规则决策是否批准。批准即在接入机构侧冻结对应额度，DCS 侧同步占用企业保证金的 availableAmount。此时钱还没真正扣。
  • 第二段·清算（Settlement）：商户事后（通常 T+1 起，可能更晚）向卡组织发起清算，DCS 收到后才发生实际扣款，并释放第一段的冻结。
授权金额与清算金额未必相等——商户可能少扣（餐厅去掉预授权小费）、多扣（加油站、酒店）、分多次扣，甚至无授权直接清算（线下/离线交易）。DCS 用 Outstanding（未清算余额） 这一中间账来串联两段债，确保最终冻结与扣款对齐归零。 常见组合（完整 13 个场景见授权与清算全场景）：
给接入机构的实践提醒：请在响应授权转发通知（authUrl）时冻结用户钱包，等每日交易对账文件读到该笔清算后，再真正扣款并释放冻结。切勿在授权阶段直接扣余额——否则遇到撤销、少额清算、过期释放时会出现账实不符。授权与交易的数据结构分别见授权数据字典与交易数据字典。

​
资金模型二：兑付节奏——DCS T+1 兑付卡组织，接入机构 T+X 回补保证金

第二个资金模型是时间差。授权是实时的，但真实的资金结算有滞后，而 DCS 对卡组织的兑付义务是刚性的：
兑付与回补的资金节奏兑付与回补的资金节奏
  • DCS → 卡组织：T+1 兑付。无论清算款何时从持卡人侧真正到账，DCS 都必须按卡组织节奏（通常 T+1）先行垫付兑付。这笔垫付的来源就是您预存的企业保证金。
  • 接入机构 → DCS：T+X 回补。您需要在保证金被消耗后及时回补（Prefund），把 availableAmount 拉回安全水位。回补的具体周期与方式按签约约定。
风控红线：当企业保证金 availableAmount 不足时，后续授权将被 DCS 拒绝（即便用户钱包里仍有余额）。建议您对 availableAmount 设置告警水位并定期轮询监控，提前安排回补。主动告警/Webhook 推送能力规划中；当前可通过定期轮询企业账户余额接口监控水位。

​
下一步

弄清资金模型后，请前往 交易生命周期 看一笔交易从授权到清算的完整流转。对账文件的获取见 每日对账报告。