Une introduction au 3DSV2 est disponible dans la section 3D Secure - Une authentification forte pour des paiements sécurisés

Le protocole 3DS V2 supporte 150 points de données véhiculées à l'émetteur. Cependant, le traitement des données par les émetteurs peut prendre du temps, il est donc recommandé de partager les données essentielles, les plus efficaces, pour l’émetteur afin de bénéficier de paiement 'frictionless'.

Dans une requête de paiement, le commerçant devra obligatoirement transmettre les données suivantes :

Les données cartes en respectant les exigences PCI DSS
Les données sur les transactions : les numéros d’identification, la devise et le montant.
Les données sur le navigateur : Localisation et système de connexion de l’utilisateur (langue, taille de l’écran, adresse IP…)
Les données sur le porteur : Nom et prénom de l’utilisateur
Les données sur les paiements récurrents (si utilisation de paiements récurrents)

Afin de favoriser les paiements frictionless, le marchand peut :

indiquer des données supplémentaires
indiquer son souhait de paiement frictionless
demander une exemption

Indiquer des données supplémentaires dans la requête de paiement

Certaines données complémentaires sont fortement recommandées pour améliorer l’analyse de risque de la transaction par l’émetteur :

les données sur l’adresse de livraison : ville, code postal, pays…
Les données sur les détails de la livraison (date de livraison)
Les données sur le compte de l’utilisateur (date de création du compte chez le commerçant, date de réinitialisation du mot de passe, etc)
Les données panier (Nombre d’articles dans le panier)
Le scoring commerçant

Les objets JSON suivants peuvent être ajoutées aux requêtes de paiement :

```
customerInfo
```
billingAddress
shipping
browserInfo

Les données recommandées sont les suivantes :

Information du porteur de la carte
- Nom et prénom
- Adresse email
- Numéro de téléphone fixe
- Numéro de téléphone portable
- Adresse de facturation
- Adresse de livraison
Information sur le navigateur/ Browser (dépend de l’intégration)
- Adresse IP

A noter : Toutes ces données seront utilisées à des fins de sécurisation du parcours en ligne dans un objectif de lutte contre la fraude. Les banques émettrices sont régulées sur la gestion de ces données confidentielles.

...
    "customerInfo": {
      "merchantCustomerId": "cus_1234567890abcdef",
      "customerType": "individual",
      "firstName": "Max",
      "lastName": "Mustermann",
      "email": "customer@example.com",
      "phone": {
        "countryCode": "+49",
        "number": "1236547890"
      },
      "salutation": "Ms",
      "title": "Dr",
      "gender": "female",
      "maidenName": "Mustermann",
      "middleName": "sam",
      "birthDate": "2001-01-01",
      "birthPlace": "Bamberg",
      "socialSecurityNumber": "123443534"
    },
...

...
    "billingAddress": {
      "streetName": "Schwarzenbergstr",
      "streetNumber": "4",
      "city": "Bamberg",
      "country": "DEU",
      "postalCode": "96050"
    },
    "shipping": {
      "address": {
        "streetName": "Schwarzenbergstr",
        "streetNumber": "4",
        "city": "Bamberg",
        "country": "DEU",
        "postalCode": "96050"
      }
    },
...

L'ajout de ces données supplémentaires sans demande explicite de paiement 'frictionless' correspond au cas 'no Preference'.

Dans ce cas, si le paiement est 'frictionless', le transfert de responsabilité vers la banque émettrice s'applique.

Pour plus de détails : Transfert de responsabilité et Matrices 3DS

Indiquer un souhait de paiement 'frictionless'

L’objet JSON threeDsPolicy permet au commerçant d'indiquer son souhait d’offrir un parcours frictionless à son acheteur.

Le paramètre challengePreference indique la préférence du commerçant vis-à-vis de l’authentification :

NO_PREFERENCE : Le commerçant laisse le choix à l’émetteur d’authentifier l’acheteur
NO_CHALLENGE : Le commerçant souhaite que l’acheteur ne soit pas authentifié (demande d’exemption, frictionless)
REQUEST_CHALLENGE : Le commerçant souhaite authentifier l’acheteur.
MANDATE_CHALLENGE : Le commerçant demande à l’émetteur d’authentifier l’acheteur (par exemple pour la première transaction d’un abonnement)

Dans tous les cas, le choix final est défini par la banque émettrice (banque du porteur).

...

"paymentMethods": {
    "integrationType": "HOSTED",
    "type": "CARD",
    "card": {
        "threeDsPolicy": {
            "challengePreference" : "NO_CHALLENGE"
            }
        }
	}
...

Le transfert de responsabilité vers la banque émettrice dépend du choix du marchand et de la marque de la carte.

Pour plus de détails : Transfert de reponsabilité et Matrices 3D-Secure

Demander une exemption

L’objet JSON threeDsPolicy permet au commerçant d'indiquer une demande d'exemption.

Le paramètre threeDsPolicy – exemption.reason indique l'exemption souhaitée par le commerçant :

LOW_VALUE : Les transactions à faible montant (inférieur à 30 €)
- Les banques doivent toutefois demander une authentification si l’exemption a été utilisée cinq fois depuis la dernière authentification réussie du titulaire de la carte ou si la somme des paiements exemptés précédemment dépasse 100 €.
TRANSACTION_RISK_ANALYSIS : Les transactions à faible risque (TRA : Transaction Risk Analysis)
- une dérogation à l’obligation d’authentification forte peut être accordée. Pour cela, il faut l'accord préalable de l'acquéreur (sur la base d’une analyse de risque en temps réel de chaque opération).
- Pour bénéficier de cette exemption, le commerçant doit contacter son chargé d’affaires.

Dans tous les cas, le choix final est défini par la banque émettrice (banque du porteur).

...

"paymentMethods": {
    "integrationType": "HOSTED",
    "type": "CARD",
    "card": {
        "threeDsPolicy": {
            "exemption" : {
                 "reason" : "LOW_VALUE"
            }
        }
    }
}
...

Le transfert de responsabilité vers la banque émettrice dépend du choix du marchand et de la marque de la carte.

Pour plus de détails : Transfert de reponsabilité et Matrices 3D-Secure