Introduction

WL Sips est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métier liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement en plusieurs fois …).

L'objectif de ce document est d'expliquer la mise en œuvre de 3-D Secure pour les moyens de paiement CB, VISA, MASTERCARD et AMEX jusqu'au démarrage en production.

A qui s’adresse ce document

Ce document s’adresse aux commerçants et à leurs équipes techniques qui souhaitent mettre en place 3-D Secure sur leur site de commerce électronique, pour les moyens de paiement CB, VISA, MASTERCARD et AMEX.

Pour avoir une vue d’ensemble de la solution WL Sips , nous vous conseillons de consulter les documents suivants :

Généralités

Principe

3-D Secure est un protocole d’authentification destiné à réduire les risques de fraude liés au paiement sur Internet. Il a pour but de s’assurer que la carte est bien utilisée par son véritable porteur.

Lors d’un paiement 3-D Secure, il y a une étape supplémentaire qui consiste à authentifier le porteur de la carte.

Attention: au 31/03/2020, la DSP2 rend obligatoire l’authentification forte pour les paiements sur Internet, échéance à partir de laquelle les premiers refus émetteurs seront appliqués sur les transactions non authentifiées 3-D Secure (champ acquirerResponseCode = A1).

Pour davantage de détails, merci de vous référer à notre communiqué RTS-SCA du 16/09/2019 .

Transfert de responsabilité

Outre le renforcement de la sécurité, 3-D Secure vous permet de bénéficier du transfert de responsabilité vers la banque émettrice de la carte. En cas de paiement frauduleux, vous êtes garanti de percevoir les fonds, c’est la banque du porteur de la carte qui supporte cette responsabilité. Dans de rares cas, la banque du porteur de la carte peut accepter une demande d’autorisation mais refuser ce transfert de responsabilité, dans ce cas précis le paiement n’est donc plus garanti, et le champ holderAuthentRelegationCode est valorisé à Y.

Ces règles de transfert de responsabilité sont édictées par les réseaux CB, VISA, MASTERCARD. Lorsque le paiement est garanti, le champ guaranteeIndicator est valorisé à Y.

Nouvelle version 3-D Secure 2.0

Les améliorations apportées

Malgré les avantages sécuritaires évidents, 3-D Secure 1.0, déployé en France depuis 2007, n’offre pas une expérience utilisateur optimale, et par conséquent a des répercussions sur le taux de transformation des achats en ligne.

Pour améliorer l’expérience utilisateur, les réseaux CB, VISA, MASTERCARD et AMEX proposent maintenant 3-D Secure 2.0 qui apporte un système d’authentification plus optimal basé sur l’évaluation du risque et plus adapté à l’usage des smartphones.

En fonction du niveau de risque, les banques émettrices décideront d’exécuter ou non l’authentification forte du client, il s’agit d’un mode de fonctionnement appelé « frictionless ». Plus le risque est faible, plus la probabilité d’obtenir une transaction « frictionless » est forte.

Comment 3-D Secure v1 et 3-D Secure v2 vont cohabiter ?

Cas 1 : vous êtes encore 3-D Secure v1, mais l’émetteur est 3-D Secure v2 :

Tout fonctionnera, car l’émetteur continue de traiter les demandes d’authentification 3DSv1. Les réseaux VISA et MASTERCARD ont d’ailleurs recommandé aux banques émettrices de continuer à enrôler leurs nouvelles cartes sur les 2 versions de 3-D Secure (v1 et v2).

Cas 2 : vous êtes déjà 3-D Secure v2, mais l’émetteur est encore 3-D Secure v1 :

Tout fonctionnera aussi, car le serveur de paiement WL Sips transmet, dans ce cas, les demandes d’authentification en 3DSv1.

Champs obligatoires Visa

Pour traiter les transactions de son réseau, en 3-D Secure v2, Visa impose que les champs adresse de facturation, nom et email du client soient renseignés. En cas d’absence d’un de ces champs dans votre requête, WL Sips oriente donc la transaction sur 3-D Secure v1.

Visa impose aussi que le champ fraudData.merchantCustomerAuthentMethod (méthode d’authentification du client par le commerçant) soit renseigné. Si vous ne renseignez pas ce champ dans la requête de paiement, WL Sips le valorise par défaut à NOAUTHENT (pas d’authentification du client par le commerçant) pour orienter la transaction en 3-D Secure v2.

Liste des champs obligatoires demandés par Visa :

billingAddress.city

billingAddress.country

billingAddress.addressAdditional1

billingAddress.addressAdditional2

billingAddress.addressAdditional3

billingAddress.zipcode

billingAddress.state

holderContact.lastName

holderContact.email

fraudData.merchantCustomerAuthentMethod

Activation de l’option 3-D Secure

La Directive des Services de Paiement 2 (DSP2), rendant obligatoire la réalisation d’une authentification forte pour les paiements initiés par le client sur Internet ou via une application mobile, entre en application le 14 Septembre 2019, avec une phase de rodage jusqu’au 31 mars 2020. 3-D Secure permet d’être en conformité pour les paiements par cartes avec cette nouvelle réglementation. Sans activation du 3-D Secure, vous vous exposez à des refus d’autorisation pour le motif de transactions non authentifiées.

Par conséquent, sauf avis contraire de votre part, toute nouvelle boutique e-commerce est inscrite sur WL Sips avec l’option 3-D Secure activée par défaut.

(Pour davantage de détails, merci de vous référer à notre communiqué RTS-SCA du 16/09/2019 ).

Si l’option 3-D Secure n’est pas activée sur votre boutique, veuillez contacter l'assistance technique de WL Sips pour activer cette option.

Pour le réseau CB, l’activation de l’option 3-D Secure est quasi-immédiate.

Pour les réseaux VISA, MASTERCARD et AMEX, l’activation de l’option 3-D Secure se fait en 2 temps :

  • étape 1 = enrôlement de votre boutique sur le Directory Server VISA et MASTERCARD, ou AMEX ;
  • étape 2 = activation de 3-D Secure lorsque l’enrôlement sur le Directory Server est réalisé. A titre informatif, VISA réalise l’enrôlement approximativement en 24 heures, MASTERCARD en 7 jours, AMEX en 3 semaines.

3-D Secure et paiement différé

Afin de bénéficier du transfert de responsabilité, pour toute transaction 3-D Secure dont le délai de capture est supérieur à 6 jours (champ captureDay > 6), WL Sips force le délai de capture à 6 (champ captureDay forcé à la valeur 6).

Par conséquent, en cas de paiement 3-D Secure, avec une carte CB/VISA/MASTERCARD/AMEX, et pour une requête de paiement dont le champ captureDay est supérieur à 6, vous aurez en réponse :

  • le champ captureDay valorisé à 6 ;
  • si le champ captureMode de votre requête a pour valeur VALIDATION, vous n’avez que 6 jours pour valider l’envoi en banque de la transaction ;
  • si le champ captureMode de votre requête a pour valeur AUTHOR_CAPTURE ou est non renseigné, vous n’avez que 6 jours pour annuler la transaction avant son envoi en banque.

Refuser les transactions en erreur 3-D Secure

Afin de réduire le risque d’impayé, vous avez la possibilité de refuser toutes les transactions pour lesquelles une erreur technique a empêché le bon déroulement du processus d’authentification 3-D Secure.

