FR2808144A1 - Procede et systeme de paiement electronique - Google Patents

Abstract

Ce procédé de paiement électronique comprend les étapes de : a) génération conditionnelle par un établissement financier, en réponse à une requête dudit client, d'un code unique et non prédictible représentatif d'un bon de paiement (BEP) de valeur maximale prédéterminée,b) transmission dudit code audit client,c) stockage par ledit établissement financier dans un serveur de paiement (SBC) de données représentatives dudit bon, lesdites données représentatives comprenant au moins ledit code, ladite valeur et des données d'identification dudit client, d) transmission par ledit client, à un serveur (ST) de traitement de bon électronique, de données de paiement comprenant ledit code et une somme déterminée, en réponse à une demande de paiement de ladite somme émanant d'un fournisseur (SF), et e) validation conditionnelle, par ledit serveur de paiement (SBC), du paiement de ladite somme audit fournisseur en réponse à la transmission électronique par ledit serveur de traitement (ST) d'une demande de validation dudit bon.

Description

La présente invention concerne un procédé et un système paiement électronique en ligne sur un réseau de communication tel le réseau Internet.

On connaît des instruments de paiement utilisables dans le cadre de l'Internet : le chèque, les cartes de paiement, le porte-monnaie électronique. Le chèque répond mal au contexte de l'Internet, tant ses délais d'acheminement que ses coûts de "compensation" en cas paiement International.

Les porte-monnaie électroniques sont principalement destinés à des paiements de petit montant. Ils doivent être rechargés ce qui immobilise des fonds inactifs pour le porteur, et leur acceptation n'est pas généralisée.

Les cartes de paiement sont bien adaptées au contexte de l'Internet, leur acceptation universelle, par leur traitement électronique, et parce elles permettent des transactions de montant élevé. Toutefois, elles presentent l'inconvénient de reposer sur un numéro de carte est en quelque sorte une clé d'accès à un compte. Elles demandent donc mise en oeuvre de fonctions d'identification et d'authentification du client afin de s'assurer qu'il est bien le titulaire de la carte dont il présente les références. Elles demandent également que ce numéro de carte, référence sensible, soit fortement protégé au cours de sa transmission sur le réseau afin de ne pouvoir être intercepté et utilisé par un tiers malveillant. Des protocoles d'échange sécurisés ont été développés (SSL ; SET). Leur mise en oeuvre est toutefois complexe (elle demande des certificats numériques d'identité), lourde en bande passante, et requiert l'inter-opérabilité des moyens cryptographiques utilisés. De plus la sécurisation apportée ne concerne que la fonction d'échange, mais ces numéros, une fois transmis doivent être stockés dans des systèmes d'information qui deviennent eux la cible des pirates.

C'est ainsi qu'a déjà eu lieu un chantage auprès d'un site Internet sur lequel 300.000 numéros de carte avaient été détournés. Le voleur menaçait ce site de divulguer ces numéros de carte, ce qui portait atteinte à la confiance de ses clients.

De façon beaucoup plus simple, ces numéros de carte sont imprimés sur les facturettes de paiement non protégées (elles restent parfois au fond des caddies de supermarchés ou sur des distributeurs de billets) que des petits voleurs peuvent ainsi très simplement se procurer.

On ne saurait omettre également qu'il existe, sur Internet, logiciels capables produire des faux numéros de cartes bancaires sont acceptés les systèmes de paiement. Ainsi, une fraude massive 0% des paiements) a déjà pu se développer pour le rechargement de télephones mobiles, en utilisant des références de cartes obtenues par ces procédés.

En conclusion, malgré son adaptation au contexte électronique, la carte présente une faiblesse majeure, celle d'un identifiant, dont la protection reste complexe et aléatoire, qui de plus permet de suivre la trace l'activité d'un utilisateur sur l'Internet.

L'invention vise à fournir un procédé et un système qui permettent d'assurer de manière simple et sûre des paiements électroniques ligne, notamment via Internet, tout en limitant le risque financier encouru par l'auteur du paiement dans l'éventualité improbable d'une fraude.

Un autre but de l'invention est de fournir un procédé et un système de paiement électronique sécurisé susceptible de bénéficier de la confiance d'utilisateurs déstabilisés par les incidents auxquels sont sujets les moyens de paiement conventionnels.

L'invention vise également à fournir un procédé et un système de paiement électronique sécurisé qui puissent aisément être mis en oeuvre par tous les acteurs concernés par de tels paiements (banques, commerçants, clients, ... ), indépendamment de la nature de leur activité, de leur localisation géographique, etc.

A cet effet, l'invention a pour objet un procédé de paiement électronique d'un fournisseur par un client via un réseau de communication, caractérisé en ce qu'il comprend les étapes de a) génération conditionnelle par un établissement financier, en réponse à une requête dudit client, d'un code unique et non prédictible représentatif d'un bon de paiement de valeur maximale prédéterminée, b) transmission dudit code audit client, c) stockage par ledit établissement financier dans un serveur paiement de données représentatives dudit bon, lesdites données representatives comprenant au moins ledit code, ladite valeur et des données d'identification dudit client, d) transmission par ledit client, à un serveur de traitement de électronique, de données de paiement comprenant ledit code une somme déterminée, en réponse à une demande de paiement de ladite somme émanant d'un fournisseur, et, e) validation conditionnelle, par ledit serveur de paiement, paiement de ladite somme audit fournisseur en réponse à transmission électronique par ledit serveur de traitement d'une demande de validation dudit bon.

