WL SIPS DOCS

Release 22.5

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
  • VISA/VPAY/ELECTRON
  • MASTERCARD/MAESTRO
  • 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 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).


Image of the diagram showing the chaining kinematics

For the CIT : the cardholder pays for an order with the card details to WL Sips through the marchand website. WL Sips sends an authorisation request with authentication to the banking system. The banking system returns a response to the authorisation request with authentication to WL Sips and provides the unique transaction reference (in the schemeTransactionIdentifier field). This unique transaction reference identifier is stored in the merchant's IS when using the wallerOrder and/or cardOrder. Once the payment kinematics is completed, the payment result page of the order is displayed to the cardholder. For the MIT1 and MITx: the merchant performs through WL Sips a request to debit part of the order amount with the CIT's unique transaction reference (in the initialSchemeTransactionIdentifier field). WL Sips sends an authorisation request to the banking system, which in turn sends a request to WL Sips a response to this request for authorisation. Then WL Sips sends this response to the merchant.
Note:

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

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 cardholder, the questions to be asked are the following:


Image of the diagram of questions to ask about chaining

If the answer to the question "What type of debit ?" is "Multiple", then chaining is required. "Multiple" means debits for multiple shipping, fixed or variable amount instalments. If the answer to the question "what type of debit ?" is "unique" and the answer to the question "debit upon shipping or when ordering?" is "when ordering", then no chaining is required. If the answer to the question "what type of debit ?" is "unique" and the answer to the question "debit upon shipping or when ordering?" is "upon shipping" and if the answer to the question "potential debit more than 6 days after order?" is "yes", then chaining is required, if the answer to the latter question is "no" then chaining is not required.

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).
The connector version must be greater than or equal to 2.28 to access the following fields :

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.

WL Sips stores transactions for 18 months in the Back Office. Thus, in the case of chaining over a long period (more than 18 months, as in the case of subscriptions for example), the initial transaction (CIT) is no longer accessible because it has been purged. It is therefore no longer possible to retrieve its chaining identifier (field schemeTransactionIdentifier).

We recommend that you duplicate your MITs by submitting the field initialSchemeTransactionIdentifier in the query with the chaining identifier of the last MIT performed :

  • Creation CIT0
  • Duplication CIT0 to create MIT1
  • Duplication MIT1 to create MIT2
  • Duplication MIT2 to create MIT3..

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.

Configuration