Authentification 3-D Secure : Amorcée par le demandeur
3-D Secure 2.2 est un protocole d’authentification de paiement d’EMVCo conçu pour réduire la fraude avec carte absente en évaluant le risque en fonction des données de la transaction et de l’appareil, tout en prenant en charge d’autres mesures d’atténuation du risque, telles qu’une contestation du titulaire de carte. Dans certains cas, l’utilisation de 3-D Secure pour vos transactions transfère la responsabilité pour certaines rétrofacturations en raison d’une fraude liée à une transaction avec carte absente. Vous pouvez alors utiliser votre compte de commerçant pour fournir des biens et services avec assurance.
1. Activation de la fonctionnalité 3-D Secure
Service de soutien aux ventes de Moneris
Service de soutien aux ventes de Moneris
Pour activer la fonctionnalité de transaction Visa Secure, Mastercard Identity Check ou American Express SafeKey, appelez le service de soutien aux ventes de Moneris pour que Moneris vous inscrive au programme et active la fonctionnalité dans votre compte.
2. Processus amorcé par le demandeur (3RI)
Dans un processus amorcé par un demandeur 3DS, le titulaire de carte ne déclenche pas directement le processus de transaction par l’entremise de l’expérience du navigateur comme plus haut. Il se peut que la transaction soit amorcée à l’extérieur du protocole 3DS, notamment par la poste ou en appelant le commerçant (connu comme commande postale et téléphonique), ou il se peut que le commerçant traite un paiement périodique ou par versements au nom d’un titulaire de carte et de son abonnement. Le commerçant peut aussi avoir besoin d’une authentification de non-paiement dans le cadre de la transformation de la carte en jeton à des fins d’utilisation ultérieure.
S’il s’agit d’une authentification de paiement lié à une commande postale ou téléphonique, l’ACS peut déclencher une authentification découplée entre l’émetteur et le titulaire de carte (voir la section Authentification découplée).
Si le paiement de suivi provient d’une transaction 3DS authentifiée précédemment, vous pouvez inclure les renseignements de l’authentification précédente pour faire le lien avec l’authentification précédente et améliorer les chances d’obtenir un résultat réussi.
Les processus 3RI n’ont pas d’interaction directe avec le titulaire de carte. Le commerçant envoie sa requête <threeDSAuthentication> en suivant les étapes 3 et 4, mais il doit inclure les champs supplémentaires pour décrire son utilisation 3RI.
Votre serveur peut utiliser les champs du canal de l’appareil (device_channel), de l’indicateur RI (ri_indicator) et de la catégorie de message (message_category) pour informer Moneris si le serveur de votre commerçant tente d’utiliser le processus amorcé par le demandeur 3DS.
3. Authentification découplée
La variable ”
threeDSecureDecoupledRequestIndicator” est “true”.La variable ”
threeDSecureDecoupledRequestAsyncUrl” est requise et informe les systèmes de Moneris de l’emplacement où envoyer la requête POST contenant les résultats d’authentification découplée de façon asynchrone.
Pour les scénarios qui ont une authentification 3RI qui nécessite une contestation, au lieu d’avoir une requête et une réponse de contestation standard, l’ACS authentifie le titulaire de carte à l’extérieur du protocole 3-D Secure, notamment dans une application bancaire ou un message texte envoyé au titulaire de carte. Le serveur 3DS de Moneris attend que l’ACS authentifie le titulaire de carte. Cette authentification peut prendre jusqu’à 7 jours. Puisque ce processus est basé sur une action du titulaire de carte à l’extérieur du processus 3DS, il a lieu de façon asynchrone par rapport au traitement des transactions.
Votre serveur peut indiquer dans la requête que vous voulez permettre une authentification découplée en utilisant l’objet “threeDSecureDecoupledRequestInformation” avec :
4. 3DS Authentication
L’authentification 3DS avec 3RI valide l’identité du titulaire de carte sans la participation de celui-ci à l’amorce de la transaction.
Vous pouvez amorcer la requête d’authentification 3DS par l’entremise d’une requête POST auprès de l’endpoint (point de terminaison) /three-d-secure/card-authentications de l’API de Moneris. Un certain nombre de champs pour cet endpoint (point de terminaison) sont conditionnels en fonction d’un scénario 3RI.
Il faut inclure “
threeDSecureDeviceChannel” = “THREE_D_SECURE_REQUESTOR_INITIATED”. Ceci indique que vous authentifiez une transaction amorcée par le commerçant. Vous devez ajouter le cas d’utilisation de cette authentification dans le champ “threeDSecureRequestorInitiatedIndicator”.Pour une authentification amorcée par le titulaire de carte, consultez plutôt la page Authentification 3-D Secure : Navigateur.
Si vous choisissez de permettre une authentification découplée, ajoutez l’objet “
threeDSecureDecoupledRequestIndicator”.S’il y avait une authentification précédente avec 3-D Secure pour ce titulaire de carte, dans le cadre d’une série de transactions, ajoutez l’objet “
threeDSecurePriorAuthenticationInformation”S’il s’agit d’une série de transactions périodiques, ajoutez les variables ”
threeDSecureRecurringFrequency” et ”threeDSecureRecurringExpiry”. L’objet ”threeDSecurePriorAuthenticationInformation” est requis dans ce scénario.
S’il s’agit d’une authentification de paiement lié à une commande postale ou téléphonique, l’ACS peut déclencher une authentification découplée entre l’émetteur et le titulaire de carte (voir la section Authentification découplée). Vous pouvez choisir de permettre une authentification découplée afin d’améliorer les chances d’obtenir des résultats réussis avec la variable “
threeDSecureDecoupledInformation”.Si le paiement de suivi provient d’une transaction 3DS authentifiée précédemment, vous pouvez inclure la variable "
threeDSecurePriorAuthenticationInformation" pour faire le lien avec l’authentification précédente et améliorer les chances d’obtenir un résultat réussi.Lorsque 3RI est utilisé pour une série de transactions périodiques avec “
threeDSecureRequestType” =RECURRING, cet objet d’authentification précédente est obligatoire, et vous devez inclure les variables "threeDSecureRecurringFrequency” et "threeDSecureRecurringExpiry”.
Omettez les champs suivants puisqu’ils sont réservés pour les authentifications par l’entremise d’un navigateur : "
threeDSecureRequestType", "threeDSecureNotificationUrl", "threeDSecureCompletionIndicator", "threeDSecureChallengeRequested", "threeDSecureChallengeWindowSize", "browserUserAgent", "browserJavaEnabled", "browserScreenHeight", "browserScreenWidth" et "browserLanguage".
Les processus 3RI ne commencent pas par une interaction directe avec le titulaire de carte. Le commerçant envoie sa requête POST de création d’authentification, qui comprend les champs supplémentaires, pour décrire son utilisation 3RI et omettre les champs liés exclusivement au navigateur.
Exemples d’authentification 3DS
5. Conclusion du paiement
Avec les résultats de votre authentification 3DS, vous pouvez maintenant passer à l’étape du paiement de façon sécuritaire. Suivez les instructions d’un processus de paiement (une étape, deux étapes associées à d’autres scénarios de paiement) et ajoutez ce qui suit :
Pour la variable “
ecommerceIndicator”, mettez la valeur de votre authentification 3DS.Mettez l’objet facultatif “
threeDSSecureData” avec ce qui suit :la variable “
threeDSecureAuthenticationValue” de l’authentification 3DS;la variable “
threeDSecureServerTransactionID” qui correspond à votre authentification 3DS.
Processus de paiement
Renseignements additionnels
Définitions de l’API
Consultez les endpoints (points de terminaison), les formats des demandes et des réponses, ainsi que les modes d’authentification de ce scénario.
.svg)