Ainsi, aucune "clé de compte" ne circule sur le réseau. La confidentialité nécessaire lors des échanges entre le client et le fournisseur est allégée puisque le besoin est réduit à la résistance de quelques secondes à une attaque : le délai entre l'envoi du bon électronique de paiement par le client et sa présentation à l'établissement financier.

Selon caractéristique de l'invention, lesdites données de paiement comprennent données d'identification dudit fournisseur, ledit code et ladite somme, ledit serveur de traitement contrôle l'identité dudit fournisseur en réponse à la réception desdites données de paiement, transmet conditionnellement ladite demande de validation audit serveur de paiement, en fonction du résultat dudit contrôle, et transmet électroniquement audit fournisseur une information de validation de paiement de ladite somme en réponse à ladite validation dudit bon par ledit serveur de paiement.

De préférence, ladite étape d) comprend d1) la transmission électronique, dudit fournisseur audit client, d'une facture électronique comprenant ladite somme et des premières données d'identification dudit fournisseur et de ladite facture, d2) la transmission électronique de ladite facture dudit client audit serveur de traitement en réponse au choix par ledit client son reglement par un bon de paiement électronique, d3) contrôle de l'identité dudit fournisseur par ledit serveur de traitement au moyen desdites premières données d'identification réponse à la réception de ladite facture, d4) la construction et la transmission électronique audit client, par ledit serveur de traitement, d'un formulaire de paiement en réponse à la validation dudit contrôle de l'identité dudit fournisseur, ledit formulaire de paiement comprenant ladite somme et des secondes données d'identification dudit fournisseur et de ladite facture, et d5) l'introduction dudit code dans ledit formulaire par ledit client pour constituer un message de paiement, ledit serveur de traitement transmettant ladite demande de validation audit serveur de paiement en réponse à la réception dudit message de paiement. Selon une autre caractéristique de l'invention, ladite étape e) comprend la mise en oeuvre par ledit serveur de paiement des opérations de e1) comparaison du code reçu dudit client via ledit serveur de traitement avec ledit code stocké à l'étape c), e2) vérification que le bon représenté par ledit code stocké n'a pas été utilisé antérieurement, et e3) comparaison de ladite somme à ladite valeur stockée à l'étape c). Selon une autre caractéristique de l'invention, - lesdites étape a) et c) comprennent l'attribution et le stockage par et dans ledit serveur de paiement d'au moins une condition limitative relative au contexte d'utilisation dudit bon, et - ladite étape e) comprend la vérification par ledit serveur de paiement du respect par ladite demande de validation de ladite condition limitative attribuée audit bon.

