3DS Authentication and Liability Shift


The use of 3D Secure authentication helps protect merchants against the non-payment reason "cardholder dispute."

We refer to "liability shift" when the responsibility for non-payments due to fraud (stolen or counterfeit cards) is transferred from the merchant to the card-issuing bank (the bank of the end customer) used for the payment.

All Axepta merchants are registered in the 3D-Secure program. This operation is performed by the Axepta Online platform when creating the MID.


Enrollment in the 3D Secure program does not protect against all non-payment and fraud reasons.

The protection related to 3D Secure authentication does not apply to :

  • MOTO payments or those manually entered in the back office by the merchant

  • Recurring payments or installments of a payment in installments (excluding the first transaction)

  • Payments made in batch




Matrix: Liability Shift Related to 3DSV1 and 3DSV2


The table below indicates the cases where the merchant benefits from liability shift :


LIABILITY SHIFT TO THE ISSUING BANK
NetworkCard Type3DS Authentication Result

3D SUCCESS*


3D ATTEMPT3D NOT ENROLLED3D ERROR3D FAILURE
With CryptogramWithout cryptogram
CBAll

YES

 YES YESYES NO NO
VISAAll YES YES NO NO NO NO
MASTERCARDAll YES YES NO NO NO NO
ALLPrepaid NO NO NO NO NO NO

*In the case of a request for strong authentication without a request for frictionless or exemption. See the table "Liability Shift & Frictionless" below.



When consulting payments in the Axepta Back-Office, the following data allows identifying the result of the authentication :

Field in BOCard Type3DS Authentication Result

3D SUCCESS


3D ATTEMPT3D NOT ENROLLED3D ERROR3D FAILURE
With CryptogramWithout cryptogram
Transaction StatusAll cardsYAA-NU
ECIVisa ou CB (co-branded Visa)

05

06-070707
Mastercard ou CB (co-branded Mastercard)0201-000000




Matrix: Liability Shift & Frictionless


During a transaction subject to strong authentication (3DS), the merchant can choose a preference for the type of authentication they wish to perform.

To do this, the merchant adds the JSON object threeDSPolicy to their payment request, which will allow them to :

  • Force authentication

  • Request passive authentication (frictionless)

  • Request an exemption


Important : The final choice of authentication is made by the issuing bank (the bank of the cardholder - the end customer).



In case of 3DS Success, the liability shift depends on the card brand used for the payment and any potential request from the merchant (frictionless, exemption, etc.) :


LIABILITY SHIFT TO THE ISSUING BANK - BASED ON MERCHANT'S REQUEST

Merchant's Request - Value for "challengePreference" 

Challenge Indicator

Authentication Method

(DS/ACS)

CB

Mastercard

(ECI = 05)

Visa

(ECI = 02)

American Express
No preference01Frictionless* / ChallengeIssuing Bank

No challenge

02Frictionless*MerchantIssuing Bank
ChallengeIssuing Bank
Request challenge03Frictionless* / ChallengeIssuing Bank
Challenge Requested (mandate)04ChallengeIssuing Bank
Acquirer's TRA exemption request05Frictionless*MerchantN.A.
ChallengeIssuing BankN.A.

Low-Value Exemption Request

02Frictionless*MerchantIssuing BankN.A.
ChallengeIssuerN.A.

* Frictionless or Frictionless Delegation


  • No labels