Si vous activez cette option et qu’une erreur 3-D Secure survient lors de l’authentification 3-D Secure, la transaction est refusée, avec en retour un code réponse 05 (champ responseCode = 05) et le champ holderAuthentStatus valorisé à ERROR.

N’accepter que les transactions garanties

Afin d’être certain de collecter tous les fonds de vos ventes et d’éviter les impayés, vous avez la possibilité de refuser toutes les transactions 3-D Secure pour lesquelles le transfert de responsabilité ne s’applique pas, même si la transaction a été autorisée.

Si vous activez cette option, seules les transactions bénéficiant du transfert de responsabilité (champ GuaranteeIndicator = Y) seront acceptées.

Cette option, et la règle qui en découle, ne s’appliquent qu’aux transactions 3-D Secure CB, VISA, MASTERCARD.

Cette option ne s'applique pas :

  • sur les transactions non 3-D Secure
  • sur les transactions effectuées avec un moyen de paiement autre que CB, VISA, MASTERCARD
  • sur les échéances 2 à N du paiement en plusieurs fois
  • sur les duplications et autres paiements récurrents

Connecteur Sips Paypage

Paiement par carte

Ce paragraphe décrit comment mettre en œuvre 3-D Secure pour les paiements à l’acte, les paiements à l’acte avec enrôlement OneClick et les paiements OneClick .

Description des flux

  1. Vous redirigez le client vers Sips Paypage en communiquant dans la requête les données de la transaction (montant, devise, ..).
  2. WL Sips affiche la page de paiement, le client saisit le numéro de carte, le cryptogramme visuel, puis valide.
  3. WL Sips procède à la vérification 3-D Secure.
  4. WL Sips envoie une demande d’autorisation à l’acquéreur.
  5. WL Sips enregistre la transaction dans le back office.
  6. WL Sips affiche la page de ticket de paiement.
  7. WL Sips vous retourne les réponses manuelle et automatique contenant les détails de la transaction y compris le résultat de l’authentification 3-D Secure.
  8. WL Sips envoie, ou pas, la transaction en remise en fonction des modalités que vous avez paramétrées dans la requête de paiement.

La séquence décrite ci-dessus se transpose sur les moyens de paiement CB, Visa, Mastercard et Amex.

débrayage dynamique du 3-D Secure

Afin de favoriser un meilleur taux de transformation, en fonction du risque (montant, connaissance du client, …) vous pouvez choisir de bypasser dynamiquement l’authentification 3-D Secure (y compris pour les paiements OneClick ). Cette option est applicable pour les moyens de paiement CB, Visa et Mastercard, elle n'a pas d'effet sur le moyen de paiement AMEX.

Pour bénéficier de cette option, vous devez préalablement obtenir l’approbation de votre acquéreur, puis demander l’activation auprès de l’assistance technique et valoriser le champ fraudData.bypass3DS à ALL (ou MERCHANTWALLET pour un paiement OneClick ). En réponse de paiement, le champ holderAuthentStatus est valorisé à BYPASS.

IMPORTANT: compte tenu de la récente réglementation (14/09/2019) rendant obligatoire l’authentification pour les paiements sur Internet, en débrayant l’authentification 3-D Secure, vous vous exposez à des refus de paiement type "soft decline" ( acquirerResponseCode = A1). Afin que vous ne perdiez pas de vente, suite à ce type de refus, nous demandons automatiquement au client de s'authentifier 3-D Secure, et ré-envoyons une seconde demande d'autorisation avec la preuve d'authentification du client.

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Paramétrer la requête de paiement

Pour proposer le paiement 3-D Secure via Sips Paypage vous n’avez aucun champ spécifique 3-D à renseigner. Si toutefois, vous souhaitez activer le débrayage dynamique du 3-D Secure , vous devez renseigner le champ fraudData.bypass3DS .

Champ Règle de valorisation
fraudData.bypass3DS ALL si vous souhaitez désactiver l’authentification 3-D Secure lors d’un paiement à l’acte.
MERCHANTWALLET si vous souhaitez désactiver l’authentification 3-D Secure lors d’un paiement OneClick .
Non renseigné sinon.
merchantName Nom de la boutique de votre site Web affiché sur la page d’authentification de la banque du client.
Si non renseigné, le nom de votre boutique renseigné lors de l’inscription de votre boutique sur WL Sips sera affiché.
fraudData.challengeMode3DS Dans un contexte 3-D Secure V2, si vous souhaitez demander une exemption, veuillez vous référer au chapitre correspondant

Veuillez consulter un des guides Sips Paypage ( Sips Paypage JSON , Sips Paypage POST ou Sips Paypage SOAP pour savoir comment renseigner la requête en fonction de votre besoin métier).

Analyser la réponse

WL Sips retourne une réponse manuelle et une réponse Sips Paypage automatique classique .

Les champs relatifs à un paiement 3-D Secure sont les suivants :

Cas d’usage Champs de la réponse
Client authentifié fortement

guaranteeIndicator = voir Dictionnaire des données .

  • version du connecteur (et de la réponse) supérieure ou égale à 2.24
    • 3DS : le client s’est authentifié dans une cinématique 3-D Secure V1 ;
    • 3DS_V2 : le client s’est authentifié dans une cinématique 3-D Secure V2.
  • version du connecteur (et de la réponse) inférieure à 2.24
    • 3DS : le client s'est authentifié dans une cinématique 3-D Secure V1 ou 3-D Secure V2
holderAuthentMethod =
  • version du connecteur (et de la réponse) supérieure ou égale à 2.24
  • version du connecteur (et de la réponse) inférieure à 2.24
    • NOT_SPECIFIED : quelle que soit la cinématique

holderAuthentStatus = ATTEMPT ou SUCCESS

holderAuthentType =

  • si cinématique 3-D Secure v1 = non renseigné ;
  • si cinématique 3-D Secure v2 = CHALLENGE.
Client authentifié passivement, sans souhait du commerçant (aussi appelé "Frictionless émetteur")

guaranteeIndicator = voir Dictionnaire des données .

  • si version du connecteur (et de la réponse) supérieure ou égale à 2.24 = 3DS_V2
  • si version du connecteur (et de la réponse) inférieure à 2.24 = 3DS
holderAuthentMethod =
  • si version du connecteur (et de la réponse) supérieure ou égale à 2.24 : voir Dictionnaire des données .
  • si version du connecteur (et de la réponse) inférieure à 2.24 = NOT_SPECIFIED

holderAuthentStatus = ATTEMPT ou SUCCESS

holderAuthentType = FRICTIONLESS ou DELEGATED_FRICTIONLESS

Client authentifié passivement, avec souhait du commerçant (aussi appelé "Frictionless commerçant", ChallengeMode3DS = NO_CHALLENGE)

guaranteeIndicator = N

  • si version du connecteur (et de la réponse) supérieure ou égale à 2.24 = 3DS_V2
  • si version du connecteur (et de la réponse) inférieure à 2.24 = 3DS
holderAuthentMethod =
  • si version du connecteur (et de la réponse) supérieure ou égale à 2.24 : voir Dictionnaire des données .
  • si version du connecteur (et de la réponse) inférieure à 2.24 = NOT_SPECIFIED

holderAuthentStatus = ATTEMPT ou SUCCESS

holderAuthentType = FRICTIONLESS ou DELEGATED_FRICTIONLESS

Carte non enrôlée

guaranteeIndicator = voir Dictionnaire des données .

