Contenu
| Sommaire | ||||
|---|---|---|---|---|
|
Plus d'informations
| Extrait |
|---|
Avant-proposCe document a pour objet de guider les clients Monext |
Le principe
Cette page vous permet de guider les commerçants Payline à évoluer en 3DS V2. |
Pour renforcer la protection des acheteurs lors de paiements à distance (online), la directive européenne DSP2 rend obligatoire l'authentification SCA (Strong Customer Authentication) de l'acheteur pour tout paiement électronique qu'il initie.
Ce traitement permet l'échange de données avec le commerçant et l'émetteur afin que ce dernier décide de l'authentification. Dorénavant plus le commerçant envoie de donner au moment de l'authentification, plus les paiements ont des chances d'être autorisés. Ce traitement s'adresse aux commerçants qui ne réalisent pas d'authentification 3DS systématique, néanmois les commerçants qui souhaitent profiter de ce traitement 3DS v2 et transmettre les données acheteurs pourront bénéficier d'un meilleur taux d'acceptation.
La directive sur les Services de Paiement (DSP2) impose l'application de nouvelles normes à appliquer (Regulatory Technical Standards (RTS)) dont une authentification forte (Strong Customer Authentication SCA) lors de paiement en ligne : c'est à dire authentification à 2 facteurs.
En décembre 2020, le 3DS 1.0 ne sera plus supporté.
Chaque transaction 3DS initiée sur Payline devra être transmise à l'ACS (serveur authentification du porteur) par l'intermédiaire du MPI, avec un maximum d'informations concernant le porteur et sa commande pour permettre à l'ACS de décider si une authentification forte (avec challenge) est requise ou non (friction less).
Rappel du 3D Secure
3D Secure est un protocole d'authentification fourni par les systèmes de cartes de crédit.
Le marchand peut demander un mot de passe au consommateur pour confirmer le paiement. Cette procédure permet d'authentifier le consommateur comme étant le porteur de la carte utilisée pour le paiement. Elle permet de renforcer la sécurité et de transférer la responsabilité au consommateur de la carte en cas d'impayé.
L'authentification se fait en deux étapes :
- vérification de l'enrôlement de la carte au système 3D Secure ;
- demande d'authentification du consommateur.
La mise en place de 3D Secure doit permettre aux e-marchands de réduire le montant de leurs impayés dus à la fraude, mais cette procédure réduit également le taux des paiements acceptés.
Pour consulter Périmètre d'application des RTS SCA Interface directe ou Pages Web de Paiement MonextL'interface directe est destinée aux commerçants soucieux de conserver toute liberté dans la mise en place de leur parcours de paiement. A cette fin, ils doivent :
Ces contraintes exigent des compétences et ressources importantes. Ce qui n'est pas le cas avec l'utilisation des Pages Web de Paiement. Dans ce dernier cas, Monext gère tout cela, sans restreindre la liste des cas de paiement.
La version 2 de 3DS en complexifie la mise en œuvre technique. La simplification apportée aux marchands par les Pages de Paiement Monext s'en trouve d'autant augmentée. Ces rappels s'adressent particulièrement aux commerçants utilisant encore l'interface directe et risquant de rencontrer des difficultés insurmontables s'ils ont des capacités sous dimensionnées. Le passage en Page de Paiement Monext est la solution pour ces derniers.
: Transition en 3DS V2 Prérequis
Les étapes de migration
| ||||||||||||||||||||||||||||||||||||
| Extrait | ||
|---|---|---|
| ||
3DS Dynamique / 3DS SélectifLe marchand peut configurer des règles du module antifraude pour basculer des demandes de paiement avec une demande l'authentification du consommateur 3D Secure. |
Le traitement d'authentification
Le commerçant inite une demande de paiement et la banque de l'acheteur va l'authentifier de manière plus sur si les transactions sont dans le périmètre 3DSv2 et si elles ne sont pas exemptées.
1. Hors périmètre
La directive n’impose pas l’authentification forte (SCA) à ces types de transactions. Pour ces transactions, le marchand est responsable en cas de fraude.
| title | Hors périmètre.. |
|---|
Commande par paiement postal et téléphone (MOTO) ;
- Transaction initée par le marchand (MIT) ;
- Transaction avec acquéreur ou émtteur hors europe (OneLeg) ;
- Transaction anonyme (Prepaid);
- Transaction B2B (Business).
| Extrait | ||
|---|---|---|
| ||
1. l'authentification SCA ne s'applique pas lorsque la transaction est réalisée par email ou par téléphone. 2. l'authentification SCA ne s'applique pas lorsque la transaciton est initée par le marchand. Exemple : un abonnement mensuel ou annuel 3. L'authentification SCA ne s'applique pas lorsque la transaction est en dehors de l'europe. Ex. pays de la carte ou pays de l'acquéreur hors Europe. lorsque l'émetteur (la banque du porteur de la carte) ou l'acquéreur (la banque du commerçant) est en dehors de l'espace économique européen. 4. L'authentification SCA ne s'applique pas lorsque la carte utilisée ne possède pas de titulaire. 5.L'authentification SCA ne s'applique pas lorsque la transaction est réalisée avec une carte Entreprise. |
2. Exemptions
Pour permettre une meilleure expérience utilisateur, la directive prévoit les exemptions suivantes. Si une demande d’exemption est acceptée, le marchand est responsable en cas de fraude.
| title | Les exemptions.. |
|---|
Montant < 30 € (LOWVALUE)
- Risque faible / TRA
- Paiement récurrent (REC)
- Bénéficiare de confiance (WHISTELIST)
| hidden | true |
|---|
1. L'authent SCA ne s'applique pas lorsque le montant de la transaction est inférieure à 30 euors et que le nombre cumulé de transaction quotidien n'excède pas 5 ou 100 euors.
2. R i s q u e F a i b l e / T R A L’ a u t h e n t i fi c a t i o n S C A n e s ’ a p p l i q u e p a s l o r s q u e l a t r a n s a c t i o n p r é s e n t e u n r i s q u e f a i b l e e t u n m o n t a n t < a u s e u i l a c q u é r e u r ( e n t r e 1 0 0 € e t 5 0 0 € ) : l'exemption n'est pas systématiquement accordée. |
3. Frictionless
Le commerçant pourra demander un traitement Frictionless pour éviter l'authentification basé sur un scoring ou l'envoi de données supplémentaires afin de bien identifier l'acheteur.
Plus d'information : 3DSv2 - Augmenter le frictionless
4. Challenge
Vous pouvez également challenger la demande de paiement en excluant ou en demandant l'authentification de l'acheteur.
La banque de l'acheteur pourra valider ou vous demandez de refaire une demande de paiement avec authentification.
Réaliser un verifyEnrollment avec l'object Object - threeDSInfo en indiquant les Codes - ChallengeInd
Intégration en page Web
En page web, vous devez appeler le contrat (Alias) du moyen de paiement avec le service doWebPayment et récupérer le résultat avec le service getWebPaymentDetails.
Le marchand doit utiliser une version de web service Payline Monext supérieure ou égale à 21 pour bénéficier des nouvelles fonctions liées au 3DS V2.
Plus d'information 3DSv2 3DSV2 - Interface PageWeb
Intégration en mode direct
Le commerçant peut préciser le mode d'authentification qu'il souhaite voir appliquer à cette transaction avec l'object ThreedsInfo et transmettre le score CB.
En mode direct, vous devez gérer la vérification de l'enrôlement avec le service verifyEnrollment puis réaliser la demande de paiement avec le service doAuthorization.
Plus d'information 3DSv2 - Interface Directe - Authentification et Autorisation
| Extrait | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||
spec : 3DSV2 > Introduction et rappel du contexte
Rec 1 TR ? balise 3DS methode ? VerifyAuthentification seule ? => recup les données av car 5 sec entre les deux verifyEnrol |
| Extrait | ||
|---|---|---|
| ||
Le module de Lutte contre la fraudeVous devez consulter le module de lutte contre la fraude afin de gérer les règles et les actions à mettre en place. |
Pages associées
| Contenu par étiquette | ||||||||
|---|---|---|---|---|---|---|---|---|
|