OliverBlog

Archive for the ‘Sécurité’ Category

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

Comme pas mal de confrères e-commerçants j’imagine, nous avons reçu ce matin, de notre chargé de compte Colisposte un message nous mettant en garde contre l’arrivée possible d’un mail en provenance de support@laposte.fr contenant un cheval de troie (trojan).
Ce mail alerte les clients potentiels (de la Poste) du fait qu’un de leurs colis n’a pas pu être livré et les invite à cliquer sur un fichier zip qui contient une soit disant facture. Ce fichier est en réalité un code malicieux (Zbot.EBA).

Bon déjà, le fait que La Poste prévienne de l’impossibilité de délivrer un colis devrait mettre la puce à l’oreille d’un utilisateur averti des services de Coliposte. Et si cela n’était pas suffisant le message en lui-même (comme souvent dans ce type de cas) sent plutôt mauvais :

Bon matin,

malheureusement, nous avons manque de livrer le pli (votre colis postal), que vous avez envoy le 29er juillet, parce que l’adresse du Destinataire n’existe pas.

S’il vous plait, imprimez la facture envoyee en fichier joint a ce message, et venez chercher le pli a notre office a l’adresse indiquee a la facture.

Consultant Erin Fisher,

La Poste France

Reste que La Poste semble plutôt réactive sur ce coup là et, outre les mails envoyés individuellement (je n’ose penser que nous sommes un cas isolé) depuis ce matin un message est en place sur l’accueil du site Coliposte.net et le détail sur http://www.coliposte.net/corp/services/actu.jsp?idactu=6

Reste qu’au cas où vous n’auriez pas été prévenu, je relaie le message.
Au bout du compte c’est ce qu’on appelle du marketing viral non ? 😉

Étiquettes : , , , ,

A compter du premier octobre prochain, le «Liability Shift» ou transfert de responsabilité, sera effectif en France. Lors d’un paiement à distance, les banques ne pourront plus « se contenter » de valider les transactions elles devront les authentifier…

L’envie d’écrire ce billet m’est venue suite à l’article publié par Daniel concernant la fraude CB et ses implications pour les e-commerçants.
A l’heure qu’il est, et depuis toujours, la situation est la suivante :
la répudiation d’une CB française pèse entièrement sur le e-commerçant français. C’est lui qui au final est « responsable » de l’impayé et qui donc subit la perte suivant un scénario invariable :

  • Un « client » donne en ligne les 3 éléments nécessaires à la transaction CB (N° de la carte + Date de validité, + Crytptogramme visuel).
  • Les serveurs de la banque du client et de la banque du commerçant dialoguent. Si la banque du client répond  favorablement (et dans les temps) la validation (OK) de la transaction est transmise au e-commerçant par le terminal de sa propre banque. La transaction a donc bien été validée par 2 banques : celle du client + celle du e-commerçant. Celui-ci a donc reçu une validation (un feu vert en quelque sorte). « La transaction est OK »
  • Dans les 70 jours qui suivent, le véritable titulaire de la carte s’aperçoit que son compte a été débité à son insu et conteste la transaction (répudiation du paiement) auprès de sa banque.
  • Le client dont la carte a été utilisée de manière abusive est remboursé.
  • La banque du client vient « rechercher » l’argent de la transaction sur le compte du e-commerçant (avec en plus quelques frais pour impayé…).
  • Le e-commerçant supporte entièrement la perte. Charge à lui de porter plainte, de fournir à la justice les éléments en sa possession pour « remonter » au fraudeur… (Je ne parlerai pas ici des résultats de ce type de démarches…)

Les banques ont pourtant, depuis plusieurs années, les moyens de vérifier au moment de la transaction que le « client » est bien le titulaire de la carte qu’il utilise grâce à la technologie 3D-Secure, proposée sous le nom «Verified by Visa» ou sous le label «MasterCard SecureCode».

Le système d’authentification 3D Secure réduit considérablement le risque de fraude et donc de non-paiement suite à  l’utilisation abusive des CB. Le titulaire se retrouve de fait protégé contre l’utilisation abusive de son numéro de carte de crédit car il a du confirmer son identité avant le paiement en donnant un code. Ce code est vérifié en ligne par l’émetteur de la carte (banque du client). Une opération triangulaire qui certifie que la personne qui passe la transaction est bien le titulaire de la carte. Dès lors que la transaction est approuvée et garantie 3D Secure, le transfert de responsabilité s’opére vers la banque du porteur de la carte.

Mais 3D Secure, (opérationnel depuis 2001) est jusqu’à maintenant utilisé partout, sauf en France ! Les banques françaises s’étant montrées particulièrement « frileuses » et « lentes » sur le sujet. En Belgique par exemple le système est actif depuis 2004. Il faut préciser qu’avec 3D Secure, en cas de fraude, la perte se déplace du e-commerçant vers la banque du client. Ce service 3D Secure est bien déjà proposé aux e-commerçants français par les banques françaises sur leurs terminaux de paiement dès lors que… la carte (et donc la banque du client) est étrangère !

Régulièrement, chaque année depuis 2002, on nous annonce la mise en place du système pour les transactions franco-françaises à un horizon proche. Il y a 6 ans (!), le 12 avril 2002 pour être précis,  01.net nous annonçait déjà la bonne nouvelle. Mais c’est l’Arlésienne !

Il semble que pourtant ,cet automne , »ça sera la bonne » ! Et que à compter du 1er octobre prochain les banques françaises devront adhérer au programme.

Effectif sur les transactions internationales depuis plusieurs années, le «Liability Shift» ou transfert de responsabilité ne l’était pas encore pour les opérations en France. Ce sera chose faîte le 1er Octobre 2008. Si une fraude intervient lors d’un paiement par carte sur un site marchand, soit la banque du commerçant est responsable car le terminal est non conforme, soit la banque émettrice si la carte est mise en cause.
Le 1er Octobre, cette règle entrera donc en application pour les transactions domestiques, impliquant de nouveaux risques et des changements pour les banques et notamment, l’adoption du système 3DSEcure.

Extrait du Livre Blanc « Sécuriser le e-commerce » par Xiring (éditeur de solutions de sécurité pour les transactions à distance.

Les banques commencent d’ailleurs à communiquer sur le sujet – pas toutes de la même manière 😉 par exemple :
> La Société Générale
> La BNP ici mais aussi la BNP là
> Ce que fait aussi la plateforme  Paybox

Quelques liens utiles pour ceux qui voudraient en savoir plus :
> Authentificationforte.info
> GIE Cartes Bancaires

Enfin, pour ceux qui voudraient en savoir encore beaucoup plus :
> Conférence LES PAIEMENTS SUR INTERNET A L’HEURE DU « LIABILITY SHIFT » 02 octobre 2008

MAJ : >> 3D-Secure-etat-des-lieux


OliverBlog

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

RSS e-commerce JDN

  • Erreur, le flux RSS est probablement en panne. Essayez plus tard.