Gestpay becomes Axerve Ecommerce Solutions

MIT transactions

What is a MIT?

Merchant Initiated Transactions, generally referred to as MIT, are transactions initiated by the merchant in the absence of the buyer, according to terms and conditions accepted in a previous agreement between the parties.

MITs are typical of certain industries and are a natural element of specific business models such as subscription based services, utilities, pay-per-use and installments.

In the aforementioned scenarios, the customer accepts the terms and conditions of an agreement with the merchant, empowering the latter to initiate future transactions when the buyer is off session.

Being initiated with the customer off-session, MITs are out of scope for PSD2 and do not require an authentication.

General integration guidelines

While there are different types of MIT, they all share the same functional principles.

If you are a merchant willing to make use of MITs, there are three key elements to keep in mind:

Axerve Ecommerce Solutions offers two types of MIT: recurring transactions and unscheduled transactions.

Recurring transactions

Recurring transactions are the best solution for those use cases when the amount and frequency of payments are known or easily foreseeable.

Classic examples are subscription-based services: a fixed monthly fee (MIT) is debited to the customer upon subscription (agreement) to the service. The subscription usually requires the tokenization of payment credentials and authorization of the amount due for the monthly fee (SCA authenticated transaction).

According to the general MIT framework, recurrences will have two steps:

  1. Set up of recurring MIT: in order to process Reccurring MIT transactions, the recurrence has to be set up by authenticating the first transaction in the series with the maximum expected amount. This is done by filling the following fields:
    • Type = 01F.
    • authenticationAmount: maximum expected payment amount according to the agreement between the parties.
    • expiry: end date of the agreement.
    • frequency: minimum number of days between payments.

    Upon completion of the payment, an identifier should be stored as it is required to process subsequent MIT recurring payments.

  2. Processing subsequent MIT recurring payments: while the first recurring is set to force a SCA, the subsequent payments on the same chain of recurrence are sent as out-of-scope for PSD2. The tags required for subsequent MITs are the following:
    • Type = 01N
    • previousTransDetails: this object contains the information needed in order to link the MIT recurring payment to its SCA authenticated first transaction. Any of the following can be used:
      • BankTransactionID: this is the field we recommend to use. It is the recurring first’s payment identifier. For payments made with SOAP technology, the parameter is BankTransactionID, for payments made via REST API, the transaction’s PaymentID must be used.
      • XID: Prior Transaction unique ID assigned by Directory Server
      • Previous 3DS2 authentication data: in this case, all of these fields must be properly filled: authData, authMethod, authTimestamp, acsID.

Unscheduled MIT Under development

Recurring transactions do not cover every case: sometimes the maximum expected amount cannot be defined beforehand or the frequency of payments can be highly variable.

For cases such as consumption-based agreements, no-show fees, fines (for example for non-returned or damaged rented goods), unscheduled MITs are the best option.

Unscheduled MITs follow the common rules for MIT transactions and need to be set up by an authenticated first transaction as well as an agreement between the parties.

However, there are less limitations compared to recurring transactions: the amount of the subsequent MIT transactions might be higher than the initially authenticated transaction and the frequency and expiry are not required.

  1. Set up of unscheduled MIT: as mentioned above, setting up an unscheduled MIT is much simpler than it is for recurring payments, as the only information needed is the proper tag of transaction type.
    • Type = 03F
  2. Processing subsequent unscheduled MIT payments: the tags required for subsequent MITs are the following:
    • Type = 03N
    • previousTransDetails: this object contains the information needed in order to link the MIT recurring payment to its first SCA authenticated first transaction. Any of the following can be used:
      • bankTransactionID: This is the field we recommend to use. It is the recurring first’s payment identifier. For payments made with SOAP technology, the parameter is BankTransactionID, for payments made via REST API, the transaction’s PaymentID must be used.
      • XID: Prior Transaction unique ID assigned by Directory Server
      • Previous 3DS2 authentication data: in this case, all of these fields must be properly filled: authData, authMethod, authTimestamp, acsID.

Grandfathered transactions

Some MIT transactions have been set up before 3DS2 protocols have been enabled.

In such cases, it is possible to process MIT transactions even without having authenticated and stored the identifiers of an initial transaction.

MIT chains and agreements preceding regulatory requirements are referred to as Grandfathered transactions and can be processed by using the following tags:

Whereas for MIT chains initiated under PDS2 regulation the ID of the first authenticated payment must be stored for future reference, Grandfathered transactions do not require any parameter to be stored.

Each transaction in the MIT chain will be processed with a bankTransactionID: -100 reference until the agreement between the parties is renewed, with an authentication of the buyer. When this happens, a new chain of recurrence will start, according to the requirements for the corresponding MIT type.