Search Overlay

3D Secure 2

3D Secure 2 permet aux marchands et aux banques de partager des données contextuelles enrichies sur les détenteurs de cartes afin d’authentifier rapidement les transactions en arrière-plan, sans les étapes de vérification supplémentaires du consommateur qui causent généralement des frictions lors du paiement (p. ex. les redirections d’authentification et la mémorisation et la saisie de mots de passe statiques). Les marchands peuvent désormais renseigner plus de 100 champs lors de la requête d’authentification, que les banques peuvent ensuite utiliser pour déterminer le niveau de risque de la transaction. Grâce à ce transfert de données enrichies, la majorité des transactions à faible risque peuvent être authentifiées sans que le consommateur doive fournir d’informations supplémentaires, ce qui permet un passage à la caisse sûr, efficace et sans friction.

Lorsque 3D Secure est utilisé en conjonction avec une requête d’autorisation via l’API Paiements par carte, exigeant du client qu’il authentifie la carte utilisée lors de la transaction, un avantage majeur pour le marchand est qu’en cas de paiement contesté, la responsabilité financière peut être transférée du marchand à l’émetteur de la carte. Cela signifie qu’en cas de contestation ou de rétrofacturation pour cause de fraude (p. ex. le client affirme qu’il n’a pas effectué la transaction), le titulaire de la carte ou, dans certains cas, l’émetteur de la carte sera responsable du montant autorisé lors de la transaction initiale. Le marchand recevra toujours les fonds de la transaction, ce qui réduit considérablement le risque de rétrofacturations.

Il n’y a pas de transfert de responsabilité pour les motifs de rétrofacturation non liés à la fraude, tels que les marchandises non livrées ou les marchandises défectueuses.

Mise en œuvre de l’API

L’API 3D Secure 2 est utilisée de pair avec l’API Paiements par carte :

  • Utilisez l’API 3D Secure 2 pour demander l’authentification.
  • Traitez l’autorisation avec l’API Paiements par carte.

Processus d’intégration des paiements 3D Secure 2

Le processus d’intégration des paiements avec 3D Secure 2 est le suivant :

  1. Un marchand utilise l’API 3D Secure 2 pour collecter l’empreinte digitale de l’appareil et authentifier le titulaire de la carte.
  2. L’émetteur de la carte détermine s’il convient de mettre au défi le titulaire de la carte ou (s’il a reçu suffisamment de données contextuelles) de compléter l’authentification.
  3. Paysafe renvoie une réponse au marchand. En fonction du résultat, le marchand doit consulter la matrice Transfert de responsabilité pour déterminer s’il y a lieu de procéder à la requête d’autorisation.
  4. Après avoir consulté la matrice de transfert de responsabilité, si le marchand décide de poursuivre, il envoie une autorisation à Paysafe à l’aide de l’API Paiements par carte. La requête contient les résultats d’authentification 3D Secure 2 appropriés (eci, cavv, threeDResult, threeDSecureVersion...).
  5. Une fois l’autorisation obtenue auprès de l’émetteur de la carte, le marchand peut procéder à un règlement (saisir un paiement), à l’aide de l’API Paiements par carte.

Pour de plus amples renseignements, voir la rubrique 3D Secure 2; pour tirer le meilleur parti de votre intégration, voir nos Pratiques exemplaires et lignes directrices d’acceptation 3D Secure 2.

Lorsque le paiement renvoie un code de « refus partiel »

Si un marchand utilise incorrectement ou saute l’authentification 3D Secure pour un paiement qui nécessite une authentification forte du client, Paysafe répondra automatiquement par un « refus partiel » conformément aux normes du secteur. L’entreprise est tenue de tenter le paiement avec l’authentification 3D Secure après avoir obtenu un « refus partiel ».

Pourquoi recevriez-vous un « refus partiel »?

  • Vous avez ignoré 3DS2 avant d’encaisser le paiement.

  • Vous avez essayé d’encaisser le paiement alors que le client n’a pas réussi à s’authentifier auprès de sa banque.

  • L’authentification du client est incomplète en raison d’un problème d’intégration ou d’un problème externe.

  • Si une exemption de l’authentification 3DS2 est demandée trop souvent pour le même client.

Vous recevrez le code et le message « refus partiel » standard suivants, tels que décrits dans le guide Erreurs d’autorisation.

Code d’erreur 3060 – votre requête a été refusée car une authentification forte du client est requise.

Lorsque vous recevez le code d’erreur 3060, vous avez deux possibilités :

Option 1 : tenter à nouveau l’autorisation, mais cette fois avec l’authentification 3DS2.

OR

Option 2 : indiquer le marqueur d’exemption 3DS approprié dans la nouvelle autorisation.

Les marchands ne doivent pas abandonner le paiement ou informer le client que sa carte a été refusée lorsqu’ils reçoivent un refus partiel. Il est obligatoire d’exécuter à nouveau la transaction, cette fois avec l’authentification 3DS2. Les marchands auront beaucoup plus de chances de voir leur paiement accepté s’ils lancent l’authentification ou s’ils demandent une exemption.