This check is fired if a liability shift has not occurred with the transaction. Note that this check has significant configuration implications.
Liability shift occurs when the liability of chargebacks passes from the merchant to the issuing bank. This is usually done when the transaction has been verified through 3D Secure. Merchants can configure if the risk check should be triggered only for 3D Secure transactions or all e-commerce credit card transactions.
Be careful when changing 3D Secure settings as they can impact your conversion rate.
This check is only triggered for E-Commerce transactions. Recurring (ContAuth) transactions have no liability shift by definition, thus are not analyzed and are accepted by this check. Contact Support Team if you want to disable ContAuth transactions (via Transaction Rules) on this merchant account.
It is also possible to give a negative (trust) score for the check.
There are several different configuration options that dramatically change how this check operates.
Apply the liability shift check for (In order of strictness):
- All E-Commerce Credit Card Transactions: This causes the check to fire for non-recurring credit card transactions where 3D has not been attempted at all, as well as scenarios in which it has. Merchants should only select this option if all transactions on the account are processed with 3D Secure. This kind of strict setup is only suggested for very high risk merchants.
- Only 3D Secure Transactions: This option results in the rule firing if 3D Secure was attempted, but liability shift did not take place. In situations in which 3D Secure did not occur (usually due to Dynamic 3D Secure thresholds), this rule is not triggered. Additionally, some transaction types are incompatible with 3D Secure (such as ContAuth). This option ignores those payments and the checks are not fired.
- Only 3D Secure Transactions Without Technical Errors: In some situations, a technical error may occur which prevents 3D Secure authorization. In these cases, a liability shift could not occur because of the technical error. This configuration eliminates these situations from being assessed by this rule.
Trigger check on transactions for which (In Order of Strictness):
- Full authentication of the card holder has not taken place: The rule triggers when the card holder could not be fully authenticated by the 3D Secure servers. Full authentication is stricter and always requires a (Y)-Authenticated response. Note that the issuing bank may grant a liability shift without an authentication.
- 3D Secure liability shift has not taken place: The rule triggers when no liability shift has occurred for the selected transaction types. This does not always require full authentication by the user i.e. the authorization was done via an automated process by the issuing bank.