logo Sogenactif

Release 24.2

go directly to content

Search by keywords

  1. Payment use cases
  2. MIT/CIT chaining

MIT/CIT chaining

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

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) :
  • 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).

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

Image of the diagram showing the chaining kinematics

For the CIT : the cardholder pays for an order with the card details to Sogenactif through the marchand website. Sogenactif sends an authorisation request with authentication to the banking system. The banking system returns a response to the authorisation request with authentication to Sogenactif 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 Sogenactif a request to debit part of the order amount with the CIT's unique transaction reference (in the initialSchemeTransactionIdentifier field). Sogenactif sends an authorisation request to the banking system, which in turn sends a request to Sogenactif a response to this request for authorisation. Then Sogenactif 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.

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:


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 Sogenactif (storage of the STI and sending the iSTI in the authorisation request of the MIT following the duplication of the CIT as well as storing the 4 specific fields for CB payment guarantee).
 The connector version must be greater than or equal to 2.28 to access the following fields :
  • Keep in your information system the chaining identifier (STI) received in response to the authorisation request (in the schemeTransactionIdentifier ),
  • Transmit this chaining identifier in the MIT authorisation request via the initialSchemeTransactionIdentifier (iSTI).
The connector version must be greater than or equal to 2.49 to access the following fields :

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

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 the transactionReference 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 or s10TransactionId);
  • 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..
Back to top Need help?

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

Configuration