axerve_logo

Our Solutions

Unique and integrated solutions to manage payments in all shapes and forms in all online channels.
Learn
 / 
CIT, MIT and COF transactions: differences and use cases

CIT, MIT and COF transactions: differences and use cases

Published: 21 July 2022 • Reading time: 3 minutes

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. About storing card details, there are two options: either the merchants 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. We have looked at tokenization more in depth in our insight on the topic and in Axerve’s whitepaper that you can download for free here.

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 you can buy using your stored credentials, initiating the transaction as a customer for a single purchase.

Merchant Initiated Transactions – MIT

If you have a subscription business, you are already familiar with merchant-initiated transactions. 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, like 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 business of your Ecommerce store, a type of payment might be optimal for your transactions. However, it’s helpful to know the possibilities and regulations that come with the different options. To keep up to date with payment trends and updates in the world of Ecommerce, sign up to our newsletter.

Source
1

Fintech report on digital payments, Statista 2021.

TagDigital paymentsEcommerce

Join our newsletter