Selon une autre caractéristique de l'invention, ladite condition limitative appartient groupe comprenant - date de péremption dudit bon, - une limitation de l'utilisation dudit bon dans le cadre d'une catégorie d'activité déterminée, - limitation de l'utilisation dudit bon pour le paiement d'au moins fournisseur déterminé, - l'association audit message transmis audit serveur de traitement d'une signature électronique dudit client.

De préférence, ladite demande de validation comprend données de datation générées par ledit serveur de traitement pour le controle par ledit serveur de paiement de la date de péremption dudit bon.

Selon autre caractéristique de l'invention, lesdites étapes a), b) et d) comprennent - transmission électronique par ledit client, à partir d'un terminal, ladite requête audit serveur de paiement, - transmission électronique par ledit serveur de paiement dudit code audit terminal, - la transmission électronique desdites données de paiement audit serveur de traitement à partir dudit terminal.

De préférence, ladite transmission électronique est effectuée via un canal de communication sécurisé.

L'invention a également pour objet un système de paiement électronique pour la mise en oeuvre du procédé défini ci-dessus, caractérisé en ce qu'il comprend - au moins un terminal d'accès d'au moins un client à une application de paiement électronique et à un réseau de communication, - au moins un serveur de paiement connecté audit réseau de communication et comprenant des moyens de génération conditionnelle dudit code pour la mise en oeuvre de ladite application, des moyens de stockage desdites données représentatives dudit bon, et des moyens de transmission dudit code audit terminal, - moins un serveur fournisseur connecté audit réseau de communication et comprenant des moyens d'élaboration et de transmission audit terminal, dans le cadre de ladite application, d'une facture susceptible d'être payée au moyen dudit , et - au moins un serveur intermédiaire de traitement bons électroniques comprenant des moyens de construction d'un message de demande de validation dudit bon en réponse à la réception d'un message de paiement émanant dudit client, des moyens de transmission dudit message de demande de validation audit serveur de paiement, et des moyen de transmission audit serveur fournisseur d'une information de validation de paiement en réponse à validation dudit bon par ledit serveur de paiement.

D'autres caractéristiques et avantages de l'invention apparaitront à la lecture la description qui suit d'un mode de réalisation particulier non limitatif l'invention illustré par les dessins annexés sur lesquels: - figure 1 est un schéma illustrant les organes essentiels d'un système pour la mise en oeuvre du procédé de paiement électronique selon l'invention, - la figure 2 est un schéma synoptique illustrant le processus d'obtention d'un bon électronique de paiement du procédé selon l'invention, - la figure 3 est un schéma synoptique illustrant le processus de paiement au moyen du bon électronique de paiement, et - la figure 4 est un schéma synoptique illustrant le traitement d'un bon électronique de paiement postérieurement au paiement proprement En se reportant à la figure 1, un système pour la mise oeuvre du procédé électronique de paiement qui sera décrit dans la suite comprend les organes essentiels suivants, susceptibles de communiquer entre par l'intermédiaire d'un réseau de communication R tel que le réseau Internet - des terminaux clients TC, tels que des ordinateurs personnels, assistants personnels (PDA), téléphones portables ou autres, permettant à des clients d'accéder au réseau R et comportant la partie "client" des logiciels d'application nécessaires pour la mise en oeuvre des fonctionnalités de paiement électronique qui seront decrites dans la suite. Pour la simplicité du dessin, un seul terminal a été représenté à la figure 1 ; - serveur SBC d'une banque ou établissement financier, ci-apres appelé serveur de paiement, qui assure à la fois les fonctions banque à domicile pour l'attribution de bons électroniques paiement à ses clients dotés d'un terminal TC et de serveur paiement dans le cadre de la négociation d'un bon électronique paiement décrite ci-après. II existe, bien entendu, autant serveurs SBC qu'il y a de banques participant au système paiement électronique. En variante, les fonctions remplies par le serveur SBC peuvent être réparties entre plusieurs serveurs, étant entendu que le ou les serveurs assurant les fonctions de paiement proprement dit peuvent accéder aux informations relatives à des bons de paiement électroniques attribués par le ou les serveurs assurant la fonction de banque à domicile ; - ou plusieurs serveurs commerçants ou fournisseurs SF auxquels des clients peuvent accéder pour passer des commandes en ligne à partir de leurs terminaux TC et qui sont susceptibles de transmettre à ces derniers des factures électroniques via le réseau R; - un serveur bancaire SBF d'une banque ou établissement financier chez qui un commerçant ou fournisseur ayant un serveur SF dispose d'un compte qui se verra crédité à l'issue d'une transaction avec un client se soldant par un paiement effectué au moyen d'un de paiement électronique. Bien entendu, le nombre de serveur bancaires SBF n'est pas limité ; - serveur ST de traitement de bons électroniques, ou plate-forme jouant un rôle d'intermédiaire ou de médiation entre differentes entités décrites ci-dessus et faisant office de pare-feu de tiers de confiance vis-à-vis de celles-ci. En variante, il peut être bien entendu prévu plusieurs serveurs de traitement ST.

