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.
Description and principle
Who does this document target?
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:
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) :
||Transaction initialized by the cardholder via a
non-electronical channel (MO/TO) :
||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).
Purpose and principle
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.
Minimal WL Sips interfaceVersion to use
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 Office Batch||12||12|
Use cases concerned
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|
Here is the list of the use cases concerned by chaining:
The payment card is expired
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):
- walletOrder or cardOrder
method : you retain the new valeu of the field
schemeTransactionIdentifierin your information system to initiate MITs. It becomes the new chaining identifier for subsequent transactions
- duplicate method : you retain the
schemeTransactionIdentifierof the new CIT which becomes the
transactionReferencefor the following duplications.
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.
For the payments made with walletOrder or cardOrder method
If the STI is not returned in response to the CIT request for authorisation, we recommend that you do the following:
- submit your MIT without valuing the field
initialSchemeTransactionIdentifierin the request
- store in your information system the chaining identifier which will
be returned to you in the
schemeTransactionIdentifierfield in response to the request for authorisation of this MIT
- value the field
initialSchemeTransactionIdentifierof the request with this same chaining identifier for the following MITs
For the payments made via the duplicate method
If in response to the duplication of the initial transaction (CIT) the
is not valued, this means that the CIT did not have an associated chaining
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 (
- Duplicate this first MIT to create subsequent MITs.
* depending on an evolution to be foreseen for the restitution of a
during the duplication