holderAuthentMethod =

  • version du connecteur (et de la réponse) supérieure ou égale à 2.24
    • si cinématique 3-D Secure v1 : NOT_SPECIFIED ;
    • si cinématique 3-D Secure v2 : NO_AUTHENT.
  • version du connecteur (et de la réponse) inférieure à 2.24
    • NOT_SPECIFIED : quelle que soit la cinématique

holderAuthentStatus = NOT_ENROLLED

holderAuthentType =

  • si cinématique 3-D Secure v1 : non renseigné ;
  • si cinématique 3-D Secure v2 : NONE.
Le client n’a pas réussi à s’authentifier, le paiement est nécessairement refusé.

guaranteeIndicator = N

holderAuthentProgram =

  • version du connecteur (et de la réponse) supérieure ou égale à 2.24
    • 3DS : le client s’est authentifié dans une cinématique 3-D Secure V1 ;
    • 3DS_V2 : le client s’est authentifié dans une cinématique 3-D Secure V2.
  • version du connecteur (et de la réponse) inférieure à 2.24
    • 3DS : le client s'est authentifié dans une cinématique 3-D Secure V1 ou 3-D Secure V2
holderAuthentMethod =
  • version du connecteur (et de la réponse) supérieure ou égale à 2.24
  • version du connecteur (et de la réponse) inférieure à 2.24
    • NOT_SPECIFIED : quelle que soit la cinématique

holderAuthentType =

  • si cinématique 3-D Secure v1 : non renseigné ;
  • si cinématique 3-D Secure v2 : CHALLENGE.
Problème technique qui a empêché le bon déroulement de l’authentification 3-D Secure.

guaranteeIndicator = voir Dictionnaire des données .

holderAuthentProgram =

  • version du connecteur (et de la réponse) supérieure ou égale à 2.24
    • 3DS : le client s’est authentifié dans une cinématique 3-D Secure V1 ;
    • 3DS_V2 : le client s’est authentifié dans une cinématique 3-D Secure V2.
  • version du connecteur (et de la réponse) inférieure à 2.24
    • 3DS : le client s'est authentifié dans une cinématique 3-D Secure V1 ou 3-D Secure V2
holderAuthentMethod =
  • si cinématique 3-D Secure v1 : NOT_SPECIFIED ;
  • si cinématique 3-D Secure v2 : NOT_SPECIFIED.

holderAuthentType =

  • si cinématique 3-D Secure v1 : non renseigné ;
  • si cinématique 3-D Secure v2 : NONE. ou CHALLENGE
Vous bypassez l’authentification 3-D Secure.

guaranteeIndicator = non renseigné

holderAuthentMethod = NO_AUTHENT_METHOD

holderAuthentType = non renseigné

Votre boutique n’est pas enrôlée 3-D Secure.

guaranteeIndicator = non renseigné

holderAuthentMethod = NO_AUTHENT_METHOD

holderAuthentType = non renseigné

Le client annule le processus d’authentification.

guaranteeIndicator = N

Le client abandonne sur la page ACS et ferme son navigateur. Vous ne recevez pas de réponse manuelle, mais uniquement une réponse automatique avec un champ responseCode valorisé à 97.

guaranteeIndicator = non renseigné

holderAuthentProgram = non renseigné

holderAuthentStatus = non renseigné

holderAuthentType = non renseigné

Connecteur Sips Office

Paiement à partir d’un numéro de carte

Description des flux

Un paiement 3-D Secure se déroule en 3 temps :

  • la vérification de l’enrôlement de la carte du client ;
  • la redirection du client vers l’ACS de sa banque ;
  • la demande d’autorisation 3-D Secure.

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Pour accepter un paiement carte 3-D Secure, vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.

Etape 1 : collecte des coordonnées de paiement

Vous collectez les données carte du client (numéro de carte, date de validité, cryptogramme visuel). Vous devez vous conformer aux recommandations PCI-DSS.

Etape 2 : vérification de l’enrôlement de la carte sélectionnée

Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la méthode cardCheckEnrollment .

Paramétrer la requête de paiement

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
amount Montant du paiement. Le montant est affiché sur la page d’authentification du client.
captureDay Doit être inférieur ou égal à 6. Si la valeur est supérieure à 6, le serveur WL Sips le force à 6.
cardCSCValue Valeur récupérée à l’étape précédente.
cardExpiryDate Valeur récupérée à l’étape précédente.
cardNumber Valeur récupérée à l’étape précédente.
merchantName Nom de la boutique de votre site Web affiché sur la page d’authentification de la banque du client. Si non renseigné, sera affiché le nom de votre boutique renseigné lors de l’inscription de votre boutique sur WL Sips .
merchantReturnUrl Ne pas valoriser, champ déprécié.
merchantUrl URL de votre site Web affichée sur la page d’authentification de la banque du client. Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur WL Sips .
orderChannel Pour les paiements effectués par Internet, valoriser : INTERNET
panType Si vous utilisez le connecteur Sips Office classique : PAN si vous utilisez le connecteur Sips Office en mode CSE : CSE
paymentMeanBrand Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la valeur indiquée détermine le choix du DS dans une cinématique 3-D Secure v2.
Exemple : pour une carte co-badgée CB+VISA :
  • si vous renseignez CB, le serveur WL Sips interrogera le DS CB ;
  • si vous renseigné VISA, le serveur WL Sips interrogera le DS VISA.
