open menu
axerve docs
Payments/Recurring payments/MIT Transactions

MIT Recurring payments

When dealing with recurring payments, two types of transactions must be known and performed correctly:

  • Merchant Initiated Transaction (MIT)
    Transactions initiated by the merchant in the absence of the buyer, according to terms and conditions accepted in a previous agreement between the parties.

  • Customer Initiated Transactions (CIT)
    It is the first transaction in the chain of recurring transactions. It requires Strong Customer Authentication (SCA), which allows to verify the authenticity of the payer and to have reference for subsequent transactions, without the payer being present.

Recurring payments 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.

default

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

General integration guidelines

There are 3 different types of MITs, all sharing the same functional principles.

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

  • In order to process MITs, there must be an agreement between the parties that empowers the merchant to initiate transactions at the buyer’s expenses.

  • MITs must refer to the first transaction performed, marked as the first in the series.

  • The first transaction (CIT), to which future MITs will refer, must be authenticated by SCA.

Axerve Ecommerce Solutions offers two types of MIT:

  • Recurring transactions

  • 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: in these cases, there is an initial transaction requiring authentication, called First Transaction (CIT), and a fixed monthly fee, called Next Transaction (MIT), which 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).

For First transactions involving a free subscription during the first payment interval (e.g. first month with a free transaction and subsequent months starting the payment chain), the use of [ASI] tool is required.

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: authDataauthMethodauthTimestampacsID.

      • expiry: end date of the agreement.

      • frequency: minimum number of days between payments.

Within 01F transactions, the data required for proper implementation are as follows:

  • AuthenticationAmount: It is the amount related to the 3DS authentication and it will be the target amount for recurring transactions subsequent to the first. For this reason, the AuthenticationAmount must be equal to or higher than the amount of the recurring transactions. In case the AuthenticationAmount was to be higher than the transaction amount, it is recommended to warn the buyer that the AuthenticationAmount and AuthorizationAmount (in the API simply called Amount) will differ.

  • expiry: It indicates the expiry date within recurring transactions, after which no more transactions will be carried out. The format required for correct implementation is: YYYYMMDD.

  • frequency: It shows the minimum number of days between two recurring transactions within the same chain. This data element is necessary for correct implementation of transaction recurrence.

Unscheduled MIT

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 (merchant and acquirer).

  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

    • expiry: end date of the agreement

  2. Processing subsequent unscheduled MIT payments: the tags required for subsequent MITs are the following:

    • Type = 03N

    • expiry: end date of the agreement

    • 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 BankTransactionID 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: authDataauthMethodauthTimestampacsID.

Grandfathered transactions

Some MIT transactions have been set up before 3DS2 protocols enabling. In such cases, it is possible to process these 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:

  • Type: It is necessary to define the MIT type. Possible values are the following:

    • 01N for Recurring Transactions

    • 03N for Unscheduled MIT.

  • bankTransactionID: -100

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.

On 31 October 2022, Payment Schemes will start a "switch-off" process regarding grandfathered transactions. It is therefore advisable to update the recurring payments's data sharing process in preparation for a correct initiation of this type of transactions.

Due to this implementation, errors are detected, tagged and distributed differently. Previously generic errors have now specific meaning, so as to help the merchant understand the dynamic of the error and where it occurred. An absolute reduction in the number of errors, but an increase on a specific case (e.g. 8026 "Soft decline - Cardholder authentication required"), is expected.

It is plausible that there will be an increase in the number of 8026 soft decline cases informing of the need for an update of the payment chain. In such case, a settable retry mechanism and monitoring of transactions returning this type of error is required. Once the error has been received, a request for the initiation of a new chain that replaces the previous grandfathered transaction is required.

Here are some examples:

SOAP
REST

Encrypt - 01F

copy
1 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecom="https://ecomm.sella.it/">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <ecom:Encrypt>
5         <ecom:shopLogin>GESPAY00001</ecom:shopLogin>
6         <ecom:uicCode>242</ecom:uicCode>
7         <ecom:amount>0</ecom:amount>
8         <ecom:shopTransactionId>OrderID_01F_001</ecom:shopTransactionId>
9         <ecom:requestToken>MASKEDPAN</ecom:requestToken>
10        <ecom:transDetails>
11        <ecom:type>01F</ecom:type>
12        <ecom:authenticationAmount>10</ecom:authenticationAmount>
13        <ecom:recurringTransaction>
14            <ecom:expiry>20301225</ecom:expiry>
15            <ecom:frequency>14</ecom:frequency>
16        </ecom:recurringTransaction>
17        </ecom:transDetails>       
18         <ecom:apikey></ecom:apikey>
19      </ecom:Encrypt>
20   </soapenv:Body>
21</soapenv:Envelope>

callPagamS2S - 01N

copy
1<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecom="https://ecomms2s.sella.it/">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <ecom:callPagamS2S>
5         <ecom:shopLogin>GESPAY00001</ecom:shopLogin>
6         <ecom:uicCode>242</ecom:uicCode>
7         <ecom:amount>10</ecom:amount>
8         <ecom:shopTransactionId>OrderID_01N_001</ecom:shopTransactionId>
9         <ecom:tokenValue><!-- Token received in the 01F :--></ecom:tokenValue>  
10        <ecom:transDetails>
11        <ecom:type>01N</ecom:type>
12        <ecom:previousTransDetails>
13            <ecom:bankTransactionID><!-- bankTransactionID of the 01F :--></ecom:bankTransactionID>
14        </ecom:previousTransDetails>
15        </ecom:transDetails>
16         <ecom:apikey></ecom:apikey>
17      </ecom:callPagamS2S>
18   </soapenv:Body>
19</soapenv:Envelope>

Encrypt - 03F 

copy
1<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecom="https://ecomms2s.sella.it/">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <ecom:callPagamS2S>
5         <ecom:shopLogin>GESPAY00001</ecom:shopLogin>
6         <ecom:uicCode>242</ecom:uicCode>
7         <ecom:amount>10</ecom:amount>
8         <ecom:shopTransactionId>OrderID_03N_001</ecom:shopTransactionId>
9         <ecom:tokenValue><!-- Token received in the 03F :--></ecom:tokenValue>  
10        <ecom:transDetails>
11        <ecom:type>03N</ecom:type>
12        <ecom:previousTransDetails>
13            <ecom:bankTransactionID><!-- bankTransactionID of the 03F :--></ecom:bankTransactionID>
14        </ecom:previousTransDetails>
15        </ecom:transDetails>
16         <ecom:apikey></ecom:apikey>
17      </ecom:callPagamS2S>
18   </soapenv:Body>
19</soapenv:Envelope>

Is this page useful?

Previous
prevObtaining the Exchange Rates
Next
Recurring payments and Negative Option Billing on MasterCard cardsnext

Create your test account to try the service!

Register
Company with Single Shareholder belonging to the Maurizio Sella S.a.a. VAT Group with VAT no. 02675650028 – Tax Code 02686620028 – Biella Court registration no. 71524 – Piazza Gaudenzio Sella 1, 13900 Biella – Share Capital € 4,000,000.00 fully paid-in – Registered in the Reg. Impr. C.C.I.A.A. Monte Rosa Laghi Alto Piemonte – Registered in the Register of Payment Institutions.