Le processus complet de mise en oeuvre du procédé de paiement électronique selon l'invention peut être décomposé en trois grandes étapes l'obtention d'un bon électronique de paiement, la négociation d'un électronique de paiement, le post traitement d'un bon électronique paiement.

La figure 2 présente la première étape du procédé: l'obtention d'un électronique de paiement, ci-après également appelé BEP. On suppose qu préalable, le client a conclu avec sa banque un accord d'utilisation de ce moyen paiement.

client se connecte par son terminal TC au serveur SBC de sa banque établit avec celui-ci une session sécurisée qui garantit l'intégrité et la confidentialité des échanges. Après une série d'échanges 1 qui aboutit la part client à une demande de BEP, la banque (serveur SBC) construit formulaire " demande de BEP " 2 et le lui adresse en 3. Ce formulaire permet en 4 client de fixer le montant demandé et de choisir éventuellement parmi différentes options offertes : utilisation du BEP limité à un type d'activité, à des paiements d'un ou plusieurs fournisseur déterminés, contre-signature exemple. II signe alors électroniquement sa demande ou requête avant de retourner en 5 à sa banque. La signature électronique de la demande ou requête lui confère une valeur contractuelle dans les pays, de plus en plus nombreux, qui reconnaissent légalement la signature électronique.

A réception de la demande complétée et signée, la banque client (serveur SBC) construit en 6 un code ou référence de BEP, qui contient au moins les données d'identification de la banque client dans le système BEP (afin que la plate-forme de paiement ST identifie l'émetteur d'un BEP lors de sa présentation), et un numéro unique et non prédictible, c'est-à-dire construit de manière à ce que sa connaissance ne permette pas de déduire un autre code.

procédé, non limitatif, permettant de construire un tel numéro unique, de chiffrer un compteur, incrémenté à chaque demande d'une valeur connue de la banque client, par un mécanisme cryptographique à clé secrète connue seulement de la banque client. Par ce procédé, seule la banque client connaissant la valeur qui est chiffrée et la clé utilisée pour chiffrement, toute attaque cryptographique, et par là même, toute tentative construire un code de BEP valide pour un fraudeur est impossible. II faudrait en effet le code recalculé par la banque réceptrice corresponde un code de qu'elle a émis et cette probabilité est inférieure à 10-' avec clé de caractères en admettant que la banque gère un portefeuille de 1.000 de BEP actifs. On peut encore accroître la difficulté en publiant une partie la valeur chiffrée : le défi devient alors non seulement de fournir une valeur existante, mais également une partie de sa traduction. Ainsi avec 3 caractères " de contrôle " la probabilité passe à 10-'3. (environ 1.000.000 de fois moins de gagner au loto !). Enfin, la limitation de la valeur d'un bon électronique paiement (BEP) à une valeur imprévisible réduit l'intérêt d'une attaque car probabilité 1) trouver un numéro par hasard, 2) trouver la traduction par hasard et 3) le montant associé soit significatif, est encore plus faible.

