Brevet FR3150025A1 — publié le 20241220

L’invention concerne un procédé de paiement électronique, comprenant les étapes suivantes, mises en œuvre par un serveur de paiement : a) réception d’un message de vente issu d’un terminal client, le message de vente comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant ; b) comparaison du montant de la transaction à une capacité de paiement contenu dans un compte client stocké dans le serveur de paiement et si le montant de la transaction est inférieur ou égal à la capacité de paiement ; b) émission vers un serveur central d’un message de transfert du montant de la transaction de manière que le serveur central crédite un compte de fonctionnement du commerçant du montant de la transaction minoré d’une commission, débite un compte de fonctionnement du client et crédite un compte de fonctionnement central de la commission ; c) émission vers le serveur central d’un ordre de prélèvement du solde débiteur du compte de fonctionnement client depuis le compte bancaire client vers le compte de fonctionnement central de l’établissement bancaire central d) émission d’un ordre de transfert du solde du compte de fonctionnement du commerçant vers le compte bancaire commerçant ; e) réception du serveur central d’une notification que le solde débiteur du compte de fonctionnement du client a été prélevé. Pas de figure Procédé de paiement électronique L’invention concerne le domaine du paiement électronique et concerne notamment un procédé de paiement électronique ne nécessitant pas une carte bancaire. ETAT DE LA TECHNIQUE On connait le paiement par carte bancaire où un client présente à un terminal de paiement électronique d’un commerçant sa carte bancaire. Le paiement par carte bancaire présente toutefois un certain nombre d’inconvénients tant pour les commerçants que pour les consommateurs. Pour les commerçants : des frais de transaction élevés, il nécessite un grand nombre d’intermédiaires, une transaction est relativement longue (environ 15s) la fraude à la carte bancaire est importante, nécessité d’avoir un terminal de paiement pour encaisser les paiements par cartes bancaires (loué ou acheté), la complexité des paiements sur internet en raison du système 3DSecure™ et authentification forte requise pour valider les paiements, la perte de chiffre d’affaires pour les e-commerçants (ou commerçants sur Internet) en raison d’un abandon de panier important au moment du paiement. Pour les consommateurs. une cotisation annuelle selon le type de carte bancaire, une facturation possible de frais sur les retraits d’espèces, une acceptation limitée chez certains commerçants (exigence d’un montant minimum), des plafonds de paiement et de retrait, l’impossibilité de faire des paiements entre particuliers, Ne pas pouvoir gérer sur une même carte un débit différé ou immédiat, les plafonds de paiement pour les paiements sans contact. Pour éviter l’utilisation de la carte bancaire des solutions mettant en œuvre un smartphone (pour téléphone intelligent) ont fait leur apparition. Ces solutions permettent de dématérialiser la carte bancaire mais présentent toujours les inconvénients du paiement par carte bancaire. Il existe un besoin de simplifier les paiements en se soustrayant au dispositif de paiement par carte bancaire. Un but de l’invention est de proposer une solution de paiement et d’encaissement qui soit simple, rapide, sécurisée qui n’utilise pas de carte bancaire pour des paiements réalisés aussi bien physiquement que pour des paiements en ligne. A cet effet, l’invention propose selon un premier aspect un procédé de paiement électronique, comprenant les étapes suivantes, mises en œuvre par un serveur de paiement : a) réception d’un message de vente issu d’un terminal client, le message de vente comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant ; b) comparaison du montant de la transaction à une capacité de paiement contenu dans un compte client stocké dans le serveur de paiement et si le montant de la transaction est inférieur ou égal à la capacité de paiement ; b) émission vers un serveur central d’un message de transfert du montant de la transaction de manière que le serveur central crédite un compte de fonctionnement du commerçant du montant de la transaction minoré d’une commission, débite un compte de fonctionnement du client et crédite un compte de fonctionnement central de la commission ; c) émission vers le serveur central d’un ordre de prélèvement du solde débiteur du compte de fonctionnement client depuis le compte bancaire client vers le compte de fonctionnement central de l’établissement bancaire central d) émission d’un ordre de transfert du solde du compte de fonctionnement du commerçant vers le compte bancaire commerçant ; e) réception du serveur central d’une notification que le solde débiteur du compte de fonctionnement du client a été prélevé. L’invention, selon le premier aspect, est avantageusement complétée par les caractéristiques suivantes, prises seules ou en une quelconque de leur combinaison techniquement possible : - préalablement à l’étape a) : a0) réception d’un message de transaction issu d’un terminal commerçant, le message de transaction comprenant un montant d’une vente ; a1) génération d’une empreinte de transaction à partir du message de transaction reçu, l’empreinte comprenant le montant de la vente et une identité du commerçant connue du serveur de paiement ; a2) émission de l’empreinte généré au terminal commerçant. - l’empreinte est un QR code, une étiquette de communication par champ proche ou un code numérique à 6 chiffres. - la réception du message de vente est consécutive à une validation de la transaction par le client par l’intermédiaire du terminal client à la suite d’une lecture par le terminal client de l’empreinte et à une authentification du client au niveau du terminal client. - si le montant de la transaction est supérieur à une capacité de paiement contenu dans le compte client, émission au terminal commerçant d’une notification d’abandon de la transaction et émission au terminal client d’une notification de refus de la transaction. - l’ordre de prélèvement est émis à chaque transaction ou bien périodiquement à une fréquence déterminée. Selon un deuxième aspect, l’invention concerne un serveur de paiement comprenant une unité de traitement configurée pour mettre en œuvre un procédé selon le premier aspect de l’invention. Selon un troisième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions, qui lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon le premier aspect de l’invention. L’invention permet de s’affranchir définitivement de l’utilisation d’une carte bancaire présentée même dématérialisée à un terminal de paiement électronique. L’invention permet : un paiement très rapide car en s’affranchissant de la carte bancaire, la solution s’affranchit de tous les intermédiaires habituels du paiement par carte bancaire. Un paiement plus sécurisée qu’un paiement par carte bancaire : Utilisation des éléments de sécurité du terminal du porteur (code pin ou éléments d’identification biométrique), Utilisation des éléments de sécurité de l’application du porteur (code pin ou éléments d’identification biométrique) pour les paiements supérieurs à un montant déterminé, par exemple 50 €, Le montant du paiement sans code PIN est paramétrable entre 0 € et un montant déterminé, par exemple 50 € dans l’application selon les besoins de sécurité voulus par chaque porteur, Il n’est plus nécessaire de saisir ou d’enregistrer ses codes de cartes bancaires pour réaliser des paiements en ligne. Pas besoin d’enregistrer sa carte bancaire dans un portefeuille dématérialisé (appelé wallet, type Apple Pay™, Google Pay™), Aucune transmission au commerçant d’informations sensibles relatives au porteur (numéro de compte par exemple) Au client porteur de l’application de paiement selon l’invention de pouvoir gérer le débit de ses paiements en choisissant s’il souhaite basculer d’un paiement à débit différé vers un paiement à débit immédiat D’obtenir une capacité de dépense en fonction de ses ressources, déterminée de façon automatique lors du parcours d’inscription. Il n’est pas utile de précharger son compte depuis l’application selon l’invention pour réaliser des achats PRESENTATION DES FIGURES D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : - la illustre une architecture de mise en œuvre d’un procédé de paiement électronique conforme à l’invention ; - la illustre des étapes d’un procédé de paiement électronique conforme à l’invention. Sur l’ensemble des figures les éléments similaires portent des références identiques. DESCRIPTION DETAILLEE Architecture La illustre une architecture de mise en œuvre d’un procédé de paiement électronique conforme à l’invention. Un client C1 accède à un point de vente PdV d’un commerçant C2 pour effectuer un achat. Le client C1 possède un terminal électronique T1 tel qu’un smartphone. Le terminal T1 est de manière plus générale n’importe quel équipement adapté pour se connecter à un serveur de paiement SP : tablette tactile, ordinateur portable, console de jeux, etc. Le point de vente PdV peut être un site Internet, un lieu physique, etc. Le point de vente PdV est notamment matérialisé par un terminal électronique T2 également adapté pour se connecter au serveur de paiement SP. Les terminaux T1, T2 peuvent se connecter au serveur de paiement SP au moyen d’une connexion sans fil par exemple par Internet R. Cette connexion peut être mise en œuvre par une liaison filaire (par exemple par une liaison par fibre optique, adsl, réseau, etc.) sans fil de type Wi-Fi ou via un réseau de communication mobile (3G, 4G, 5G, etc.). Le serveur de paiement SP est typiquement configuré pour mettre en œuvre des traitements et comprend à ce titre un calculateur. De préférence, le serveur de paiement SP et les terminaux T1, T2 sont configurés pour échanger des données de manière sécurisées via la connexion Internet. Avantageusement, le serveur de paiement SP et les terminaux T1, T2 sont configurés pour échanger des données de manière hautement sécurisée selon des standards de communication bien connus de l’homme du métier. En outre, le serveur de paiement SP comprend une ou plusieurs mémoires pour permettre le stockage de différentes données. Pour accéder au serveur de paiement SP, une application de paiement est installée sur le terminal T1 du client C1 et le client C1 a créé un compte client 10 lui permettant d’utiliser l’application. De manière similaire le commerçant C2 utilise une application dédiée pour lui permettre d’interagir avec le terminal T1 du client C1, le commerçant C2 possédant un compte commerçant 20 pour accéder au serveur de paiement SP. Les comptes clients et commerçants respectivement 10 et 20 sont stockés par le serveur SP de paiement et comprennent toutes les informations relatives au client et au commerçant et permettent de tracer toutes les transactions. Le serveur de paiement SP est associé et connecté à un serveur central SC d’un établissement EC bancaire central qui permet de gérer des flux bancaires tels que des transferts interbancaires de fonds par virement bancaire notamment. La connexion entre le serveur central SC et le serveur de paiement SP est mise en œuvre de manière similaire à la connexion entre le serveur de paiement SP et les terminaux T1, T2. Le serveur de paiement SP est associé au serveur central SC d’un établissement bancaire EC central qui va gérer tous les flux bancaires. S’agissant d’une application permettant le paiement électronique, le client C1 possède un compte bancaire client 11 géré par un serveur S1 d’un établissement E1 bancaire client et le commerçant possède un compte bancaire commerçant 21 géré par un serveur S2 d’un établissement E2 bancaire commerçant. Sur la trois établissements bancaires distincts sont représentés mais un ou plusieurs établissements bancaires peuvent être confondus en fonction des préférences du client et du commerçant. Comme on l’aura compris, les communications entre les différents serveurs et le terminal du commerçant et celui du client transitent par le réseau R Internet et sont sécurisées selon les standards bien connus de l’homme du métier. Les connexions mises en œuvre ne seront pas plus détaillées. Le terminal T1 du client C1 et le terminal T2 du commerçant C2 peuvent par ailleurs être configurés pour communiquer entre eux selon la technologie de communication en champ proche (en anglais, Near Field Communication, NFC). Procédé de paiement électronique Initialisation Un procédé de paiement électronique décrit en relation avec la , nécessite l’installation côté client C1 d’une application sur le terminal client T1. Une fois l’application installée pour accéder au service de paiement, le client C1 s’inscrit (étape Init C1) sur l’application en créant son compte client 10. Il a pour cela besoin d’entrer son identité et de communiquer une autorisation de prélèvement de son compte bancaire 11 hébergé dans l’établissement E1 bancaire qui peut être quelconque. On constate que le client C1 n’a pas à posséder de carte bancaire pour s’enregistrer et finaliser l’ouverture d’un compte. Le compte client 10 est stocké dans le serveur de paiement SP et comporte outre l’identité et les coordonnées bancaires, une capacité de paiement. Une telle capacité paiement limite le montant que le client peut utiliser mensuellement (en une ou plusieurs transactions) mettant en œuvre le procédé de paiement électronique ici décrit. Cette capacité de paiement est initialement plafonnée à une faible valeur et relevée une fois le compte bancaire extérieur 11 du client confirmé. De manière similaire, le commerçant C2 s’est inscrit au service (étape Init C2) et possède un compte commerçant 20 stocké dans le serveur de paiement SP. Ce compte commerçant 20 comporte l’identité du commerçant mais aussi ses coordonnées bancaires associées à son compte bancaire commerçant 21. Les coordonnées bancaires vont permettre l’initiation d’opérations bancaires requises par le serveur de paiement SP au serveur central SC qui est habilité à mettre en œuvre ce type d’opérations. Pour ce faire, à la création des comptes client et commerçant 10, 20, un compte de fonctionnement client 12 (type compte de paiement) et un compte de fonctionnement commerçant 22 (type compte de paiement) sont créés dans le serveur central SC de l’établissement bancaire central EC. Ces comptes de fonctionnement vont permettre de gérer les flux bancaires initiés exclusivement au moment du paiement, de manière transparente pour le client et le commerçant. Initiation d’un paiement Comme illustré en relation avec la , un client C1 se rend dans un point PDV de vente pour acheter un ou plusieurs bien(s) (étape 100). Le client C1 se présente au point de vente PDV pour que le commerçant C2 saisisse la vente (étape 101). Il s’agit par exemple ici d’un passage en caisse classique. La saisie de la vente est faite par le commerçant C2 sur son terminal T2 commerçant et conduit à la génération d’un message M1 de transaction comprenant le montant de la vente (étape 102). Le commerçant C2 via son terminal T2 valide la vente ce qui déclenche l’émission (étape 103) du message M1 de transaction vers le serveur SP de paiement. A la réception (étape 104) de ce message M1 de transaction, le serveur SP de paiement génère (étape 105) une empreinte EP1 de transaction telle qu’un QR code ou une étiquette NFC. Cette empreinte EP1 contient le montant de la vente ainsi que l’identité du commerçant C2 connue du serveur SP de paiement. Cette empreinte EP1 est stockée (étape 106) dans le serveur de paiement SP pour permettre une traçabilité des transactions et est retournée (étape 107) au terminal T2 du commerçant C2 pour effectuer la transaction avec le client C1. Session de transaction L’empreinte EP1 est présentée au client C1 (étape 108) notamment par l’intermédiaire du terminal commerçant T2. Puis, le client C1 confirme la transaction selon l’un des procédés suivants : Paiement par QR code : Une authentification préalable du client C1 est mise en œuvre par le terminal T1 du client avant de pouvoir valider une transaction. Cette authentification peut se faire par exemple par une reconnaissance d’une empreinte digitale ou une reconnaissance faciale ou encore par saisie d’un code. Le client C1 approche son terminal T1 client du terminal T2 pour procéder à l’acquisition (étape 109) de l’empreinte EP1. Le terminal T1 procède à la lecture du QR code par acquisition d’une image du QR code. L’acquisition de l’empreinte de transaction déclenche une requête de validation de la transaction par le client C1 qui prend la forme d’une authentification du client C1 (étape 110). En pratique, l’acquisition de l’empreinte déclenche l’ouverture de l’application de paiement sur le terminal client T1 qui demande une authentification du client C1. Paiement sans contact par NFC : Le client C1 approche son terminal T1 client du terminal T2 pour procéder à l’acquisition (étape 109) de l’empreinte EP1. Le terminal T1 procède à la lecture par liaison NFC de l’empreinte. En pratique, l’acquisition de l’empreinte déclenche l’ouverture d’une application de paiement sur le terminal client T1 qui demande une authentification du client C1. Cette authentification est mise en œuvre par le terminal T1 du client par exemple par une reconnaissance d’une empreinte digitale ou une reconnaissance faciale ou encore par saisie d’un code. L’acquisition de l’empreinte de transaction déclenche une requête de validation de la transaction par le client C1 qui prend la forme d’une authentification du client C1 (étape 110). Paiement par saisie d’un code de transaction : Le client C1 saisie le code à 6 chiffres associé à l’empreinte présentée par le commerçant sur son terminal T1. Le montant demandé par le commerçant est alors affiché et le client C1 a la possibilité de valider ou d’annuler la transaction. Une fois le client C1 authentifié, ce dernier valide la transaction (étape 111) ce qui déclenche une génération (étape 112) par le terminal T1 du client d’un message de vente M2 suivi de son émission (étape 113) vers le serveur SP de paiement. Le message de vente M2 comporte notamment une information relative au montant de la transaction, une information relative à une identité du client et une information relative à une identité d’un commerçant. Un tel message de vente M2 va permettre au serveur SP de paiement de traiter la transaction. Le message de vente M2 reçu (étape 114) est ensuite décodé (étape 115) par le serveur SP de paiement pour extraire les informations relatives à la transaction. Le serveur SP de paiement procède alors à une comparaison (étape 116) du montant de la transaction à une capacité de paiement renseignée dans son compte client 10. Une telle capacité est définie à la création du compte client 10 et est variable selon les informations communiquées par le client, en fonction des données financières collectées. La capacité de paiement peut être comprise entre 0 et 200 euros par défaut et au-delà après analyse des données collectées et compte bancaire (11) confirmé. Si le montant de la transaction est supérieur à la capacité de paiement du client, la transaction est abandonnée, le serveur de paiement SP émet au terminal commerçant T2 un message ainsi qu’au terminal T1 client. Le client C1 et le commerçant C2 sont ainsi notifiés simultanément du refus de la transaction (étape 117, étape 118). Si le montant de la transaction est inférieur ou égal à la capacité de paiement du client C1 alors le serveur SP de paiement émet (étape 121) au serveur central SC un message de transfert M3 qui permet au serveur central SC d’exécuter les opérations suivantes (étape 122) : créditer le compte de fonctionnement du commerçant 22 du montant de la transaction minoré d’une commission qui est transféré un compte de fonctionnement central 30 également stocké dans le serveur central SC, débiter le compte de fonctionnement du client 12 du montant de la transaction. Une fois le transfert effectué sur le compte de fonctionnement du commerçant 22, la transaction est terminée et le commerçant C2 est notifié (étape 123). A l’issue de la transaction, le compte de fonctionnement du client est donc débiteur du montant de la transaction tandis que celui du compte de fonctionnement du commerçant est positif de ce montant minoré du montant de la commission. On comprend que plusieurs transactions peuvent être portées au crédit ou au débit des comptes de fonctionnement commerçant et client. Session transfert bancaire Lorsque la transaction est terminée, le serveur de paiement SP émet un premier ordre de prélèvement (étape 124) au serveur central SC de l’établissement bancaire central EC. Ce premier ordre vise à recouvrir le ou les débit(s) du compte de fonctionnement client 12. Un tel ordre de prélèvement peut être initié chaque jour ou mensuellement. Le serveur central SC exécute alors un prélèvement du total des débits du compte de fonctionnement client selon les standards en vigueur connus. L’exécution ce premier ordre de prélèvement implique que le serveur central SC envoie le premier ordre à l’établissement bancaire client E1 et en particulier au serveur S1 de l’établissement bancaire client. Le serveur de l’établissement bancaire client S1 transfère (étape 126) donc depuis le compte bancaire du client 11 vers le compte de fonctionnement central 30 le total des débits du compte de fonctionnement client 12. Le serveur de paiement SP est alors notifié de la couverture des débits du client (étape 127, étape 128). Parallèlement, les sommes créditées sur le compte de fonctionnement 22 du commerçant lors de chaque transaction sont ensuite virées sur le compte bancaire commerçant 21. Cette opération est émise par le serveur de paiement SP (étape 129) vers le serveur central SC de l’établissement bancaire central EC. Ce deuxième ordre vise à créditer le compte bancaire commerçant 21 du montant au crédit de son compte de fonctionnement 22. Le serveur central SC exécute (étape 131) alors un virement du compte de fonctionnement du commerçant 22 du montant à créditer au compte bancaire commerçant 21 (étape 132). Procédé de paiement électronique, comprenant les étapes suivantes, mises en œuvre par un serveur (SP) de paiement : a) réception (114) d’un message de vente (M2) issu d’un terminal (T1) client, le message de vente (M2) comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant ; b) comparaison (116) du montant de la transaction à une capacité de paiement contenu dans un compte client stocké dans le serveur de paiement (SP) et si le montant de la transaction est inférieur ou égal à la capacité de paiement ; b) émission (121) vers un serveur central (SC) d’un message (M3) de transfert du montant de la transaction de manière que le serveur (SC) central crédite un compte de fonctionnement du commerçant du montant de la transaction minoré d’une commission, débite un compte de fonctionnement du client et crédite un compte de fonctionnement central de la commission ; c) émission (124) vers le serveur central (SC) d’un ordre de prélèvement du solde débiteur du compte de fonctionnement client depuis le compte bancaire client (11) vers le compte de fonctionnement central (30) de l’établissement bancaire central d) émission d’un ordre de transfert du solde du compte de fonctionnement du commerçant (22) vers le compte bancaire commerçant (21) ; e) réception (127) du serveur central d’une notification que le solde débiteur du compte de fonctionnement du client a été prélevé. Procédé selon la revendication 1, comprenant préalablement à l’étape a) : a0) réception (104) d’un message de transaction (M1) issu d’un terminal commerçant (T2), le message de transaction (M1) comprenant un montant d’une vente ; a1) génération (105) d’une empreinte (EP1) de transaction à partir du message de transaction (M1) reçu, l’empreinte (EP1) comprenant le montant de la vente et une identité du commerçant (C2) connue du serveur (SP) de paiement ; a2) émission (107) de l’empreinte (EP1) généré au terminal commerçant. Procédé selon la revendication 2, dans lequel l’empreinte (EP1) est un QR code, une étiquette de communication par champ proche ( NFC) ou un code numérique à 6 chiffres. Procédé selon l’une des revendications 2 à 3, dans lequel la réception du message de vente (M2) est consécutive à une validation (103) de la transaction par le client par l’intermédiaire du terminal (T1) client à la suite d’une lecture par le terminal client de l’empreinte (EP1) et à une authentification (110) du client au niveau du terminal client. Procédé selon l’une des revendications 1 à 4, dans lequel si le montant de la transaction est supérieur à une capacité de paiement contenu dans le compte client, émission (117) au terminal (T2) commerçant d’une notification d’abandon de la transaction et émission (118) au terminal (T1) client d’une notification de refus de la transaction. Procédé selon l’une des revendications 1 à 5, dans lequel l’ordre de prélèvement est émis à chaque transaction ou bien périodiquement à une fréquence déterminée. Serveur (SP) de paiement comprenant une unité de traitement configurée pour mettre en œuvre un procédé selon l’une des revendications précédentes. Produit programme d’ordinateur comprenant des instructions, qui lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une des revendications 1 à 6.