Article

Observations, R.D.C.-T.B.H., 2011/4, p. 292-296

OPERATIONS BANCAIRES
Carte bancaire - Transaction en dehors de la présence du titulaire de la carte de crédit - Risque de fraude à charge de l'affilié au système de payement
Lorsque, dans le cadre d'un système de payement par cartes de crédit, un affilié a conclu séparément un contrat de licence avec l'entreprise qui l'a affilié et celle qui fournit le logiciel informatique permettant la transmission des données, ledit affilié ne peut faire grief à la première de ne pas avoir procédé à des vérifications non prévues dans le contrat, notamment quant à l'identité du titulaire d'une carte de credit utilisée pour une commande à distance.
BANKVERRICHTINGEN
Bankkaart - Betalingstransactie zonder aanwezigheid van de houder van de kredietkaart - Frauderisico gedragen door de handelaar
Wanneer, in het raam van een betalingssysteem met kredietkaarten, een geaffilieerde afzonderlijke overeenkomsten heeft afgesloten met het bedrijf dat hem heeft geaffilieerd en het bedrijf dat instaat voor het computerprogramma waarmee de betalingsgegevens worden doorgegeven, kan die geaffilieerde het eerste bedrijf niet verwijten dat het niet is overgegaan tot verificaties waarin het contract niet voorziet, namelijk met betrekking tot de identiteit van de houder van een kredietkaart die is gebruikt voor een bestelling op afstand.

1.La société SIG a conclu un contrat d'affiliation avec BCC en 1996 pour pouvoir accepter les paiements par carte de crédit. Dans le courant de l'année 2004, plusieurs transactions par fax ont eu lieu. Ces transactions s'étant avérées frauduleuses, elles ont été contestées par les titulaires légitimes des cartes de paiement. Concrètement, les titulaires de cartes se sont plaints auprès de leurs banques, qui se sont adressées à BCC, qui, à son tour, a enjoint SIG de produire une preuve de l'autorisation de ces transactions par les titulaires de carte. SIG ne pouvant apporter cette preuve, BCC a été débitée par les banques émettrices étrangères, qui ont à leur tour remboursé les titulaires de carte en application des 'Rules and Regulations' de Visa et de MasterCard; ensuite BCC a débité le compte interne de SIG des montants concernés, en application des clauses du contrat d'affiliation ('charge back'). SIG a contesté cette mesure et a refusé de rembourser le montant correspondant, aussi BCC a-t-elle cité SIG en justice pour en obtenir le paiement.

En justice, SIG a contesté le bien-fondé de la demande de BCC, au motif que BCC lui aurait imposé l'encodage de données à distance dans un logiciel fourni par Ogone, et que BCC avait autorisé le paiement ce qui équivaudrait à une garantie de paiement de la part de BCC. SIG n'avait pas appelé Ogone à la cause (nous verrons cependant plus loin que sa solution ne présente pas de défaut), ni son client qui avait fait le paiement frauduleux.

Le premier juge suivit l'argumentation de SIG et déclara l'action en paiement de BCC non fondée. En application du principe de l'exécution de bonne foi des conventions, dit en substance le premier juge, BCC ne peut faire supporter par le commerçant affilié, qui a respecté toutes ses obligations contractuelles, les risques de malversations dont le premier juge considéra qu'elles avaient été rendues possibles, par suite de l'insuffisance du système de vérification mis en oeuvre par BCC [1].

Ce jugement fut réformé en appel, et la cour d'appel donna raison à BCC. La cour d'appel releva que la société Ogone était une partie tierce avec laquelle le commerçant affilié avait conclu un contrat distinct. Après une analyse approfondie des faits, la cour releva que le recours aux services d'Ogone n'était aucunement imposé par BCC, plusieurs alternatives s'offrant à SIG qui avait contracté directement avec Ogone. La cour jugea par ailleurs que BCC n'avait commis aucune faute, et qu'aucun manquement à l'exécution de bonne foi des conventions n'avait été établi dans le chef de BCC. La cour condamna SIG à payer à BCC le montant correspondant aux transactions contestées, en application des conditions du contrat d'affiliation, sous réserve d'une réduction du taux d'intérêts contractuels, jugé excessif.

