> ## Documentation Index
> Fetch the complete documentation index at: https://doc.haipay.net/llms.txt
> Use this file to discover all available pages before exploring further.

# CIT 与 MIT 交易模式

> 全面理解持卡人发起交易（CIT）与商户发起交易（MIT）的本质区别、首笔授权与后续扣款关系，以及在 HaiPay 中如何选择单次代收、MIT 代扣与固定周期订阅。

在国际卡组织（VISA、MasterCard 等）与支付合规体系中，卡交易根据\*\*「谁发起扣款」**以及**「持卡人是否在场（On-Session vs. Off-Session）」\*\*，严格划分为 **CIT（持卡人发起交易）** 与 **MIT（商户发起交易）** 两类。正确理解并区分这两类交易，直接关系到发卡行授权通过率、3DS / SCA 强客户认证豁免以及争议责任界定。

## 1. 什么是 CIT 与 MIT？

| 对比维度 | CIT（持卡人发起交易） (Customer-Initiated Transaction，持卡人主动发起的在线交易) | MIT（商户发起交易） (Merchant-Initiated Transaction，商户基于既有授权在后台发起的离线交易) |
| :- | :- | :- |
| **英文全称** | Customer-Initiated Transaction | Merchant-Initiated Transaction |
| **谁触发扣款** | **持卡人（用户）** 在结账页面主动点击支付 | **商户服务端** 根据事先约定的协议在后台主动发起 |
| **用户是否在场** | **在场（On-Session）**：用户正处于网页或 App 结账流程中 | **不在场（Off-Session）**：用户无需打开页面，无实时交互 |
| **身份验证（3DS / SCA）** | 若发卡行要求验证，用户可当场完成 3DS / 生物识别挑战 | 依赖首笔 CIT 建立的授权凭证与网络豁免，通常直接静默完成扣款 |
| **凭证要求** | 可直接输入新卡支付，或首次支付并授权保存卡片凭证 | **必须基于已通过首笔 CIT 验证的支付凭证（`tokenID`）**，不可无授权直接扣款 |
| **典型业务场景** | 电商单次购物结账、首次绑卡并付款、用户手动点击充值 | 按量计费自动扣款、余额不足自动续充、分期扣款、会员自动续费 |

> [!WARNING]
>
> 任何 MIT 离线扣款都**不能凭空发起**。卡组织规则要求：必须先由持卡人在场完成一笔 **首笔交易（Initial CIT）**，明确同意商户保存其支付凭证用于后续扣款并完成必要的身份验证后，商户才能在后续交易（Subsequent MIT）中使用保存的凭证发起离线扣款。未保存凭证的普通单次 CIT 交易，无法在事后转为 MIT 扣款。

## 2. 首笔交易 vs. 后续交易全链路

```mermaid theme={null}
sequenceDiagram
    actor User as 持卡人 (User)
    participant Merchant as 商户系统 (Merchant)
    participant HaiPay as HaiPay 平台

    rect rgb(235, 245, 255)
    Note over User,HaiPay: 阶段一：首笔交易（Initial CIT，用户在场授权并付款）
    User->>Merchant: 1. 勾选同意代扣协议并下单
    Merchant->>HaiPay: 2. 调用 /usd/mit/apply（不传 tokenID）
    HaiPay-->>Merchant: 3. 返回 payUrl 与 clientToken
    User->>HaiPay: 4. 在收银台或前置组件完成首笔支付与 3DS 验证
    HaiPay-->>Merchant: 5. 异步通知支付成功，并返回绑定的 tokenID
    Merchant->>Merchant: 6. 安全存储 tokenID 与 partnerUserId 的映射关系
    end

    rect rgb(240, 255, 240)
    Note over User,HaiPay: 阶段二：后续交易（Subsequent MIT，用户不在场静默扣款）
    Merchant->>HaiPay: 7. 满足扣款条件时，服务端调用 /usd/mit/apply（传入已保存的 tokenID）
    HaiPay->>HaiPay: 8. 校验 tokenID 与授权状态，直接向卡组发起 MIT 扣款
    HaiPay-->>Merchant: 9. 异步通知扣款结果（成功 / 失败）
    Merchant-->>User: 10. 发放权益并发送站外扣款通知（邮件 / 短信）
    end
```

## 3. 在 HaiPay 中如何对应到具体产品与接口？

HaiPay 将 CIT 与 MIT 能力封装为三类清晰的产品接口。请根据您的**计费周期是否固定**以及**由谁调度扣款时间**进行选择：

