> ## 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 vs. MIT Transaction Modes

> Understand the difference between Customer-Initiated Transactions (CIT) and Merchant-Initiated Transactions (MIT), how initial authorization enables subsequent off-session charges, and when to choose One-Time Collection, MIT, or Subscriptions on HaiPay.

Under card network rules (VISA, MasterCard, etc.) and global payment regulations, card transactions are strictly categorized into **CIT (Customer-Initiated Transactions)** and **MIT (Merchant-Initiated Transactions)** based on **who triggers the payment** and **whether the cardholder is present (on-session vs. off-session)**. Understanding and properly separating CIT and MIT is essential for maximizing authorization approval rates, qualifying for 3DS / SCA exemptions, and minimizing dispute liability.

## 1. What Are CIT and MIT?

| Dimension | CIT (Customer-Initiated Transaction) (Customer-Initiated Transaction: an on-session payment actively triggered by the cardholder) | MIT (Merchant-Initiated Transaction) (Merchant-Initiated Transaction: an off-session charge triggered by the merchant under a prior agreement) |
| :- | :- | :- |
| **Full Name** | Customer-Initiated Transaction | Merchant-Initiated Transaction |
| **Who Triggers It** | **The cardholder (shopper)** actively clicks pay at checkout | **The merchant's server** initiates the charge in the background under a prior agreement |
| **Session State** | **On-Session**: The shopper is actively present on your website or app | **Off-Session**: The shopper is offline and not interacting in real time |
| **Authentication (3DS / SCA)** | If challenged by the issuer, the shopper completes 3DS or biometric authentication immediately | Relies on the credential and SCA exemption established during the initial CIT; typically processes seamlessly without user friction |
| **Credential Requirement** | Works with a newly entered card or saves a credential during the first payment | **Requires a previously verified stored credential (`tokenID`)** established via an initial CIT |
| **Typical Use Cases** | One-off e-commerce checkout, initial card-saving payment, manual balance top-up | Usage-based billing, auto top-ups, installment plans, recurring membership renewals |

> [!WARNING]
>
> An MIT charge **cannot be initiated without prior authorization**. Card network rules mandate that the cardholder must first complete an **Initial CIT (on-session)**—explicitly consenting to store their payment credential for future charges and completing any required authentication—before you can initiate **Subsequent MIT (off-session)** charges with the returned `tokenID`. A standard one-off CIT payment made without credential tokenization cannot be charged again later as an MIT.

## 2. Initial CIT vs. Subsequent MIT End-to-End Flow

```mermaid theme={null}
sequenceDiagram
    actor User as Cardholder (User)
    participant Merchant as Merchant System
    participant HaiPay as HaiPay Platform

    rect rgb(235, 245, 255)
    Note over User,HaiPay: Phase 1: Initial CIT (Shopper On-Session Authorization & First Charge)
    User->>Merchant: 1. Agree to recurring/stored-credential terms & place order
    Merchant->>HaiPay: 2. Call /usd/mit/apply (omit tokenID)
    HaiPay-->>Merchant: 3. Return payUrl & clientToken
    User->>HaiPay: 4. Complete first payment & 3DS authentication via Checkout or Component
    HaiPay-->>Merchant: 5. Webhook confirms payment success & returns bound tokenID
    Merchant->>Merchant: 6. Securely store mapping between tokenID & partnerUserId
    end

    rect rgb(240, 255, 240)
    Note over User,HaiPay: Phase 2: Subsequent MIT (Shopper Off-Session Merchant Charge)
    Merchant->>HaiPay: 7. When billing condition is met, call /usd/mit/apply (pass stored tokenID)
    HaiPay->>HaiPay: 8. Validate tokenID & prior consent, execute off-session MIT charge
    HaiPay-->>Merchant: 9. Webhook notifies charge outcome (Success / Failure)
    Merchant-->>User: 10. Deliver service & send off-platform receipt/notification
    end
```

## 3. How CIT and MIT Map to HaiPay Products & APIs

HaiPay provides three distinct API paths covering CIT and MIT scenarios. Choose based on **whether your billing schedule is fixed** and **who schedules the charges**:

