logo Sogenactif

Release 22.3

aller directement au contenu

Rechercher par mots clés

3-D Secure

Pour rechercher dans la page utiliser Ctrl+F sur votre clavier

  • Sogenactif

Sogenactif 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 échelonné…).

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

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, Bancontact et AMEX.

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

Pour toute question technique ou demande d'assistance, nos services sont disponibles du lundi au vendredi, hors jours fériés, de 9 h à 19 h :

  • par téléphone au : +33 (0) 825 090 095  (0,15 € TTC/min + prix d’un appel local – Tarif au 01/11/2021)
  • par e-mail : supportsogenactif@worldline.com

Pour faciliter le traitement de vos demandes, veuillez communiquer votre identifiant de commerçant : merchantId (numéro à 15 chiffres).

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: la DSP2 rend obligatoire l’authentification forte pour les paiements sur Internet, des premiers refus émetteurs sont appliqués sur les transactions non authentifiées 3-D Secure (champ acquirerResponseCode = A1).

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 et Bancontact. Lorsque le paiement est garanti, le champ guaranteeIndicator est valorisé à Y.

Pour plus de détails sur les cas d’éligibilité au transfert de responsabilité, veuillez vous référer au paragraphe Calcul du transfert de responsabilité.

Le 3-D Secure s'applique dans les cas suivants :

  • Paiement simple (décrit dans cette documentation)
  • Paiement en plusieurs fois
  • Paiement multiple à l'expédition
  • Paiement par abonnement (via wallet ou via duplication)

Pour améliorer l’expérience utilisateur par rapport à 3-D Secure v1, 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.

En 3-D Secure V2 et pour être conforme à la DSP2 :

  • les paiements échelonné doivent être authentifiés du montant total de l'échéancier (ce n'était pas le cas en 3-D Secure V1 où le montant de l'authentification était celui de la première échéance uniquement).
  • le paiement qui permet la mise en place d'un abonnement doit être authentifié du montant moyen des échéances.
Note: Sogenactif vous permet de spécifier un montant différent de celui à autoriser, via l'utilisation du champs authenticationData.authentAmount.

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. 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 Sogenactif avec l’option 3-D Secure activée par défaut.

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

L’activation de l’option 3-D Secure se fait en 2 temps :

  • étape 1 = enrôlement de votre boutique sur les Directory Servers (CB, VISA, MASTERCARD, AMEX) ;
    • Pour CB et Visa, l'enrôlement est quasiment immédiat
    • Pour MASTERCARD, l'enrôlement est réalisé en 7 jours
    • Pour AMEX, l'enrôlement est réalisé en 3 semaines
  • étape 2 = activation de 3-D Secure lorsque l’enrôlement sur le Directory Server est réalisé :

Afin d’être certain de collecter tous les fonds de vos ventes et d’éviter les impayés, vous avez la possibilité de refuser des transactions éligibles au transfert de responsabilité mais qui n’en bénéficient pas.

En activant cette option, les transactions non garanties (champ guaranteeIndicator = N ou U ou "vide") se verront donc refusées avec un complementaryCode valorisé à 17.

Cette option s’applique uniquement sur les transaction initiées par le porteur (CIT) effectuées avec une carte CB, VISA ou MASTERCARD (enregistrée ou non dans un wallet Sips, Paylib ou Masterpass).

Cette option ne s'applique pas :

  • sur les transactions initiées par le commerçant (MIT)
  • sur les CITs sur lesquelles le transfert de responsabilité n’est pas éligible (transaction Paypal par exemple)
  • sur les CIT sur lesquelles le 3-D Secure n’a pas été effectué (cardOrder sans données 3-D Secure par exemple)

Ce paragraphe décrit comment mettre en œuvre 3-D Secure pour les paiements à l’acte, les paiements à l’acte.


