FR3074946A1 - Methodes et systemes de transaction electronique - Google Patents

Methodes et systemes de transaction electronique Download PDF

Info

Publication number
FR3074946A1
FR3074946A1 FR1761891A FR1761891A FR3074946A1 FR 3074946 A1 FR3074946 A1 FR 3074946A1 FR 1761891 A FR1761891 A FR 1761891A FR 1761891 A FR1761891 A FR 1761891A FR 3074946 A1 FR3074946 A1 FR 3074946A1
Authority
FR
France
Prior art keywords
transaction
electronic payment
server
retention
medium
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
Application number
FR1761891A
Other languages
English (en)
Other versions
FR3074946B1 (fr
Inventor
Alexis Rizet
Thomas Moreau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oney Bank
Original Assignee
Oney Bank
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Oney Bank filed Critical Oney Bank
Priority to FR1761891A priority Critical patent/FR3074946B1/fr
Publication of FR3074946A1 publication Critical patent/FR3074946A1/fr
Application granted granted Critical
Publication of FR3074946B1 publication Critical patent/FR3074946B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/407Cancellation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q30/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Infrastructure de paiement électronique à laquelle au moins un moyen d'acceptation (221) est connecté, configuré pour accepter un support de transaction (211) en vue de la réalisation d'un paiement électronique, cette infrastructure comprenant : - un serveur d'autorisation (231) configuré pour ○ recevoir, depuis le moyen d'acceptation, une demande d'autorisation concernant une transaction de paiement électronique ; ○ communiquer, au moyen d'acceptation, une réponse à la demande d'autorisation ; ○ générer un code de transaction associé à cette transaction, la réponse communiquée comprenant ce code de transaction ; un serveur de rétention (233) configuré pour ○ recevoir, depuis le moyen d'acceptation, des informations concernant la transaction autorisée, ces informations comprenant le code de transaction, o retenir les informations reçues pendant un délai prédéfini de rétention ; ○ permettre l'accès, pendant ce délai, aux informations retenues sur réception d'au moins le code de transaction.

Description

METHODES ET SYSTEMES DE TRANSACTION ELECTRONIQUE [001] L'invention a trait au domaine des réseaux électroniques, et plus particulièrement aux infrastructures de transaction électronique.
[002] L’invention trouve notamment utilisation dans les infrastructures de paiement électronique.
[003] On entend ici par infrastructure de paiement électronique l'ensemble des moyens techniques permettant la réalisation d’opérations de paiement électronique.
[004] Le règlement de telles opérations fait intervenir plusieurs éléments, dont
- un support de transaction, généralement sous la forme d'une carte de paiement ou d'une application mobile mise à disposition d'un porteur par un organisme financier dit « l'émetteur ». Cet émetteur tient, le plus souvent, le compte bancaire auquel est rattaché le support de transaction et sur lequel seront prélevés les débits correspondants aux paiements effectués au moyen de ce support de transaction ;
- une infrastructure de paiement électronique de l'émetteur, comprenant des moyens configurés pour autoriser ou refuser un paiement électronique utilisant ledit support de transaction, et des moyens configurés pour débiter le compte auquel est rattaché le support de transaction conformément à des règles de fonctionnement prédéfinies ;
- un moyen d’acceptation, tel qu’un terminal de paiement électronique plus connu sous l'acronyme TPE, ou aussi par POI, (pour « Point of Interaction » désignant un terminal de paiement quel qu'il soit), mis à la disposition de l'accepteur du support de transaction. Un TPE permet l’acceptation d’un moyen de paiement en vue de la réalisation d’un paiement, et permet de lire des données sur le support de transaction et de communiquer à distance avec une ou plusieurs infrastructures de paiement électronique appartenant à des organismes financiers, chacun de ces organismes étant dit « acquéreur » auprès desquels l'accepteur possède un compte bancaire. Un acquéreur assure l'acquisition des transactions de paiement électronique, en vue de leur dénouement financier auprès de l'émetteur, pour le compte de l'accepteur. Les opérations de configuration ou de mises à jour de ce TPE sont traitées par un des acquéreurs ou, le plus souvent, par un mainteneur ;
- une infrastructure de paiement électronique d'au moins un acquéreur, comprenant des moyens configurés pour créditer le compte bancaire de l'accepteur par un montant correspondant au règlement d'une transaction qui lui a été communiquée par le TPE ; et le cas échéant
- un réseau interbancaire, comprenant une chambre de compensation et auquel sont connectés le réseau monétique de l'émetteur et le réseau monétique de l'acquéreur.
[005] Le déroulement schématique d'un paiement électronique faisant intervenir les éléments cités ci-dessus est illustré à la figure 1.
[006] Dans un tel mode de paiement, suite à la communication des références d'une transaction (choix d'un acquéreur, lorsque plusieurs y sont configurés, et un montant de la transaction à payer), à un TPE 21 mis à disposition par exemple d’un commerçant 20, l'insertion de la carte bancaire 11 dans ce TPE 21 ouvre une session, qui commence par une étape d'authentification mutuelle entre le TPE 21 et la carte bancaire 11.
[007] Le TPE 21 et la carte bancaire 11 échangent (étape 1) des informations, pour s'assurer que la carte bancaire 11 est valide et que le TPE 21 est un lecteur autorisé.
[008] Lors de cette étape 1, il peut également y avoir une authentification du porteur 10 de la carte bancaire 11, en l'invitant à saisir un code PIN ou toute autre information permettant de vérifier qu'il en est le porteur légal.
[009] Au succès de l'étape précédente, le TPE 21 envoie (étape 2) une demande d'autorisation, à destination d'un serveur d’autorisation 31 de l’infrastructure de paiement électronique de l'acquéreur 30.
[010] Sur réception de cette demande d'autorisation, le serveur d’autorisation 31 de l'acquéreur 30 réalise certains contrôles, comme l’identification du TPE 21 source de la demande et de l'émetteur 40 de la carte bancaire 11 et, ensuite, transfère (étape 3) cette demande d'autorisation à un serveur d'autorisation 41 de l'infrastructure de paiement électronique de l'émetteur 40 identifié.
[011] Le serveur d'autorisation 41 de l'émetteur 40 effectue, à son tour, des contrôles monétiques, pour déterminer s’il faut autoriser ou refuser cette transaction.
[012] Ces vérifications comprennent, entre autres, l'authentification de la carte 11, le contrôle du solde du compte associé à la carte bancaire 11, et le contrôle des plafonds autorisés.
[013] La réponse du serveur d’autorisation 41 de l'infrastructure de paiement électronique de l'émetteur 40 emprunte en sens inverse le même chemin que la demande d'autorisation, et est donc rendue (étape
4) au serveur d’autorisation 31 de l'acquéreur 30 qui la renvoie (étape
5) au TPE 20 telle quelle ou, dans certains cas, modifiée, en application d'une politique de risque acquéreur qui lui est propre.
[014] La réponse à la demande d’autorisation comprend un code réponse indiquant au TPE 21 s'il convient d'accepter ou refuser la transaction de paiement électronique.
[015] Le TPE 21 en informe (étape 6) le porteur 10 (transaction refusée ou acceptée), en éditant un ticket de carte bancaire (preuve de l’échec ou de la réussite de la transaction) et ferme la session.
[016] Lorsque la transaction de paiement électronique est autorisée, le TPE 21 mémorise en local cette transaction.
[017] Sur demande de l'accepteur 20 ou à des temps prédéfinis, le TPE 21 transmet (étape 7) à un serveur 32 de télécollecte de l’infrastructure de paiement électronique de l'acquéreur 30 l'ensemble des transactions de paiement électronique mémorisées, pour que le compte bancaire de l'accepteur 20 soit crédité des montants correspondants.
[018] Les transactions remises par le TPE 21 à l’acquéreur 30 sont, par la suite, supprimées de la mémoire du TPE 21.
[019] Lorsque l’accepteur 20 dispose de plusieurs points de vente et, par conséquent, de plusieurs TPE 21, la télécollecte peut se faire en un premier temps vers une base de données intermédiaire.
[020] Une fois toutes les transactions centralisées, la télécollecte est ensuite effectuée vers le serveur 32 de télécollecte de l'infrastructure de paiement électronique de l'acquéreur 30.
[021] Le serveur 32 de télécollecte de l'acquéreur 30 est, en outre, configuré pour centraliser l'ensemble des transactions de paiement électronique remises par les autres accepteurs adhérents, respectivement, détenant un compte bancaire auprès de cet acquéreur 30.
[022] En centralisant l'ensemble des transactions de paiement électronique réalisées pour le compte des différents accepteurs, l'acquéreur 30 procède à un traitement de flux.
[023] Ce traitement massif et uniforme porte sur l'ensemble des transactions.
[024] Ce traitement consiste principalement en une mise en forme de l’ensemble des transactions sous un format de fichier convenable aux émetteurs 40.
[025] Pour cela, les acquéreurs ont souvent recours à des méthodes de traitement de transactions en masse, tout comme dans les industries de traitement de l'information.
[026] La principale motivation sous-jacente à cette massification des flux réside dans la réduction des coûts, vu notamment le nombre grandissant des paiements électroniques, grâce à l'augmentation du nombre des porteurs des cartes bancaires et à la multiplication et la dispersion des moyens d’acceptation.
[027] Suite au traitement massif des flux de l'ensemble des transactions provenant des différends accepteurs adhérents, les fichiers qui en résulte sont communiqués (étape 8) à une chambre 50 de compensation.
[028] Cette chambre 50 de compensation se charge de l'équilibre des débits et crédits globaux entre l’acquéreur 30 et les émetteurs 40.
[029] L'acquéreur 30, qui a déjà crédité le compte bancaire de l’accepteur 20, perçoit la somme due par le porteur 10 auprès de l’émetteur 40 que ce dernier prélève sur le compte du porteur 10.
[030] Dans toutes ces opérations, la capacité de traiter massivement des flux d'informations de bout en bout, c’est-à-dire depuis la remise des transactions par les moyens d’acceptation jusqu'à la compensation et le règlement, est une performance essentielle des infrastructures de paiement électronique.
[031] De ce fait, les infrastructures de paiement électronique des organismes financiers sont souvent configurées pour une gestion massive des flux de bout en bout.
[032] Ce choix est conforté par l'évolution continue des capacités des équipements de traitement des flux de données (calculateurs, débits de communications, routeurs et centres de données).
[033] Ce type de gestion est dans une certaine mesure bénéfique, la massification des flux permettant d'optimiser les coûts, en bénéficiant d'une économie d'échelle.
[034] Cependant, ce traitement qui capte le flux dans son ensemble conduit à une automatisation massive et uniforme des transactions, et manque par conséquent d’agilité.
[035] Aucun traitement particulier ne peut donc être destiné à une transaction cible faisant partie du flux.
[036] S'agissant d'une gestion de flux de bout en bout, toutes les transactions font l'objet d'un traitement systématique, défini avant même que ces transactions n'aient lieu, de sorte qu'aucun traitement spécifique ne peut être adapté à une certaine transaction une fois autorisée.
[037] Il en résulte que lorsque le porteur 10 a réalisé un paiement électronique, il ne lui est plus possible d'intervenir par la suite sur cette transaction, qui est destinée à faire partie d'un flux à traiter d'une manière globale et non individualisée.
[038] Les méthodes de gestion actuelles des flux des paiements électroniques ne permettent pas, en effet, d’extraire une transaction du flux et encore moins d’y apporter une modification par le porteur 10 à une date postérieure à la date de la transaction.
[039] Plus généralement, les méthodes de gestion de flux existantes ne permettent pas d'apporter à une transaction financière un traitement particulier fixé à une date postérieure à la date de la transaction.
[040] Un objet de la présente invention est de proposer des systèmes et méthodes de traitement permettant une meilleure maîtrise des transactions.
[041] Un autre objet de la présente invention est de proposer une infrastructure de transaction électronique, permettant d'appliquer un traitement défini à une date postérieure à la date de la réalisation d'une transaction faisant partie d’un flux.
[042] Un autre objet de la présente invention est de proposer une nouvelle chaîne de traitement de transactions.
[043] Un autre objet de la présente invention est de pouvoir paramétrer la gestion d'une transaction à une date postérieure à la date de son autorisation et tant qu'elle n'a pas fait l'objet d'une compensation.
[044] Un autre objet de la présente invention est d'apporter plus de souplesse aux méthodes de traitements des flux de transactions, de sorte qu'elles puissent prendre en considération des modifications apportées, dans un délai prédéfini, par un demandeur à une transaction qu’il a réalisée récemment.
[045] L’invention trouve diverses applications, notamment dans les infrastructures de paiement électroniques.
[046] Il est proposé, en premier lieu, une infrastructure de paiement électronique d’un acquéreur à laquelle est connecté au moins un moyen d’acceptation configuré pour accepter un support de transaction en vue d’un paiement électronique, cette infrastructure comprenant :
serveur d’autorisation configuré pour recevoir, depuis le d’autorisation concernant un moyen d’acceptation, une transaction une de demande électronique au moyen d’un support de transaction, de transaction étant émis par un router la demande d’autorisation émetteur ;
vers l’émetteur du support de transaction ;
recevoir, depuis l’émetteur du réponse à la demande d’autorisation ; communiquer, au moyen d’acceptation, demande d’autorisation ;
lorsque ce serveur d’autorisation générer, support de transaction une réponse autorise une à la transaction, un code de transaction associé à cette transaction et destiné au porteur du support de transaction, la réponse communiquée au moyen d’acceptation comprenant ce code de transaction ;
un serveur de rétention configuré pour o recevoir, depuis le moyen d’acceptation, des informations concernant la transaction autorisée, ces informations comprenant le code de transaction, o retenir les informations reçues, avant exploitation de cette transaction par l’acquéreur, pendant un délai prédéfini de rétention ;
o permettre l’accès, pendant le délai prédéfini de rétention, à au moins une information parmi les informations retenues sur réception d’au moins le code de transaction associé à la transaction.
[047] Diverses caractéristiques supplémentaires peuvent être prévues, seules ou en combinaison :
le serveur de rétention est configuré pour permettre la modification de ladite au moins une information parmi les informations retenues ;
la réponse communiquée au moyen d’acceptation comprend, en outre, une adresse pointant vers le serveur de rétention ;
le serveur d’autorisation est configuré pour générer le code de transaction lorsque le montant de la transaction est supérieur à un montant minimum prédéfini, et/ou lorsque la demande d’autorisation est reçue depuis un moyen d’acceptation compris dans une liste prédéfinie, et/ou l’émetteur du support de transaction est compris dans une liste prédéfinie, et/ou le support de transaction est compris dans une liste prédéfinie ;
le serveur de rétention est configuré pour permettre l’accès à ladite au moins une information parmi les informations retenues sur réception du code de transaction et au moins une information concernant le support de transaction au moyen duquel a été réalisée la transaction ;
le code de transaction est généré de sorte à permettre l’identification de manière unique la transaction.
[048] Il est proposé, en second lieu, une procédé de traitement d’une transaction de paiement électronique entre un porteur disposant d’un support de transaction et un accepteur disposant d’un moyen d’acceptation acceptant le support de transaction du porteur en vue de la réalisation d’un paiement électronique, le moyen d’acceptation étant connecté à une infrastructure de paiement électronique d’un acquéreur, le support de transaction étant émis par un émetteur, ce procédé comprenant les étapes suivantes :
envoi d’une demande d’autorisation, depuis le moyen d’acceptation à un serveur d’autorisation de l’infrastructure de paiement électronique de l’acquéreur, cette demande d’autorisation concernant une transaction de paiement électronique au moyen du support de transaction, routage de la demande d’autorisation, depuis le serveur d’autorisation vers l’émetteur du support de transaction ;
réception, depuis l’émetteur du support de transaction, d’une réponse à la demande d’autorisation ;
communication, au moyen d’acceptation, d’une réponse à la demande d’autorisation ;
génération par le serveur d’autorisation, lorsque ce serveur d’autorisation autorise ladite transaction, d’un code de transaction associé à cette transaction et destiné au porteur du support de transaction, la réponse communiquée au moyen d’acceptation comprenant ce code de transaction ;
réception par un serveur paiement électronique de d’acceptation d’informations ces informations de rétention de l’infrastructure de le moyen comprenant serveur de rétention, par le pendant un délai transaction par l’acquéreur ;
prédéfini de l’acquéreur et depuis concernant la transaction autorisée, le code de transaction ;
rétention, des informations reçues, rétention avant exploitation de cette accès par le porteur, pendant le délai prédéfini de rétention à au moins une information parmi les informations retenues sur réception par le serveur de rétention d’au moins le code de transaction associé à la transaction.
[049] Diverses étapes supplémentaires peuvent être prévues, seules ou en combinaison une étape de modification de ladite au moins une information parmi les informations retenues ;
une étape d’impression du code de transaction sur le justificatif de paiement et/ou une étape d’envoi par courriel ou par SMS du code de transaction à destination du porteur du support de transaction ;
une étape d’envoi, lorsque ladite au moins une information parmi les informations retenues est modifiée et concerne le support de transaction, d’une demande d’autorisation par le serveur de rétention à l’émetteur du support de transaction modifié.
[050] D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ciaprès de modes de réalisation, laquelle est faite en référence aux dessins annexés dans lesquels :
la figure 1 illustre schématiquement des étapes d’une méthode de gestion, connue de l’état de la technique, d’une transaction de paiement électronique ;
la figure 2 illustre schématiquement des méthodes et systèmes pour la gestion d’une transaction de paiement électronique selon divers modes de réalisation.
[051] En se référant à la figure 2, il est représenté un porteur 210 disposant d’un support de transaction 211, un accepteur 220 disposant d’un moyen d’acceptation 221, un acquéreur 230 recevant les transactions acceptées par l’accepteur 220 via le moyen d’acceptation 221, et un émetteur 240 mettant à disposition du porteur 210 le support de transaction 211 et étant en charge du compte associé à ce support.
[052] Dans les modes de réalisations décrits, la transaction est de type paiement électronique.
[053] Il est entendu toutefois que l’invention trouve application dans la modification d’une transaction électronique de tout type, commerciale, boursière, ou bien encore non commerciale (par exemple transaction contractuelle, transaction de services, de temps de travail).
[054] Le support de transaction 211 est tout moyen matériel et/ou logiciel permettant d’effectuer un paiement électronique tel qu’une carte de paiement (carte à piste magnétique, carte programmable, carte sans contact, ou carte à puce, par exemples) ou une application de paiement installée sur un terminal utilisateur.
[055] Le moyen d’acceptation 221 est tout point d’interaction (ou POI pour « Point Of Interaction ») permettant l’acceptation d’une transaction de paiement électronique tel qu’un terminal de paiement électronique (TPE) ou une application de paiement en ligne intégré à un site ou une application e-commerce.
[056] L’accepteur 220 est toute entité acceptant un paiement électronique telle qu’un commerçant, une machine de distribution de biens et/ou de services, ou, d’une manière générale, un point de vente réel ou virtuel (un site de vente en ligne, un magasin, une boutique, une superette, un supermarché, ou un hypermarché).
[057] La capacité d’acceptation du moyen d’acceptation 221 est définie par les applications de paiement qu’il comprend.
[058] A titre d’exemple, un moyen d’acceptation pourvu par l’une des applications EMV (« EMV®, Integrated Circuit Card Spécifications for Payment Systems », Version 4.3a, Novembre 2015 https://www.emvco.com/wpcontent/uploads/201 7/05/IFM L1 Protocol Test Cases v43a 20151103.pdf) telles que CB®,
Visa®, ou MasterCard accepte, respectivement, les supports de transaction 211 de type «Cartes Bancaires» désignés par CB®, VISA®, et MASTERCARD®.
[059] La sélection d’une application de paiement par le moyen d’acceptation 221 résulte d’un échange entre ce moyen d’acceptation 221 et le support de transaction 211 du porteur 210.
[060] Lorsque le porteur 210 initie une transaction de paiement électronique acceptée par l’accepteur 220 (en insérant sa carte dans le TPE ou en renseignant des informations concernant sa carte bancaire dans un formulaire dédié, en déclenchant un paiement sans contact, ou en passant sa carte dans un lecteur de bande magnétique), le moyen d’acceptation 221 sélectionne l’application de paiement convenable et procède à des vérifications telles que spécifiées par l’application de paiement sélectionnée.
[061] L’application de paiement sélectionnée est ensuite initialisée.
[062] Il convient de noter que la chaîne des traitements de la transaction de paiement est définie par l’application de paiement sélectionnée, dont les spécifications sont connues pour l’homme du métier.
[063] Suite à une vérification (étape 201) positive de la validité du support de transaction 211, et éventuellement de l’authentification du porteur 210 et d’une gestion de risques au niveau du moyen d’acceptation 221, le moyen d’acceptation 221 décide de traiter l’autorisation de la transaction en ligne (« on-line »).
[064] Autrement dit, avant de conclure quant à la transaction, le moyen d’acceptation 221 demande si l’émetteur 240 du support de transaction 211 accepte ou refuse la transaction en question.
[065] La transaction est dite en ligne car le moyen d’acceptation 221 communique en temps réel avec l’acquéreur 230 qui se charge de contacter l’émetteur 240 (émission d’une demande d’autorisation et attente de la réception d’une réponse pour conclure la transaction).
[066] Pour cela, le moyen d’acceptation 221 envoie (étape 202) une demande d’autorisation au serveur d’autorisation 231 de l’acquéreur 230.
[067] Cette demande d’autorisation comprend le montant de la transaction et des informations concernant le support de transaction 211 (numéro, nom et prénom du porteur, identifiants du compte bancaire associé par exemples).
[068] Le serveur d’autorisation 231 de l’acquéreur 230 identifie le moyen d’acceptation 221 source de cette demande d’autorisation, identifie l’émetteur 240 du support de transaction 211 et se charge de router (étape 203), à travers les réseaux monétiques appropriés, cette demande au serveur d’autorisation 241 de l’émetteur 240.
[069] Autrement dit, l'acquéreur 230 reçoit la demande d’autorisation que l’accepteur 220 accepte et la met à disposition de l’émetteur 240 pour autorisation ou refus.
[070] Le serveur d’autorisation 241 de l’émetteur 240 effectue différents contrôles monétiques vis-à-vis de cette demande d’autorisation et envoie (étape 204), en retour, une réponse au serveur d’autorisation 231 de l’acquéreur 230 signifiant son accord ou son refus.
[071] Ces vérifications monétiques comprennent, entre autres, le risque émetteur, la solvabilité du porteur 210, ou le montant maximal autorisé.
[072] L’accord de la transaction par l’émetteur 240 signifie que ce dernier garantit la compensation du montant de cette transaction à l'acquéreur 230.
[073] A la réception de la réponse de l’émetteur 240 à la demande d’autorisation, le serveur d’autorisation 231 de l’acquéreur 230 interprète cette réponse et communique (étape 205) sa propre réponse au moyen d’acceptation 221.
[074] Lorsque la transaction est refusée par l’émetteur 240, le serveur d’autorisation 231 de l’acquéreur 230 transfère (étape 205) ce refus au moyen d’acceptation 221.
[075] En revanche, lorsque la transaction est acceptée par le serveur d’autorisation 241 de l’émetteur 240, le serveur d’autorisation 231 de l’acquéreur 240 effectue, à son tour, des contrôles vis-à-vis de cette demande d’autorisation.
[076] En effet, en plus de l’application d’une éventuelle gestion de risque propre à l’acquéreur 230, le serveur d’autorisation 231 de l’acquéreur 230 vérifie, en interrogeant (étape 209) une base de données 234, que le porteur 210 et/ou le support de transaction 211 ne figurent pas dans une liste prédéfinie (liste d’oppositions par exemple) tenue par cet acquéreur 230 ou partagée avec d’autres établissements financiers.
[077] Lorsque la transaction est également acceptée par le serveur d’autorisation 231 de l’acquéreur 230, ce serveur d’autorisation 231 génère un code de transaction au moyen d’un générateur 232 de code de transaction.
[078] Le code de transaction généré est associé à la transaction sur laquelle porte la demande d’autorisation émise par le moyen d’acceptation 221 et autorisée par le serveur d’autorisation 231 de l’acquéreur 230.
[079] Dans un autre mode de réalisation, un code de transaction est systématiquement généré et associé à toute transaction autorisée par le serveur d’autorisation 241 de l’émetteur 240 (la réponse du système d’autorisation 231 de l’acquéreur 230 étant, dans ce cas, favorable dès que la transaction est acceptée par l’émetteur 240).
[080] Dans un mode de réalisation, le code de transaction permet d’identifier de manière unique la transaction autorisée.
[081] Dans un autre mode de réalisation, ce code de transaction permet d’identifier, en combinaison d’au moins une autre information concernant le support de transaction 211 (par exemple, la date d’expiration ou le cryptogramme d’une carte bancaire) et/ou une information concernant le porteur 210 (nom et/ou prénom), de manière unique la transaction autorisée par le serveur d’autorisation 231 de l’acquéreur 230.
[082] Le code de transaction généré par le générateur 232 peut prendre toute forme appropriée, tel qu’un mot alphanumérique, un code QR (pour « Quick Response »), ou un code à barres.
[083] Dans un mode de réalisation, le code de transaction est généré (ou chiffré) au moins à partir d’une information relative à la transaction (montant, date) et/ou au support de transaction 211 (numéro de carte, date d’expiration) et/ou au porteur 210 (nom, prénom ou tout autre identifiant), et/ou à l’accepteur 220 (identifiant, nom de l’enseigne), ou à partir d’une combinaison de ces informations.
[084] Dans un mode de réalisation, un code de transaction est généré uniquement lorsque :
la transaction pour laquelle une autorisation est demandée porte sur un montant supérieur à un montant minimum prédéfini, et/ou la demande d’autorisation provient d’un moyen d’acceptation 221 et/ou d’un accepteur 220 compris dans une liste prédéfinie (uniquement les terminaux de paiement électronique physique, et/ou uniquement les moyens d’acceptation d'une certaine enseigne commerciale, ou uniquement des modules de paiement électronique d’un site e-commerce par exemple); et/ou l’émetteur 240 du support de transaction 211 est compris dans une liste prédéfinie d’émetteurs (une liste de banques par exemple) intégrant, dans un mode de réalisation, l’acquéreur 230 lui-même; et/ou le porteur 210 ne figure pas dans une liste prédéfinie par l’acquéreur 230 dans une base de données 234 ;
le support de transaction 211 est parmi une liste prédéfinie (cartes Visa® par exemple).
[085] Les informations concernant chaque transaction autorisée par l’acquéreur 230, y compris le code de transaction généré par le générateur 232, sont mémorisées par le serveur d’autorisation 231 de l’acquéreur 230.
[086] Lorsque le serveur d’autorisation 231 de l’acquéreur 230 confirme l’accord du serveur d’autorisation 241 de l’émetteur 240, le serveur d’autorisation 231 de l’acquéreur 230 envoie (étape 205) une réponse favorable, intégrant le code de transaction générée, au moyen d’acceptation 221.
[087] En fonction de la réponse reçue depuis le serveur d’autorisation 231 de l’acquéreur 230, le moyen d’acceptation 221 accepte ou refuse la transaction et en informe le porteur 210 et/ou l’accepteur 220.
[088] A la réception, par le moyen d’acceptation 221, de l’accord et du code de transaction, le moyen d’acceptation 221 communique (étape 206) ce code au porteur 210.
[089] Le porteur 210 est, ainsi, informé du code de transaction généré par le serveur d’autorisation 231 de l’acquéreur 230, en plus des informations standards qui lui sont également communiquées (le montant de la transaction, date et heure de la transaction, et enseigne de l’accepteur 220 par exemples).
[090] Dans un autre mode de réalisation, des informations additionnelles sont également communiquées au porteur 210, telles qu’une adresse Web, un nom d’une application mobile via lequel le porteur 210 peut utiliser le code de transaction ou, plus généralement, tout pointeur (codé ou en clair) vers une ressource en ligne, et/ou un délai durant lequel ce code de transaction est valide.
[091] Dans un mode de réalisation, lorsque le moyen d’acceptation 221 est un terminal de paiement pourvu d’une imprimante, le ticket de carte bancaire (c.à.d. la facturette ou, plus généralement, le justificatif de transaction) imprimé comprend le code de transaction généré par le serveur d’autorisation 231 de l’acquéreur 230.
[092] Le justificatif de la transaction comprend, en outre, dans un autre mode de réalisation, une adresse pointant directement ou indirectement vers un serveur distant.
[093] En variante ou en combinaison, un délai de validité du code de transaction est, en outre, communiqué au porteur 210.
[094] Dans un mode de réalisation, le code de transaction est : instantanément, imprimé à la caisse sur le justificatif de paiement, tel que le ticket de carte bancaire ou le ticket de caisse ; et/ou affiché au porteur, de sorte qu’il lui soit porté à sa connaissance ; envoyé au porteur 210, par courrier, par courriel, par SMS ou via une notification, dans ou séparé du justificatif du paiement. Pour cela, les cordonnées requises (courriel, adresse postale, numéro de téléphone, application mobile de paiement électronique utilisée) peuvent être fournies au préalable ou demandées au porteur 210 et/ou au support de transaction 211.
[095] En fonction du support utilisé pour communiquer le code de transaction au porteur 210, le moyen d’acceptation 221 est connecté à un ou plusieurs dispositifs dédiés (une imprimante de ticket de carte bancaire, un écran, un serveur de notification Push, un serveur pour envoi de courriel ou de SMS, ou une interface de communication sans fil de courte portée).
[096] Outre la communication (étape 206) au porteur 210 du code de transaction et les informations conventionnelles concernant la transaction autorisée, le moyen d’acceptation 221 mémorise en local les informations relatives à cette transaction (montant, date, et identifiants concernant le support de transaction 211, et/ou le compte associé à ce support, et/ou le porteur 210), y compris le code de transaction correspondant.
[097] Lors de la télécollecte, qu’elle soit déclenchée d'une façon manuelle ou automatique, les informations mémorisées par le moyen (étape 207) à un serveur de rétention de l’acquéreur 230.
d’acceptation 221 sont envoyées
233 de l’infrastructure monétique [098] Les transactions, par exemple journalières, mémorisées par le moyen d’acceptation 210 sont, ainsi, remises (étape 207) au serveur de rétention 233 de l’acquéreur 230.
[099] Suite à cette télécollecte, crédité par l’acquéreur transactions remises dans un
230 le compte de d’un montant convenu entre l’accepteur 220 est correspondant : eux (par exemple, aux heures).
[0100] mainteneur permet de rétention 233.
La configuration ou par l’acquéreur 230 connecter
Le serveur le de du le moyen moyen d’acceptation 221 par lors d’une phase de téléparamétrage d’acceptation 221 au serveur de rétention 233 est accessible à distance, via ou analogue, apte à se connecter à un une tablette numérique, un [0101] une adresse Web, URL utilisateur au serveur distant, Smartphone, moyen de tout terminal tel qu’un un téléphone portable, ou plus généralement tout dispositif permettant au porteur d’interagir avec un serveur distant.
un mode de réalisation, le serveur porteur 210 à l’adresse qui lui [0102] est accessible au
210
Dans a été de rétention
233 préalable.
[0103] Ainsi, le porteur 210 s’authentifie lorsqu’un code de transaction (étape le code rétention 233 en
300) auprès du serveur de de transaction et, éventuellement pour des d’autres informations concernant le support renseignant raisons de sécurité, de transaction 211 utilisé (par exemples le cryptogramme, la date d’expiration et/ou le numéro de la carte bancaire utilisée) et/ou concernant le porteur 210 (par exemples, nom, prénom, courriel et/ou identifient) et/ou concernant la transaction (montant, date par exemple) et/ou l’acquéreur 220 (adresse, enseigne exemple, procédés d’authentification forte); lorsqu’il est authentifié par le serveur de rétention 233 comparant les informations qui lui sont soumises par le porteur 210 avec les informations qui lui sont communiquées lors de la télécollecte, accède (étape 300) à la transaction en question.
par en [0104] Dans un mode de réalisation, l’authentification peut se faire en saisissant et/ou en scannant (lorsque le code de transaction ou autre information requise est/sont sous la forme d’un code QR ou code à barres) les informations requises dans un formulaire électronique à soumettre au serveur de rétention 233.
[0105] Dans un autre mode de réalisation, pour authentifier le porteur 210, le serveur de rétention 233 compare également les informations qui lui sont soumises par le porteur 210 aux informations déjà mémorisées par le serveur d’autorisation 231 dans la base de données 234 de l’acquéreur 230.
[0106] De préférence, les méthodes d’authentification et les mécanismes de sécurité applicables au paiement électronique (chiffrement, procédés d’authentification forte) sont utilisés pour protéger l’accès aux transactions mémorisées par le serveur de rétention 233.
[0107] Une transaction est identifiée par le serveur de rétention 233 par son code de transaction, combiné, le cas échéant, avec toute autre information mémorisée et qui lui est associée.
[0108] Une fois authentifié, le porteur 210 accède, dans un délai prédéfini à compter de la date de la transaction requise, à l’ensemble ou à une partie des informations mémorisées concernant cette transaction.
[0109] Dans un mode de réalisation, le porteur 210 peut copier et/ou imprimer ces informations.
[0110] Dans un autre mode de réalisation, le porteur 210 peut modifier, parmi les informations auxquelles a accès, certaines informations prédéfinies par l’acquéreur 230.
[0111] Il en résulte que le porteur peut avoir accès et extraite, à partir du flux des transactions en gestion par l’acquéreur 230, une transaction qu’il a récemment réalisée et, éventuellement, la modifier.
[0112] La modification par le porteur 210 d’une information concernant une transaction mémorisée peut déclencher des actions prédéfinies à entreprendre par le serveur de rétention 233.
[0113] Par exemple, la modification des informations concernant le support de transaction (numéro de carte, identité du porteur par exemple) peut déclencher l’émission d’une nouvelle demande d’autorisation auprès de l’émetteur du nouveau support de transaction;
la modification du montant de la transaction peut déclencher la division de la transaction en deux ou plusieurs autres transactions divisionnaires, de sorte que le montant de la première transaction divisionnaire soit inférieur ou égal au montant de la transaction initiale ;
la combinaison des deux modifications précédentes déclenche une demande d’autorisation pour chacune des transactions divisionnaires auprès de l’émetteur de chaque nouveau support de transaction correspondant.
[0114] Dans un mode de réalisation, la modification de certaines informations concernant une transaction de paiement peut être refusée au porteur 210 (par exemple, suite à un refus signifié par l’émetteur du nouveau support de transaction renseigné par le porteur 210).
[0115] Dans un mode de réalisation, une copie de secours des transactions reçues par le serveur de rétention 233 (les remises) est sauvegardée, de sorte à avoir une copie originale d’une transaction modifiée par la suite par le porteur 210.
[0116] Le serveur de rétention est configuré pour retenir chaque transaction qui lui est remise par un moyen d’acceptation, avant qu’elle
ne soit exploitée par l’acquéreur, pendant un délai prédéfini de
rétention
[0117] Ce délai de rétention correspond au délai de validité du
code de transaction.
[0118] Dans un mode de réalisation, ce délai prédéfini de
rétention est de 2 jours, 3 jours, 4 jours, 5 jours, 6 jours ou 7 jours à
compter de la date de la transaction de paiement.
[0119] Une transaction demeure, ainsi, accessible au porteur 210 pendant tout ce délai de rétention.
[0120] Dans un autre mode de réalisation, la rétention est clôturée à compter d’un nombre prédéfini de modifications. A titre d’exemple, la rétention arrive à échéance suite à la validation, pendant le délai de rétention initial, par le porteur d’un nombre de transactions divisionnaires.
[0121] A l’expiration de son délai de rétention, chaque transaction éventuellement consultée, voire modifiée, par le porteur 210 est transmise au serveur de télécollecte 232 pour leur exploitation par l’acquéreur 230.
[0122] L’exploitation de ces transactions par l’acquéreur 230 comprend, entre autres, une étape de compensation (étape 208) auprès d’un organisme de compensation 250.
[0123] L’ensemble ou seulement une partie des éventuelles transactions divisionnaires générées (c.à.d. en cas de division de la transaction initiale) par le serveur de rétention 233 suite à une modification apportée par un porteur 210 sur une transaction de paiement qu’il a réalisée récemment est transmise au serveur de télécollecte 232 pour traitement ultérieur.
[0124] Dans un mode de réalisation, le serveur de rétention 233 est un serveur intermédiaire entre les moyens d’acceptation 221 et le serveur de télécollecte 232.
[0125] Le serveur de rétention 233 est, par exemple, un serveur pourvu d’une base de données pour y retenir pendant une durée prédéfinie (délai de rétention) les informations qui lui sont transmises depuis les moyens d’acceptation 221. Ce serveur de rétention 233 est accessible par un utilisateur depuis une interface homme-machine. Cet accès peut être direct ou via un ou plusieurs serveurs intermédiaires. Ces serveurs intermédiaires peuvent être des serveurs Web, des serveurs applicatifs ou tout autre moyen présentant une interface homme-machine.
[0126] En alternative, le serveur de rétention 233 est le serveur de télécollecte 233 qui est configuré (ou adapté) pour retenir toute transaction qui lui est remise par télécollecte depuis un moyen d’acceptation 221 pendant un délai prédéfini de rétention à compter de la date de cette transaction ou, d’une manière équivalente, de la télécollecte, avant son exploitation par l’acquéreur 230.
[0127] Les méthodes et systèmes décrits ci-dessus présentent plusieurs avantages.
[0128] Ils permettent, en effet, une meilleure maîtrise des transactions après leur autorisation ;
la modification ultérieure, par le porteur 210, des données d’une transaction, conduisant à la modification des flux de transactions ;
d’apporter une certaine souplesse aux méthodes de traitement des flux de transactions de paiement électronique, dans le sens ils offrent la possibilité d’isoler une transaction particulière du flux en vue d’un traitement spécifique ;
de tenir compte, lors l’exploitation des transactions par l’acquéreur 230, d’informations fournies à une date postérieure à 5 la date de télécollecte de ces transactions depuis les accepteurs ;
de faire intervenir le porteur dans le cycle de vie d’une transaction qu’il a conclu récemment.

Claims (10)

  1. Revendications
    1. Infrastructure de paiement électronique d’un acquéreur (230) à laquelle est connecté au moins un moyen d’acceptation (221) configuré pour accepter un support de transaction (211) en vue de la réalisation d’un paiement électronique, cette infrastructure comprenant :
    un serveur d’autorisation (231) configuré pour o recevoir, depuis le moyen d’acceptation (221), une demande d’autorisation concernant une transaction de paiement électronique au moyen d’un support de transaction (211), le support de transaction (211) étant émis par un émetteur (240) ;
    o router la demande d’autorisation vers l’émetteur (240) du support de transaction (211) ;
    o recevoir, depuis l’émetteur (241) du support de transaction (211), une réponse à la demande d’autorisation ;
    o communiquer, au moyen d’acceptation, une réponse à la demande d’autorisation ;
    cette infrastructure de paiement électronique étant caractérisée en ce que le serveur d’autorisation (231) est, en outre, configuré pour générer, lorsque ce serveur d’autorisation (231) autorise ladite transaction, un code de transaction associé à cette transaction et destiné au porteur (210) du support de transaction (211), la réponse communiquée au moyen d’acceptation (221) comprenant ce code de transaction ;
    cette infrastructure de paiement électronique comprend, en outre, un serveur de rétention (233) configuré pour o recevoir, depuis le moyen d’acceptation (221), des informations concernant la transaction autorisée, ces informations comprenant le code de transaction ;
    o retenir les informations reçues, avant exploitation de cette transaction par l’acquéreur (230), pendant un délai prédéfini de rétention ;
    o permettre l’accès, pendant le délai prédéfini de rétention, à au moins une information parmi les informations retenues sur réception d’au moins le code de transaction associé à la transaction.
  2. 2. Infrastructure de paiement électronique selon la revendication précédente, caractérisé en ce que le serveur de rétention (233) est configuré pour permettre la modification de ladite au moins une information parmi les informations retenues.
  3. 3. Infrastructure de paiement électronique selon la revendication 1 ou 2, caractérisé en ce que la réponse communiquée au moyen d’acceptation (221) comprend, en outre, une adresse pointant vers le serveur de rétention (233).
  4. 4. Infrastructure de paiement électronique selon l’une quelconque des revendications précédentes, caractérisé en ce que le serveur d’autorisation (231) est configuré pour générer le code de transaction lorsque le montant de la transaction est supérieur à un montant minimum prédéfini, et/ou lorsque la demande d’autorisation est reçue depuis un moyen d’acceptation (221) compris dans une liste prédéfinie, et/ou l’émetteur (240) du support de transaction (211) est compris dans une liste prédéfinie, et/ou le support de transaction (211) est compris dans une liste prédéfinie.
  5. 5. Infrastructure de paiement électronique selon l’une quelconque des revendications précédentes, caractérisé en ce que le serveur de rétention (233) est configuré pour permettre l’accès à ladite au moins une information parmi les informations retenues sur réception du code de transaction et au moins une information concernant le support de transaction (211) au moyen duquel a été réalisée la transaction.
  6. 6. Infrastructure de paiement électronique selon l’une quelconque des revendications précédentes, caractérisé en ce que le code de transaction est généré de sorte à permettre l’identification de manière unique la transaction.
  7. 7. Procédé de traitement d’une transaction de paiement électronique entre un porteur (210) disposant d’un support de transaction (211) et un accepteur (220) disposant d’un moyen d’acceptation (221) acceptant le support de transaction (211) du porteur (210) en vue de la réalisation d’un paiement électronique, le moyen d’acceptation (221) étant connecté à une infrastructure de paiement électronique d’un acquéreur (230), le support de transaction (211) étant émis par un émetteur (240), ce procédé comprenant les étapes suivantes :
    envoi (202) d’une demande d’autorisation, depuis le moyen d’acceptation (221) à un serveur d’autorisation (231) de l’infrastructure de paiement électronique de l’acquéreur (230), cette demande d’autorisation concernant une transaction de paiement électronique au moyen du support de transaction (211), routage (203) de la demande d’autorisation, depuis le serveur d’autorisation (231) vers l’émetteur (240) du support de transaction (211 );
    réception, depuis l’émetteur (240) du support de transaction (211), d’une réponse à la demande d’autorisation ;
    communication (205), au moyen d’acceptation (221), d’une réponse à la demande d’autorisation ;
    ce procédé étant caractérisé en ce qu’il comprend, en outre, les étapes suivantes génération par le serveur d’autorisation (231), lorsque ce serveur d’autorisation (231) autorise ladite transaction, d’un code de transaction associé à cette transaction et destiné au porteur (210) du support de transaction (211), la réponse communiquée au moyen d’acceptation (221) comprenant ce code de transaction ;
    réception par un serveur de rétention (233) de l’infrastructure de paiement électronique de l’acquéreur (230) et depuis le moyen d’acceptation (221) d’informations concernant la transaction autorisée, ces informations comprenant le code de transaction ; rétention, par le serveur de rétention (233), des informations reçues, pendant un délai prédéfini de rétention avant exploitation de cette transaction par accès par le porteur rétention, à au moins retenues l’acquéreur (230);
    (210), pendant information une par sur réception code de transaction le serveur le délai prédéfini de parmi les informations de rétention (233) d’au associé à la transaction.
  8. 8.
    Procédé de traitement selon la revendication 7, caractérisé en ce qu’il comprend, en outre, une étape de modification de ladite au moins une information parmi les informations retenues.
  9. 9. Procédé de traitement selon la revendication 7 ou 8, caractérisé en ce qu’il comprend, en outre, une étape d’impression du code de
    5 transaction sur le justificatif de paiement et/ou une étape d’envoi par courriel ou par SMS du code de transaction à destination du porteur (210) du support de transaction (211).
  10. 10. Procédé de traitement selon la revendication 8 ou 9, caractérisé 10 en ce qu’il comprend, en outre, une étape d’envoi, lorsque ladite au moins une information parmi les informations retenues est modifiée et concerne le support de transaction (211), d’une demande d’autorisation par le serveur de rétention (233) à l’émetteur du support de transaction modifié.
FR1761891A 2017-12-11 2017-12-11 Methodes et systemes de transaction electronique Active FR3074946B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1761891A FR3074946B1 (fr) 2017-12-11 2017-12-11 Methodes et systemes de transaction electronique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1761891 2017-12-11
FR1761891A FR3074946B1 (fr) 2017-12-11 2017-12-11 Methodes et systemes de transaction electronique

Publications (2)

Publication Number Publication Date
FR3074946A1 true FR3074946A1 (fr) 2019-06-14
FR3074946B1 FR3074946B1 (fr) 2021-08-27

Family

ID=62017366

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1761891A Active FR3074946B1 (fr) 2017-12-11 2017-12-11 Methodes et systemes de transaction electronique

Country Status (1)

Country Link
FR (1) FR3074946B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791451A1 (fr) * 1999-03-23 2000-09-29 Virgile Systeme et procede de transaction mobile, et equipements mobiles mis en oeuvre dans ce systeme
US20050015336A1 (en) * 2003-07-15 2005-01-20 Microsoft Corporation Electronic draft capture
US20090204522A1 (en) * 2000-12-14 2009-08-13 Payscan America, Inc. Bar coded bill payment system and method
US20140019352A1 (en) * 2011-02-22 2014-01-16 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791451A1 (fr) * 1999-03-23 2000-09-29 Virgile Systeme et procede de transaction mobile, et equipements mobiles mis en oeuvre dans ce systeme
US20090204522A1 (en) * 2000-12-14 2009-08-13 Payscan America, Inc. Bar coded bill payment system and method
US20050015336A1 (en) * 2003-07-15 2005-01-20 Microsoft Corporation Electronic draft capture
US20140019352A1 (en) * 2011-02-22 2014-01-16 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems

Also Published As

Publication number Publication date
FR3074946B1 (fr) 2021-08-27

Similar Documents

Publication Publication Date Title
US8856043B2 (en) Method and system for managing data and enabling payment transactions between multiple entities
US7499889B2 (en) Transaction system
US9390410B2 (en) Automated transaction system and settlement processes
US10346823B2 (en) Methods and systems for activating an electronic payments infrastructure
EP3113099A1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
US20100191622A1 (en) Distributed Transaction layer
RU2740734C2 (ru) Системы и способы для упрощения защищенных электронных транзакций
CN104657848A (zh) 用于实时账户访问的***和方法
EP1421732B1 (fr) Systeme de transaction
CA2505791A1 (fr) Mecanismes de carte-prime portant interet
WO2015023172A2 (fr) Systemes et procedes de paiement mobile interpersonnel instantane (p2p)
US10970697B2 (en) Transaction mediation method
US11928654B2 (en) Application program interface for conversion of stored value cards
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
US20180293572A1 (en) System and method for administering a user account
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants.
US20120271763A1 (en) Method and system for mobile remittance
WO2006035136A1 (fr) Installation de reglement de produits ou services aupres de marchands au moyen de tickets d'achat prepayes
FR3074946A1 (fr) Methodes et systemes de transaction electronique
EP1744518A2 (fr) Système de transaction
EP1421564B1 (fr) Dispostif de paiement
BR102021009919A2 (pt) Sistema de captura de pagamentos eletrônicos via aplicativo vendedor adquirente
WO2009095747A1 (fr) Systeme informatique de modelisation et d'exploitation de documents publics

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20190614

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7