3DS authentication and liability shift
3D Secure authentication protects the merchant against "cardeholder challenge".
The term "liability shift" is used when liability for unpaid amounts for fraud (stolen or forged cards) is transferred from the merchant to the card-issuing bank (the final customer's bank) used for payment.
All Axepta merchants are registered in the 3D-Secure program. This operation is managed by Axepta teams during the onboarding.
3D Secure enrolement does not protect the merchant against all types of unpaid and fraudulent transactions.
3DS Secure authentication protection does not apply to :
- MOTO payments or manually entered on the BO by the merchant
- recurring payments or installements (excluding 1st transaction)
- Batch payments
Matrix : Liability shift for 3DSV1 and 3DSV2
The following table shows the cases where liability shift applies :
LIABILITY SHIFT TO ISSUING BANK | |||||||
---|---|---|---|---|---|---|---|
Brand | Product | 3DS Authentication result | |||||
3D SUCCESS* | 3D ATTEMPT | 3D NOT ENROLLED | 3D ERROR | 3D FAILURE | |||
With cryptogram | Without cryptogram | ||||||
CB | All | YES | YES | YES | NO | NO | NO |
VISA | All | YES | YES | NO | NO | NO | NO |
MASTERCARD | All | YES | YES | NO | NO | NO | NO |
ALL | Prepaid | NO | NO | NO | NO | NO | NO |
*In case of strong authentication request without frictionless or exemption request cf. The table 'Liability shift & Frictionless' below
In the Back-Office Axepta, the following data allows to understand the result of the authentication
Field in the Back-Office | Card | 3DS Authentication result | |||||
---|---|---|---|---|---|---|---|
3D SUCCESS | 3D ATTEMPT | 3D NOT ENROLLED | 3D ERROR | 3D FAILURE | |||
With cryptogram | Without cryptogram | ||||||
Transaction Status | All cards | Y | A | A | - | N | U |
ECI | Mastercard or CB (cobadged Mastercard) | 05 | 06 | 06 | 07 | 07 | 07 |
Visa or CB (cobadged Visa) | 02 | 01 | 01 | 00 | 00 | 00 |
Matrix : Liability shift & Frictionless
In a strongly authenticated transaction (SCA - 3DS), the merchant can indicate which type of authentication he wishes to perform
To do so, the merchants add the JSON object threeDSPolicy EN to the payment request in order to :
- Mandate an authentication
- Request a passive authentication (frictionless)
- Request an exemption
Important : The final choice of the authentication type applied to the transaction is made by the issuing bank (cardholder's bank).
In the case of 3DS Success, the liability shift depends on the card brand and the authentication type requested by the merchant (frictionless, exemption, etc.):
LIABILITY SHIFT TO ISSUING BANK | ||||||
---|---|---|---|---|---|---|
Merchant request - Value for "challengePreference" | Challenge Indicator | Authentication method (DS/ACS) | CB | Mastercard (ECI = 05) | Visa (ECI = 02) | American Express |
No preference | 01 | Frictionless* / Challenge | Issuer | |||
No challenge | 02 | Frictionless* | Merchant | Issuer | ||
Challenge | Issuer | |||||
Request challenge | 03 | Frictionless* / Challenge | Issuer | |||
Challenge Requested (mandate) | 04 | Challenge | Issuer | |||
Exemption : TRA acquérer | 05 | Frictionless* | Merchant | N.A. | ||
Challenge | Issuer | N.A. | ||||
Exemption : Low Amount | 02 | Frictionless* | Merchant | Issuer | N.A. | |
Challenge | Issuer | N.A. |
* Frictionless or Frictionless delegation