Processus de paiement 3-D Secure avec Paypage. Description textuelle de ce schéma juste en dessous

  1. Vous redirigez le client vers Sogenactif Paypage en communiquant dans la requête les données de la transaction (montant, devise, ..).
  2. Sogenactif affiche la page de paiement, le client saisit le numéro de carte, le cryptogramme visuel, puis valide.
  3. Sogenactif procède à la vérification 3-D Secure.
  4. Sogenactif envoie une demande d’autorisation à l’acquéreur.
  5. Sogenactif enregistre la transaction dans le back office.
  6. Sogenactif affiche la page de ticket de paiement.
  7. Sogenactif 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. Sogenactif 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.

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

Pour proposer le paiement 3-D Secure via Sogenactif Paypage vous n’avez aucun champ spécifique 3-D à renseigner.

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

Sogenactif retourne une réponse manuelle et une réponse Sogenactif Paypage automatique classique . Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.

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
Votre boutique n’est pas enrôlée 3-D Secure.

guaranteeIndicator = non renseigné

holderAuthentMethod = NO_AUTHENT_METHOD

holderAuthentStatus = NO_AUTHENT

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é

holderAuthentMethod = non renseigné

holderAuthentRelegationCode = non renseigné

holderAuthentStatus = non renseigné

holderAuthentType = non renseigné

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.

diagramme montrant la cinématique de paiement via office

1) Vous collectez les informations cartes sur votre la page de paiement hébergée sur votre site web et transmettez ces informations à Sogenactif via la méthode cardCheckEnrollment. 2) Sogenactif vous envoie url de l'ACS. 3) Vous redirigez votre client vers l'ACS. 4) Votre client s'authentifie puis est redirigé vers votre site. 5) Vous collectez les informations d'authentification et envoyez une demande d'autorisation à Sogenactif via la méthode cardValidateAuthenticationAndOrder. 6) Sogenactif vous envoie la réponse de paiement et vous affichez le résultat du paiement à votre client sur votre site.

Si votre boutique n’est pas 3-D Secure, veuillez contacter l’assistance technique de Sogenactif 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.

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.

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

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 Sogenactif la 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 Sogenactif.
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 Sogenactif.
orderChannel Pour les paiements effectués par Internet, valoriser : INTERNET
panType Si vous utilisez le connecteur Sogenactif Office Serveur classique : PAN

si vous utilisez le connecteur Sogenactif Office Serveur 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 Sogenactif interrogera le DS CB ;
  • si vous renseignez VISA, le serveur Sogenactif 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

Si vous souhaitez ajouter la carte dans le wallet Sogenactif à la suite du paiement, alors ce champ doit obligatoirement être valorisé avec «CHALLENGE_MANDATE»

Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.

Cas d’usage Champs de la réponse Action à réaliser
Carte enrôlée 3-D Secure.

responseCode = 00

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.

responseCode = 00

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 Passez à l’étape 5 : demande d’autorisation.
Boutique non enrôlée au programme 3-D Secure. responseCode = 40 Veuillez contacter l'assistance technique de Société Générale.
Transaction invalide

responseCode = 12

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.
Clé secrète ou version de clé invalide

responseCode = 34

redirectionStatusCode = 34
Vérifiez la clé secrète utilisée (champ secretKey) et la version de la clé (champ keyVersion)
Serveur Sogenactif temporairement indisponible responseCode = 99 Vous pouvez soumettre une seconde fois la requête. Si l'erreur persiste, alertez l'assistance technique de Société Générale.

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 Sogenactif Office Serveur JSON pour mettre en œuvre ce message.

A la fin du processus d'authentification, le client est redirigé vers votre site Web 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 Sogenactif Office Serveur 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.

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, Sogenactif ne transmet pas de demande d'autorisation vers votre acquéreur, le paiement est nécessairement refusé.

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, préalablement "URL encodé", 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

Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.

