OliverBlog

Posts Tagged ‘3D secure

pink-pig

Cas d’école que j’attendais (sans impatience excessive) depuis le 1er octobre dernier : un cas de fraude avec une carte « 3D not enrolled ». C’est à dire un paiement frauduleux avec une carte dont le porteur n’a pas été enrollé (inscrit) dans le programme 3D par sa banque. Il restait en juin dernier environ 30% des cartes françaises dans ce cas (selon les chiffres donnés lors de la conférence du GIE CB)

Lors du paiement, le process d’authentification n’est donc pas lancé et le client n’est donc pas mis en rapport avec sa banque, et… il ne lui est pas demandé de s’authentifier…
Dès lors on en revient à la situation d’avant 3DS : une fraude peut « passer »  et/ou  le porteur peut répudier la transaction.

Hors à l’inverse de SIPS, qui fournit le détail des cas des satuts 3D lors de chaque transaction:

3D success (authentification réussie)
3D not enrolled, (authentification non demandée)
3D attempt, (authentification non obligatoire cette fois…)
3D failure,
3D error…

SPPLUS résume ces statuts juste en : paiement garanti : OUI (3D success)
ou Paiement garanti : NON (tous les autres cas)

On pourrait donc imaginer avec ce vocabulaire, plus qu’approximatif, qu’en cas d’impayé le paiement étant simplement indiqué « non garanti » sera renvoyé vers le commerçant…

Hypothèse confirmée par une conversation avec une opératrice de la hotline SPPLUS il y a quelque mois à ce sujet. Comme je m’évertuais à la convaincre que, dès lors que 3D était implémenté sur le serveur du commerçant, le défaut d’authentification renvoyait la responsabilité, selon les statuts, vers la banque du porteur ou vers la banque du commerçant (selon les cas) mais en aucun cas vers le commerçant, la (fort aimable) demoiselle m’expliqu’a qu’en cas de retour impayé, rien n’était prévu pour savoir si la transaction avait eu lieu sur un serveur 3D ou pas et que dans le doute… il était renvoyé… vers le commerçant 😉
– Ben voyons ! me dis-je in petto
Je pensais donc bien voir ce cas se présenter un jour ou l’autre… et je fus servi…

En avril ou mai (je ne sais plus) la gendarmerie m’adresse une réquisition concernant une transaction frauduleuse passée sur notre site en date du 12 novembre 2008 ! La carte utilisée est une carte du Credit Agricole et la transaction s’élève à 316,30 euros…
Je transmets les infos demandées (adresse IP du « client », adresse de livraison etc…) et attends (un peu sournoisement je dois dire) un éventuel avis d’impayé…

Le 14 aout dernier je reçois du centre régional de notre banque l’avis d’impayé daté du 7 août (oauh la Poste !) avec la mention :

Motif du rejet : TRANSACTION VAD NON SECURISEE (SIC !)
Je m’étouffe avec mon croissant et aussitôt mon souffle repris, je décroche mon téléphone pour prendre contact avec le « Responsable du Département Echanges & Monétique » signataire de ma lettre d’impayé… Pas de chance, il est en vacances mais l’un de ses collaborateurs écoute avec bienveillance ma réclamation. En clair : cet impayé ayant eut lieu avec une carte 3D Not enrolled du Credit Agricole, cet impayé doit retourner illico… Vers le Credit Agicole. Il convient de la logique de la chose en regard de la présence sur notre site de la solution 3D secure et du transfert de responsabilité du 1er octobre 2008… et m’annonce qu’il va faire remonter ma demande.

Le 28 aout un mail m’annonce que
« Suite à l’impayé du 7 Août 2009 en objet et après requêtes au niveau national, nous vous informons que cette somme vous est créditée ce jour. »

Ce que la comptabilité me confirme ce matin..

CQFD !

Et bien voilà, le liability Shift est entré en vigueur et, depuis le 1er octobre dernier, le transfert de responsabilité vers la banque du porteur est effectif pour toute transaction par CB avec une carte émise par une banque française. L’occasion de faire un premier petit bilan.

Constatation n° 1 : le sujet passionne et suscite des réactions et des supputations.
Il faut dire que les banques n’ont pas été très bavardes sur le sujet. Tant vers les commerçants que vers leurs clients porteurs de cartes.

