CIT, MIT and COF transactions: differences and use cases

The number of digital payments is nowadays increasing exponentially, since customers have grown accustomed to making purchases online and digitally, trend that is also spreading to the older generations. Recent research shows that Europe has the highest growth in digital payments compared to China and the United States, both considering Ecommerce and mobile POS payments. When looking at the UK specifically, with a transaction value of 218.3 billion USD in 2020 - projected to grow to 439.1 billion by 2025 - the UK appears to be the biggest digital payments market in the countries of the European region.¹

These market growth trends are a clear indicator of customers’ payment preferences at the moment around the world.

What do CIT, MIT and COF transactions mean?

In the Ecommerce world, transactions can be customer initiated (CIT) or merchant initiated (MIT). The main difference is that the first type happens with the buyer presence during the transaction, while the second one without the presence of the buyer. Both CIT and MIT fall under the PSD2 obligations and need to be regulated and follow strong customer authentication (SCA) protocols unless they fall under the umbrella of SCA exemptions. MIT transactions however do not need SCA because of the fact that the buyer is not present during the transaction. However, MIT transactions need to follow a first transaction that underwent SCA authentication, in order to guarantee security for the buyer.

Let’s now look at COF or Card on file transactions, where – as you can tell by their name – card credentials are saved by the merchant and are used for future purchases, in order to make the buying process quicker for returning purchases. Regarding storing card details, there are two options: either companies store the credentials themselves or they rely on an outside provider. In this case tokenization becomes an important factor to ensure the security of the stored sensitive information by replacing it with tokens, that by themselves have no meaning and cannot be used by anyone but the merchant itself.

However, let’s go back to card on file transactions: COF can be used in different ways. Firstly, a MIT transaction is always COF, because of the need to rely on card information for the transaction to be processed. However, some COF transactions are not merchant initiated: for example, one-click payments on websites where it is possible to buy using stored credentials, initiating the transaction as a customer for a single purchase.

Merchant Initiated Transactions – MIT

When it comes to subscription businesses, merchant-initiated transactions are a must. However, what are their main aspects? Firstly, like we said they are initiated by the merchant itself. Secondly, the buyer is off-session. Finally, there needs to be an agreement between the parties. In fact, the payments that fall under this umbrella are the ones that, because of their business offering and nature, cannot be processed with a cardholder-initiated transaction, as for example all subscription-based businesses.

When it comes to the actual transactions, there are two steps:

• First phase
  Authentication of the buyer with a CIT transaction and this represents the agreement with the buyer
• Second phase
  MIT transactions where the buyer is not present and the merchant processes the transactions

Moreover, when looking at MIT transactions there are two types:

• Recurring
  Recurring transactions are merchant-initiated and are for the types of payments that have a fixed frequency. In fact, there is the need for a set agreement on a payment schedule defined with a maximum amount over a certain timeframe and a certain frequency (e.g. up to £100 each month). Moreover, authentication on the first recurring payment is required as this is the proof of consensus between the merchant and the buyer on submitting subsequent payments.
  Some examples of use cases are:
  1. Donations
  2. Subscription products
  3. Subscription to digital services (like VOD, video on demand)
  
• Unscheduled
  When we refer to unscheduled transactions, we are looking at transactions that rely on stored credentials for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date. In this case the cardholder has provided consent for the merchant to initiate one or more future transactions. These transactions are used by merchants that cannot follow the restrictions of recurring transaction, for example when payments occur without a specific frequency and with amounts that are always changing.
  Some examples of use cases are:
  1. Smart devices
  2. Hotel No-show
  3. Utilities
  4. Rentals
  5. Pay-Per-Use
  6. Car Sharing

Some transactions, like utilities, although recurring in time with a certain frequency, may vary in their amount so it is better to process them as unscheduled.

As mentioned before, depending on the type of Ecommerce business, different types of payment might be optimal for those transactions. However, it may be helpful to know the possibilities and regulations that come with the different options.

If you are interested in the subscription business and how to optimise payment processing in this sector, download our whitepaper on subscription economy for free.