Lex informations ci-dessous ne concernent que l'authentification. Pour les informations sur le paiement, veuillez-vous référer aux documentations des connecteurs Sogenactif Office Serveur.

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
Clé secrète ou version de clé invalide responseCode = 34
Cette opération a déjà été effectuée sur cette transaction. responseCode = 24

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.

image trop complexe pour être décrite, merci de prendre contact avec le support

Si votre boutique ne dispose pas d'authentification 3-D Secure, veuillez contacter l’assistance technique de Sogenactif pour activer le service.

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

Vous initialisez le paiement en faisant appel à la méthode orderInitialize.

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 Sogenactif la force à 6.
sdkOperationName THREEDSECUREANDORDER
challengeMode3DS Indiquez votre souhait d'exemption. Si le champ n'est pas renseigné, le champ est à la charge de l'émetteur.

Lorsque vous recevez la réponse, avant de l'analyser et suivre les conseils du tableau ci-dessous, vérifiez le seal. Le seal recalculé, doit être identique au seal reçu.

Cas d’usage Champs de la réponse Action à réaliser
Initialisation de paiement réussie redirectionStatusCode = 00 Vous affichez l'écran de collecte des coordonnées de paiement dans votre l'application mobile. Vous transmettez à l'application mobile les données nécessaire à la poursuite du paiement :
Requête d'initialisation invalide redirectionStatusCode = 12, 30 Une ou plusieurs données de la requête sont invalides. Consultez le champ redirectionStatusMessage, et corrigez la valeur incorrecte.
Serveur Sogenactif temporairement indisponible redirectionStatusCode = 99 Resoumettez la requête. Si le problème persiste, alertez l'assistance technique de Société Générale.
Transaction dupliquée redirectionStatusCode = 94 Le transactionReference ou le transactionId est déjà consommé par une autre requête de votre boutique. Resoumettez la requête avec une autre référence de transaction.

