> Fraude 3D Not Enrolled… CQFD

Publié par   : Olivier le  : 31 août 2009

• In: e-commerce | Pecheur.com | Sécurité | Transactions
• Commentez !

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 !

Tags : 3D secure, CB, e-commerce, fraude, Impayé, Responsabilité