Après génération d'un code de BEP en 8, la banque client (serveur SBC) enregistre sa " racine " (la valeur qui a été chiffrée pour le calculer) dans son système de stockage d'informations, avec le compte client associé, ses paramètres, sa date de création. Cette dernière permettra de déterminer date de péremption du BEP en fonction de la durée de validité assignée la banque émettrice au BEP. L'enregistrement de la racine " du code BEP protège la banque de toute attaque sur son système de stockage d'informations, puisque c'est le code chiffré qu'il faut produire commerçant: accéder à la racine ne permet pas de connaître un code de BEP.

En le code de BEP est retourné au client en réponse à sa demande (sous protocole sécurisé, pour en garantir la confidentialité) . II accompagné de ses caractéristiques (montant, cadre d'utilisation) qui peuvent être utiles client au moment du paiement pour choisir le BEP adapté à transaction. Le client est alors responsable de la sécurité de son code BEP, (comme il est responsable des billets qu'il retire de sa banque), et stocke le support de son choix en 9. II est possible au client de consulter sur terminal TC la liste de ses BEP actifs à tout moment, à travers outils de banque à domicile, ou directement dans un dossier BEP qu'il aurait lui même constitué. Le client a la faculté de transmettre un BEP à un tiers, comme un billet de banque, en lui communiquant le code de ce BEP.

Il est important de noter que dans ce processus, le compte du client n'a pas été débité, c'est-à-dire que la requete ou demande d'un BEP n'immobilise pas de capitaux non productifs. Il faut egalement noter que la perte du BEP est sans conséquences financières pour le client: le BEP non utilisé s'annulera de lui même à sa date de péremption.

La figure 3 illustre la deuxième étape du processus : le paiement.

Le client se connecte par son terminal TC sur un site marchand (serveur SBC) et, par une série d'échanges 10, passe sa commande. A la fin des échanges, sur demande du client, serveur SF construit une facture 11 et l'adresse en 12 au client. Cette facture contient au moins les données d'identification du fournisseur ou commerçant dans le serveur ST, le montant de la facture, une référence de facture. Elle contient également des propositions de modes de règlement, dont le BEP. Le code de BEP détenu par le client correspond à un lien vers le serveur ST (plate-forme BEP). Pour pouvoir proposer un paiement par BEP, le commerçant doit avoir obtenu l'agrément de sa banque SBF qui doit elle-même être participante à ce système de paiement. L'agrément commerçant par une banque constitue une " labellisation " qui est elle-même un élément de confiance.

Le choix en 13, par le client du règlement au moyen d'un bon électronique de paiement, le met automatiquement (hyperlien) en relation en 14 avec le serveur ST auquel il transmet les éléments de la facture contenant notamment le numéro du commerçant, ainsi que le montant et la référence de la facture. Le serveur ST peut alors contrôler que le commerçant est référencé dans la plate-forme construire en 15 un formulaire de paiement. Ce formulaire, destiné à la saisie du code de BEP, est adressé au Client en 16 dans une session sécurisée qui garantit la confidentialité des échanges. Le formulaire reçu en 17 par le client sur le terminal TC reprend le montant de la facture, le numéro et les données d'identification du commerçant et une date/heure fournie par le serveur ST. Le client choisit un BEP adapté au paiement et en saisit le code sur le formulaire 17 avant de l'adresser en 18, dans une session sécurisée, au serveur ST (plate-forme BEP).

II est important de noter à ce niveau que ce processus ne comporte aucune fonction d'identification du client par le serveur ST, et que le client pas besoin d'être équipé d'un lecteur de carte affichant le montant de transaction pour éviter une fraude basée sur une différence entre la valeur affichée à l'écran et la valeur " signée " par le client. Le client est protégé par valeur du BEP qu'il transmet et qui limite implicitement le montant maximal debitable (qui n'est connu que de lui-même et de sa banque) : toute tentative majoration risque de conduire à un dépassement de la valeur du BEP et donc à son rejet.