Vous collectez les données carte du client (numéro de carte, date de validité, cryptogramme visuel) via votre application mobile.

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

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.
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 Sogenactif interrogera le DS CB ;
  • si vous renseignez VISA, le serveur Sogenactif interrogera le DS VISA.
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 authentRedirectionUrl (voir l'étape suivante).
Carte non enrôlée 3-D Secure. redirectionStatusCode = 01 Passez à l’étape 6 : 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 6 : demande d’autorisation.
Boutique non enrôlée au programme 3-D Secure. reponseCode = 40 Veuillez contacter l'assistance technique de Société Générale.
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.
Wallet inexistant ou moyen de paiement inexistant redirectionStatusCode = 25 Vérifier le champ merchantWalletId ou le champpaymentMeanId

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 authentRedirectionUrl. 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 traitant de la redirection vers l’ACS de la documentation Sogenactif In-App pour mettre en œuvre ce message.

A la fin du processus d'authentification, le client est redirigé vers votre application 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 traitant du retour de l’ACS de la documentation Sogenactif In-App 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.

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

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

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
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, préalablement "URL encodé", 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.

Veuillez vous référer à la documentation Sogenactif In-App.

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é.

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, ...), et demander à votre contact Sogenactif habituel d'activer l'option « TRA acquéreur ».

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 non activé sur votre boutique et client authentifié (dans ce cas Sogenactif traduit en demande d'exemption "basique" : fraudData.challengeMode3DS = NO_CHALLENGE) voir chapitre suivant Contactez votre interlocuteur Sogenactif pour ajouter le droit à l'utilisation de cette fonctionnalité
IMPORTANT:

La valeur du champ fraudData.challengeMode3DS peut être surchargée avec la valeur NO_CHALLENGE si :

  • vous n'avez pas demandé l'autorisation à votre acquéreur et n'avez donc pas l'option « TRA acquéreur » activée sur votre boutique
  • l'émetteur est encore en EMVCo 2.1.0 (au lieu de EMVCo 2.2) et que la transaction est réalisée sur le réseau Visa ou Mastercard

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é

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

Champ Valorisation
challengeMode3DS NO_PREFERENCE

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

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

  • 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.
  • Rx - champs Recommandés par le réseau CB et ayant une pertinence majeure pour le scoring du DS CB : ces champs facultatifs ont été identifiés par le réseau CB comme étant très important pour le scoring de la transaction. Ainsi le réseau CB recommande leur alimentation par le commerçant si l’information est disponible. L'ordre d'importance est traduit par le chiffre derrière la lettre R. Les champs les plus importants sont classés en R1 et ainsi de suite.
  • 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 recommandés.

Nom du champ CB Visa Mastercard
billingAddress.city R3 R F
billingAddress.country R3 R F
billingAddress.addressAdditional1 R3 R F
billingAddress.addressAdditional2 R3 R F
billingAddress.addressAdditional3 R3 R F
billingAddress.zipcode R3 R F
billingAddress.state R3 R F
holderContact.lastName R4 R F
holderContact.email R2 R F
holderContact.phone R6 R F
holderContact.mobile R6 R F
holderContact.workPhone R6 R F
deliveryAddress.city R1 R F
deliveryAddress.country R1 R F
deliveryAddress.addressAdditional1 R1 R F
deliveryAddress.addressAdditional2 R1 R F
deliveryAddress.addressAdditional3 R1 R F
deliveryAddress.zipcode R1 R F
deliveryAddress.state R1 R F
deliveryContact.email R2 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 R F
fraudData.merchantCustomerAuthentDateTime F R F
fraudData.merchantCustomerAuthentData F (usage futur) R (usage futur) F (usage futur)
fraudData.challengeMode3DS R R F
fraudData.productAvailabilityDate F R F
shoppingCartDetail.giftCardAmount F R F
shoppingCartDetail.giftCardCurrencyCode F R F
shoppingCartDetail.giftCardCount F R F
fraudData.merchantAuthentScoreValue F A A
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 R5 R F
shoppingCartDetail.shoppingCartTotalQuantity R7 A A

image trop complexe pour être décrite, merci de prendre contact avec le support

En fonction des options complémentaires auxquelles vous avez souscris, Sogenactif applique les règles suivantes :


image trop complexe pour être décrite, merci de prendre contact avec le support

Pour les paiements cartes (CB, Visa, Mastercard) via des acquéreurs français, Sogenactif calcule l’indicateur de transfert de garantie et alimente le champ guaranteeIndicator comme décrit ci-dessous :


image trop complexe pour être décrite, merci de prendre contact avec le support

Pour les paiements cartes (CB, Visa, Mastercard) via des acquéreurs français, Sogenactif calcule l’indicateur de transfert de garantie et alimente le champ guaranteeIndicator comme décrit ci-dessous :


image trop complexe pour être décrite, merci de prendre contact avec le support

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

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

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"

Serveur URL de test
Paypage POST https://payment-webinit-sogenactif.test.sips-services.com/paymentInit
Paypage JSON https://payment-webinit-sogenactif.test.sips-services.com/rs-services/v2/paymentInit
Paypage SOAP https://payment-webinit-sogenactif.test.sips-services.com/services/v2/paymentInit
Données de test
merchantId 201040040170001
Clé secrète rxSP61eeP_oNi5TxCD7Ngy9YcwC8MLw6OlmFGGcsY54
Version de la clé 1
cartes de test cf page "Cartes de test"

Serveur URL de test
Office https://office-server-sogenactif.test.sips-services.com

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).

page de simulation de l’ACS 3-D Secure v1

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).

page de simulation de l’ACS 3-D Secure v2

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).

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é.

Retourner en haut de page Besoin d'aide ?

Besoin d'aide ?

Fermer

Ce site utilise des traceurs pour améliorer votre expérience de navigation, effectuer des analyses et des recherches sur votre utilisation du site web de documentation Sogenactif.
En fermant ce bandeau vous refusez notre utilisation des traceurs sur votre appareil.

Paramètres