Edit History

Bonjour à tous,

Je suis le sujet depuis un moment mais j'interviens car je lis beaucoup de confusion concernant le DSP2.
Comme l'a indiqué Yama, il est tout à fait normal qu'il n'y ait plus de 3D secure (le SMS), n'est plus censé exister dans le cadre de la DSP2.

Le 3D secure v.1 (SMS) reste utilisé dans seulement 2 cas:
1- si votre module stripe n'est pas DSP2 (dans ce cas la transaction est envoyée en 3DS V1 à la banque).
2-  la transaction est envoyées en DSP2 à la banque émettrice de la carte mais celle-ci n'est pas compatible DSP2 ou le client n'a pas encore l'application ou de smartphone biométrique. (dans ce cas c'est stripe qui est censé prendre la décision d'utiliser en secours l'ancien système).

Concrètement, le DSP2 (3D Secure v.2) fonctionne ainsi :
en plus des informations classiques (numéro de carte, nom du porteur, montant), on envoi désormais des infos personnelles sur le client (adresse de facturation, de livraison, téléphone, adresse ip, etc..) ces informations permettent à la banque émettrice d'évaluer le risque de la transaction et c'est désormais elle (et plus vous) qui détermine s'il faut une authentification forte ou non (le fameux sms, mais qui va être délaissé au profit d'une application, de mots de passe, et surtout de données biométriques)
Concrètement, si les données personnelles correspondent à ce que la banque connais du client et de ses habitudes, la transaction sera faite "sans friction", aucune authentification forte n'est nécessaire, ou si le montant est faible, la transaction se fait directement sans sms ni rien d'autre).

Si par contre les données ne correspondent pas (exemple le client fait livrer des fleurs chez sa belle mère, à une nouvelle adresse inconnue de la banque émettrice, ou d'une adresse ip différentes de celle utilisée habituellement), là la banque demande l'authentification forte.
Pour les puristes, sachez que j'ai synthétisé mon explication, car il y a d'autres cas ou l'authentification forte sera demandée, et d'autres cas ou on peut encore basculer sur une authentification 3DS V.1, mais ce serait plus long à expliquer, il y a plein d'articles sur le net détaillant le principe de manière précise).

Donc pour résumer, si tout fonctionne bien, il est normal que le paiement puisse se faire sans sms. C'est justement le but, de sécuriser encore plus le paiement (avec plus d'indicateurs et de données contrôlées) tout en fluidifiant le parcours client (pas de sms ou d'authentification forte si tout indique que c'est bien le porteur de la carte qui tente de faire l'achat).

Malheureusement, et on reviens au sujet du topic, le module stripe de 202ecommerce ne fonctionne pas comme il faut. Puisque outre les doubles facturations (voir sujet en anglais ici => https://www.prestashop.com/forums/topic/1000346-stripe-official-sca-ready%09module-problems/), outre les paiements "incomplets" remontés inutilement (chaque fois qu'un client fait un panier sur votre site), le module ne remonte pas les infos nécessaires à la prise de décision par la banque. pour le DSP2.
Le gros problème c'est que si on envoie à la banque, une transaction dites DSP2 avec des données incomplètes ou erronées, la banque refuse tout simplement le paiement (l'effet inverse de ce qu'on nous dit, à savoir que pour ne pas perdre de paiement il fallait etre compatible DSP2 au 14 septembre...)

Au final sachez également que la France à obtenu il y a 3 semaine un report de la mise en application du DSP2 (de 12 à 24 mois selon les sujets). Il n'y a donc pas du tout urgence à changer votre module stripe !! Laissons le temps à stripe de trouver un autre partenaire plus performant que 202ecommerce, ou laissons le temps à 202ecommerce de sortir un module qui tiens la route. En attendant, n'installer surtout pas de version 2.x.x du module sur un site en production ! (sauf si vous êtes l'un de mes concurrents :-d)