| Table of Contents |
|---|
3DS authentication and liability shift
| Tip |
|---|
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. |
| Warning |
|---|
3D Secure enrolement does not protect the merchant against all types of unpaid and fraudulent transactions. 3DS Secure authentication protection does not apply to :
|
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 | NOYES | 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 for CB / NA for Mastercard | 07 | 07 | 07 |
| Visa or CB (cobadged Visa) | 02 | 01 | 01 for CB / NA for Visa | 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
| Info |
|---|
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