| 业务需求 | 交易分类 | 调用接口 | 前端集成方式与组件 `mode` | 核心机制说明 |
| :- | :- | :- | :- | :- |
| **普通单次收款** （不保存卡凭证，仅扣一次） | 单次 CIT | [银行卡代收申请 `POST /usd/collect/apply`](https://doc.haipay.net/zh/api-reference/card/collect-apply) | • 收银台模式（`payUrl`） • 前置组件模式（`mode: 'payment'`） | 用户当场付款，交易结束后不生成可复用的代扣令牌。 |
| **MIT 首笔授权并扣款** （首次付款 + 获取 `tokenID`） | 首笔 CIT（含绑卡授权） | [MIT 代收申请 `POST /usd/mit/apply`](https://doc.haipay.net/zh/api-reference/card/mit-apply) （**不传 `tokenID`**） | • 收银台模式（`payUrl`） • 前置组件模式（**`mode: 'payment'`**） | 用户在场完成首次付款，HaiPay 在回调中返回 `tokenID` 供商户保存。**注意：MIT 在平台内归类为常规代收，前置组件 `mode` 固定传 `'payment'`**。 |
| **MIT 后续主动扣款** （商户按需/按量/自定周期扣款） | 后续 MIT | [MIT 代收申请 `POST /usd/mit/apply`](https://doc.haipay.net/zh/api-reference/card/mit-apply) （**必传 `tokenID`**） | 服务端后台调用（必要时配合 `loadingType`） | 由**商户自己的计费系统**决定何时扣款、扣多少金额（在限额内），传入已保存的 `tokenID` 发起扣款。 |
| **固定套餐期限订阅** （固定金额 + 固定周期自动续费） | 首笔 CIT + 平台托管定期 MIT | [订阅申请 `POST /subscription/apply`](https://doc.haipay.net/zh/api-reference/subscription/subscription-apply) | • 收银台模式（`payUrl`） • 前置组件模式（**`mode: 'subscription'`**） | 明确包含套餐周期（天 `D` / 周 `W` / 月 `M` / 年 `Y`）与最大期数（最长 3 年）。首笔用户授权后，后续每期扣款与失败重试由 **HaiPay 平台自动按期调度**，无需商户自建定时任务。 |

## 4. MIT 接口 vs. 订阅接口：我该选哪个？

许多商户容易混淆「MIT 支付（`/usd/mit/apply`）」与「订阅支付（`/subscription/apply`）」。两者的底层虽然都使用了卡组织的 MIT 通道，但**调度方与适用场景不同**：

> [card] [选择「MIT 支付」(/usd/mit/apply)](https://doc.haipay.net/zh/payments/card-mit.md)
>
> * **扣款时间或金额不固定**：如 AI Token 按量计费、云资源后付费、打车/酒店事后结算、余额低于阈值自动充值。
> * **商户自建订阅引擎**：您已有成熟的账单调度系统，希望完全由自己控制每次扣款的触发时机与重试策略。
> * **前置组件配置**：组件初始化时 `mode` 传 `'payment'`。

> [card] [选择「订阅支付」(/subscription/apply)](https://doc.haipay.net/zh/payments/subscription.md)
>
> * **标准固定周期套餐**：如 \$19.99/月的 VIP 会员、按年续费的 SaaS 许可证，有明确的周期与总期数上限（≤ 3 年）。
> * **希望免去定时扣款开发**：由 HaiPay 自动在每个周期到期时发起扣款、支持首期/全期优惠券与自动失败重试（`retryTimes`）。
> * **前置组件配置**：组件初始化时 `mode` 传 `'subscription'`。

## 5. 合规与提升成功率最佳实践

由于 MIT 与订阅扣款发生在用户不在场时，若协议不透明极易引发持卡人拒付（Chargeback）。遵循以下卡组织合规要求可显著提升扣款成功率并降低争议率：

1. **清晰的首次授权条款**：在首笔 CIT 结账页显著展示计费规则（金额或计费方式、扣款频率、自动续费说明及取消政策），并由用户主动确认。
2. **扣款前后站外通知**：在首次绑定成功、每次后续扣款前（特别是年费或大额周期扣款）及扣款完成后，通过邮件或短信通知用户。
3. **畅通的取消/解绑入口**：在商户网站或 App 的个人中心提供清晰、无障碍的退订或关闭自动扣款入口。
4. **保持 `partnerUserId` 真实一致**：在首笔授权与后续所有扣款请求中传递真实、唯一且一致的 `partnerUserId`，有助于风控模型识别合法复购。

## 相关主题

* [MIT 支付接入指南](https://doc.haipay.net/zh/payments/card-mit.md)
* [订阅支付接入指南](https://doc.haipay.net/zh/payments/subscription.md)
* [订阅支付全流程拆解](https://doc.haipay.net/zh/payments/subscription-process.md)
* [收银台集成方式对比（收银台 vs. 前置组件）](https://doc.haipay.net/zh/payments/integration-modes.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.