Avant de renvoyer le BEP au serveur ST, le client a la possibilité de le contresigner électroniquement avec la facture. La signature inclut le montant code de BEP, le numéro de facture, le numéro du commerçant et la date la transaction. Cette contre signature permet à sa banque (serveur SBC) d'authentifier son client si celui-ci le souhaite.

A réception du BEP, le serveur ST construit en 19 un message demande de validation ou vérification destiné à être adressé au serveur (banque client). Ce message contient le montant de la facture, le code mais également les informations sur le commerçant qui peuvent être necessaires à la validation du paiement: catégorie de commerçant et numéro de commerçant. Ce message est adressé en 20 au serveur SBC (banque client) par une liaison sécurisée.

A réception de la demande de paiement, le serveur SBC contrôle en compatibilité du BEP qui lui est présenté avec le paiement demande verification que le BEP a bien été émis par la banque client, qu'il n'a pas déjà " utilisé, qu'il n'est pas périmé, que sa valeur est supérieure ou égale montant de la transaction; qu'il est contresigné si son client a choisi cette option, que le commerçant satisfait aux conditions limitatives éventuelles (Catégorie d'activité, identité du commerçant), enfin que le compte présente provision suffisante. Si l'ensemble des conditions est satisfait, le serveur SBC débite immédiatement le compte du client du montant de la facture (comme dans le cas d'un retrait à un distributeur). II avise alors en 22 la plate- forme (serveur ST) de son accord ou de son refus de paiement. Dans le cas refus, le serveur de banque client SBC ne fournit aucune indication sur raisons de ce refus pour des raisons de sécurité. Dans tous les cas, le presenté devient inutilisable pour un nouveau paiement.

faut noter que, dans le mode de réalisation décrit, la négociation d'un BEP implique obligatoirement l'intermédiation de la plate-forme BEP (serveur ST). Cette obligation protège la banque client (serveur SBC) d'une attaque par commerçants qui utiliseraient des codes BEP aleatoires. La plate- forme (serveur ST) joue en quelque sorte un rôle pare-feu vis-à-vis de la banque client (serveur SBC).

A réception de la réponse, le serveur ST enregistre 23 la transaction s'il y a accord de la banque client, sinon elle revient en 26 à l'envoi au client d'un formulaire de saisie de BEP (une erreur de saisie du code de BEP peut être à l'origine du rejet). Toutefois cette offre de correction n'est proposée qu'un nombre limité de fois pour une même référence ou numéro de facture afin d'interdire à un client fraudeur, ou à un automate de fraude, d'essayer des codes de BEP aléatoires.

Le serveur ST avise alors en 24 le commerçant du succès ou de l'échec du paiement.

Selon la réponse, le commerçant engage ou non en le processus de traitement de la commande du client, et avise celui-ci en La figure 4 illustre la troisième étape du procède: le traitement d'un BEP postérieurement au paiement.

s'agit de la compensation des paiements. Le traitement effectué en 31 est identique au traitement de compensation des transactions par cartes, et n' ' ici que pour aider à la compréhension du processus complet.

partir du détail des paiements enregistrés au cours de la journée, la plate-forme BEP (serveur ST) adresse en 32 à la banque commerçant (serveur SBF) le détail des paiements reçus par commerçant, afin que celle-ci puisse crediter leur compte en 33.

même, la plarte-forme BEP adresse en 34 à la banque client (serveur SBC) le détail des transactions . La banque client connaît déjà les transactions, mais cet envoi est destiné à lui permettre de vérifier en 35 montant total débité (en cas de différence).

Enfin la plate-forme BEP adresse en 36 à une banque compensation BEP les écritures de débit et de crédit interbancaires afin de permettre de passer en 37 les écritures de compensation entre banques participantes.