| Business Scenario | Transaction Type | API Endpoint | Frontend Integration & Component `mode` | How It Works |
| :- | :- | :- | :- | :- |
| **One-Time Payment** (No card saved, single charge) | One-off CIT | [Card Collection Apply `POST /usd/collect/apply`](https://doc.haipay.net/en/api-reference/card/collect-apply) | • Checkout Mode (`payUrl`) • Component Mode (`mode: 'payment'`) | Shopper pays on-session; no reusable token is generated after the transaction. |
| **Initial MIT Authorization** (First payment + save `tokenID`) | Initial CIT (with credential storage) | [MIT Collection Apply `POST /usd/mit/apply`](https://doc.haipay.net/en/api-reference/card/mit-apply) (**omit `tokenID`**) | • Checkout Mode (`payUrl`) • Component Mode (**`mode: 'payment'`**) | Shopper completes the first payment on-session; HaiPay returns a `tokenID` via callback. **Note: MIT is categorized as standard collection on HaiPay, so always set Component `mode` to `'payment'`.** |
| **Subsequent MIT Charge** (On-demand, usage-based, or merchant-scheduled) | Subsequent MIT | [MIT Collection Apply `POST /usd/mit/apply`](https://doc.haipay.net/en/api-reference/card/mit-apply) (**pass `tokenID`**) | Server-to-server call (optionally with `loadingType`) | **Your own billing engine** decides when and how much to charge (within limits) by passing the stored `tokenID`. |
| **Fixed-Term Subscription** (Fixed amount + fixed recurring cycle) | Initial CIT + HaiPay-scheduled MIT | [Subscription Apply `POST /subscription/apply`](https://doc.haipay.net/en/api-reference/subscription/subscription-apply) | • Checkout Mode (`payUrl`) • Component Mode (**`mode: 'subscription'`**) | Defines an explicit billing cycle (`D` / `W` / `M` / `Y`) and max cycles (up to 3 years). After the initial user authorization, **HaiPay automatically schedules recurring charges and retries**. |

## 4. MIT API vs. Subscription API: Which Should I Choose?

Both `/usd/mit/apply` and `/subscription/apply` use MIT rails for subsequent charges, but they differ in **who manages the billing schedule**:

> [card] [Choose MIT Payment (/usd/mit/apply)](https://doc.haipay.net/en/payments/card-mit.md)
>
> * **Unscheduled or variable-amount charges**: Usage-based AI tokens, cloud metering, post-service charges, or auto-top-up when balance drops below a threshold.
> * **Self-managed billing engine**: You already run your own subscription scheduler and want full control over when each charge is triggered.
> * **Component setting**: Initialize Component Mode with `mode: 'payment'`.

> [card] [Choose Subscription (/subscription/apply)](https://doc.haipay.net/en/payments/subscription.md)
>
> * **Fixed-cycle plans**: Standard \$19.99/month VIP memberships or annual SaaS plans with a fixed interval and duration (≤ 3 years).
> * **Turnkey recurring billing**: Let HaiPay automatically trigger each cycle's deduction, apply promotional coupons (`couponPeriod`), and handle automatic retries (`retryTimes`).
> * **Component setting**: Initialize Component Mode with `mode: 'subscription'`.

## 5. Compliance & Approval Rate Best Practices

Because MIT and subscription deductions occur when the shopper is offline, unclear terms often lead to chargebacks. Follow these best practices to maintain high approval rates and stay compliant:

1. **Clear Terms at Initial Checkout**: Prominently display pricing, billing frequency, auto-renewal terms, and cancellation policies before the shopper authorizes the initial CIT.
2. **Proactive Off-Platform Notifications**: Notify shoppers via email or SMS upon initial agreement activation, before upcoming renewals, and after each deduction.
3. **Unobstructed Cancellation Path**: Provide a clear, self-service cancellation or unbinding entry inside the user's account settings.
4. **Consistent `partnerUserId`**: Pass a valid, consistent `partnerUserId` across the initial CIT and all subsequent MIT requests to help risk models recognize legitimate repeat charges.

## Related Topics

* [MIT Payment Integration Guide](https://doc.haipay.net/en/payments/card-mit.md)
* [Subscription Payment Guide](https://doc.haipay.net/en/payments/subscription.md)
* [Subscription Payment Flowchart](https://doc.haipay.net/en/payments/subscription-process.md)
* [Checkout Integration Modes (Checkout vs. Component)](https://doc.haipay.net/en/payments/integration-modes.md)


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