Whenever card credentials (i.e. cardholder name, card number/token and/or expiry date) are stored for future use a prior consent by the cardholder is required. During the establishment of such a mandate the cardholder should be informed about the exact reason for storage of the credentials with the merchant. That means an authorization request that establishes a mandate for stored credentials also must indicate the kind of potential subsequent transactions. These subsequent transactions with a stored payment credential that the cardholder has consented to are broadly categorized into Customer Initiated Transactions (CITs) and Merchant Initiated Transactions (MITs).

The decisive difference between CITs and MITs is that the latter are out of scope of the RTS for SCA. This is because the Cardholder regularily is off-session and thus, practically not available for an authentication. |
There are various use cases for MITs that can be generally categorized into transactions following a certain Industry Practice and Standing Instructions. In CITs and MITs for Standing Instructions are flagged via the JSON object credentialOnFile.
Please note that all unscheduled MIT transactions are not supported in 3DS 2.0 and thus, will be directly sent for authorization without entering the 3DS sequence. MIT Recurring transactions however will be sent through the 3DS 2.0 protocol to the issuer in order to garantuee best possible acceptance rates. |
Please note that with each initial CIT that establishes a mandate for subsequent MITs you will receive a schemeReferenceID that must be included in follow-up transactions in order to link the sequence. Once SCA becomes mandatory on September 14, 2019 existing MITs covered by cardholder agreements can continue to be processed without a schemeReferenceID if the mandates were setup before that date (i.e. grandfathering). Please do not submit any dummy values. will automatically apply appropriate values in the authorization protocol to indicate so called grandfathering. |