Challenge Request Indicator
The challengeRequestIndicator provides you with the option to request the issuer, to not challenge the card holder at the time of the transaction.
However, it is worth noting that irrespective of the challenge preference indicated, the final decision is up to the issuer if they want to present the card holder with a challenge or not.
This applies to all of the below indicators:
Used by a merchant to indicate that they do not have a preference for whether the card holder is presented with a challenge or not.
This does provide liability shift to the merchant, as they have indicated that they will challenge (or not challenge) the card holder as per the issuer’s preference.
Used by a merchant if they are requesting a frictionless 3D Secure 2 flow (requesting that the card holder should not be presented with a challenge) from the issuer.
Issuers will more likely allow a frictionless flow when this indicator is used. However, with this indicator, the merchant loses liability shift on the transaction if the card holder has not been presented with a challenge.
Used by a merchant to indicate they would prefer the card holder to be presented with a challenge however, they will also accept a frictionless journey for their card holder if allowed by the Issuer. This does provide liability shift to the merchant as they have indicated that they will challenge (or not challenge) the card holder as per the issuer’s preference. While this is similar to NO_PREFERENCE, it is more likely the card holder will be presented with a challenge.
Used by a merchant to indicate the card holder be presented with a challenge each time.This does provide liability shift to the merchant as they have indicated they will challenge the card holder each time. While the ultimate decision on whether to present the card holder with a challenge or not is left to the issuer, this indicator is used by the issuer to always present the card holder with a challenge.
This indicator is particularly used for certain cases where a challenge needs to be performed each time.For example, if a merchant wants to authenticate the card holder with a Checkcard, (zero value auth) at the point of registration then follow up with Merchant-Initiated-Transactions (MIT)s using this original transaction.
It is mandated that Checkcard (zero value Customer-Initiated-Transactions (CIT))s are always challenged, as the purpose of this transaction type is to verify the card holder.
In general, there is no known negative impact on MITs, as long as the original CIT went through a 3D Secure 2 flow and the card holder completed the transaction as per the issuer’s response.
A MIT will succeed, even if the original transaction was a frictionless journey as long as this was the issuer’s decision.
It is important to reference the receiptID of the original CIT which went through a 3D Secure 2 flow (frictionless OR challenged) when submitting a MIT.
Similarly, Collections will continue to work as expected.
We have observed during the run up to the 3D Secure 2 deadline in Europe, that while issuers are actively ramping up the roll-out of 3D Secure 2, it is recommended to challenge CITs to reduce the likelihood of declines.