Le procédé et le système décrits permettent de simplifier les techniques sécurisation des paiements électroniques en s'affranchissant de la nécessite d'authentifier en ligne l'auteur du paiement. Les problèmes de sécurisation des échanges dans lesquels l'auteur du paiement est impliqué sont, pour l'essentiel, réduits à ce qui touche à la relation entre la banque et son client. sécurité des échanges entre le serveur de traitement ST et le serveur de la banque du client est en effet d'une autre nature car il s'agit là de professionnels. Les mécanismes mis en oeuvre sont suffisamment simples pour être facilement compris par les utilisateurs. Les clients ont la possibilité gérer leur risque, par exemple en ne demandant l'attribution d'un BEP valeur élevée qu'au moment du paiement, et les banques sont placées au coeur du processus de confiance.

Il va de soi que le mode de réalisation décrit n'est qu'un exemple et l'on pourrait le modifier, notamment par substitution d'équivalents techniques, sans sortir pour cela du cadre de l'invention.

C'est ainsi qu'une version simplifiée du système pourrait être dépourvue serveur autonome de traitement des bons électroniques de paiement : réponse à la proposition de paiement en 13, le client saisirait directement son code de BEP et retournerait ce code et la facture au serveur commerçant SF qui, à son tour, présenterait directement à la banque client (serveur SBC) la requête de validation du paiement. Dans ce cas, le serveur commerçant SF remplit partiellement les fonctions du serveur de traitement ST. Bien entendu, une telle version simplifiée n'offre pas les mêmes garanties de sécurité celle décrite ci-dessus.

Selon autre variante, le client pourrait introduire directement le code de BEP dans la facture électronique émise par le serveur fournisseur SF, et celle-ci serait retournée ainsi complétée au serveur de traitement qui contrôlerait alors l'identité du fournisseur. Faute d'identification du fournisseur, le serveur de traitement avertirait le client du refus de la transaction. Dans ce cas, suivant la configuration du système, serveur de traitement ST ne présenterait pas de demande de validation serveur et le BEP pourrait être utilisé ultérieurement par le client pour un autre paiement ou, au contraire, par mesure de sécurité, ce BEP serait rendu inutilisable par sa présentation au serveur SBC.

Claims (10)

REVENDICATIONS

1. Procédé de paiement électronique d'un fournisseur par un client un réseau communication, caractérisé en ce qu'il comprend les étapes de a) genération conditionnelle (6) par un établissement financier, en réponse à une requête dudit client, d'un code unique et non predictible représentatif d'un bon de paiement de valeur maximale predéterminée, b) transmission (7) dudit code audit client, c) stockage (8) par ledit établissement financier dans un serveur de paiement (SBC) de données représentatives dudit bon, lesdites données représentatives comprenant au moins ledit code, ladite valeur et des données d'identification dudit client, d) transmission par ledit client, à un serveur (ST) de traitement de électronique, de données de paiement comprenant ledit code une somme déterminée, en réponse à une demande de paiement de ladite somme émanant d'un fournisseur (SF), et, e) validation conditionnelle, par ledit serveur de paiement (SBC), paiement de ladite somme audit fournisseur en réponse à transmission électronique (20) par ledit serveur de traitement (ST) d'une demande de validation dudit bon.

2. Procédé selon la revendication 1, caractérisé en ce que lesdites données de paiement comprennent des données d'identification dudit fournisseur (SF), ledit code et ladite somme, et ledit serveur de traitement (ST) contrôle l'identité dudit fournisseur (SF) en réponse à la réception desdites données de paiement, transmet conditionnellement ladite demande de validation audit serveur de paiement (SBC), en fonction du résultat dudit contrôle, et transmet électroniquement audit fournisseur (SF) une information de validation dé paiement de ladite somme en réponse à ladite validation dudit bon par ledit serveur de paiement (SBC).

