Introduction
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:
- CB
- VISA/VPAY/ELECTRON
- MASTERCARD/MAESTRO
- AMEX
To get an overview of the Sogenactif solution, we advise you to consult the following documents:
Transaction qualification
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 (also called NTI network_transaction_id),
- iSTI or initial Scheme Transaction Identifier is used to refer to the reference identifier to be provided in subsequent transactions.
This principle applies regardless of the version of the 3DS protocol version used (3DSv2, 3DSv1).
To benefit from a payment guarantee in the case of a multiple payment upon shipping with CB scheme on MIT which intervene in the 30 days which follow the CIT authentication, you must also fill in the following 4 fields :
Sips fields | CB2A DA fields | CB2A settlement fields | CB2A description |
---|---|---|---|
initialHolderAuthentProgram | 56-0046-01 | 59-0046-01 | 3DS protocol major version |
initialAuthentDateTime | 56-0046-05 | 59-0046-05 | Authentication date |
initialHolderAuthentType | 59-0420-05-01 | 58-0420-05-01 | 3DS authentication type |
initialChallengeMode3DS | 59-0420-05-02 | 58-0420-05-02 | Authentication level requested |
In case of payment with the CB scheme, there are some particularities, please refer to the CB integration guide for more details.
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 cardholder, the questions to be asked are the following:
Here are the functions to use for chaining:
duplicate | cardOrder or walletOrder |
---|---|
|
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:
- One-time payment upon shipping with shipment expected more than 6 days after the order (see documentation multiple payment upon shipping : only one CIT 6 days after the initial CIT)
- Multiple payment upon shipping
- Payment in instalments
- Variable amount subscription
- Via wallet
- Via duplication
Special cases
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 method : you retain the new value of the field
schemeTransactionIdentifier
in your information system to initiate MITs. It becomes the new chaining identifier for subsequent transactions - duplicate method : you retain the
schemeTransactionIdentifier
of the new CIT which becomes thetransactionReference
for the following duplications.
Unknown STI
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.
For the payments made with walletOrder 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
initialSchemeTransactionIdentifier
in the request - store in your information system the chaining identifier which will
be returned to you in the
schemeTransactionIdentifier
field in response to the request for authorisation of this MIT - value the field
initialSchemeTransactionIdentifier
of 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
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
ors10TransactionId
); - Duplicate this first MIT to create subsequent MITs.
Chaining over 18 months
Sogenactif 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..