FR2979450A1 - Systeme de paiement multi echeances - Google Patents
Systeme de paiement multi echeances Download PDFInfo
- Publication number
- FR2979450A1 FR2979450A1 FR1157455A FR1157455A FR2979450A1 FR 2979450 A1 FR2979450 A1 FR 2979450A1 FR 1157455 A FR1157455 A FR 1157455A FR 1157455 A FR1157455 A FR 1157455A FR 2979450 A1 FR2979450 A1 FR 2979450A1
- Authority
- FR
- France
- Prior art keywords
- payment
- transaction
- router
- remote server
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 43
- 238000012545 processing Methods 0.000 title claims abstract description 41
- 230000004044 response Effects 0.000 title claims abstract description 24
- 238000000034 method Methods 0.000 claims abstract description 30
- 238000004891 communication Methods 0.000 claims description 81
- 238000012011 method of payment Methods 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 claims 1
- 238000012384 transportation and delivery Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000010926 purge Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/24—Credit schemes, i.e. "pay after"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
La présence invention a pour objet un système (1) de paiement multi échéances pour réaliser une transaction (T) entre un client porteur de moyens d'identification et de paiement (2) comprenant un identifiant unique (Id) et un commerçant dans un point de vente du commerçant, caractérisé en ce qu'il comprend un terminal d'acceptation (10) et un serveur-routeur distant (20) comprenant agencé pour déterminer et inscrire dans l'agencement de données d'échéances (24) les dates (d , ..., d ) et les montant (m , ..., m ) des échéances en fonction d'une date effective (d) de la transaction (T) et des paramètres (P) de la transaction (T), exécuter le paiement d'un montant d'échéance (m ,..., m ) aux dates (d ,..., ) respectives, ainsi qu'un procédé de paiement.
Description
La présente invention concerne le secteur de la monétique, en particulier les moyens de paiement de proximité. Le paiement de proximité est un type de paiement ou le porteur des moyens de paiement ou client et le commerçant sont physiquement présents 5 lors de la réalisation de la transaction. Ce mode de paiement implique l'utilisation de moyens d'identification du client par le commerçant. Le porteur est un titulaire et utilisateur d'une carte bancaire souscrite au travers un contrat carte dans un établissement financier. Le porteur peut être soit le titulaire nominatif du contrat (cas des 10 particuliers) ou le porteur "professionnel" d'une carte adossée au compte d'une entreprise. Plus précisément, la présente invention a pour objet un système de paiement multi échéances pour réaliser une transaction entre un client porteur de moyens d'identification et de paiement comprenant un identifiant unique et 15 un commerçant dans un point de vente du commerçant ainsi qu'un procédé de paiement. Un système de paiement multi échéances permet aux commerçants de proposer à leurs clients un outil supplémentaire pour faciliter le paiement de leurs achats. 20 Le montant dû est divisé selon le nombre d'échéances. Le montant des échéances est encaissé à chaque terme échu par le commerçant. De plus, une facilité de paiement dont la durée est inférieure à 90 jours n'est pas apparentée à du crédit et ne génère donc pas d'intérêts financiers. Un client a donc tout intérêt à utiliser un système de paiement multi 25 échéances. Un commerçant souscrivant à un tel système attirera quant à lui davantage de clients dans son point de vente. Les systèmes de paiement différés nécessitent bien souvent l'utilisation de moyens supplémentaires spécifiques telle qu'une carte de crédit 30 délivrée par un commerçant donné, ce qui est contraignant pour le client. Le paiement multi écheances peut être quant à lui réalisé selon plusieurs solutions différentes telles que : - la remise de plusieurs chèques destinés à être déposés à des dates données, 35 - l'établissement d'une autorisation de prélèvement bancaire pour les échéances à honorer, - le règlement des échéances par carte bancaire... Le paiement multi écheances est apprecié des consommateurs dans le cadre d'achat presentant un ticket moyen conséquent, la plus part du temps supérieur à cent euros.
Il existe des solutions alternatives permettant de proposer ce même service aux consommateurs. La première d'entre elles est le chèque à tiroirs dans laquelle l'acheteur rédige n chèques correspondant au nombre d'échéances négociées avec le commerçant. Les chèques sont stockés et encaissés par le 10 commerçant aux dates convenus. Cependant, cette solution présente un inconvénient majeur pour le commercant. En effet, la gestion administrative d'une telle solution est lourde de par la nécessité de stockage des chèques et la remise à la bonne date. De 15 plus, cette solution présente un risque d'impayé pouvant entrainer une lourde procédure de recouvrement de l'impayé. Cette solution présente également un inconvénient majeur pour le consommateur. En effet, les chèques peuvent être remis en une fois par un 20 commerçant qui ne respecte pas ses engagements. La deuxième solution est apportée par le prélèvement bancaire. L'acheteur et le commerçant s'accordent sur un nombre d'échéances. La première échéance est réglée au comptant. Les autres échéances sont réglées avec un différé par prélèvement bancaire. Une 25 autorisation de prélèvement avec remise d'un relevé d'identité bancaise ou RIB et d'une pièce d'identité au commerçant est nécessaire. Cependant, cette solution présente elle aussi un inconvénient majeur pour le commercant. En effet, la procedure administrative d'une telle solution est 30 également lourde de par la nécessité de remplissage des documents et du traitement de ces documents. De plus, cette solution présente un risque d'erreur de saisie et de traitement, et génère une augmentation du temps lié à l'encaissement (rupture dans le flux, génération d'une éventuelle attente aux caisses). Cette solution implique également un traitement des impayés non 35 automatisé, dont la garantie des paiements est possible mais onéreuse (recours à un établissement financier).
Cette solution présente également un inconvénient majeur pour le consommateur. En effet, ce mode de paiement nécessite des pièces que le consommateur n'a pas nécessairement sur lui, comme un RIB ou une pièce d'identité. La présente invention a pour but de résoudre tout ou partie des inconvénients mentionnés ci-dessus. A cet effet, la présente invention a pour objet un système de paiement multi échéances pour réaliser une transaction entre un client porteur de moyens d'identification et de paiement comprenant un identifiant unique et un commerçant dans un point de vente du commerçant, caractérisé en ce qu'il comprend : - un terminal d'acceptation destiné à équiper le point de vente du commerçant, ledit terminal d'acceptation comprenant : - des moyens de lecture des moyens d'identification et de paiement destinés à identifier le client à partir de son identifiant unique, - des moyens d'interface destinés à permettre au client ou au commerçant de définir des paramètres d'une transaction, ces paramètres comprenant au moins : - un montant total à payer pour la transaction, - un nombre d'échéances pour payer le montant total à payer pour la transaction, - des premiers moyens de communication avec un premier serveurrouteur distant au travers un premier canal de communication, pouvant 25 également communiquer avec au moins un deuxième serveur-routeur distant au travers un deuxième canal de communication, - des premiers moyens de traitement agencés de manière à : - envoyer vers le premier serveur-routeur distant l'identifiant unique du client, et les paramètres de la transaction via le premier canal de 30 communication des premiers moyens de communication, - envoyer vers l'au moins un deuxième serveur-routeur distant une demande d'autorisation de paiement sur le montant d'une première échéance de la transaction via le deuxième canal de communication des premiers moyens de communication, et 35 - recevoir de ce même au moins un deuxième serveur-routeur distant la réponse sur cette demande d'autorisation de paiement sur le montant de cette première échéance de la transaction via le deuxième canal de communication des premiers moyens de communication, - le premier serveur-routeur distant comprenant : - des deuxièmes moyens de communication agencés pour recevoir depuis le terminal d'acceptation l'identifiant unique du client, et les paramètres de la transaction via le premier canal de communication des premiers moyens de communication, et destinés à communiquer avec l'au moins un deuxième serveur-routeur distant au travers un troisième canal de communication, - une base de données agencée de manière à : - stocker un agencement de données dites d'échéances comprenant l'identifiant unique du client et les paramètres de la transaction en provenance du terminal d'acceptation, et - des deuxièmes moyens de traitement agencés pour : - créer l'agencement de données d'échéances dans la base de 15 données, - déterminer et inscrire dans l'agencement de données d'échéances les dates et les montants des échéances en fonction d'une date effective de la transaction et des paramètres de la transaction, - envoyer les données d'échéances au terminal d'acceptation 20 via le premier canal de communication de manière à permettre l'envoie depuis le terminal d'acceptation de la demande d'autorisation de paiement sur le montant de la première échéance de la transaction vers le deuxième serveurrouteur distant via le deuxième canal de communication - exécuter le paiement d'un montant d'échéance à la date 25 respective de l'échéance déterminée et inscrite dans la base de données, les premiers moyens de traitement et/ou les.deuxièmes moyens de traitements étant agencés pour valider ou annuler la création de l'agencement de données d'échéances en fonction de la réponse sur la demande d'autorisation de paiement sur le montant de la première échéance de la transaction. 30 Ces dispositions permettent d'effectuer un découpage automatisé d'une transaction de paiement tout en garantissant la sécurité et l'intégrité de la transaction globale. Chaque échéance d'une transaction permet d'identifier la transaction globale et ne peut être associée à un autre achat. En outre, ces dispositions permettent d'effectuer à l'aide d'un seul 35 et même moyen d'identification et de paiement, un paiement à échéances et un paiement à débit immédiat sans que le client n'ait besoin d'effectuer deux opérations différentes. Selon un aspect de l'invention, les deuxièmes moyens de traitement sont agencés de manière à : - émettre une demande d'autorisation de paiement sur un montant fictif à destination du deuxième serveur-routeur distant via le troisième canal de communication des deuxièmes moyens de communication, - recevoir une réponse sur la demande d'autorisation de paiement sur un montant fictif émise par le deuxième serveur-routeur distant via le troisième 10 canal de communication des deuxièmes moyens de communication. Selon un aspect de l'invention, le montant fictif est égal à un montant minime, par exemple inférieur à cinq euros. Cette disposition permet de contrôler si le compte du client auxquels sont associés les moyens de paiement du client ne comprend pas 15 une opposition formée à l'encontre de l'utilisation de ce moyens de paiement. Selon un aspect de l'invention, le montant fictif est égal au montant total de la transaction. Cette disposition permet de contrôler si le compte du client auxquels sont associés les moyens de paiement du client est suffisament 20 approvisionné à la date de la transaction. Selon un aspect de l'invention, lors de l'exécution du paiement d'un montant d'échéance à la date respective de l'échéance déterminée et inscrite dans la base de données, les deuxièmes moyens de traitement sont agencés de manière à : 25 - émettre une demande d'autorisation de paiement sur le montant de l'échéance à la date respective de l'échéance déterminée et inscrite dans la base de données à destination du deuxième serveur-routeur distant via le troisième canal de communication des deuxièmes moyens de communication, - recevoir une réponse sur la demande d'autorisation de paiement sur le 30 montant de l'échéance à la date respective de l'échéance déterminée et inscrite dans la base de données à destination du deuxième serveur-routeur distant via le troisième canal de communication des deuxièmes moyens de communication. Selon un aspect de l'invention, les deuxièmes moyens de 35 traitement sont agencés pour créer dans la base de données un identifiant unique associé à l'agencement de données d'échéances correspondant à une première transaction de manière à prendre en compte les données d'échéances de la première transaction lors d'une deuxième transaction ultérieure à la première transaction. Selon un aspect de l'invention, le terminal d'acceptation est un 5 terminal de paiement électronique, un micro ordinateur, une caisse enregistreuse ou un ordiphone. Cette disposition permet de diversifier les moyens de paiement et d'identification du client. Selon un aspect de l'invention, les moyens d'interface du terminal 10 d'acceptation comprennent des moyens d'affichage. Cette disposition permet au client de suivre le déroulement de sa transaction mais peut également permettre de réaliser la sélection d'un choix dans le cas par exemple d'un moyen d'affichage à écran tactile. Selon un aspect de l'invention, le terminal d'acceptation comprend 15 des moyens d'édition d'un ticket à destination du client et/ou un ticket à destination du commerçant. Cette disposition permet au client et/ou au commerçant de conserver une trace de la transaction en cas d'erreurs sur les données en relation avec la transaction. 20 Selon un aspect de l'invention, les premiers moyens de communication du terminal d'acceptation avec un premier serveur-routeur distant utilisent des protocoles du type GPRS, IP ou RTC. Selon un aspect de l'invention, les données échangées entre les premiers moyens de communication du terminal d'acceptation et les 25 deuxièmes moyens de communication du premier serveur-routeur distant sont cryptées. Selon un aspect de l'invention, les premiers moyens de traitement sont évolutifs et paramétrables depuis le premier serveur-routeur distant relié au terminal d'acceptation via les premiers moyens de communication. 30 Cette disposition permet de vérifier la présence d'éventuelles mise à jour et de télécharger des paramètres de fonctionnement. La présente invention concerne également un procédé de paiement pour réaliser une transaction entre un client porteur de moyens d'identification et de paiement comprenant un identifiant unique et un commerçant dans un 35 point de vente du commerçant, caractérisé en ce qu'il comprend les étapes consistant à : - permettre la lecture d'un moyen d'identification et de paiement par un terminal d'acceptation, - identifier le client à partir de son identifiant unique, - sélectionner un mode de paiement multi échéances sur le terminal 5 d'acceptation, sinon basculer vers un autre mode de paiement, - saisir le montant total de la transaction du client sur le terminal d'acceptation, - saisir le nombre d'échéances pour le paiement de l'achat du client sur le terminal d'acceptation, 10 - transmettre les données sur la transaction en cours à un premier serveur-routeur distant, - calculer à l'aide de moyens de traitement du premier serveurrouteur distant le montant et la date de paiement de chaque échéance, - transmettre depuis le premier serveur-routeur distant vers le 15 terminal d'acceptation au moins le montant préalablement calculé de la première échéance de la transaction, - valider le montant de la première échéance de la transaction sur le terminal d'acceptation, sinon interrompre la transaction, - envoyer directement depuis le terminal d'acceptation une demande 20 d'autorisation de paiement sur le montant de la première échéance de la transaction auprès d'au moins un deuxième serveur-routeur distant, - recevoir directement une réponse sur le terminal d'acceptation sur la demande d'autorisation de paiement sur le montant de la première échéance de la transaction de la part de l'au moins un deuxième serveur-routeur distant, 25 - le cas échéant, créer un agencement de données dites d'échéances dans une base de données du premier serveur-routeur distant pour permettre le paiement à échéance des autres échéances, sinon interrompre la transaction en cours. Ces différentes étapes permettent au client de sélectionner un 30 mode de paiement multi échéances à partir d'un même moyen de paiement lui servant d'habitude à effectuer des paiements à débit immédiat sur le montant total de la transaction. En outre, le paiement à échéances et le paiement à débit immédiat de la première échéance sont réalisés communément, par exemple sans que 35 le client n'ait besoin de retirer sa carte de paiement pour réaliser et valider les deux opérations.
Selon une mise en oeuvre du procédé, le procédé comprend une étape supplémentaire mise en oeuvre après l'étape consistant à transmettre les données sur la transaction en cours à un premier serveur-routeur distant, ladite étape supplémentaire consistant à : - demander depuis le premier serveur-routeur distant une autorisation de paiement sur un montant fictif à destination du deuxième serveur-routeur distant, - recevoir sur le premier serveur-routeur distant une réponse sur la demande d'autorisation de paiement sur un montant fictif émise par le 10 deuxième serveur-routeur distant, - seulement si la réponse est positive basculer à l'étape consistant à calculer le montant et la date de paiement de chaque échéance, sinon interrompre la transaction T. Cette étape supplémentaire permet de vérifier qu'il n'y a pas 15 d'oppositions sur le compte client à prélever et/ou que ce compte est suffisament approvisonné selon le montant choisi lors de la demande. Selon une mise en oeuvre du procédé, le procédé comprend une étape supplémentaire d'édition d'un ticket récapitulatif à destination du client et/ou à destination du commerçant réalisée après l'étape de création d'un 20 agencement de données dites d'échéances dans une base de données du premier serveur-routeur distant. De toute façon, l'invention sera bien comprise à l'aide de la description qui suit, en référence au dessin schématique annexé représentant, à titre d'exemple non limitatif, un système ainsi que les étapes d'un procédé 25 selon l'invention. La figure 1 est un schéma synoptique illustrant une première partie du système selon l'invention comprenant des moyens d'identification et de paiement et un terminal d'acceptation. La figure 2 est un schéma synoptique illustrant une deuxième partie 30 du système selon l'invention comprenant un premier serveur-routeur distant. La figure 3 est une vue d'ensemble comprenant le système et illustrant les différentes flux de communication entre différents éléments interagissant dans et avec le système. La figure 4 est un schéma illustrant les étapes du procédé selon 35 l'invention.
La figure 5 est un schéma illustrant les étapes d'une variante du procédé de la figure 4. Comme illustré à la figure 1, un système 1 de paiement multi échéances pour réaliser une transaction T entre un client porteur de moyens 5 d'identification et de paiement 2 comprenant un identifiant unique Id et un commerçant dans un point de vente du commerçant comprend une première partie la destinée à être présente dans le point de vente au moment de la transaction T et une deuxième partie lb comprenant un premier serveurrouteur distant 20 destiné à être installé dans un site d'hébergement spécialisé 10 et sécurisé. Les moyens d'identification et de paiement 2 comprennent un identifiant unique Id et sont la propriété du client. La première partie 1 a du système 1 comprend un terminal d'acceptation 10 utilisé par le commerçant auprès duquel le client désire 15 effectuer sa transacation T sous forme de paiement de proximité. Les moyens d'identification et de paiement 2 sont habituellement constitués par une carte de paiement électronique 2a dont la puce électronique comprend l'identifiant unique Id du client, et associée à un compte en banque surveillé par un serveur-routeur distant appartenant à la banque du client et 20 faisant partie plus généralement d'un système d'information 50 illustré à la figure 3. Comme illustré sur cette même figure 3, le terminal d'acceptation 10 peut prendre la forme d'un terminal de paiement électronique 10a, d'un micro ordinateur 10b, d'une caisse enregistreuse 10c ou d'un ordiphone 10d. 25 Le fonctionnement de certains de ces terminaux d'acceptation 10 est explicité plus loin dans le texte. En outre, le terminal d'acceptation 10 comprend tout d'abord des moyens de lecture 11 des moyens d'identification et de paiement 2 du client. Ces moyens de lecture 11 comprennent par exemple un lecteur de 30 carte à puce agencé pour lire les informations contenus dans la puce électronique de la carte électronique de paiement 2a. Dans un souci de sécurisation des données, l'accès à ces données est soumis à un code secret numérique connu du seul client et les données échangées sont cryptées. Le terminal d'acceptation 10 comprend également des moyens 35 d'interface 12 agencés pour permettre au client de définir des paramètres P d'une transaction T.
Ces moyens d'interface 12, dans le cas d'un terminal électronique de paiement 10a, comprennent par exemple des moyens d'affichage 18 et un clavier 19. Les moyens d'affichage 18 permettent d'afficher une requête émise 5 par le terminal d'acceptation 10 auprès du client, tandis que le clavier 19 permet de répondre à cette requête. Une première requête porte sur un premier paramètre de la transaction T. Il s'agit du montant total Z à payer pour la transaction T. Une deuxième requête porte sur un deuxième paramètre de la 10 transaction T. Il s'agit du nombre d'échéances n désiré par le client pour payer le montant total Z à payer pour la transaction T. Bien entendu ces paramètres P peuvent être renseignés indifféremment par le client ou le commerçant sur le clavier 19 du terminal d'acceptation 10. 15 De même, les valeurs de ces paramètres peuvent être soumises à des restrictions souhaitées par le commerçant et/ou par sa banque, par exemple un montant maximal pour la transaction et un nombre d'échéance limité, généralement de deux à quatre. Dans le cas d'un micro ordinateur 10b, les moyens de lecture 11 20 peuvent comprendre un lecteur de carte externe ou une interface sécurisée pour la saisie du numéro de carte. Une caisse enregistreuse 10c peut quant à elle directement intégrer un terminal de paiement électronique 10a. Un ordiphone 10d peut quant à lui disposer d'un lecteur de carte 25 externe ou d'une application sécurisée de saisie du numéro de cartes. Cependant, aucun de ces terminaux d'acceptation 10a, 10b, 10c, 10d n'est équipé de moyens d'identification et de paiement 2. Ces terminaux d'acceptation 10a, 10b, 10c, 10d n'ont qu'une fonction permettant l'interaction entre le client et le système 1 de paiement multi échéances. 30 L'ordiphone 10d peut faire office de terminal d'acceptation 10 mais aussi, dans l'éventualité où celui-ci est équipé d'un dispositif spécifique utilisant par exemple une technologie NFC ou une carte SIM ou SD dotée de fonctionnalité bancaire, peut faire office de moyen de paiement 2. Le terminal d'acceptation 10 comprend des premiers moyens de 35 communication 13 lui permettant de communiquer par flux de données FD vers l'extérieur du point de vente, notamment vers la deuxième partie lb du 2 9 79450 11 système 1 représentée à la figure 2 au travers un premier canal de communication FD1 ainsi que vers au moins un deuxième serveur-routeur distant 30 au travers un deuxième canal de communication FD2, le deuxième serveur-routeur distant 30 étant généralement un serveur-routeur distant de la banque du commerçant représenté à la figure 3. Ces premiers moyens de communication 13 du terminal d'acceptation 10 utilisent des protocoles du type GPRS, IP ou RTC. Les types de communication peuvent différer selon la nature du terminal d'acceptation 10. L'utilisation de protocole spécifique dépend 10 notamment du type de technologie et des canaux de communication FD1, FD2. Le terminal d'acceptation 10 comprend également des premiers moyens de traitement 14 dont les fonctions sont décrites plus loin dans le texte. Dans un mode de réalisation préféré, le terminal d'acceptation 10 comprend une première base de données 16 et des moyens d'édition de ticket 15 15 permettant au client et/ou au commerçant de conserver une preuve physique de la transaction T réalisée par le client. La première base de données 16 est destinée à stocker un fichier dit de remise 17 créé par les premiers moyens de traitement 14. Ce fichier de remise 17 comprend des informations permettant d'identifier de façon unique la 20 transaction T. Plus précisément, le fichier de remise 17 contient des informations sur l'ensemble des transactions T effectuées sur le terminal d'acception 10 considéré sur une durée donnée, par exemple au cours d'une journée. La fonction de ce fichier de remise 17 est explicité plus loin dans le 25 texte. Ces informations sont par exemple la date, l'heure et le montant total de la transaction T, le numéro de la carte utilisée par le client, l'identifiant du commerçant idc' ou le numéro d'une demande Tdir d'autorisation de paiement dont l'acheminement est décrit plus loin dans le 30 texte. Les premiers moyens de traitement 14 sont également agencés pour envoyer vers le premier serveur-routeur distant 20 l'identifiant unique Id du client, et les paramètres P de la transaction T via le premier canal de communication FD1 des premiers moyens de communication 13. 35 De plus, comme il apparait à la figure 4, les premiers moyens de traitement 14 sont destinés à envoyer vers le deuxième serveur-routeur distant 30 représenté aux figures 3 à 5, une demande Tdir d'autorisaton de paiement de la première échéance n1 de la transaction T via le deuxième canal de communication FD2 des premiers moyens de communication 13 ainsi que de recevoir directement de ce même deuxième serveur-routeur distant 30 la réponse Rdir sur cette demande Tdir d'autorisation de paiement sur le montant de cette première écéhance n1 de la transaction T via le deuxième canal de communication FD2 des premiers moyens de communication 13. La fonction de cette demande Tdir d'autorisation de paiement est décrite plus loin dans le texte. Toutefois, cette demande Tdir d'autorisation de paiement génère le numéro de demande d'autorisation de paiement mentionné précédemment et présent dans le fichier de remise 17 stocké dans la première base de données 16. Comme illustré à la figure 2, le premier serveur-routeur distant 20 comprend quant à lui des deuxièmes moyens de communication 21 agencés 15 pour communiquer par flux de données FD notamment avec le terminal d'acceptation 10 et le deuxième serveur-routeur distant 30. Plus précisément, ces deuxièmes moyens de communication 21 permettent de recevoir depuis le terminal d'acceptation 10 l'identifiant unique Id du client et les paramètres P de la transaction T via le premier canal de 20 communication FD1 des premiers moyens de communication 13. L'identifiant unique Id du client, les paramètres P de la transaction T en provenance du terminal d'acceptation 10 sont stockées dans un agencement de données dites d'échéances 24 sur une deuxième base de données 22 du premier serveur-routeur distant 20. 25 A cet instant, un identifiant unique idspur associé à cet agencement de données d'échéances 24 est créé dans la deuxième base de données 22. Cet identifiant unique idspur sert par la suite au traitement des transactions arrivées à échéances et dans le suivi de ces transactions. En outre, le premier serveur-routeur distant 20 comprend des 30 deuxièmes moyens de traitement 23 agencés pour créer l'agencement de données d'échéances 24 dans la deuxième base de données 22 et pour déterminer et inscrire dans l'agencement de données d'échéances 24 à partir des paramètres P déjà présents dans l'agencement de données d'échéances 24 contenues dans la base de données 22, les dates dX et les montant mx des 35 n échéances en fonction d'une date effective d de la transaction T correspondant au jour réel auquel est réalisé la transaction T sous sa forme de paiement de proximité. Dans un second temps, les deuxièmes moyens de traitement 23 du premier serveur-routeur distant 20 exécutent le paiement d'un montant d'échéance mx aux dates dx déterminées des échéances déterminées nx inscrites dans l'agencement de données d'échéances 24 de la base de données 22. L'exécution du paiement d'un montant d'échéance nx est détaillé plus loin dans le texte.
Afin de valider la transaction T, la demande Tdir d'autorisation de paiement sur le montant de la première échéance n1 mentionnée précédemment est envoyée directement depuis le terminal d'acceptation 10 vers le deuxième serveur-routeur distant 30 au moment de la transaction T entre le client et le commerçant via le deuxième canal de communication FD2 des premiers moyens de communication 13. La fonction de cette demande Tdir d'autorisation de paiement mentionnée précédemment est donc de valider ou d'annuler la création de l'agencement de données d'échéances 24 dans la deuxième base de données 22 du premier serveur-routeur distant 30 et donc de valider ou d'annuler la transcation T entre le client et le commerçant au moment de la réponse du deuxième serveur-routeur distant 30 au terminal d'acceptation 10. La date dl déterminée par les deuxièmes moyens de traitement 23 pour le paiement du montant m1 de la première échéance n1 correspond donc à la date effective d de réalisation de la transaction T entre le client et le 25 commerçant. Cependant, le paiement effectif de cette première échéance n1 n'est pas réalisé au moment de la transaction T. En effet, la validation de la demande Tdir d'acceptation de paiement est stockée sous forme d'ordre de paiement Qni dans le fichier de remise 17 30 contenu dans la première base de données 16 du terminal d'acceptation 10. Le paiement effectif du montant m1 de la première échéance n1 est réalisé ultérieurement à un moment déterminé lors d'une procédure bancaire appelée télécollecte TC déclenchant le mécanisme de compensation. Comme illustrée aux figures 3 à 5, la télécollecte TC est la 35 récupération à distance par le deuxième serveur-routeur distant 30 de la banque du commerçant du fichier de remise 17 enregistré dans la base de données 16 de chacun des terminaux d'acceptation 10 reliés au premier serveur-routeur distant 20. Les premiers moyens de traitement 14 compilent dans le fichier de remise 17 les données nécessaires pour effectuer une compensation entre la 5 banque du client porteur et la banque de l'accepteur commerçant. Dans le domaine monétique, la compensation est un mécanisme permettant à des banques et des institutions financières de déboucler une transaction T réalisée entre un porteur par exemple le client, et un accepteur par exemple le commerçant. 10 La compensation se matérialise par un solde net dû ou à recevoir ainsi que par les flux financiers de débit ou crédit entre banques. La télécollecte TC et le traitement des fichiers de remises 17 par le deuxième serveur-routeur distant 30 de la banque du commerçant lui permet d'adresser une demande de recouvrement à la banque de chacun des clients 15 identifiés par leur identifiant id1, id2,..., idx par l'intermédire du système d'information 50 sur lequel sont reliés le deuxième serveur-routeur distant 30 et l'ensemble des serveurs-routeurs distants de la banque de chacun des clients. A la réception de cet ordre de paiement Qni et après vérification de l'authenticité, la banque du client considéré déclenche le règlement, c'est-à20 dire débite le client du montant m1 associé à l'ordre de paiement Qn1 puis crédite la banque teneur du compte du commerçant de ce même montant m1. La télécollecte TC se fait généralement la nuit, à la fin de l'activité journalière du commerçant. Le terminal d'acceptation 10 par l'intermédiaire de ces premiers moyens de traitement 14 et de son deuxième canal de 25 communication FD2 de ses premiers moyens de communication 13 appelle et transmet le fichier de remise 17 vers le deuxième serveur-routeur distant 30 en utilisant par exemple une ligne RTC ou une connexion IP. De la même façon, à chaque échéance, le premier serveur-routeur distant crée un fichier de remise avec un ordre de paiement Qnx d'un montant 30 égal au montant mx de l'échéance nx. Le premier serveur-routeur distant 20 par l'intermédiaire de ses deuxièmes moyens de traitement 23 trie et compile ses données en ordre de débit et de crédit dans ce fichier de remise puis les transfère à chacun des établissements bancaires concernés afin de débloquer l'ordre de paiement Qnx 35 de l'échéance nx entre le client et le commerçant.
Dans un deuxième mode de réalisation, le système 1 vérifie au préalable lors de la transaction T que le compte en banque associé aux moyens d'identification et de paiement 2 du client ne fait pas l'objet d'une opposition ou est suffisamment approvisionné.
Pour cela, les deuxièmes moyens de traitement 23 du premier serveur-routeur distant 20 sont agencés de manière à émettre une demande Tfic d'autorisation de paiement sur un montant fictif mfic à destination du deuxième serveur-routeur distant 30 via ses deuxièmes moyens de communication 21, et à recevoir via ses mêmes deuxièmes moyens de communication 21, une réponse Rfic sur la demande Tfic d'autorisation de paiement sur un montant fictif mfic émise par le deuxième serveur-routeur distant 30 suite à sa consultation du système d'information 50. Selon que le montant fictif mfic porte sur un montant minime, par exemple inférieur à cinq euros ou sur le montant total de la transaction T, le commerçant a la possibilité de vérifier si une opposition a été formé à l'encontre du compte à débiter du client ou bien si celui-ci est suffisamment approvisionné. En effet, si une opposition est formée à l'encontre du compte du client associé au moyen d'identification et de paiement 2 alors cette information 20 est véhiculée par le système d'information 50 jusqu'au deuxième serveurrouteur distant 30 et transmise sous la forme d'un refus de débit jusqu'au terminal d'acceptation 10 par l'intermédiaire du premier serveur-routeur distant 20. Une demande de paiement suffit pour vérifier si une oposition est 25 formée à l'encontre du compte du client. Au cours de cette demande Tfic, aucune transaction n'est réalisée. Ce montant fictif peut également prendre en considération des montants d'échéances d'une première transaction T1 antérieure à la transaction en cours T2 toutes deux réalisées par le même client 30 Ces montants d'échéances sont stockées dans les agencements de données d'échéances 24 de la base de données 22 du premier serveurrouteur distant 20 et facilement identifiables à partir de leur identifiant unique idspur- Comme cela apparait à la figure 3, le premier serveur-routeur 35 distant 20 a également la possibilité d'aller consulter le Fichier national des Incidents de remboursement des Crédits aux Particuliers dit fichier FICP sur un troisième serveur-routeur distant 40 hébergé sur un site sécurisé de la Banque de France sans pour autant devoir émettre une demande d'autorisation de paiement sur un montant fictif. Le premier serveur-routeur distant 20 émet alors une demande 5 directe TFicp auprès du troisième serveur-routeur distant 40 et reçoit directement sa réponse RFicp pour voir si le client est fiché dans le fichier FICP de la Banque de France. Selon cette réponse la transaction est poursuivie ou interrompue. Les premiers moyens de traitement 14 sont évolutifs et 10 paramétrables depuis le premier serveur-routeur distant 20 relié via ses deuxièmes moyens de communication 21 au terminal d'acceptation 10 via le premier canal de communication FD1 de ses premiers moyens de communication 13. Ces paramètres de configuration du terminal d'acceptation 10 15 peuvent par exemple inclure les adresses ou numéro d'appel des différents serveur-routeur distant 20, 30 avec lesquels le terminal d'acceptation 10 est amené à communiquer ainsi qu'une indication sur le montant fictif mfic sur lequel doit porter la demande Tfic d'autorisation de paiement à destination du deuxième serveur-routeur distant 30. 20 Le premier serveur-routeur distant 20 est également paramétrable et sa base de données 22 comprend également les adresses ou numéro d'appel des différents serveur-routeur distant 30, 40 avec lesquels le premier serveur-routeur distant 20 est amené à communiquer. En outre, la base de données 22 comprend également en plus des 25 agencements de données d'échéances 24 décrits précédemment, des agencements de données respectifs concernant chacun des commerçants ayant adhéré au système 1 de paiement multi échéances. Ces agencements de données respectifs comprennent par exemple des paramètres fonctionnels renseignant sur l'adresse ou le numéro 30 d'appel du terminal d'acceptation 10 du commerçant considéré ainsi que des paramètres plus spécifiques concernant le taux de commission négocié sur la transaction T pour la rémunération du propriétaire du système 1, les types de moyens d'identification et de paiement 2 autorisés par le commerçant ou encore les garanties et restrictions de paiement définies par le commerçant. 35 L'ensemble des données présentes dans la base de données 22 peuvent également être compilées en vue de réaliser des statistiques et permettent également d'établir un compte rendu des succès et erreurs d'opérations transactionnelles. Le fonctionnement d'un tel système 1 de paiement multi échéances peut être segmenté en plusieurs étapes pouvant se situer dans le temps les 5 unes par rapport aux autres, conduisant naturellement à un procédé de paiement P1 faisant également l'objet de la présente invention. Ce procédé de paiement P1 pour réaliser une transaction T entre un client porteur de moyens d'identification et de paiement 2 comprenant un identifiant unique Id et un commerçant dans un point de vente du commerçant 10 comprend plusieurs étapes se situant temporellement les unes par rapport aux autres. Comme illustré à la figure 4, une première étape A de ce procédé P1 consiste à permettre la lecture d'un moyen d'identification et de paiement 2 du client par un terminal d'acceptation 10. 15 Dans le cas d'une carte de paiement 2a, cette étape A consiste à se saisir de la carte de paiment 2a et à l'introduire dans les moyens de lecture 11 du terminal de paiement électronique 10a. Une deuxième étape B consiste à identifier le client à partir de son identifiant unique Id, notamment par une lecture des moyens d'identification et 20 de paiement 2 qui par l'intermédiaire du premier serveur-routeur distant 20 et du deuxième serveur-routeur distant 30 a accès au système d'information 50. Une troisième étape C consiste à sélectionner un mode de paiement multi échéances sur le terminal d'acceptation 10. Pour cela, et dans le cas d'un terminal de paiement électronique 25 10a, le client peut se servir du clavier 19 des moyens d'interface 12. Si le client sélectionne ce type de paiement multi échéances alors le procédé se poursuit vers une quatrième étape D. Si le client ne sélectionne pas ce type de paiement multi échéances mais préfère payer directement le montant total Z de sa transaction T à l'aide 30 de ses moyens d'identification et de paiement 2 par l'intermédiaire du dispositif d'acceptation 10, alors le procédé de paiement multi échéances P1 est interrompu et bascule vers un procédé de paiement à débit immédiat P2 non détaillé car connu en soi. Une quatrième étape D consiste à saisir le montant total Z de la 35 transaction T du client sur le terminal d'acceptation 10.
Pour cela, dans le cas d'un terminal de paiement électronique 10a, le client peut également se servir du clavier 19 des moyens d'interface 12. La cinquième étape E consiste de la même façon à saisir le nombre d'échéances n pour le paiement de l'achat du client sur le terminal d'acceptation 10. Une liste d'aide à la sélection peut éventuellement s'afficher sur les moyens d'affichage 18. Bien entendu, la quatrième étape D et la cinquième étape E peuvent être réversibles.
Une sixième étape F consiste à transmettre les données sur la transaction T en cours au premier serveur-routeur distant 20 afin que ce dernier puisse exploiter ces données. La sixième étape conduit à une septième étape G dans laquelle le premier serveur-routeur distant 20 calcule le montant mx et la date dx de 15 paiement de chaque échéance. Une huitième étape H consiste à transmettre depuis le premier serveur-routeur distant 20 vers le terminal d'acceptation 10 le montant préalablement calculé de la première échéance n1 de la transaction T. Une neuvième étape I consiste à valider le montant de la première 20 échéance n1 de la transaction T sur le terminal d'acceptation 10, sinon interrompre la transaction T. Cette étape donne ainsi la possibilité au client d'interrompre la transaction T. Une dixième étape J consiste à envoyer directement depuis le 25 terminal d'acceptation 10 une demande Tdir d'autorisation de paiement sur le montant de la première échéance n1 de la transaction T auprès d'au moins un deuxième serveur-routeur distant 30. Ce deuxième serveur-routeur distant 30 est notamment le serveur de la banque du commerçant qui est relié au système d'information 50. 30 Une onzième étape K consiste à recevoir directement sur le terminal d'acceptation 10 une réponse sur cette demande d'autorisation de paiement sur le montant de la première échéance de la transaction T de la part de l'au moins un deuxième serveur-routeur distant 30. La dixième étape J et la onzième étape K valident donc la 35 transaction T entre le client et le commerçant.
Une douzième étape L consiste en cas d'acceptation de réponse positive sur la demande d'acceptation de paiement sur le montant de la première échéance n1 par la banque du commerçant, à créer un agencement de données dites d'échéances 24 dans une base de données 22 du premier serveur-routeur distant 20 pour permettre le paiement à échéance des autres échéances n2...nn, sinon interrompre la transaction T en cours. Parallèlement à cette étape L, les premiers moyens de traitement 14 procèdent au stockage d'un ordre de paiement Qni de la première échéance n1, sans identification supplémentaire du client, et créent un fichier de remise 17 dans la première base de données 16 du terminal d'acceptation 10 pour permettre le stockage de l'ordre de paiement Qni de la première échéance n1 en vue d'une télécollecte TC ultérieure. Une autre étape postérieure à la douzième étape L consiste à réaliser la télécollecte TC du fichier de remise 17 du terminal d'acceptation 10 15 à partir du deuxième serveur-routeur distant 30 pour permettre le débit du compte du client et créditer le compte du commerçant. Dans une étape non illustrée postérieure à cette autre étape, l'agencement de données d'échéances 24 permet au premier serveur-routeur distant 20 de transmettre pour chaque transaction à chaque échéance une 20 demande d'autorisation de paiement vers le deuxième routeur-serveur distant 30 tout comme l'a précédemment fait le terminal d'acceptation 10 pour la première échéancen n1. Si cette demande est validée, les deuxièmes moyens de traitement 23 créent alors un ordre de paiement Qnx stocké temporairement dans un 25 fichier de remise de la deuxième base de données 22., le montant correspondant à cet ordre de paiement Qnx étant égal au montant calculé de l'échéance nx considérée. Ce fichier de remise est ensuite transmis lors d'une télécollecte à chacun des établissements bancaires concernés afin de débloquer l'ordre de 30 paiement Qnx de l'échéance nx entre le client et le commerçant. Selon une variante de ce procédé P1 illustrée à la figure 5, une étape supplémentaire N est intercalée entre la sixième étape F et la septième étape G. Cette étape supplémentaire N se décompose en trois sous-étapes 35 N1, N2 et N3.
La première sous-étape N1 consiste à demander depuis le premier serveur-routeur distant 20 une demande Tfic d'autorisation de paiement sur un montant fictif mfic à destination du deuxième serveur-routeur distant 30. La deuxième sous-étape N2 consiste à recevoir sur le premier 5 serveur-routeur distant 20 une réponse Rfic sur la demande Tfic d'autorisation de paiement sur un montant fictif mfic émise par le deuxième serveur-routeur distant 30. La troisième sous-étape N3 réalisée seulement si la réponse Rfic est positive consiste à basculer à la septième étape G sinon interrompre la 10 transaction T. Selon une variante de ce procédé P1 illustrée également à la figure 5, une autre étape supplémentaire M d'édition d'un ticket récapitulatif à destination du client et/ou à destination du commerçant est réalisée après la douzième étape L. 15 Un message d'état signalant l'interruption de la transaction T après la non validation par le client à l'étape I du montant de la premère échéance n1 est envoyé vers le premier serveur-routeur distant 20 qui par l'intermédiaire de ces deuxièmes moyens de traitement 23 va alors effacer de sa deuxième base de données 22 l'agencement de données 24 propre à cette transaction T. 20 De la même façon, suite à une réponse négative sur une demande de paiement aux étapes K ou N2, le terminal d'acceptation 10 par l'intermédiaire de ses premiers moyens de traitement 14 va alors purger sa première base de données 16 en effaçant les paramètres P propres à cette transaction T. 25 Bien que l'invention ait été décrite en liaison avec des exemples particuliers de réalisation, il est bien évident qu'elle n'y est nullement limitée et qu'elle comprend tous les équivalents techniques des moyens décrits ainsi que leurs combinaisons.
Claims (15)
- REVENDICATIONS1. Système (1) de paiement multi échéances pour réaliser REVENDICATIONS1. Système (1) de paiement multi échéances pour réaliser une transaction (T) entre un client porteur de moyens d'identification et de 5 paiement (2) comprenant un identifiant unique (Id) et un commerçant dans un point de vente du commerçant, caractérisé en ce qu'il comprend : - un terminal d'acceptation (10) destiné à équiper le point de vente du commerçant, ledit terminal d'acceptation (10) comprenant : - des moyens de lecture (11) des moyens d'identification et de 10 paiement (2) destinés à identifier le client à partir de son identifiant unique (Id), - des moyens d'interface (12) destinés à permettre au client ou au commerçant de définir des paramètres (P) d'une transaction (T), ces paramètres comprenant au moins : - un montant total (Z) à payer pour la transaction (T), 15 - un nombre (n) d'échéances pour payer le montant total (Z) à payer pour la transaction (T), - des premiers moyens de communication (13) avec un premier serveur-routeur distant (20) au travers d'un premier canal de communication (FD1), pouvant également communiquer avec au moins un deuxième serveur-20 routeur distant (30) au travers d'un deuxième canal de communication (FD2), - des premiers moyens de traitement (14) agencés de manière à : - envoyer vers le premier serveur-routeur distant (20) l'identifiant unique (Id) du client, et les paramètres (P) de la transaction (T) via le premier canal de communication (FD1) des premiers moyens de 25 communication (13), - envoyer vers l'au moins un deuxième serveur-routeur distant (30) une demande d'autorisation (Td,,) de paiement sur le montant d'une première échéance (ni) de la transaction (T) via le deuxième canal de communication (FD2) des premiers moyens de communication (13), et 30 - recevoir de ce même au moins un deuxième serveur-routeur distant (30) la réponse (Rd,r) sur cette demande (Td,,) d'autorisation de paiement sur le montant de cette première échéance (ni) de la transaction (T) via le deuxième canal de communication (FD2) des premiers moyens de communication (13), 35 - le premier serveur-routeur distant (20) comprenant : - des deuxièmes moyens de communication (21) agencés pour recevoir depuis le terminal d'acceptation (10) l'identifiant unique (Id) du client, et les paramètres (P) de la transaction (T) via le premier canal de communication (FD1) des premiers moyens de communication (13), et destinés à communiquer avec l'au moins un deuxième serveur-routeur distant (30) au travers un troisième canal de communication (FD3), - une base de données (22) agencée de manière à : - stocker un agencement de données dit d'échéances (24) comprenant l'identifiant unique (Id) du client, les paramètres de la 10 transaction (T) en provenance du terminal d'acceptation (10),et - des deuxièmes moyens de traitement (23) agencés pour : - créer l'agencement de données d'échéances (24) dans la base de données (22), - déterminer et inscrire dans l'agencement de données 15 d'échéances (24), les dates (di, , dn) et les montants (mi, , mn) des échéances en fonction d'une date effective (d) de la transaction (T) et des paramètres (P) de la transaction (T), - envoyer les données d'échéances au terminal d'acceptation (10) via le premier canal de communication (FD1) de manière à 20 permettre l'envoi depuis le terminal d'acceptation (10) de la demande d'autorisation (Td,,) de paiement sur le montant de la première échéance (n1) de la transaction (T) vers le deuxième serveur-routeur distant (30) via le deuxième canal de communication (FD2), - exécuter le paiement d'un montant d'échéance (m2,..., mn) à 25 la date (d2,..., dn) respective de l'échéance déterminée et inscrite dans la base de données (22), les premiers moyens de traitement (14) et/ou les deuxièmes moyens de traitements (23) étant agencés pour valider ou annuler la création de l'agencement de données d'échéances (24) en fonction de la réponse (Rd,$) sur 30 la demande (Td,,) d'autorisation de paiement sur le montant de la première échéance (n1) de la transaction (T).
- 2. Système (1) selon la revendication 1, dans lequel les deuxièmes moyens de traitement (23) sont agencés de manière à : - émettre une demande (Tf,c) d'autorisation de paiement sur un 35 montant fictif (mf,c) à destination du deuxième serveur-routeur distant (30) via letroisième canal de communication (FD3) des deuxièmes moyens de communication (21), - recevoir une réponse (Rf,c) sur la demande (Tfic) d'autorisation de paiement sur un montant fictif (mf,c) émise par le deuxième serveur-routeur 5 distant (30) via le troisième canal de communication (FD3) des deuxièmes moyens de communication (30).
- 3. Système (1) selon la revendication 2, dans lequel le montant fictif (mf,c) est égal à un montant minime, par exemple inférieur à cinq euros.
- 4. Système (1) selon la revendication 2, dans lequel le montant 10 fictif (mf,c) est égal au montant total (Z) de la transaction (T).
- 5. Système (1) selon l'une des revendications 1 à 4, dans lequel lors de l'éxécution du paiement d'un montant d'échéance (m2,..., mn) à la date (d2,..., dn) respective de l'échéance déterminée et inscrite dans la base de données (22), les deuxièmes moyens de traitement (23) sont agencés de 15 manière à : - émettre une demande d'autorisation de paiement sur le montant d e l'échéance (m2, , mn) à I a date (d2, , dn) respective de l'échéance déterminée et inscrite dans la base de données (22) à destination du deuxième serveur-routeur distant (30) via le troisième canal de 20 communication (FD3) des deuxièmes moyens de communication (21), - recevoir une réponse sur la demande d'autorisation de paiement sur le montant de l'échéance (m2, , mn) à I a date (d2, dn) respective de l'échéance déterminée et inscrite dans la base de données (22) à destination du deuxième serveur-routeur distant (30) via le troisième canal de 25 communication (FD3) des deuxièmes moyens de communication (21).
- 6. Système (1) selon l'une des revendications 1 à 5, dans lequel les deuxièmes moyens de traitement (23) sont agencés pour créer dans la base de données (22) un identifiant unique (idspuT) associé à l'agencement de données d'échéances (24) correspondant à une première transaction (T1) 30 de manière à prendre en compte les données d'échéances de la première transaction (T1) lors d'une deuxième transaction (T2) ultérieure à la première transaction (T1).
- 7. Système (1) selon l'une des revendications 1 à 6, dans lequel le terminal d'acceptation (10) est un terminal de paiement 35 électronique(10a), un micro ordinateur (10b), une caisse enregistreuse (10c) ou un ordiphone (10d).
- 8. Système (1) selon l'une des revendications 1 à 7, dans lequel les moyens d'interface (12) du terminal d'acceptation (10) comprennent des moyens d'affichage (18).
- 9. Système (1) selon l'une des revendications 1 à 8, dans lequel le terminal d'acceptation (10) comprend des moyens d'édition d'un ticket (15) à destination du client et/ou un ticket à destination du commerçant.
- 10. Système (1) selon l'une des revendications 1 à 9, dans lequel les premiers moyens de communication (13) du terminal d'acceptation (10) avec un premier serveur-routeur distant (20) utilisent des 10 protocoles du type GPRS, IP ou RTC.
- 11. Système (1) selon l'une des revendications 1 à 10, dans lequel les données échangées entre les premiers moyens de communication (13) du terminal d'acceptation (10) et les deuxièmes moyens de communication (21) du premier serveur-routeur distant (30) sont cryptées. 15
- 12. Système (1) selon l'une des revendications 1 à 11, dans lequel les premiers moyens de traitement (14) sont évolutifs et paramétrables depuis le premier serveur-routeur distant (20) relié au terminal d'acceptation (10) via les premiers moyens de communication (13).
- 13. Procédé de paiement (P1) pour réaliser une transaction (T) 20 entre un client porteur de moyens d'identification et de paiement (2) comprenant un identifiant unique (Id) et un commerçant dans un point de vente du commerçant, caractérisé en ce qu'il comprend les étapes consistant à : (A) : permettre la lecture d'un moyen d'identification et de paiement (2) par un terminal d'acceptation (10), 25 (B) : identifier le client à partir de son identifiant unique (Id), (C) : sélectionner un mode de paiement multi échéances sur le terminal d'acceptation (10), sinon basculer vers un autre procédé de paiement (P2), (D) : saisir le montant total (Z) de la transaction (T) du client sur le 30 terminal d'acceptation (10), (E) : saisir le nombre d'échéances (n) pour le paiement de l'achat du client sur le terminal d'acceptation (10), (F) : transmettre les données sur la transaction (T) en cours à un premier serveur-routeur distant (20),(G) : calculer à l'aide de moyens de traitement (23) du premier serveur-routeur distant (20) le montant mn) et la date (di,..., dn) de paiement de chaque échéance (ni,..., ne), (H) : transmettre depuis le premier serveur-routeur distant (20) vers 5 le terminal d'acceptation (10) au moins le montant (mi) préalablement calculé de la première échéance (ni) de la transaction (T), (I) : valider le montant (mi) de la première échéance (ni) de la transaction (T) sur le terminal d'acceptation (10), sinon interrompre la transaction (T), 10 (J) : envoyer directement depuis le terminal d'acceptation (10) une demande (Td,r) d'autorisation de paiement sur le montant (mi) de la première échéance (ni) de la transaction (T) auprès d'au moins un deuxième serveurrouteur distant (30), (K) : recevoir directement une réponse (Rd,r) sur le terminal 15 d'acceptation (10) sur la demande (Td,,) d'autorisation de paiement sur le montant (mi) de la première échéance (ni) de la transaction (T) de la part de l'au moins un deuxième serveur-routeur distant (30), (L) : le cas échéant, créer un agencement de données dites d'échéances (24) dans une base de données (22) du premier serveur-routeur 20 distant (20) pour permettre le paiement à échéance des autres échéances (n2,..., ne), sinon interrompre la transaction (T) en cours.
- 14. Procédé de paiement selon la revendication 13, comprenant une étape supplémentaire (N) mise en oeuvre après l'étape (F) consistant à transmettre les données sur la transaction (T) en cours à un premier serveur-25 routeur distant (10), ladite étape supplémentaire (N) consistant à : (N1) : demander depuis le premier serveur-routeur distant (10) une demande (Tf,c) d'autorisation de paiement sur un montant fictif (mf,c) à destination du deuxième serveur-routeur distant (30), (N2) : recevoir sur le premier serveur-routeur distant (10) une 30 réponse (Rf,c) sur la demande (Tf,c) d'autorisation de paiement sur un montant fictif (mi,c) émise par le deuxième serveur-routeur distant (30), (N3): seulement si la réponse (Rf,c) est positive basculer à l'étape (G) consistant à calculer mn) et la date (di,..., de) de paiement de chaque échéance (ni,..., ne), sinon interrompre la transaction (T). 35
- 15. Procédé de paiement selon l'une des revendications 13 à 14, comprenant une étape supplémentaire (M) d'édition d'un ticket récapitulatifà destination du client et/ou à destination du commerçant réalisée après l'étape (L) de création d'un agencement de données dites d'échéances (24) dans une base de données (22) du premier serveur-routeur distant (20).
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1157455A FR2979450B1 (fr) | 2011-08-23 | 2011-08-23 | Systeme de paiement multi echeances |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1157455A FR2979450B1 (fr) | 2011-08-23 | 2011-08-23 | Systeme de paiement multi echeances |
Publications (2)
Publication Number | Publication Date |
---|---|
FR2979450A1 true FR2979450A1 (fr) | 2013-03-01 |
FR2979450B1 FR2979450B1 (fr) | 2016-02-05 |
Family
ID=45809065
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR1157455A Active FR2979450B1 (fr) | 2011-08-23 | 2011-08-23 | Systeme de paiement multi echeances |
Country Status (1)
Country | Link |
---|---|
FR (1) | FR2979450B1 (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114677138A (zh) * | 2021-05-19 | 2022-06-28 | 腾讯云计算(北京)有限责任公司 | 一种数据处理方法、设备以及计算机可读存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030061154A1 (en) * | 2001-09-24 | 2003-03-27 | Chacko Bobby J. | Systems and methods to facilitate an acquisition of information associated with a requested financial account |
US20040128256A1 (en) * | 2002-12-04 | 2004-07-01 | Krouse Wayne F. | Remote location credit card transaction system with card present security system |
US20040230535A1 (en) * | 2002-10-07 | 2004-11-18 | Philip Binder | Method and system for conducting off-line and on-line pre-authorized payment transactions |
US20090281937A1 (en) * | 2008-05-09 | 2009-11-12 | Embarq Holdings Company, Llc | System, Method and Apparatus for Associating a Credit Card Account with Sub-Account Codes |
-
2011
- 2011-08-23 FR FR1157455A patent/FR2979450B1/fr active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030061154A1 (en) * | 2001-09-24 | 2003-03-27 | Chacko Bobby J. | Systems and methods to facilitate an acquisition of information associated with a requested financial account |
US20040230535A1 (en) * | 2002-10-07 | 2004-11-18 | Philip Binder | Method and system for conducting off-line and on-line pre-authorized payment transactions |
US20040128256A1 (en) * | 2002-12-04 | 2004-07-01 | Krouse Wayne F. | Remote location credit card transaction system with card present security system |
US20090281937A1 (en) * | 2008-05-09 | 2009-11-12 | Embarq Holdings Company, Llc | System, Method and Apparatus for Associating a Credit Card Account with Sub-Account Codes |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114677138A (zh) * | 2021-05-19 | 2022-06-28 | 腾讯云计算(北京)有限责任公司 | 一种数据处理方法、设备以及计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
FR2979450B1 (fr) | 2016-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20190043026A1 (en) | Financial services ecosystem | |
CN109313762B (zh) | 用于表征预存资金支付的数据集的安全生成和处理的系统、方法和设备 | |
WO2023200840A1 (fr) | Réseau de jetons agnostique de chaîne de blocs | |
US20130246260A1 (en) | Mobile Payment Transaction System | |
EP1657687B1 (fr) | Carte de paiement prépayée à rechargement instantané à distance par coupon | |
CN107563747A (zh) | 用于进行组合支付的方法及装置 | |
CN101454794A (zh) | 移动的个人之间支付系统 | |
AU2008245878A1 (en) | System and method for performing person-to-person funds transfers via wireless communications | |
WO2011133958A2 (fr) | Procédé et système de facturation et de paiement inter-réseau | |
WO2018154082A1 (fr) | Système et procédé de traitement d'une transaction bancaire | |
AU2020281086A1 (en) | Payment Re-direction System and Topology and Programming Method | |
FR2923635A1 (fr) | Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants. | |
EP3692488A1 (fr) | Procédé et système pour réaliser une transaction de paiement sur un terminal bancaire avec un dispositif électronique | |
US9118761B1 (en) | Computing device assistance for phone based customer service representative interaction | |
FR2979450A1 (fr) | Systeme de paiement multi echeances | |
WO2019016470A1 (fr) | Procédé et système de gestion d'un paiement par porte-monnaie électronique | |
EP2824625B1 (fr) | Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant | |
WO2012042277A1 (fr) | Systèmes et procédés de transaction | |
WO2020128240A1 (fr) | Traitement d'un service de tickets electroniques | |
FR2905021A1 (fr) | Procede et systeme de paiement a l'aide d'un telephone mobile | |
WO2003007251A1 (fr) | Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre | |
GB2493331A (en) | Transaction Systems and Methods | |
EP1421564B1 (fr) | Dispostif de paiement | |
US20210110441A1 (en) | Student loan payment device | |
FR3020166A1 (fr) | Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PLFP | Fee payment |
Year of fee payment: 5 |
|
PLFP | Fee payment |
Year of fee payment: 6 |
|
PLFP | Fee payment |
Year of fee payment: 7 |
|
PLFP | Fee payment |
Year of fee payment: 8 |
|
PLFP | Fee payment |
Year of fee payment: 10 |
|
PLFP | Fee payment |
Year of fee payment: 11 |
|
PLFP | Fee payment |
Year of fee payment: 12 |
|
PLFP | Fee payment |
Year of fee payment: 13 |
|
PLFP | Fee payment |
Year of fee payment: 14 |