Release 21.6

go directly to content
Search by keywords

MIT/CIT chaining

To search in the page use Ctrl+F on your keyboard

The implementation of version 2 of the Payment Services Directive (PSD2) requires the authentication of the cardholder during payment transactions.

This authentication is possible when the cardholder is present when the transaction is created, when the order is placed (this is known as a "CIT" or "Customer Initiated Transaction").

On the other hand, authentication is not possible when the cardholder is not present and the transaction is initiated by the merchant (this is called a MIT or "Merchant Initiated Transaction").

In this second case, the merchant must chain the MIT to an "originating" CIT, using a chaining identifier (or grouping identifier) to comply with PSD2.

The purpose of this document is to explain the principle and the implementation of this chaining in the various use cases identified.

This document is intended for merchants and their technical teams wishing to implement transaction chaining on their e-commerce website, for the following means of payment:

  • CB
  • AMEX

To get an overview of the WL Sips solution, we advise you to consult the following documents:

The regulations therefore provide for different qualifications, which determine whether or not strong authentication is required; These include CIT and MIT:

Customer Initiated Transaction via internet Customer Initiated Transaction via email or phone Merchant Initiated Transaction
Transaction initialized by the cardholder, via an electronical channel (internet) :
  • or by direct card entry,
  • or by using the card data previously stored in a stored in a wallet.
Transaction initialized by the cardholder via a non-electronical channel (MO/TO) :
  • the cardholder has sent the card data via a mail or telephone channel, their entry for payment purposes is carried out by the merchant.
Transaction initiated by the merchant without the the cardholder, regardless of the channel.
These transactions are subject to the requirement of strong authentication of the cardholder. These transactions are not subject to the requirement of strong authentication of the cardholder. These transactions are not subject to the requirement of strong authentication of the cardholder.

However, they must be linked to the CIT (through chaining).

Chaining is carried out using a chaining identifier or grouping identifier. This is a unique transaction reference provided by the issuer in the response to the CIT authorisation (or information) request.

Depending on the use case:

  • STI or Scheme Transaction Identifier is used to refer to the identifier provided by the issuer in the response to the authorisation request,
  • iSTI or initial Scheme Transaction Identifier is used to refer to for the reference identifier to be provided in subsequent subsequent transactions.

This principle applies regardless of the version of the 3DS protocol version used (3DSv2, 3DSv1).



In case of payment with the CB scheme, there are some particularities, please refer to the CB integration guide for more details.

To be able to handle chaining, the STI and even iSTI fields must be able to be conveyed. fields must be able to be conveyed.

For this, the following versions or higher must be used higher:

Connector STI in response iSTI in request
Sips Paypage 2.28 not applicable
Sips In-App 2.28 2.33
Sips Office 2.31 2.33
Sips Office Batch 12 12

Depending on the use case, chaining may or may not be required.

Assuming that the order corresponds to the act of purchase in the presence of the presence of the cardholder, the questions to be asked are the following:


Here are the functions to use for chaining:

duplicate cardOrder or walletOrder
  • no particular action on the part of the merchant, the chaining is managed by WL Sips (storage of the STI and sending the iSTI in the authorisation request of the MIT following the duplication of the CIT).

Here is the list of the use cases concerned by chaining:

If the card expires, you ask the cardholder to re-enter his or her card number with the validity date, just as they did when the order.

A new CIT with mandatory strong authentication must be sent for authorisation.

For the following payments (MIT):

If the schemeTransactionIdentifier of the initial transaction (CIT) is not known because it was not returned during the order or subscription taking, different solutions are possible depending on the function used.

If the STI is not returned in response to the CIT request for authorisation, we recommend that you do the following:

If in response to the duplication of the initial transaction (CIT) the field initialSchemeTransactionIdentifier is not valued, this means that the CIT did not have an associated chaining identifier.

In this case, we recommend that you do the following:

  • Take as a transaction reference the MIT created as a result of the duplication of the CIT (transactionReference or s10TransactionId);
  • Duplicate this first MIT to create subsequent MITs.

* depending on an evolution to be foreseen for the restitution of a initialSchemeTransactionIdentifier during the duplication

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.