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 BNP Paribas merchants are registered in the 3D-Secure program. This operation is performed by the Axepta BNP Paribas 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 | |||||||
|---|---|---|---|---|---|---|---|
| Network | Card Type | 3DS Authentication Result | |||||
3D SUCCESS* | 3D ATTEMPT | 3D NOT ENROLLED | 3D ERROR | 3D FAILURE | |||
| With Cryptogram | Without cryptogram | ||||||
| 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 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 BO | Card Type | 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 | Visa | 05 | 06 | - | 07 | 07 | 07 |
| Mastercard | 02 | 01 | - | 00 | 00 | 00 | |
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 preference | 01 | Frictionless* / Challenge | Issuing Bank | |||
No challenge | 02 | Frictionless* | Merchant | Issuing Bank | ||
| Challenge | Issuing Bank | |||||
| Request challenge | 03 | Frictionless* / Challenge | Issuing Bank | |||
| Challenge Requested (mandate) | 04 | Challenge | Issuing Bank | |||
| Acquirer's TRA exemption request | 05 | Frictionless* | Merchant | N.A. | ||
| Challenge | Issuing Bank | N.A. | ||||
Low-Value Exemption Request | 02 | Frictionless* | Merchant | Issuing Bank | N.A. | |
| Challenge | Issuer | N.A. | ||||
* Frictionless or Frictionless Delegation