Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents

Authentification


3DS et transfert de responsabilité

3DS authentication and liability shift



Tip

L'utilisation de l'authentifcation 3D Secure permet de protéger le marchand contre le motif d'impayés "contestation du porteur".

On parle de "transfert de responsabilité" lorsque la responsabilité des impayés pour fraude (cartes volées ou falsifiées) est transférée du marchand vers la banque émettrice de la carte (la banque du client final) utilisée pour le paiement.

Tous les marchands Axepta sont enregistrés au programme 3D-Secure. Cette opération réalisée par la plateforme Axepta Online lors de la création du MID.

Warning

L'enrôlement du marchand au programme 3D Secure ne protège pas contre tous les motifs d'impayés et de fraude.

La protection liée à l'authentification 3D Secure ne s'applique pas :

  • aux paiements MOTO ou saisis manuellement sur le BO par le marchand
  • aux paiements récurrents ou échéances d'un paiement en plusieurs fois (hors 1ère transaction)
  • aux paiements réalisés par Batch

Matrice : Transfert de responsabilité lié au 3DSV1 et 3DSV2

Le tableau ci-dessous indique les cas où le marchand bénéfice du transfert de responsabilité :

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 :

  • 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 :



Réseau
Type de carte
LIABILITY SHIFT TO ISSUING BANK
Brand

Product

3DS Authentication result
TRANSFERT DE RESPONSABILITE VERS LA BANQUE EMETTRICE
Résultat de l'authentification 3DS

3D SUCCESS*


3D ATTEMPT3D NOT ENROLLED3D ERROR3D FAILURE
With cryptogramWithout cryptogramAvec CryptogrammeSans cryptogramme
CBTousAll OUI YES OUI YES OUI YES NON NO NON NO NON NO
VISATousAll OUI YES OUI YES NON NO NON NO NON NO NON NO
MASTERCARDTousAll OUI YES OUI YES NON NO NON NO NON NO NON NO
TOUSALLPré-payésPrepaid NON NO NON NO NON NO NON NO NON NO NON

*Dans le cas d'une demande d'authentification forte sans demande de frictionless ou d'exemption. cf. Le tableau 'Transfert de responsabilité & Frictionless" ci dessous

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-OfficeCard3DS Authentication result

Lors de la consultation des paiements dans le Back-Office Axepta, les données suivantes permettent d'identifier le résultat de l'authentification :

Champ dans le BOType de carteRésultat de l'authentification 3DS

3D SUCCESS


3D ATTEMPT3D NOT ENROLLED3D ERROR3D FAILURE
With cryptogramWithout cryptogramAvec CryptogrammeSans cryptogramme
Transaction StatusToutes cartesAll cardsYAA-NU
ECIMastercard ou or CB (co-badgée cobadged Mastercard)

05

06-06070707
Visa ou or CB (co-badgée cobadged Visa)0201-01000000





Matrice : Transfert de responsabilité

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

Lors d'une transaction soumise à authentification forte (3DS), le marchand peut choisir une préférence pour le type d'authentification qu'il souhaite effectuer.

Pour cela, le marchand ajoute à sa requête de paiement l'objet JSON threeDSPolicy EN qui permettra de :

  • Forcer une authentification
  • Demander une authentification passive (frictionless)
  • Demander une exemption



Info

Important : Le choix final de l'authentification est effectué par la banque émettrice (la banque du porteur du carte - le client final).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

En cas de 3DS Success, le transfert de responsabilité dépend de la marque de la carte utilisée pour le paiement et d'une éventuelle demande du marchand (frictionless, exemption...) :

TRANSFERT DE RESPONSABILITE VERS LA BANQUE EMETTRICE - EN FONCTION DE LA DEMANDE DU MARCHAND

Demande du marchand -

Valeur pour "challengePreference"

Challenge Indicator

Méthode d'authentificationAuthentication method

(DS/ACS)

CB

Mastercard

(ECI = 05)

Visa

(ECI = 02)

American Express
No preference01Frictionless* / ChallengeBanque émettriceIssuer

No challenge

02Frictionless*MarchandMerchantBanque émettriceIssuer
ChallengeBanque émettriceIssuer
Request challenge03Frictionless* / ChallengeBanque émettriceIssuer
Challenge Requested (mandate)04ChallengeBanque émettriceIssuer
Exemption : Demande d'exemption TRA acquérer05Frictionless*MarchandMerchantN.A.
ChallengeBanque émettriceIssuerN.A.

Demande d'exemption Petit montantExemption : Low Amount

02Frictionless*MarchandMerchantBanque émettriceIssuerN.A.
ChallengeÉmetteurIssuerN.A.

* Frictionless ou or Frictionless délégationdelegation