2.Pour pouvoir réaliser un paiement électronique, de nombreux acteurs interviennent: outre le titulaire de carte et le commerçant qui accepte le paiement par carte, il y a la banque émettrice de la carte (ici des banques étrangères), la société (BCC) qui affilie le commerçant (SIG), le fournisseur du terminal de paiement, parfois un fournisseur de logiciel de paiement (Ogone), des sociétés informatiques qui assurent le processing des transactions, …

L'interaction de tous ces intervenants est régie par un ensemble de règles et de procédures, sous le contrôle d'organisations internationales responsables de la marque de paiement électronique, les schémas de paiement (Visa et MasterCard). Le fonctionnement d'un schéma de paiement est complexe, et requiert l'imposition d'un ensemble cohérent et transparent de règles [2]. Ces règles sont imposées par les schémas par voie de licences, et les titulaires de licences les répercutent contractuellement à leurs cocontractants, de sorte que tout se tient. Elles portent notamment sur la gestion de procédures de traitement de litiges potentiels entre les différents intervenants.

BCC [3] est titulaire de licences de Visa et MasterCard. Ces licences autorisent BCC à affilier des commerçants aux réseaux de Visa et de MasterCard [4], et, partant, de leur proposer des contrats d'affiliation qui leur permettront d'accepter les cartes Visa ou MasterCard comme moyen de paiement.

Les licences de Visa et de MasterCard imposent à BCC le respect d'une série de contraintes contractuelles. Ainsi, lorsqu'un titulaire de carte conteste une transaction de paiement électronique effectuée avec sa carte de crédit, et en l'absence de preuve d'authentification de la transaction (par exemple: signature de la transaction par une carte à puce après vérification du code secret), BCC devra créditer la banque du titulaire de carte du montant correspondant [5]. Nous verrons plus loin que cette preuve est facile à fournir lorsque la transaction se fait en présence du titulaire de carte ('face to face payment') avec les technologies récentes que sont la carte à puce combinée avec la vérification du code secret. La situation devient plus complexe lorsque la transaction de paiement s'opère à distance, et particulièrement lorsque la transaction ne se fait pas en ligne (Internet) mais par simple fax, comme ce fut le cas en l'espèce.

BCC n'a aucun lien contractuel avec le titulaire de carte. Ce dernier formulera donc sa réclamation auprès de sa banque, qui la transmettra, via le schéma de paiement, à BCC pour suite utile. La banque quant à elle est titulaire d'un autre type de licence de Visa et de MasterCard [6], qui comporte l'autorisation pour la banque d'émettre ce type de cartes de crédit, moyennant également toute une série de contraintes contractuelles (voy. le schéma page suivante).

Ainsi, les conditions d'affiliation proposées par BCC stipulent très clairement que BCC peut débiter le compte interne du commerçant dans certains cas particuliers, et notamment lorsque le titulaire de carte conteste la vente, la livraison de marchandise ou l'exécution des services. Les cours et tribunaux ont à de très nombreuses occasions confirmé ce droit contractuel de BCC [7]. Pour l'application de cette clause, il n'est pas requis que le commerçant ait commis une faute.

3.Pour une bonne compréhension du problème, nous devons faire une première digression technique sur le déroulement d'une transaction de paiement par carte de crédit, ce qui nous permettra de rectifier d'emblée certaines erreurs d'appréciation dans le premier jugement.

On distingue plusieurs types de transaction de paiement par carte de crédit. Les transactions classiques se font dans un point de vente, en présence du commerçant et du titulaire de carte [8]. Mais d'autres transactions se font en l'absence du titulaire de carte, notamment si le commerçant accepte des commandes du type téléachat soit par courrier, téléphone, fax ou e-mail [9], ou encore s'il accepte des commandes sur son site Internet.

Le commerçant demande une autorisation à BCC (via l'équipement dédié à l'acceptation de paiement par carte bancaire), qui transmet cette demande d'autorisation à la banque qui a émis la carte, qui effectue alors un contrôle au niveau de la carte. L'émetteur vérifiera si, au moment de la demande, (i) la carte est authentique (par exemple: au moyen de la signature unique pour chaque transaction générée par une carte à puce), (ii) la carte n'est pas expirée, (iii) aucune opposition n'a été formulée contre la carte [10] et (iv) la limite d'utilisation de la carte n'a pas été atteinte. Lorsque ce contrôle a été exécuté, la réponse est envoyée à BCC qui à son tour envoie au commerçant un code d'autorisation ou de refus.