3. Procédé selon'la revendication 2, caractérisé en ce que ladite étape d) comprend d1) la transmission électronique, dudit fournisseur (SF) audit client (TC), d'une facture électronique comprenant ladite somme et premières données d'identification dudit fournisseur et de ladite facture, d2) la transmission électronique de ladite facture dudit client (TC) audit serveur de traitement (ST) en réponse au choix par ledit client de son règlement par un bon de paiement électronique, d3) le contrôle de l'identité dudit fournisseur (SF) par ledit serveur traitement (ST) au moyen desdites premières données d'identification en réponse à la réception de ladite facture, d4) construction et la transmission électronique audit client (TC), ledit serveur de traitement (ST), d'un formulaire de paiement en réponse à la validation dudit contrôle de l'identité dudit fournisseur, ledit formulaire de paiement comprenant ladite somme et des secondes données d'identification dudit fournisseur et de ladite facture, et d5) l'introduction dudit code dans ledit formulaire par ledit client (TC) pour constituer un message de paiement, ledit serveur de traitement (ST) transmettant ladite demande de validation audit serveur de paiement (SBC) en réponse à la réception dudit message paiement.

4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé en ce que ladite étape e) comprend la mise en oeuvre par ledit serveur de paiement (SBC) des opérations de e1) comparaison du code reçu dudit client (TC) via ledit serveur de traitement (ST) avec ledit code stocké à l'étape c), e2) vérification que le bon représenté par ledit code stocké n'a pas été utilisé antérieurement, et e3) comparaison de ladite somme à ladite valeur stockée à l'étape c).

5. Procédé selon la revendication 4, caractérisé en ce que - lesdites étape a) et c) comprennent l'attribution et le stockage par et dans ledit serveur de paiement (SBC) d'au moins une condition limitative relative au contexte d'utilisation dudit bon, et - ladite étape e) comprend la vérification par ledit serveur paiement (SBC) du respect par ladite demande de validation ladite condition limitative attribuée audit bon.

6. Procédé selon la revendication 5, caractérisé en ce que ladite condition limitative appartient au groupe comprenant - date de péremption dudit bon, - limitation de l'utilisation dudit bon dans le cadre d'une catégorie d'activité déterminée, - limitation de l'utilisation dudit bon pour le paiement d'au moins fournisseur déterminé, - l'association audit message transmis audit serveur de traitement (ST) d'une signature électronique dudit client.

7. Procédé selon la revendication 6, caractérisé en ce que ladite demande validation comprend des données de datation générées par ledit serveur traitement (ST) pour le contrôle par ledit serveur de paiement (SBC) de la date de péremption dudit bon.

8. Procédé selon l'une quelconque des revendications 1 ' 7, caractérisé en ce que lesdites étapes a), b) et d) comprennent - la transmission électronique par ledit client, à partir d'un terminal (TC), de ladite requête audit serveur de paiement (SBC), - la transmission électronique par ledit serveur de paiement (SBC) dudit code audit terminal (TC), - transmission électronique desdites données de paiement audit serveur de traitement (ST) à partir dudit terminal (TC).

9. Procédé selon l'une quelconque des revendications 1 a 8, caractérisé ce que ladite transmission électronique est effectuée via un canal de communication sécurisé (R).

10. Système de paiement électronique pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend - au moins un terminal (TC) d'accès d'au moins un client à une application de paiement électronique et à un réseau de communication (R), - au moins un serveur de paiement (SBC) connecté audit réseau de communication et comprenant des moyens de génération conditionnelle dudit code pour la mise en oeuvre de ladite application, des moyens de stockage desdites données representatives dudit bon, et des moyens de transmission dudit code audit terminal (TC), - au moins un serveur fournisseur (SF) connecté audit réseau de communication (R) et comprenant des moyens d'élaboration et de transmission audit terminal, dans le cadre de ladite application, d'une facture susceptible d'être payée au moyen dudit , et - moins un serveur intermédiaire (ST) de traitement de bons electroniques comprenant des moyens (19) de construction d'un message de demande de validation dudit bon en réponse à la réception d'un message de paiement émanant dudit client, des moyens (20) de transmission dudit message demande de validation audit serveur de paiement (SBC), et des moyens (24) de transmission audit serveur fournisseur (SF) d'une information de validation de paiement en réponse à la validation dudit bon par ledit serveur de paiement (SBC).