Qu’implique donc en réalité ce transfert de responsabilité ?

La réponse est simple :
C’est la banque du porteur de la carte qui est désormais responsable de la transaction. Libre à elle de mettre en place telle ou telle mesure pour authentifier son client. Ne pas mettre en place de contrôle pour vérifier que c’est bien son client qui commande ne l’exonère bien entendu pas de la responsabilité.
Il n’est donc plus possible depuis le 1er octobre, pour un e-commerçant, de se retrouver avec un impayé dès lors que le serveur bancaire qu’il utilise est 3D secure
(c’est à dire qu’il a souscrit l’option auprès de sa banque).
Plusieurs cas de figure sont alors possibles en cas de répudiation ou utilisation frauduleuse :

1 – La transaction validée était signalée « Garantie 3D Secure » >> Pas d’impayé possible
La banque du client a authentifié la transaction. En cas de répudiation elle « se débrouille » avec son client

2 – La transaction a été acceptée mais non garantie 3D Secure >> Pas d’impayé possible.
En effet si elle n’est pas garantie c’est parce que la banque du porteur n’a pas pris les mesures pour la garantir. Elle reste donc responsable en cas de répudiation de son client et « se débrouille » avec lui.
Dans le cas d’une carte non « enrolable 3D Secure » (ancienne génération) le cas est le même, la banque émettrice doit prendre ses disposition pour la faire évoluer.

3 – La transaction est acceptée mais non garantie alors que la banque du porteur avait bien mis en place la validation 3D Secure mais la banque du e-commerçant (pour une raison X) n’a pas demandé la vérification, alors que le 3D Secure est implémenté sur le serveur. Dans ce cas, la responsabilité bascule vers la banque du e-commerçant. Pas vers le e-commerçant ! >>Pas d’impayé possible.

Remarque : lorsqu’une transaction avec une carte FR est acceptée mais non « enrollée 3D Secure », vous ne savez pas si vous vous trouvez dans le cas n°2 ou le cas n°3. Et après tout peu importe !

Rien que de très logique en fait ! Mais comme rien n’était clair et que tout et son contraire circule sur le sujet, j’ai pris soin avant d’écrire ces lignes de faire enquêter un peu un responsable monétique d’une de nos banques pour être affirmatif.

Attention toutefois :

– Si vous n’avez pas souscrit à l’option 3D Secure sur le serveur de votre banque, vous n’êtes pas couvert. (Encore que, mon interprétation sur le sujet serait que votre banque, pour se dégager de la responsabilité qui lui retomberait dessus, devrait normalement vous forcer à l’adopter !)

– Il est possible encore de recevoir encore des impayés pendant un moment mais uniquement pour des transactions effectuées avant le 1er octobre.

– Les cartes étrangères non garanties 3D Secure ne sont pas couvertes. Il n’est en effet pas possible de soumettre à une mesure franco-française une banque étrangère qui reste libre ou pas d’adhérer à un système pas forcément obligatoire dans son pays d’origine. Restez donc vigilants sur le pays d’origine de la carte en cas de livraison en France avec une transaction non garantie !

Et l’aspect commercial dans tout ça ?
Le taux de transactions garanties 3D Secure tourne actuellement (pour notre part) autour des 50% et le pourcentage est sensiblement le même sur les 2 solutions que nous utilisons, SPPLUS (Caisse Epargne) et SIPS (Atos)

Le pop up 3D Secure fait il peur aux clients ? Ont ils des réticences à donner leur date de naissance ?
Je n’ai pas de réponse précise là dessus. Quelques (très peu) appels ou interrogations par mail sur cette nouveauté mais rien de bien significatif. Un indicateur tout de même : pour notre part nous constatons depuis le 1er octobre des taux d’abandon de panier tout à fait conformes à ce qui se passait avant. Pas plus pas moins ! Je pense même que très rapidement cette petite sécurité sera un élément de rassurance.
En tout cas c’est un sacré confort et ça fait gagner un temps précieux !

A lire ailleurs :

Visa et mastercard à la rescousse des e-commerçants sur le JDN


OliverBlog

E-commerce
architectureS
pêche à la mouche
& autres lubies...

Retrouvez-moi sur Twitter

RSS e-commerce JDN

  • Une erreur est survenue ; le flux est probablement indisponible. Veuillez réessayer plus tard.