Si la transaction se fait en présence du titulaire de carte (transaction dans un point de vente classique 'face to face'), le commerçant ou le titulaire de carte passera la carte dans un terminal de paiement: la lecture de la puce électronique permet d'authentifier la carte, l'introduction par le titulaire de son code PIN permet d'authentifier le titulaire de carte.

Si la transaction se fait en l'absence du titulaire de carte (paiement à distance) - dans le cas qui nous occupe, c'était par fax - c'est le commerçant lui-même qui assure la transmission des données. Rappelons qu'une des problématiques majeures du paiement à distance est l'identification et l'authentification du porteur de carte, par opposition au paiement de proximité ('face to face') où le porteur va utiliser son instrument de transfert électronique de fonds et va s'authentifier sur le terminal du marchand, en général en présence du marchand. Deux possibilités s'offrent au commerçant: (i) soit il introduit les données manuellement dans un terminal de saisie classique [11], (ii) soit il transmet les données par ordinateur (terminal de saisies virtuel). Le choix entre la saisie manuelle des données et l'utilisation d'un terminal virtuel pour la saisie des données incombe au commerçant, ainsi que le choix du fournisseur de logiciel de paiement, où le commerçant est également en présence de plusieurs alternatives commerciales. Notons que quelle que soit la solution retenue par le commerçant, celle-ci doit respecter les règles établies par les schémas de paiement (MasterCard et Visa); l'organisme en charge de l'affiliation du marchand (ici BCC) doit s'assurer que c'est bien le cas. En l'occurrence, SIG avait opté pour la transmission des données par ordinateur, et SIG avait sélectionné le fournisseur Ogone [12]. C'est à tort que le premier juge avait considéré que c'était BCC qui aurait fait intervenir Ogone, Ogone étant un fournisseur de services sélectionné et contracté par le commerçant.

Lors de l'exécution d'une transaction de paiement à distance, Ogone demande les renseignements suivants: numéro de la carte, date d'expiration de la carte, montant de la trans­action et devise. Ogone permet au commerçant d'enregistrer, de manière facultative, des données complémentaires telles le nom et le prénom du titulaire de carte. Il est clairement indiqué que ces données sont facultatives. Elles ne seront pas transmises à BCC car elles ne sont pas requises pour obtenir l'autorisation de la transaction par l'émetteur de la carte et les interfaces techniques entre banque du commerçant et banque du titulaire de carte mis à disposition par les schémas de paiement ne prévoient pas le transfert de ces informations. Le contrat d'affiliation que le commerçant a signé avec BCC ne requiert d'ailleurs pas la communication du nom ni du prénom. Ceci étant, on comprend que le nom et l'adresse du titulaire sont des données qui présentent néanmoins un intérêt pour le commerçant qui devra envoyer les marchandises à son client. Le logiciel Ogone transmet les données de la carte (numéro, date d'échéance et montant de la transaction) à BCC. Sur base de ces informations, BCC enverra une demande d'autorisation à la banque qui a émis la carte; puis elle enverra un code d'autorisation ou un refus d'autorisation au commerçant. Si c'est un refus, le commerçant ne pourra pas exécuter la transaction. Si c'est une autorisation, le commerçant devra confirmer la transaction afin d'accepter le paiement par carte de crédit.

