Merchant-Initiated Transaction (MIT)

The MIT/CIT distinction matters operationally because it determines SCA applicability, liability allocation, and how the authorization message must be formatted. Getting it wrong is a common source of authorization failures for subscription businesses.

MIT vs CIT

Cardholder-Initiated Transaction (CIT): The cardholder is actively present and initiates the payment — a standard online purchase, an in-store tap, or the first charge in a subscription where the customer completes checkout. CITs are subject to SCA in EEA markets.

Merchant-Initiated Transaction (MIT): The merchant initiates the charge on a schedule or trigger, without the cardholder taking any action at that moment — subscription renewals, instalment 2 through N, recharges of a stored balance. MITs are explicitly exempt from SCA because cardholder presence isn’t possible.

The first charge in any recurring relationship must be a CIT — the cardholder authenticates (via 3DS2 or equivalent), and that authentication establishes the standing agreement. Every subsequent MIT references this original CIT.

MIT Categories

Visa and Mastercard define specific MIT subtypes, each with a corresponding reason code that must be included in the authorization:

MIT Type	Use Case	Scheme Code (Visa)
Recurring	Fixed-amount subscription billing	R
Instalment	Split-payment plans, known total	I
Unscheduled credential-on-file	Variable amount, no fixed schedule	U
Resubmission	Retry of a previously declined transaction	RS
Delayed charge	Final billing after goods/service delivery (e.g., hotel)	DC
No-show	Penalty charge when cardholder doesn’t honour a reservation	NS

SCA Exemption and Issuer Behaviour

MIT SCA exemption is based on logic: if the cardholder isn’t present, they cannot complete an authentication challenge. However, issuers are not required to honour MIT exemptions — some issuers, particularly in the EEA, decline MIT attempts at elevated rates if the original CIT lacked strong authentication.

The practical implication: if the initial subscription CIT did not go through 3DS2 frictionless or challenge, the issuer may have no authentication record to anchor the MIT against, increasing decline risk on recurring charges.

Authorization Rate Impact

MIT flagging directly affects authorization rates. Transactions sent as MITs without the correct prior CIT reference can:

• Trigger SCA challenges the cardholder cannot complete (resulting in declines)
• Be treated as unauthorized by the issuer (triggering disputes)
• Fail Visa/Mastercard scheme validation checks

Conversely, correctly flagged MITs with a strong CIT anchor typically achieve higher authorization rates than equivalent CITs — issuers recognise the established relationship and apply less friction.

Practical Requirements

For subscription platforms:

1. The initial checkout must be a CIT processed with 3DS2 (in EEA markets)
2. Store the network transaction ID from the CIT authorization
3. Include this ID as the “previous transaction reference” in all subsequent MITs
4. Use the correct MIT reason code for each charge type
5. For failed MITs, follow scheme rules on retry timing before resubmission

Most PSPs handle MIT flagging automatically if the integration is configured for recurring billing. The risk is manual or custom-built billing integrations that send all charges as standard authorizations without MIT flags.