fraudData.challengeMode3DS Dans un contexte 3-D Secure V2, si vous souhaitez demander une exemption, veuillez vous référer au chapitre correspondant
Analyser la réponse
Cas d’usage Champs de la réponse Action à réaliser
Carte enrôlée 3-D Secure. redirectionStatusCode = 00 Vous devez rediriger le client sur l’ACS de sa banque via l’URL contenue dans le champ redirectionUrl (voir l'étape suivante).
Carte non enrôlée 3-D Secure. redirectionStatusCode = 01 Passez à l’étape 5 : demande d’autorisation.
Erreur technique empêchant le bon déroulement d’une cinématique 3-D Secure. redirectionStatusCode = 10, 80, 89, 99 Passez à l’étape 5 : demande d’autorisation.
Boutique non enrôlée au programme 3-D Secure. reponseCode = 40 Veuillez contacter l'assistance technique de Worldline .
Transaction invalide redirectionStatusCode = 12 Une ou plusieurs données de la requête sont invalides. Consultez le champ errorFieldName , et corrigez la valeur incorrecte.
Carte invalide redirectionStatusCode = 14 Les coordonnées du moyen de paiement sont invalides, repasser à l’étape 1 en demandant au client de saisir de nouveau ses informations de paiement.
Transaction dupliquée redirectionStatusCode = 94 Le transactionReference ou le transactionId sont déjà utilisés par une autre requête de la boutique. Resoumettez la requête avec un autre identifiant de transaction.

Etape 3 : redirection du client vers l’ACS de sa banque

Si la carte est enrôlée, vous devez rediriger le client vers l’URL de l’ACS de sa banque, récupérée à l’étape précédente dans le champ redirectionUrl . Dans un cas d'authentification passive, vous devez aussi réaliser cette étape, même si le client ne sera pas réellement redirigé vers l'ACS de sa banque.

Merci de vous référer au paragraphe Formulaire POST vers l’ACS de la documentation Sips Office JSON pour mettre en œuvre ce message.

Etape 4 : récupération des données de l’authentification du client

A la fin du processus d'authentification, le client est redirigé vers votre site via une redirection HTTP. Le résultat de l’authentification est récupéré au travers du champ PARes .

Merci de vous référer au paragraphe Formulaire POST vers l’ACS de la documentation Sips Office JSON pour mettre en œuvre ce message.

Si le client abandonne le processus d’authentification (il ferme son navigateur, il n’est jamais redirigé sur votre site Web), ne transmettez pas la demande d’autorisation, ne livrez pas la commande.

Etape 5 : demande d’autorisation 3-D Secure

Après son authentification (y compris pour une authentification passive ou une authentification échouée), au retour du client sur votre site de commerce électronique, transmettez la demande d’autorisation 3-D Secure via la méthode cardValidateAuthenticationAndOrder .

En cas d'authentification échouée, WL Sips ne transmet pas de demande d'autorisation vers votre acquéreur, le paiement est nécessairement refusé.

Paramétrer la requête

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
redirectionData Contient les données de la transaction de paiement. Valorisez ce champ avec le champ redirectionData reçu en retour de la méthode cardCheckEnrollment .
transactionReference
ou
Doit être identique au champ transactionReference ou s10TransactionReference transmis lors de l’appel à la méthode cardCheckEnrollment .
paResMessage Si vous avez redirigé le client vers l’ACS de sa banque, car sa carte est enrôlée : renseignez ce champ avec le contenu du champ PARes reçu en retour de l’ACS.
Si vous n’avez pas redirigé le client vers l’ACS de sa banque, car sa carte n’est pas enrôlée, ne renseignez pas ce champ.
messageVersion Valorisez ce champ avec le champ messageVersion reçu en retour de la méthode cardCheckEnrollment
Analyser la réponse
Cas d’usage Champs de la réponse
Client authentifié Voir Analyser la réponse .
Le client n’a pas réussi à s’authentifier, ou a annulé sur la page ACS, le paiement est nécessairement refusé. Voir Analyser la réponse .
Problème technique qui a empêché le bon déroulement de l’authentification 3-D Secure. Voir Analyser la réponse .
paResMessage invalide.
Ce cas peut survenir :
  • si le message PARES que vous transmettez n’est pas strictement identique au PARES reçu de l’ACS (par exemple, le message est tronqué) ;
  • si le client a volontairement modifié le message PARES avant de revenir sur votre site. Ceci peut s’apparenter à une tentative de fraude. Il faut alors stopper le processus d’achat.
holderAuthentResponseCode = 95
Session 3D expirée.
Ce cas peut survenir si vous transmettez la requête cardValidateAuthenticationAndOrder plus de 15 minutes après traitement de la requête cardCheckEnrollment .
holderAuthentResponseCode = 89

Paiement à partir d’un identifiant client (aussi appelé OneClick )

Dans ce paragraphe, nous ne décrivons pas la phase d’enregistrement de la carte, nous faisons l’hypothèse que le client a déjà enregistré sa carte dans le wallet WL Sips . Pour davantage de détails sur cette phase, merci de vous référer à la documentation OneClick .

Description des flux

Un paiement 3-D Secure à partir d’un identifiant client se déroule en 4 temps :

  • l’authentification de votre client, et le choix du moyen de paiement qu’il sélectionne dans son wallet ;
  • la vérification de l’enrôlement de la carte sélectionnée ;
  • la redirection du client vers l’ACS de sa banque ;
  • la demande d’autorisation 3-D Secure.

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Pour mettre en œuvre un paiement OneClick 3-D Secure, vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.

Etape 1 : authentification de votre client et choix de son moyen de paiement

Vous authentifiez votre client afin de retrouver la valeur de la donnée merchantWalletId qui lui correspond.

Vous lui affichez la liste des moyens de paiement contenu dans son wallet. Si vous n’avez pas stocké cette liste de moyens de paiement dans votre système d’information, vous pouvez la récupérer via l’appel à une requête getWalletData .

Il sélectionne le moyen de paiement carte de son choix, ce qui vous permet de retrouver la valeur de la donnée paymentMeanId .

Etape 2 : vérification de l’enrôlement de la carte sélectionnée

Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la méthode walletCheckEnrolment .

Paramétrer la requête

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
amount Montant du paiement. Le montant est affiché sur la page d’authentification du client.
captureDay Doit être inférieur ou égal à 6.
Si la valeur est supérieure à 6, le serveur WL Sips le force à 6.
merchantName Nom de la boutique de votre site affiché sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché le nom de votre boutique renseigné lors de l’inscription de votre boutique sur WL Sips .
merchantReturnUrl Ne pas valoriser, champ déprécié.
merchantUrl URL de votre site affichée sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur WL Sips .
merchantWalletId Valeur récupérée à l’étape précédente.
paymentMeanId Valeur récupérée à l’étape précédente.
orderChannel Pour les paiements effectués par Internet, valoriser : INTERNET.
Analyser la réponse
Cas d’usage Champs de la réponse Action à réaliser
Carte enrôlée 3-D Secure redirectionStatusCode = 00 Vous devez rediriger le client sur l’ACS de sa banque via l’URL contenue dans le champ redirectionUrl (voir l'étape suivante).
Carte non enrôlée 3-D Secure redirectionStatusCode = 01 Passez à l’étape 5 : demande d’autorisation.
Boutique non enrôlée au programme 3-D Secure. redirectionStatusCode = 40 Veuillez contacter l'assistance technique de Worldline .
Erreur technique empêchant le bon déroulement d’une cinématique 3-D Secure. redirectionStatusCode = 10, 80, 89, 99 Passez à l’étape 5 : demande d’autorisation.
Transaction invalide redirectionStatusCode = 12 Une ou plusieurs données de la requête sont invalides. Consultez le champ errorFieldName , et corrigez la valeur incorrecte.
Carte expirée redirectionStatusCode = non renseigné Redemandez à votre client de sélectionner un autre moyen de paiement ou de saisir un nouveau moyen de paiement.
Transaction dupliquée redirectionStatusCode = 94 Le transactionReference ou le transactionId sont déjà utilisés par une autre requête de la boutique. Resoumettez la requête avec un autre identifiant de transaction.

Etape 3 : redirection du client vers l’ACS de sa banque

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 4 : récupération des données de l’authentification du client

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 5 : demande d’autorisation 3-D Secure

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Paiement à partir d’un token

Dans ce paragraphe, nous ne décrivons pas la phase transformation de la carte en token, nous faisons l’hypothèse que le client a déjà payé une première fois et que vous avez stocké le token correspondant à son numéro de carte, ainsi que la date de validité de la carte.

Description des flux

Un paiement 3-D Secure à partir d’un token se déroule en 4 temps :

  • la récupération du token et la collecte du cvv de la carte ;
  • la vérification de l’enrôlement de la carte du client ;
  • la redirection du client vers l’ACS de sa banque ;
  • la demande d’autorisation 3-D Secure.

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Pour mettre en œuvre un paiement token 3-D Secure, vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.

Etape 1 : identification de votre client, récupération du token de sa carte et collecte du cvv

Vous identifiez votre client afin de retrouver le token et la date de validité de sa carte, token et date de validité que vous avez préalablement stocké lors du premier paiement de votre client.

Vous collectez aussi le cvv de la carte du client, en lui demandant de le saisir.

Etape 2 : vérification de l’enrôlement de la carte sélectionnée

Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la méthode cardCheckEnrollment .

Paramétrer la requête

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
amount Montant du paiement. Le montant est affiché sur la page d’authentification du client.
captureDay Doit être inférieur ou égal à 6.
Si la valeur est supérieure à 6, le serveur WL Sips le force à 6.
cardCSCValue Valeur récupérée à l’étape précédente, par saisie du client.
cardExpiryDate Valeur récupérée à l’étape précédente, stockée préalablement dans votre système d’information.
cardNumber Token de la carte
merchantName Nom de la boutique de votre site affiché sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché le nom de votre boutique renseigné lors de l’inscription de votre boutique sur WL Sips .
merchantReturnUrl Ne pas valoriser, champ déprécié.
merchantUrl URL de votre site affichée sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur WL Sips .
orderChannel Pour les paiements effectués par Internet, valoriser : INTERNET
panType TOKEN_PAN
paymentMeanBrand Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la valeur indiquée détermine le choix du DS.
Exemple : pour une carte co-badgée CB+VISA :
  • si vous renseignez CB, le serveur WL Sips interrogera le DS CB ;
  • si vous renseigné VISA, le serveur WL Sips interrogera le DS VISA.
Analyser la réponse
Cas d’usage Champs de la réponse Action à réaliser
Carte enrôlée 3-D Secure redirectionStatusCode = 00 Vous devez rediriger le client sur l’ACS de sa banque via l’URL contenue dans le champ redirectionUrl (voir l'étape suivante).
Carte non enrôlée 3-D Secure redirectionStatusCode = 01 Passez à l’étape 5 : demande d’autorisation.
Boutique non enrôlée au programme 3-D Secure redirectionStatusCode = 40 Veuillez contacter l'assistance technique de Worldline .
Erreur technique empêchant le bon déroulement d’une cinématique 3-D Secure. redirectionStatusCode = 10, 80, 89, 99 Passez à l’étape 5 : demande d’autorisation.
Transaction invalide redirectionStatusCode = 12 Une ou plusieurs données de la requête sont invalides. Consultez le champ errorFieldName , et corrigez la valeur incorrecte.
Token inconnu redirectionStatusCode = 12 Vérifiez le champ cardNumber .
Carte expirée redirectionStatusCode = 14 Redemandez à votre client de sélectionner un autre moyen de paiement ou de saisir un nouveau moyen de paiement.
Transaction dupliquée redirectionStatusCode = 94 Le transactionReference ou le transactionId sont déjà utilisés par une autre requête de la boutique. Resoumettez la requête avec un autre identifiant de transaction.
Détokenisation Hors Service redirectionStatusCode = 99 Il s’agit éventuellement d’un problème ponctuel, resoumettez la requête une seconde fois. En cas de nouvelle erreur, stoppez le processus. Merci alors d’alerter l'assistance technique de Worldline de l’incident.

Etape 3 : redirection du client vers l’ACS de sa banque

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 4 : récupération des données de l’authentification du client

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 5 : demande d’autorisation 3-D Secure

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Authentification du client dissociée du paiement (aussi appelé Authentication-only)

Ce paragraphe décrit comment mettre en œuvre des cas d’usage de 3-D Secure nécessitant de dissocier le flux d’authentification du flux de paiement.

Authentification traitée par WL Sips et paiement traité par un autre PSP

Description des flux

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Pour mettre en œuvre un paiement carte 3-D Secure en mode « Authentication-only », vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.

Etape 1 : collecte des coordonnées de paiement

Vous collectez les données de carte du client (numéro de carte, date de validité, cryptogramme visuel). Vous devez vous conformer aux recommandations PCI-DSS.

Etape 2 : vérification de l’enrôlement de la carte via WL Sips
Paramétrer la requête de paiement

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
cardCSCValue Valeur récupérée à l’étape précédente
cardExpiryDate Valeur récupérée à l’étape précédente
cardNumber Valeur récupérée à l’étape précédente
merchantName Nom de la boutique de votre site affiché sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché le nom de votre boutique renseigné lors de l’inscription de votre boutique sur WL Sips .
merchantReturnUrl Ne pas valoriser, champ déprécié.
merchantUrl URL de votre site affichée sur la page d’authentification de la banque du client. Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur WL Sips .
panType Valoriser à PAN.
paymentMeanBrand Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la valeur indiquée détermine le choix du DS.
Exemple : pour une carte co-badgée CB+VISA :
  • si vous renseignez CB, le serveur WL Sips interrogera le DS CB.
  • si vous renseigné VISA, le serveur WL Sips interrogera le DS VISA.
Analyser la réponse

Merci de vous référer à la partie Analyser la réponse du paragraphe de Connecteur Sips Office .

Etape 3 : redirection du client vers l’ACS de sa banque

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 4 : récupération des données de l’authentification du client

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 5 : vérification du résultat de l’authentification

Merci de vous référer à la même étape du paragraphe Enrôlement d'une carte sans paiement.

Etape 6 : demande d’autorisation vers l’autre PSP

Les données 3-D Secure sont présentes dans la réponse de la méthode cardValidateAuthentication appelée à l’étape précédente :

  • si l’authentification a été réalisée en 3-D Secure v1, voir container authenticationData.threeD ;
  • si l’authentification a été réalisée en 3-D Secure v2, voir container authenticationData.threeDV2.

Authentification traitée par un autre PSP et paiement traité par WL Sips

Description des flux

Mise en œuvre

Pour mettre en œuvre un paiement carte 3-D Secure en mode « Authentication-only », vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.

Etape 1 : collecte des coordonnées de paiement

Vous collectez les données de carte du client (numéro de carte, date de validité, cryptogramme visuel). Vous devez vous conformer aux recommandations PCI-DSS.

Etape 2 : demande d’authentification vers autre PSP
Etape 3 : demande d’autorisation 3-D Secure vers WL Sips

Après son authentification, au retour du client sur votre site de commerce électronique, transmettez la demande d’autorisation 3-D Secure via la méthode cardOrder .

Paramétrer la requête de paiement

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
amount Doit être identique au montant de l’authentification
captureDay Doit être inférieur ou égal à 6.
Si la valeur est supérieure à 6, le serveur WL Sips le force à 6.
cardCSCValue Renseigné avec la valeur récupérée à l’étape 1. Doit nécessairement être renseigné dans le cadre d’un paiement 3-D Secure.
cardExpiryDate Renseigné avec la valeur récupérée à l’étape 1.
cardNumber Renseigné avec la valeur récupérée à l’étape 1.
orderChannel Pour les paiements effectués par Internet, valoriser : INTERNET
paymentPattern ONE_SHOT
panType Si vous utilisez le connecteur Sips Office classique : PAN
Si vous utilisez le connecteur Sips Office en mode CSE : CSE
paymentMeanBrand Renseigné avec la valeur récupérée à l’étape 1.
Si l’authentification a été réalisée en 3-D Secure v1.
authenticationData.threeD.cavv En cas d’authentification 3-D Secure v1, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeD.cavvAlgorithm En cas d’authentification 3-D Secure v1, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeD.eci En cas d’authentification 3-D Secure v1, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeD.securityIndicator En cas d’authentification 3-D Secure v1, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeD.txStatus En cas d’authentification 3-D Secure v1, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeD.xid En cas d’authentification 3-D Secure v1, à renseigner avec la valeur correspondante reçue à l’étape 2.
Si l’authentification a été réalisée en 3-D Secure v2.
authenticationData.threeDV2.cavv En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.cavvAlgorithm En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.securityIndicator En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.eci En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.txStatus En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentTransStatusReason En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentDsTransId En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentAmount En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentAcsTransId En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentDateTime En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentType En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentScoreValue En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.challengeMode3DS En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.
authenticationData.threeDV2.authentCancelReason En cas d’authentification 3-D Secure v2, à renseigner avec la valeur correspondante reçue à l’étape 2.

Enrôlement d'une carte sans paiement

Description des flux

La vérification d’une carte via le processus 3-D Secure avant son enrôlement dans le wallet WL Sips se déroule en 4 temps :

  • la vérification de l’enrôlement de la carte ;
  • la redirection du client vers l’ACS de sa banque pour l’authentifier ;
  • la vérification de l’authentification 3-D Secure ;
  • l’enregistrement de la carte dans le wallet si l’authentification est réussie.

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Pour mettre en œuvre la vérification 3-D Secure d’une carte avant son enrôlement dans un wallet, vous devez mettre en œuvre les messages reçus et transmis par l’entité nommée « Serveur e-commerce » du schéma ci-dessus.

Etape 1 : collecte des coordonnées de paiement

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 2 : vérification de l’enrôlement de la carte sélectionnée

Vous vérifiez l’enrôlement 3-D Secure de la carte en faisant appel à la méthode cardCheckEnrollment .

Paramétrer la requête

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
amount Etant donné qu’il n’y a pas de paiement, vous pouvez valoriser à 0.
cardCSCValue Valeur récupérée à l’étape précédente.
cardExpiryDate Valeur récupérée à l’étape précédente.
cardNumber Valeur récupérée à l’étape précédente.
merchantName Nom de la boutique de votre site affiché sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché le nom de votre boutique renseigné lors de l’inscription de votre boutique sur WL Sips .
merchantReturnUrl Ne pas valoriser, champ déprécié.
merchantUrl URL de votre site Web affichée sur la page d’authentification de la banque du client.
Si non renseigné, sera affiché l’URL de votre boutique renseignée lors de l’inscription de votre boutique sur WL Sips .
panType Valoriser à PAN
paymentMeanBrand Pour les cartes co-badgées (CB+VISA ou CB+MASTERCARD), la valeur indiquée détermine le choix du DS.
Exemple : pour une carte co-badgée CB+VISA :
  • si vous renseignez CB, le serveur WL Sips interrogera le DS CB ;
  • si vous renseigné VISA, le serveur WL Sips interrogera le DS VISA.
Analyser la réponse

Merci de vous référer à la partie Analyser la réponse du paragraphe de Connecteur Sips Office .

Etape 3 : redirection du client vers l’ACS de sa banque

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 4 : récupération des données de l’authentification du client

Merci de vous référer à la même étape du paragraphe Connecteur Sips Office .

Etape 5 : vérification du résultat de l’authentification

Après son authentification, au retour du client sur votre site de commerce électronique, vérifiez le résultat de son authentification via la méthode cardValidateAuthentication .

Paramétrer la requête

Dans un contexte 3-D Secure, en dehors des données obligatoires de la méthode, voici les données de la requête auxquelles vous devez prêter attention.

Nom du champ Règle de valorisation
redirectionData Contient les données de la transaction de paiement. Valorisez ce champ avec le champ redirectionData reçu en retour de la méthode cardCheckEnrollment .
transactionReference
ou
Doit être identique au champ transactionReference ou s10TransactionReference transmis lors de l’appel à la méthode cardCheckEnrollment .
paResMessage Si vous avez redirigez le porteur vers l’ACS de sa banque, car sa carte est enrôlée : renseignez ce champ avec le contenu du champ PARes reçu en retour de l’ACS.
Si n’avez pas redirigé le porteur vers l’ACS de sa banque, car sa carte n’est pas enrôlée, ne renseignez pas ce champ.
Analyser la réponse
Cas d’usage Champs de la réponse
Client authentifié

holderAuthentResponseCode = 00

  • version du connecteur supérieure ou égale à 2.24
    • 3DS : le client s’est authentifié dans une cinématique 3-D Secure V1 ;
    • 3DS_V2 : le client s’est authentifié dans une cinématique 3-D Secure V2.
  • version du connecteur inférieure à 2.24
    • 3DS : le client s'est authentifié dans une cinématique 3-D Secure V1 ou 3-D Secure V2
holderAuthentMethod =
  • version du connecteur supérieure ou égale à 2.24
  • version du connecteur inférieure à 2.24
    • NOT_SPECIFIED : quelle que soit la cinématique
holderAuthentStatus = ATTEMPT ou SUCCESS

si cinématique 3-D Secure v2 threeDv2.holderAuthentType = cf. dictionnaire des données
Le client n’a pas réussi à s’authentifier, ou a annulé sur la page ACS

holderAuthentResponseCode = 01

holderAuthentProgram =
  • version du connecteur supérieure ou égale à 2.24
    • 3DS : le client s’est authentifié dans une cinématique 3-D Secure V1 ;
    • 3DS_V2 : le client s’est authentifié dans une cinématique 3-D Secure V2.
  • version du connecteur inférieure à 2.24
    • 3DS : le client s'est authentifié dans une cinématique 3-D Secure V1 ou 3-D Secure V2
holderAuthentMethod =
  • version du connecteur supérieure ou égale à 2.24
  • version du connecteur inférieure à 2.24
    • NOT_SPECIFIED : quelle que soit la cinématique
si cinématique 3DSv2 threeDv2.holderAuthentType = CHALLENGE
Problème technique qui a empêché le bon déroulement de l’authentification 3-D Secure.

holderAuthentResponseCode = 02

holderAuthentProgram =
  • version du connecteur supérieure ou égale à 2.24
    • 3DS : le client s’est authentifié dans une cinématique 3-D Secure V1 ;
    • 3DS_V2 : le client s’est authentifié dans une cinématique 3-D Secure V2.
  • version du connecteur inférieure à 2.24
    • 3DS : le client s'est authentifié dans une cinématique 3-D Secure V1 ou 3-D Secure V2
holderAuthentMethod =
  • si cinématique 3-D Secure v1 : NOT_SPECIFIED ;
  • si cinématique 3-D Secure v2 : NOT_SPECIFIED.
si cinématique 3DSv2 threeDv2.holderAuthentType = CHALLENGE
paResMessage invalide.
Ce cas peut survenir :
  • si le message PARES que vous transmettez n’est pas strictement identique au PARES reçu de l’ACS (par exemple, le message est tronqué) ;
  • si le client a volontairement modifié le message PARES avant de revenir sur votre site. Ceci peut s’apparenter à une tentative de fraude. Il faut alors stopper le processus d’enrôlement.
holderAuthentResponseCode = 95
Session 3D expirée.
Ce cas peut survenir si vous transmettez la requête cardValidateAuthentication plus de 15 minutes après traitement de la requête cardCheckEnrollment .
holderAuthentResponseCode = 89
Etape 6 : ajouter la carte au wallet

Si le client est bien authentifié vous pouvez enregistrer sa carte à son wallet via la méthode addCard . Merci de vous référer à la documentation Sips Office pour connaître les détails d’implémentation de cette méthode.

Connecteur Sips Walletpage

Enregistrement d’une carte d’un abonné

Ce paragraphe décrit comment mettre en œuvre 3-D Secure pour l’enrôlement d’un abonné.

Description des flux

  1. Lors du processus d’enrôlement de votre abonné, vous le redirigez vers Sips Walletpage pour lui permettre d’enregistrer ses coordonnées de paiement. L’abonné sélectionne un moyen de paiement, fournit ses coordonnées de paiement puis valide.
  2. WL Sips procède à la vérification 3-D Secure.
  3. WL Sips effectue les contrôles anti-fraude.
  4. WL Sips envoie une demande d’autorisation à l’acquéreur.
  5. WL Sips enregistre les données du moyen de paiement dans le wallet si les contrôles fraude sont OK et l’autorisation acceptée.
  6. WL Sips affiche la page d’accueil contenant un message de confirmation. L’abonné peut désormais voir son moyen de paiement sur la page d’accueil.
  7. WL Sips vous retourne les réponses manuelle et automatique contenant le contenu du wallet.

débrayage dynamique du 3-D Secure

Si vous êtes sûr de l’identité de votre abonné car vous l’avez authentifié en amont, vous pouvez choisir de bypasser dynamiquement l’authentification 3-D Secure.

Pour activer cette option, vous devez préalablement obtenir l’approbation de votre acquéreur, puis demander l’activation auprès de l’assistance technique et valoriser le champ fraudData.bypass3DS à ALL. En réponse de paiement, le champ holderAuthentStatus est valorisé à BYPASS.

Mise en œuvre

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de WL Sips pour activer le service.

Paramétrer la requête de paiement

Pour proposer l’authentification 3-D Secure via Sips Paypage vous n’avez aucun champ spécifique 3-D Secure à renseigner. Si toutefois, vous souhaitez activer le débrayage dynamique, vous devez renseigner le champ fraudData.bypass3DS .

Nom du champ Règle de valorisation
fraudData.bypass3DS ALL si vous souhaitez désactiver l’authentification 3-D Secure lors de l’enregistrement de la carte du client.
Non renseigné sinon.

Merci de vous référer au guide Sips Walletpage JSON pour savoir comment renseigner la requête en fonction de votre besoin métier.

Analyser la réponse

WL Sips retourne une réponse manuelle et une réponse automatique classique walletpage. Il n’y a pas de champs relatif à une authentification 3-D Secure dans une réponse de Sips Walletpage .

Les exemptions à l'authentification forte

Description des exemptions

Le protocole 3-D Secure v2 permet d'authentifier le client de manière passive, lorsque le risque de fraude est suffisamment bas. Ce type d'authentification est aussi appelée authentification « frictionless ». Lors d'un paiement « frictionless », l’opération est bien authentifiée, mais le client n’est pas sollicité. Dans un cas de frictionless, un cryptogramme d’authentification est fourni par l’émetteur et transmis dans la demande d’autorisation.

La DSP2 distingue plusieurs cas d'exemption :

  • Les exemptions pour petits montants (< 30 €)
  • Les exemptions suite à une analyse de risque acquéreur (Transaction Risk Analysis Acquéreur)
  • Les exemptions suite à une analyse de risque émetteur (Transaction Risk Analysis Emetteur)
  • Les exemptions dans le cadre d'un paiement chez un bénéficiaire de confiance
  • Les exemptions sur l'utilisation de cartes non-nominatives (cartes attribuées aux personnes morales)

Le paiement frictionless se décline de 2 manières :

  • frictionless commerçant , que vous demandez explicitement dans la requête de paiement, via le champ faudData.challengeMode3DS . Même si vous demandez une authentification « frictionless » la décision définitive d’accorder ou pas cette authentification frictionless reste du ressort de l’émetteur de la carte. Il est important de noter que si l’émetteur accorde l'authentification frictionless , dans ce cas, vous perdez la garantie de paiement, c’est alors vous qui supportez le risque d’impayé et non plus l’émetteur de la carte. Si l’émetteur n'accorde pas l'authenification « frictionless », il supporte le risque d'impayé.
  • frictionless émetteur décidé par l’émetteur de la carte en fonction des données de contexte de la transaction que vous aurez renseignées dans la requête. Même si l’émetteur accorde l'authentification frictionless , vous conservez la garantie de paiement, c’est donc l’émetteur de la carte qui supporte le risque d’impayé.

Mise en oeuvre des exemptions

Exemption suite à une analyse de risque

Vous pouvez demander une exemption si votre analyse de risque montre que le risque de fraude est suffisamment bas pour solliciter une authentification "frictionless". Ce cas de dérogation est appelé Transaction Risk Analysis (TRA) acquéreur. Pour profiter de cette fonctionnalité, vous devez demander l'autorisation à votre acquéreur, qui vous indiquera les modalités d'usage de cette exemption (montant maximal, règles à appliquer en cas d'évolution dans le temps, ...).

Paramétrer la requéte

Champ Valorisation
fraudData.challengeMode3DS NO_CHALLENGE_TRA_ACQ

Analyser la réponse

Cas d'usage Champs de la réponse Action à réaliser
Demande d'exemption accordée par l'émetteur et client authentifié passivement

holderAuthentType = FRICTIONLESS ou DELEGATED_FRICTIONLESS

holderAuthentStatus = SUCCESS ou ATTEMPT

authentExemptionReasonList = voir Dictionnaire des données

Demande d'exemption rejetée par l'émetteur et client authentifié fortement

holderAuthentType = CHALLENGE

holderAuthentStatus = SUCCESS ou ATTEMPT

authentExemptionReasonList = non renseigné

Demande d'exemption non autorisée car droit non permis sur WL Sips et client authentifié (dans ce cas WL Sips traduit en demande d'exemption "basique" : fraudData.challengeMode3DS = NO_CHALLENGE) voir chapitre suivant Contactez votre interlocuteur WL Sips pour ajouter le droit à l'utilisation de cette fonctionnalité

Autre demande d'exemption

Si vous ne bénéficiez pas du droit d'utilisation de l'exemption TRA acquéreur, vous pouvez aussi demander une exemption basique.

Paramétrer la requéte

Champ Valorisation
fraudData.challengeMode3DS NO_CHALLENGE

Analyser la réponse

Cas d'usage Champs de la réponse Action à réaliser
Demande d'exemption accordée par l'émetteur et client authentifié passivement

holderAuthentType = FRICTIONLESS ou DELEGATED_FRICTIONLESS

holderAuthentStatus = SUCCESS ou ATTEMPT

AuthentExemptionReasonList = voir Dictionnaire des données

Demande d'exemption rejetée par l'émetteur et client authentifié fortement

holderAuthentType = CHALLENGE

holderAuthentStatus = SUCCESS ou ATTEMPT

authentExemptionreasonList = non renseigné

Exemption pour petit montant et exemption TRA Emetteur

Même si vous ne demandez pas explicitement d'exemption, l'emetteur de la carte peut accorder une exemption dans 2 autres cas :

  • le paiement est d'un montant faible, inférieur à 30 €.
  • l'analyse de risque effectuée par l'émetteur montre que le risque de fraude est suffisament bas

Paramétrer la requéte

Il n'y a pas de données spécifique à transmettre, toutefois, afin de favoriser l'obtention d'une exemption, il est préférable de valoriser les champs recommandés par les réseaux. Veuillez vous référer au chapitre suivant .

Analyser la réponse

Cas d'usage Champs de la réponse Action à réaliser
Demande d'exemption accordée par l'émetteur et client authentifié passivement

holderAuthentType = FRICTIONLESS ou DELEGATED_FRICTIONLESS

holderAuthentStatus = SUCCESS ou ATTEMPT

authentExemptionreasonList = voir Dictionnaire des données

Champs permettant de favoriser le paiement "frictionless"

Afin de favoriser le paiement « frictionless » et par conséquent optimiser votre taux de conversion, vous devez renseigner certains champs de la requête de paiement recommandés par les réseaux CB, VISA et MASTERCARD. Ces champs optionnels sont transmis au Directory Server du réseau ainsi qu’à l’émetteur de la carte qui décide ou pas d’accorder l'authentification frictionless .

Ce paragraphe liste les champs des connecteurs WL Sips qui, s’ils sont alimentés, sont transmis au réseau de la carte ainsi qu’à l’émetteur dans la demande d’authentification. Ces données, définies par la norme EMVco , sont utilisées pour la lutte contre la fraude et favorisent l’obtention d'une authentification frictionless .

Parmi ces champs on peut distinguer :

  • O - champs Obligatoires pour le réseau : ces champs sont identifiés comme obligatoires par le réseau. En cas d’absence WL Sips applique des règles de gestion décrites au paragraphe Champs obligatoires Visa .
  • R - champs Recommandés par le réseau : ces champs facultatifs ont été identifiés par le réseau comme étant important pour le scoring de la transaction. Ainsi le réseau recommande leur alimentation par le commerçant si l’information est disponible.
  • F - champs Facultatifs : ces champs sont purement facultatifs, le réseau n’a pas indiqué de recommandation pour leur alimentation.
  • A - champs Absents : ces champs ne sont pas transmis au réseau.

Vous noterez que le réseau Mastercard, n’a pas défini de champs obligatoires ni recommandés.

Nom du champ CB Visa Mastercard
billingAddress.city R O F
billingAddress.country R O F
billingAddress.addressAdditional1 R O F
billingAddress.addressAdditional2 R O F
billingAddress.addressAdditional3 R O F
billingAddress.zipcode R O F
billingAddress.state R O F
holderContact.lastName R O F
holderContact.email R O F
holderContact.phone R R F
holderContact.mobile R R F
holderContact.workPhone R R F
deliveryAddress.city R R F
deliveryAddress.country R R F
deliveryAddress.addressAdditional1 R R F
deliveryAddress.addressAdditional2 R R F
deliveryAddress.addressAdditional3 R R F
deliveryAddress.zipcode R R F
deliveryAddress.state R R F
deliveryContact.email R F F
fraudData.addressDeliveryBillingMatchIndicator R R F
fraudData.nameDeliveryCustomerMatchIndicator R F F
fraudData.productAvailabilityIndicator R F F
fraudData.reorderProductIndicator R F F
fraudData.merchantCustomerAuthentMethod R O F
fraudData.merchantCustomerAuthentDateTime F R F
fraudData.merchantCustomerAuthentData F R F
fraudData.challengeMode3DS R R F
fraudData.productAvailabilityDate F R F
fraudData.giftCardAmount F R F
fraudData.giftCardCurrency F R F
fraudData.giftCardCount F R F
customerAccountHistoric.customerAccountId F R F
customerAccountHistoric.numberOfPurchase180Days R F F
customerAccountHistoric.numberOfTransactionYear F R F
customerAccountHistoric.customerAccountCreationDate R R F
customerAccountHistoric.numberOfAttemptsAddCard24Hours R R F
customerAccountHistoric.suspiciousActivityIndicator R R F
customerAccountHistoric.numberOfTransaction24Hours R R F
customerAccountHistoric.customerAccountChangeDate F R F
customerAccountHistoric.passwordChangeDate F R F
customerAccountHistoric.addPaymentMeanDate F R F
deliveryData.deliveryAddressCreationDate R R F
deliveryData.electronicDeliveryIndicator R R F
deliveryData.estimatedDeliveryDelay R R F
deliveryData.deliveryMode R R F
shoppingCartDetail.shoppingCartTotalQuantity R A A

Synthèse des règles de décision 3-D Secure

Démarrer 3-D Secure en 4 étapes

Etape 1 - mettre en œuvre le service

En fonction de votre cas d’usage, suivez les recommandations d’intégration décrites dans un des chapitres précédents.

Etape 2 - tester le service sur l’environnement recette

Une fois la mise en œuvre des connecteurs WL Sips réalisée, vous pouvez effectuer des tests pour valider votre intégration de WL Sips .

Connecteur Sips Paypage

Données de test
merchantId 201000076690001
clé secrète p64ifeYBVIaRcjaWoahCiw9L8wokNLqG2_YOj_POD4g
version de la clé 1
cartes de test cf page " Cartes de test "

Connecteur Sips Office

Données de test
merchantId 201040040170001
Clé secrète rxSP61eeP_oNi5TxCD7Ngy9YcwC8MLw6OlmFGGcsY54
Version de la clé 1
cartes de test cf page " Cartes de test "

ACS de simulation

Lors de vos tests et en fonction de la carte utilisée, vous êtes redirigé vers notre simulateur ACS 3-D Secure v1 ou notre simulateur ACS 3-D Secure v2.

Sur les pages de simulation de l’ACS 3-D Secure v1, vous pourrez simuler :

  • Une authentification réussie ( holderAuthentStatus = SUCCESS)
  • Une authentification échouée (holderAuthentStatus = FAILURE)
  • Une erreur technique lors de la phase d’authentification ( holderAuthentStatus = ERROR)
  • Un cas ou le porteur n’a pas eu à s’authentifier ( holderAuthentStatus = ATTEMPT)

Sur les pages de simulation de l’ACS 3-D Secure v2, vous pourrez simuler :

  • Une authentification réussie ( holderAuthentStatus = SUCCESS)
  • Une authentification échouée ( holderAuthentStatus = FAILURE)
  • Une erreur technique lors de la phase d’authentification ( holderAuthentStatus = ERROR)
  • Un cas ou le porteur n’a pas eu à s’authentifier ( holderAuthentStatus = ATTEMPT)

Etape 3 - souscrire au service en production

Si votre boutique n’a pas encore été inscrite au service 3-D Secure, vous devez en faire la demande auprès d votre interlocuteur habituel, en indiquant pour quels moyens de paiement le service 3-D Secure doit être activé (CB/VISA/MASTERCARD et/ou AMEX).

Pour le réseau CB, l’activation de l’option 3-D Secure est quasi-immédiate.

Pour les réseaux VISA, MASTERCARD et AMEX, l’activation de l’option 3-D Secure se fait en 2 temps :

  • Etape 1 = enrôlement de votre boutique sur le DS VISA et MASTERCARD, ou AMEX ;
  • Etape 2 = activation de 3-D Secure lorsque l’enrôlement sur les DS est réalisé. A titre informatif, VISA réalise l’enrôlement approximativement en 24 heures, MASTERCARD en 7 jours, AMEX en 3 semaines.

Etape 4 – démarrer et valider le service en production

L’activation du service 3-D Secure est à présent opérationnelle en production.

Afin de vous assurer qu’il n’y a pas de régression, contrôlez l’évolution de votre taux de transformation. Il est normal que le taux de transformation réduise légèrement, mais si vous constatez une réduction importante de votre taux de transformation, avertissez rapidement votre contact habituel, afin qu’il réalise avec vous le diagnostic du problème rencontré.