A l'obtention du code d'autorisation, on n'a pas la certitude que le client du commerçant est le titulaire légitime de la carte et qu'il est réellement présent lors de l'exécution de la transaction et approuve celle-ci. La situation serait différente s'il s'agissait d'une transaction de paiement sur Internet (e-commerce) avec authentification forte du titulaire qui sera invité à valider le montant de la transaction et à introduire des éléments (mot de passe dynamique, code d'authentification envoyé par la banque sur son GSM, code sécurisé généré par un équipement dédié fourni par sa banque, etc.) permettant à sa banque émettrice de s'assurer de l'acceptation réelle de la transaction par le titulaire.

Mais en l'occurrence, il s'agit d'une simple commande par fax, dès lors sans authentification du titulaire de carte. Tout commerçant connaît ou doit connaître les risques liés à l'acceptation d'un paiement électronique sans authentification du titulaire de carte [13]. Le cas échéant il lui revient de se retourner contre son client, le titulaire de carte. Contrairement à l'hypothèse prise par le premier juge, l'attribution d'un code d'autorisation dans ce cas n'implique pas de garantie de paiement de la part de BCC [14]. Le paiement exécuté par BCC après autorisation d'une transaction est toujours sous réserve. Contractuellement, BCC se réserve expressément le droit de débiter le compte du commerçant en cas de contestation par le titulaire de carte, ce qui est pratique courante dans le secteur [15]. Rappelons que le titulaire de carte pour sa part est protégé par les lois sur les pratiques de commerce en matière de vente à distance et par la nouvelle loi du 10 décembre 2009 relative aux services de paiement [16].

4.En l'espèce, lorsque les transactions seront contestées, il s'avérera que les noms des titulaires de cartes ne correspondaient pas aux noms que SIG avait communiqués (mention facultative) à Ogone. SIG reprochera à BCC d'avoir mis en place 'un système qui incite à la fraude', en limitant délibérément les contrôles (ne pas demander le nom) et le premier juge suivra son argumentation.

Nous avons déjà vu que le système de saisie des données critiqué a été mis en place par Ogone, fournisseur d'un logiciel librement choisi par SIG, et non pas par BCC. Nous verrons à présent qu'il a été injustement critiqué, ce système ne présentant pas de défaut.

La cour d'appel confirmera que l'on ne peut reprocher à BCC de ne pas avoir relevé que les noms des titulaires renseignés différaient de celui des titulaires réels, qu'il n'est pas établi qu'elle aurait failli dans l'exercice de ses contrôles tout comme il n'est aucunement établi que les données auraient été détournées au profit de tiers auxquels elles n'étaient pas destinées. BCC a en effet de bonnes raisons de ne pas exiger du commerçant de transmettre le nom du titulaire de la carte, et de ne pas utiliser cette donnée pour opérer ses contrôles.

D'abord, parce que la transmission du nom n'est pas une donnée relevante en la matière de prévention ou de lutte contre la fraude [17]. En effet, à supposer que le nom pouvait être transmis et vérifié (et nous verrons plus loin que ce n'est même pas le cas), il suffirait que le fraudeur communique le nom du véritable titulaire de carte (souvent imprimé sur la carte) pour faire une commande frauduleuse.

Ensuite, il est important de souligner que BCC est soumise à la loi sur la protection des données personnelles [18]. Comment pourrait-elle en pratique recueillir l'accord de tous les titulaires de cartes, afin d'être autorisée de traiter leurs données personnelles? Rappelons que BCC n'a aucun lien contractuel avec les titulaires de carte, qu'ils peuvent provenir du monde entier, ce qui rend la difficulté de l'obtention des autorisations absolument insurmontable. Par ailleurs, BCC est connectée à de nombreux réseaux internationaux et également à des réseaux présents dans des pays qui ne sont pas membres de l'Union européenne et qui ne connaissent pas un niveau de protection adéquat.

Rappelons que les protocoles techniques permettant la communication avec Ogone ne permettent pas la communication de ces données, et que le système d'Ogone est utilisé par un grand nombre de banques belges et étrangères, non seulement pour les paiements avec Visa ou MasterCard mais également pour un grand nombre d'autres schémas de paiement. Le fait de ne pouvoir transmettre le nom et le prénom est une caractéristique inhérente au système Ogone, mais également à tous les autres systèmes similaires disponibles sur le marché, et n'est en aucun cas un vice ou un défaut.

5.En conclusion, le partage des risques de l'utilisation frauduleuse de la carte entre les différents intervenants est réglé de manière contractuelle, dans le respect des règles établies par les schémas de paiement. Les dispositions contractuelles ne font que refléter la réalité économique sous-jacente, qui est à qualifier de mandat d'encaissement [19]. En effet, lorsque le titulaire de carte souhaite utiliser sa carte de crédit pour payer un achat chez le commerçant, il donne instruc­tion à la banque (émettrice ou 'issuer') de payer le commerçant. Quant au commerçant, il donne mandat à BCC ('acquirer') pour encaisser le montant de la transaction; en l'absence d'un titre valable, tel par exemple un paiement autorisé avec le code PIN, BCC n'a pas de titre pour encaisser les fonds auprès du titulaire de carte et, partant, doit pouvoir récupérer les montants qu'elle a avancés.

Dans le cas qui nous occupe, l'autorisation du paiement n'implique pas une garantie de paiement de la part de BCC. Il s'agit d'une autorisation pour le commerçant de procéder à la transaction par carte de crédit, sous réserve.

Faut-il en déduire que l'acceptation d'un paiement par carte de crédit pour des transactions à distance est très risquée pour le commerçant qui en fera toujours les frais en cas d'une fraude éventuelle? La réponse est négative. Relevons d'abord que SIG était affiliée depuis 1996, et que le cas qui nous occupe s'est produit seulement en 2004; les cas de fraude restent heureusement relativement rares. Les schémas de paiement ne badinent pas avec la sécurité et le système est fiable.

Pascale De Jonckheere

General counsel Atos Wordline

[1] Comm. Bruxelles 31 mars 2006, non publié.
[2] P. Bellens, “Aspects généraux du paiement électronique par carte bancaire” in Aspects juridiques du paiement électronique - Juridische aspecten van elektronische betaling, T. I, Kluwer, 2004, 23.
[3] 'B.C.C.' ou 'Bank Card Company'. En 2007, BCC a fusionné avec Banksys, et l'entité fusionnée a changé son nom depuis en 'Atos Worldline'.
[4] Dans le jargon l'activité d'affiliation des commerçants est qualifiée d''acquiring'.
[5] Répudiation avec demande de remboursement, dit 'charge-back'.
[6] License 'issuing'.
[7] Comm. Bruxelles (20ème ch.) 7 décembre 2004, RG 564/02, non publié; Comm. Bruxelles (30ème ch.) 4 octobre 2005, AR 04/09664, non publié; Comm. Bruxelles (17ème ch.) 8 janvier 2004, RG 03/01664, non publié; Comm. Bruxelles (11ème ch.) 13 septembre 2007, RG 4387/04; Comm. Bruxelles (14ème ch.) 10 septembre 2007, RG A/05/10.987, non publié; Comm. Bruxelles (7ème ch.) 26 septembre 2007, RG A/03/10468, non publié; Comm. Bruxelles 19 septembre 2005, RG 4505/04, non publié; Comm. Bruxelles (9ème ch.) 11 mai 2005, RG A/01/11.454, non publié; Comm. Bruxelles (30ème ch.) 1er mars 2005, RG 04/00358, non publié; Comm. Bruxelles (30ème ch.) 14 juillet 2004, non publié; Comm. Bruxelles (15ème ch.) 28 novembre 2006, RG 01/08362, non publié; Comm. Bruxelles 4 août 2005, RG A01/14962 et A/02/10536, non publié; J.-P. Bruxelles 25 janvier 2008, RG 20.12.2007, G.01/A785, non publié; Comm. Bruxelles (23ème ch.) 20 décembre 2007, RG A/04.371, non publié; Comm. Bruxelles (18ème ch.) 11 mars 2005, RG 239.04, non publié, confirmé en appel par Bruxelles (4ème ch.) 4 décembre 2007, 2005/AR/1411, non publié; Comm. Bruxelles (29ème ch.) 12 octobre 2007, RG 00/9895, non publié; Comm. Bruxelles (20ème ch.) 14 février 2006, RG 10.235.04, non publié; Comm. Bruxelles (30ème ch.) 1er mars 2005, RG 03/11297, non publié, confirmé en appel par Bruxelles 18 juin 2007, NjW 2007, 935; Comm. Bruxelles (30ème ch.) 11 janvier 2005, RG 03/05738, non publié, confirmé en appel par Bruxelles (8ème ch.) 30 août 2006, 2005/AR/288, non publié; Comm. Bruxelles (16ème ch.) 18 septembre 2005, RG 6569/04, non publié; Comm. Bruxelles (3ème ch.) 5 janvier 2005, RG 7332/2004, non publié; Comm. Bruxelles 16 juin 2006, RG 05/08495, non publié; Comm. Bruxelles (20ème ch.) 5 mars 2007, RG A05/05992, non publié; Comm. Bruxelles (10ème ch.) 1er février 2007, RG A/A04.3928, non publié; Comm. Bruxelles (10ème ch.) 26 avril 2005, RG A/04.04751, non publié, confirmée en appel par Bruxelles 19 juin 2008, DAOR 2009, 167 avec note de A. Vandoolaeghe, “Het aanvaarden van kredietkaarten, een gevaarlijke onderneming voor de handelaar?”, et RDC 2010, 117, avec note de M. Delierneux et J.-P. Buyle; Comm. Bruxelles (25ème ch.) 26 octobre 2004, RG 5513.2003, non publié; Comm. Bruxelles (24ème ch.) 15 juin 2005, 03/09071, non publié; Comm. Bruxelles (25ème ch.) 9 février 2007, RG 4798/06, non publié; Comm. Bruxelles (29ème ch.) 1er octobre 2007, RG 668/05, non publié confirmé en appel par Bruxelles (4ème ch.) 4 novembre 2009, RG 2007/AR/3172, non publié; Comm. Bruxelles (3ème ch.) 22 mars 2005, RG 04/05/085, non publié; Bruxelles 10 mars 2009, Dr.banc.fin. 2009, III, p. 173 avec note R. Steennot “De handelaar als dupe van het frauduleus gebruik van een kredietkaart op afstand”; Bruxelles (8ème ch.) 3 septembre 2008, RG 2004/AR 2611; Bruxelles (8ème ch.) 5 novembre 2008, 2007/AR/846, non publié; Bruxelles (8ème ch.) 21 juin 2006, 2005/AR/586, non publié; Bruxelles (18ème ch.) 27 juin 2006, 2006/5116, non publié; Bruxelles (18ème ch.) 19 décembre 2009, 2006/0409, non publié; Bruxelles (8ème ch.) 16 janvier 2008, 2006/720, non publié; Comm. Malines 19 février 2009, confirmé par Bruxelles 13 septembre 2010, RG 2009/AR/801, non publié; R. Steennot, “Girale en elektronische betalingen, nieuwe wettelijke regeling”, NjW 2010, 518 (voy. p. 529).
[8] Transactions 'PoS' (Point of Sale) ou 'face to face'.
[9] Transaction 'MOTO' (Mail Order, Telephone Order).
[10] Vérification si la carte n'a pas été bloquée par le service que nous connaissons en Belgique comme 'CardStop'.
[11] Plusieurs sociétés fournissent ce type de terminaux telles par exemple Keyware, Veriphone, Thales ou encore Atos Wordline (anciennement Banksys).
[12] DocDataPayment, Bibit, Business2you ou encore la solution Banxafe proposée par Atos Worldline (anciennement Banksys) ou SIPS proposé par Atos Worldline sont des alternatives à la solution proposée par Ogone.
[13] Bruxelles 19 juin 2008, RDC 2010, 117; Bruxelles 10 mars 2009, Dr.banc.fin. 2009, 173 et observations R. Steennot, “De handelaar als dupe van het frauduleus gebruik van een kredietkaart op afstand”.
[14] Bruxelles 30 août 2006, RW 2008-09, 499; Bruxelles 18 juin 2007, NjW 2007, 935; R. Steennot, Elektronisch betalingsverkeer, Intersentia, 2002, 162; R. Steennot, “Juridische problemen in het kader van de elektronische handel”, RDC 1999, p. 674, n° 56.
[15] R. Steennot, o.c., 162 et références citées par lui.
[16] Loi du 10 décembre 2009 relative aux services de paiement (MB 15 janvier 2010) transposant en partie la directive européenne 2007/64/CE du Parlement européen et du Conseil du 13 novembre 2007 concernant les services de paiement dans le marché intérieur; cette loi remplace la loi du 17 juillet 2002 relative aux opérations effectuées au moyen d'instruments de transfert électronique de fonds.
[17] Bruxelles 18 juin 2007, l.c., 936.
[18] Loi du 8 décembre 1992 relative à la protection de la vie privée à l'égard du traitement de données à caractère personnel; voy. aussi Bruxelles 18 juin 2007, l.c., 936.
[19] M. Delierneux et J.-P. Buyle, observations sous Bruxelles 19 juin 2008, RDC 2010, 117; A. Vandoolaeghe, “Het aanvaarden van kredietkaarten, een gevaarljike onderneming voor de handelaar?” (note sous Bruxelles 19 juin 2008), DAOR 2009, 170; R. Steennot, Elektronisch betalingsverkeer, een toepassing van de klassieke principes, Intersentia, 2002, 162.