FR 2814836 A1 20020405 FR 0106895 A 20010525 PROCEDE DE PAIEMENT EN LIGNE La présente invention concerne le domaine du paiement en ligne, et en particulier du paiement sur Internet. Le principe général du paiement en ligne est connu. Il consiste en un échange de fichiers numériques entre un marchand, d'un client et d'un tiers de paiement, chacun étant équipé d'un terminal informatique. Les différents équipements informatiques communiquent entre eux par un réseau informatique. Les solutions de paiement en ligne doivent présenter un haut degré de sécurité pour limiter les risques de fraude, mais aussi une architecture évitant l'augmentation inopinée des flux informatiques. La présente invention concerne selon son acception la plus générale un procédé de paiement en ligne par un échange de fichiers numériques sur un réseau informatique ou de télécommunication, comportant une étape de transmission par un terminal informatique client à un serveur de paiement d'un fichier numérique contenant au moins un identifiant d'une carte prépayée ou d'une carte de paiement (crédit ou débit) ou tout identifiant du client relatif à un compte bancaire ou non bancaire et un identifiant unique d'une commande, ledit identifiant étant par ailleurs enregistrée dans une mémoire d'un terminal informatique marchand , caractérisé en ce qu'il comporte une étape additionnelle de vérification du solde du compte correspondant à l'identifiant de la carte prépayée, une étape de décrémentation dudit compte et une étape de transmission au terminal du client d'un fichier correspondant au fichier numérique reçu, signé avec une signature numérique du serveur de paiement, le procédé étant caractérisé en outre par le fait qu'aucun échange d'information entre le serveur et le terminal marchand n'intervient pendant la transaction avec le client. Il comporte une étape préalable de transmission par le terminal marchand d'un fichier numérique de préférence signé avec une signature numérique du marchand, ledit fichier contenant un identifiant unique d'une commande effectuée par le client. Selon une variante avantageuse, le serveur mémorise le fichier transmis par le client et le conserve en mémoire même en cas d'interruption de la communication avec le client. Selon un mode de réalisation préféré, le procédé comporte une étape de vérification de l'état de la transaction précédente en cas de rétablissement de la communication après une interruption. Avantageusement, il comporte une étape ultérieure de compensation par transmission par le marchand au serveur de paiement des bons de commandes signés par ce dernier qui lui ont été communiqués par les clients, et de crédit du compte du marchand par le serveur en cas de comparaison positive des bons de commandes transmis par le marchand, et des bons de commande enregistrés dans la mémoire du serveur. De préférence, l'échange de fichiers numériques entre le terminal client et le serveur est réalisé dans le cadre d'une session sécurisé [de type SSL]. Selon une variante, le bon de commande initial est signé par le marchand à l'aide d'une clé publique transmise dans un certificat électronique délivré par une autorité de certification. La présente invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation qui suit, se référant au dessin annexé où : - la figure 1 représente le schéma des échanges de données. Le client est équipé d'un équipement informatique (100) constitué par exemple par un ordinateur muni de moyens de communication pour la connexion à un réseau informatique, par exemple Internet, ou par un terminal tel qu'un téléphone cellulaire communiquant par un réseau de télécommunication. Le marchand est une désignation simplifiée pour un serveur de commerce électronique (200). Le client conçoit son panier (1) chez le marchand au moment du choix du mode de paiement par carte prépayée, ou par une carte bancaire (de crédit ou de débit), ou par un compte identifiant le client. Pour cela, il établit un lien sécurisé de type SSL1 (cette liaison SSL1 n'est pas obligatoire, elle peut notamment dépendre du montant). Au cours de cette session, il envoie un fichier numérique comportant les identifiants des biens qu'il souhaite commander. Le marchand retourne (2) au client un bon de commande signé par lui-même sur cette même liaison (SSL, si elle a été ouverte précédemment). Ce bon de commande contient une référence unique et est stocké dans une mémoire (10) par le marchand pour être traité lors du paiement. Si le client accepte ce bon de commande, il engage un processus de paiement, consistant à transmettre le bon de commande signé par le marchand à un serveur de paiement auprès duquel il possède un compte, notamment un compte prépayé. Le client transmet (3) au serveur de paiement le bon de commande signé par le marchand accompagné des identifiants de sa/ses carte prépayée, ou d'identifiant d'une carte de paiement bancaire (crédit ou débit), ou par un identifiabt d'un compte du client sur une liaison sécurisée de type SSL2. Ce bon de commande est constitué par un fichier numérique comportant une séquence constituant une signature calculée par un moyen de cryptologie, notamment une fonction cryptographique calculée à partir de la clé du marchand et de l'identifiant unique de la commande. Le Serveur de paiement (300) vérifie le crédit sur la/les carte prépayée (s) transmise (s) par le client et la/les débite. Il transmet (4) alors au client le bon de commande signé par lui même (le serveur de paiement). Le serveur de paiement par ailleurs sauvegarde ce bon de commande signé dans une mémoire permanente (11), par le marchand et lui même pour une future compensation du marchand. Les bons de commande signé par le marchand et serveur de paiement sont archivés par le serveur de paiement, ceci permet entre autres au client en cas de rupture de sa connexion de demander au serveur de paiement le dernier bon de commande ou même l'état des achats relatifs à une carte, il faut que le client soit en possession de la carte dite). Le bon de commande signé par le serveur de paiement est équivalent comme un bon d'achat mais ciblé vers un marchand donné (en relation avec le bon de commande). Le client transmet (5) le bon de commande signé par le marchand et le serveur de paiement au marchand par la liaison SSL1 (si elle a été ouverte précédemment). Lors de cet échange le client peut éventuellement demander (6) une facture au marchand. Le marchand vérifie que ce bon de commande n'a pas été traité et vérifie la signature du serveur de paiement et déclenche la délivrance de la marchandise au client. Ce bon de commande est considéré alors comme traité (ceci évite une réutilisation de ce bon de commande par le client et protège ainsi le commerçant). Le marchand stocke ce bon de commande signé par le serveur de paiement pour une future compensation. Le paiement du marchand par le serveur est réalisé postérieurement par compensation selon le système SET par exemple, il suffit que le marchand présente les bons de commande signé par ledit serveur de paiement. Dans cette solution les marchands pour signer sont en possession d'une double clé privé/public. Leur clé publique sont diffusés dans un certificat, ce certificat n'étant pas obligatoirement signé par le serveur de paiement. Il peut être signé par l'autorité de certification choisie par le marchand (soulignant ici que la plupart des marchands sont dotés de certificats, avec cette approche on facilite grandement la mise en oeuvre de cette solution de paiement). En particulier, il n'est pas nécessaire que le marchand soit en possession d'un certificat délivré par le serveur de paiement. On évite ainsi que le marchand soit obligé de changer ses installations, notamment redéployer un nouveau certificat voir changer d'autorité de certification. Dans l'invention, il n'y a pas de liaison directe ente le serveur de paiement et le marchand. Cette liaison n'est pas nécessaire, il suffit que le serveur de paiement signe le bon de commande délivré par le marchand, pour que ce dernier autorise l'achat. Les échanges entre serveur de paiement et marchand sont totalement inutiles il apporte en aucune manière plus de sécurité, leur seul bénéfice et d'alourdir la charge du marchand et du serveur de paiement et offrent une qualité de service au client en termes de temps de réponse prohibitif. REVENDICATIONS 1-Procédé de paiement en ligne par un échange de fichiers numériques sur un réseau informatique ou de télécommunication, comportant une étape de transmission par un terminal informatique client à un serveur de paiement d'un fichier numérique contenant au moins un identifiant d'une carte prépayée ou un identifiant d'une carte de paiement banciaire (crédit ou débit), ou par une identifiant d'un compte du client et un identifiant unique d'une commande, ledit identifiant étant par ailleurs enregistrée dans une mémoire d'un terminal informatique marchand , caractérisé en ce qu'il comporte une étape additionnelle de vérification du solde du compte correspondant à l'identifiant de la carte prépayée, une étape de décrémentation dudit compte et une étape de transmission au terminal du client d'un fichier correspondant au fichier numérique reçu, signé avec une signature numérique du serveur de paiement, le procédé étant caractérisé en outre par le fait qu'aucun échange d'information entre le serveur et le terminal marchand n'intervient pendant la transaction avec le client. 2-Procédé de paiement en ligne selon la revendication 1, caractérisé en ce qu'il comporte une étape préalable de transmission par le terminal marchand d'un fichier numérique signé avec une signature numérique du marchand, ledit fichier contenant un identifiant unique d'une commande effectuée par le client. 3-Procédé de paiement en ligne selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur mémorise le fichier transmis par le client et le conserve en mémoire même en cas d'interruption de la communication avec le client. 4-Procédé de paiement en ligne selon la revendication précédente, caractérisé en ce qu'il comporte une étape de vérification de l'état de la transaction précédente en cas de rétablissement de la communication après une interruption. 5-Procédé de paiement en ligne selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape ultérieure de compensation par transmission par le marchand au serveur des bons de commandes signés qui lui ont été communiqués par les clients, et de crédit du compte du marchand par le serveur en cas de comparaison positive des bons de commandes transmis par le marchand, et des bons de commande enregistrés dans la mémoire du serveur. 6-Procédé de paiement en ligne selon l'une quelconque des revendications précédentes, caractérisé en ce que l'échange de fichiers numériques entre le terminal client et le serveur est réalisé dans le cadre d'une session sécurisé [de type SSL]. 7-Procédé de paiement en ligne selon l'une quelconque des revendications précédentes, caractérisé en ce que le bon de commande initial est signé par le marchand à l'aide d'une clé public transmis dans un certificat électronique délivré par une autorité de certification différente du serveur de paiement.