WO2024256700A1 - Procédé de paiement électronique - Google Patents

Procédé de paiement électronique Download PDF

Info

Publication number
WO2024256700A1
WO2024256700A1 PCT/EP2024/066683 EP2024066683W WO2024256700A1 WO 2024256700 A1 WO2024256700 A1 WO 2024256700A1 EP 2024066683 W EP2024066683 W EP 2024066683W WO 2024256700 A1 WO2024256700 A1 WO 2024256700A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
customer
merchant
terminal
payment
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.)
Ceased
Application number
PCT/EP2024/066683
Other languages
English (en)
Inventor
Joël-Alexis BIALKIEWICZ
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.)
Delupay
Original Assignee
Delupay
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 Delupay filed Critical Delupay
Priority to EP24732323.1A priority Critical patent/EP4728457A1/fr
Priority to AU2024304156A priority patent/AU2024304156A1/en
Publication of WO2024256700A1 publication Critical patent/WO2024256700A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/403—Solvency checks
    • G06Q20/4037—Remote solvency checks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device

Definitions

  • the invention relates to the field of electronic payment and relates in particular to an electronic payment method not requiring a bank card.
  • bank card For consumers: it requires an annual fee depending on the type of bank card, it is subject to possible billing of fees on cash withdrawals, the bank card is sometimes accepted in a limited way by certain merchants (requirement of a minimum amount), the bank card has payment and withdrawal limits, it is impossible to make payments between individuals, it is not possible to manage a deferred or immediate debit on the same card, there are payment limits for contactless payments.
  • the aim of the invention is to propose a payment and collection solution that is simple, fast and secure and does not use a bank card for payments made either physically or online.
  • an electronic payment method comprising the following steps, implemented by a payment server:
  • the imprint comprising the sale amount and an identity of the merchant known to the payment server in a format that can be acquired by acquisition means of a client terminal;
  • the merchant terminal being configured to present the imprint to a customer terminal;
  • the sales message including information relating to the amount of a transaction and a information relating to the identity of a merchant, the sales message having been generated by the customer terminal following the acquisition of the transaction imprint by the customer terminal, an authentication of the customer and a validation of the transaction by the customer at the customer terminal.
  • the process includes the following steps, carried out by a payment server:
  • the imprint is a QR code, a near field communication label, a 6-digit digital code, a low energy Bluetooth communication label.
  • the amount of the transaction is greater than a payment capacity contained in the customer account, sending to the merchant terminal a notification of abandonment of the transaction and sending to the customer terminal a notification of refusal of the transaction.
  • the collection order is issued for each transaction or periodically at a determined frequency, once a day or once a month or at the end of the day or at the end of the month.
  • the method comprises the following steps implemented by a client terminal: - acquisition of the imprint issued by the payment server and presented to the customer using a merchant terminal;
  • the acquisition of the fingerprint triggers the opening of an application stored on the client's terminal, the application making it possible to authenticate the client and validate the transaction.
  • the method comprises the following steps implemented by a merchant terminal:
  • the invention relates to a payment server comprising a processing unit configured to implement a method according to the first aspect of the invention.
  • the invention relates to a payment method implemented by a customer terminal comprising the following steps:
  • the invention relates to a payment method comprising the following steps implemented by a merchant terminal:
  • the invention relates to a computer program product comprising instructions, which when the program is executed by a computer, lead the latter to implement the steps of the method according to one of the aspects of the invention.
  • the invention relates to an electronic payment method, comprising the following steps:
  • the sales message comprising information relating to the amount of a transaction and information relating to the identity of a merchant, the sales message having been generated by the customer terminal following the acquisition of the transaction imprint by the customer terminal, authentication of the customer and validation of the transaction by the customer at the customer terminal.
  • the invention makes it possible to definitively free oneself from the use of a bank card presented, even if dematerialized, to an electronic payment terminal.
  • the invention does not require prior recharging of the account, due to the operation by direct debit (unlike solutions based on bank cards).
  • the invention identifies all parties to the transaction, which secures transactions.
  • the invention allows for very rapid payment because by eliminating the need for a bank card, the solution frees itself from all the usual intermediaries for payment by bank card.
  • the invention allows for a more secure payment than payment by bank card:
  • the amount of the payment without PIN code can be set between €0 and a specific amount, for example €50 in the application according to the security needs of each cardholder,
  • a wallet such as Apple PayTM, Google PayTM
  • the bank card is a means of payment that draws information from the interbank system thanks to the card identification number (PAN code for Primary Account Number) whereas with the invention it is the merchant who gives the payment information to the customer who validates the transaction.
  • PAN code is used by fraudsters to make the link between the customer's bank account and his card. The invention therefore limits fraud.
  • the invention allows the customer using the payment application according to the invention to be able to manage the debit of his payments by choosing whether he wishes to switch from a deferred debit payment to an immediate debit payment.
  • the invention makes it possible to obtain a spending capacity based on one's resources, determined automatically during the registration process.
  • the invention does not require preloading your account from the application to make purchases.
  • the invention does not require any entry of the transaction amount by the customer. Only the merchant performs this entry.
  • FIG. 1 illustrates an implementation architecture of an electronic payment method in accordance with the invention
  • FIG. 3 illustrates a client terminal comprising a screen and a QR code acquisition area.
  • FIG 1 illustrates an implementation architecture of an electronic payment method in accordance with the invention.
  • a customer C1 accesses a POS of a merchant 02 to make a purchase.
  • the customer C1 has an electronic terminal T1.
  • the electronic terminal T1 is preferably a smartphone but can also be any equipment suitable for connecting to a payment server SP: touch tablet, laptop, game console, smartwatch, etc.
  • the PdV point of sale can be a website, a physical location, etc.
  • the PdV point of sale is notably materialized by an electronic terminal T2 also adapted to connect to the SP payment server.
  • Terminals T1, T2 can connect to the payment server SP by means of a wireless connection, for example via the Internet R.
  • This connection can be implemented by a wired connection (for example by a fiber optic connection). optical, ADSL, network, etc.) wireless Wi-Fi type or via a mobile communication network (3G, 4G, 5G, etc.).
  • the payment server SP is typically configured to implement processing operations and, as such, comprises one or more calculators.
  • the payment server SP and the terminals T1, T2 are configured to exchange data securely via the Internet connection.
  • the payment server SP and the terminals T1, T2 are configured to exchange data in a highly secure manner according to communication standards well known to those skilled in the art.
  • the payment server SP comprises one or more memories to allow the storage of different data.
  • a payment application is installed on the terminal T1 of customer 01 and customer C1 has created a customer account 10 allowing him to use the application.
  • the merchant 02 uses a dedicated application to allow it to interact with the terminal T1 of the customer 01, the merchant 02 having a merchant account 20 to access the payment server SP.
  • the customer and merchant accounts 10 and 20 respectively are stored by the payment server SP and include all the information relating to the customer and the merchant and make it possible to trace all the transactions.
  • the client and merchant applications use deep links that provide increased security for the transaction. This helps limit the risks associated with man-in-the-middle attacks (MITM) or the man-in-the-middle attack that aims to intercept and modify communications between two parties. Indeed, the client and the merchant never communicate directly with each other but always go through the SP payment server.
  • MITM man-in-the-middle attacks
  • the client and the merchant never communicate directly with each other but always go through the SP payment server.
  • the payment server SP is associated and connected to a central server SC of a central EC banking institution which makes it possible to manage banking flows such as interbank transfers of funds by bank transfer in particular.
  • the connection between the central server SC and the payment server SP is implemented in a similar way to the connection between the payment server SP and the terminals T1, T2.
  • the payment server SP is associated with the central server SC of a central EC banking institution which will manage all banking flows.
  • the client C1 has a client bank account 11 managed by a server S1 of an establishment E1 customer bank and the merchant has a merchant bank account 21 managed by an S2 server of a merchant bank E2 establishment.
  • FIG. 1 three separate banking institutions are shown but one or more banking institutions may be confused depending on customer and merchant preferences.
  • the terminal T1 of the customer C1 and the terminal T2 of the merchant C2 can also be configured to communicate with each other using Near Field Communication (NFC) technology or using Bluetooth Low Energy (BLE) communication technology.
  • NFC Near Field Communication
  • BLE Bluetooth Low Energy
  • an electronic payment method described in relation to Figure 2 requires the installation on the client side C1 of an application on the client terminal T1 to access the payment service. Once the application is installed on his client terminal T1, to be able to access the payment service, the client C1 registers for the service (step Insc C1) via the application by creating his client account 10.
  • the registration (step Insc C1) of the customer includes the following steps:
  • such verification may include the transmission of a customer's identity document (identity card, passport, residence, driving license.
  • the copy of the document can be made using the camera of the customer's terminal.
  • the customer's face is captured to verify the correspondence between the customer's face and the one on the identity document;
  • the bank details thus recorded constitute a banking authorization to debit the customer's bank account 11 hosted in the banking institution E1 which can be any.
  • the payment service operates by implementing bank debits.
  • customer C1 does not need to have a bank card to register to finalize his registration and the opening of his customer account.
  • All recorded data are attached to the customer account 10 which is stored in the payment server SP and includes, in addition to the recorded data (in particular the identity and bank details), a payment capacity.
  • a payment capacity limits the amount that the customer can use monthly (in one or more transactions) to use the service and implement the electronic payment method described here.
  • This payment capacity is preferably initially capped at a low value and increased once the customer bank account 11 has been confirmed.
  • Customer registration is optimized in terms of the number of manual entries and validation. Indeed, the customer has only a few elements to complete manually, which reduces the risk of error and speeds up registration.
  • the customer can use the service (even if he has not associated automatically their bank account via DSP2) even if their external bank customer account is not confirmed. There is therefore no waiting, the service can be used immediately to make a payment.
  • the merchant C2 registers for the service (step Insc C2) and has a merchant account 20 stored in the payment server SP.
  • This merchant account 20 includes the identity of the merchant but also his bank details associated with his merchant bank account 21.
  • the registration (step Insc C2) of the trader includes the following steps:
  • identity and contact information surname, first name, telephone number, postal address, email address, password to access the merchant account;
  • an electronic message is sent containing a code that the trader must enter in order to verify his/her electronic address; this makes it possible to verify that the electronic address is correct;
  • such verification may include the transmission of an identity document of the trader (identity card, passport, residence permit.
  • identity card identity card
  • passport residence permit.
  • the copy of the document can be made using the camera of the trader's terminal.
  • the trader's face is captured to verify the correspondence between the trader's face and the one on the identity document;
  • the registration of the customer and the merchant allows the two parties involved in a transaction to be identified unambiguously. This helps to secure the transaction. This is particularly useful when it comes to combating money laundering and terrorist financing.
  • the bank details will allow the initiation of banking operations required by the payment server SP to the central server SC which is authorized to implement this type of operation.
  • a customer operating account 12 (payment account type) and a merchant operating account 22 (payment account type) are created in the central server SC of the central banking institution EC with which the payment server SP is associated.
  • These operating accounts will make it possible to manage banking flows transparently for the customer and the merchant when the time comes.
  • a customer C1 goes to a POS point of sale to purchase one or more goods (step 100).
  • Customer C1 goes to the POS point of sale so that merchant C2 can enter the sale (step 101).
  • this is a classic checkout.
  • the sale is entered by merchant C2 on their merchant terminal T2 and leads to the generation of a transaction message M1 including the amount of the sale (step 102).
  • the transaction message M1 also includes the identity of the merchant so that the payment server SP can identify them.
  • the merchant C2 validates the sale via his terminal T2, which triggers the transmission (step 103) of the transaction message M1 to the payment server SP. Only the merchant C2 enters the transaction amount, so the customer does not have to enter such an amount.
  • step 104 Upon receipt (step 104) of this transaction message M1, the payment server SP generates (step 105) a transaction imprint EP1 intended to be acquired/received by the client terminal T1.
  • the transaction EP footprint can take several forms.
  • the transaction imprint EP1 is a QR code.
  • the transaction fingerprint EP1 is a near field communication (NFC) tag.
  • the transaction imprint EP1 is a 6-digit numeric code.
  • the EP1 fingerprint is a BLE (Bluetooth Low Energy) communication label.
  • This EP1 fingerprint contains the amount of the sale as well as the identity of the C2 merchant known to the SP payment server.
  • This EP1 fingerprint is stored (step 106) in the payment server SP to enable transaction traceability and is returned (step 107) to the terminal T2 of the merchant C2 to carry out the transaction with the customer C1.
  • the EP1 imprint is shown to the customer via the merchant's website. In this way, the merchant is able to create a transaction in different collection contexts.
  • the merchant frees himself from the use of an electronic payment terminal (EPT), which reduces costs for the merchant in terms of equipment and IT resources and therefore energy.
  • EPT electronic payment terminal
  • the EP1 footprint can take several forms, the merchant is not technologically limited. Thus, it is very easy for a merchant to offer such a payment service.
  • the EP1 imprint is presented/issued to the customer C1 (step 108) in particular via the merchant terminal T2, the transaction can be carried out physically or remotely.
  • client C1 confirms the transaction in the following manner based on the EP1 fingerprint type.
  • the client C1 reads the QR code using the terminal T1. He can either read the QR code directly with his camera or with the application of payment installed on its T1 terminal.
  • Figure 3 illustrates a T1 customer terminal with the application in use. This figure shows screen S showing the QR code acquisition zone Z.
  • reading the QR code will trigger the opening of the payment application installed on the T1 terminal.
  • a prior authentication of the C1 client is implemented by the client’s T1 terminal before a transaction can be validated.
  • This authentication can be done, for example, by fingerprint recognition or facial recognition or by entering a code.
  • the client C1 approaches his terminal T1 client to the terminal T2 to acquire (step 109) the fingerprint EP1.
  • the terminal T1 reads the QR code by acquiring an image of the QR code.
  • the acquisition of the transaction fingerprint triggers a request for validation of the transaction by the client C1 which takes the form of authentication of the client C1 (step 110). Note that if the client does not have the application, the acquisition of the fingerprint will refer to a download link for the application to access the service.
  • the QR code carries a deep link that allows direct access to the application.
  • QR code ensures security for the customer since the imprint systematically refers to secure and certified addresses, otherwise an error is returned to the customer.
  • the client C1 approaches his client terminal T1 to the terminal T2 to acquire (step 109) the fingerprint EP1.
  • the terminal T1 reads the fingerprint via NFC.
  • the acquisition of the fingerprint triggers the opening of a payment application on the client terminal T1 which requests authentication of the client C1.
  • This authentication is implemented by the client terminal T1 for example by recognition of a fingerprint or facial recognition or by entering a code.
  • the acquisition of the transaction fingerprint triggers a request for validation of the transaction by the client C1 which takes the form of authentication of the client C1 (step 110).
  • the reception by NFC of the fingerprint EP1 if the application is not already open triggers the opening of the application. So :
  • the customer in the context of contactless payment by NFC: the customer must approach his terminal near an NFC chip (which can be located on the merchant's counter or on a table or on a wall). Also, the customer arrives directly on the interface allowing the transaction to be validated, he will automatically arrive on this interface when the phone detects an NFC chip;
  • NFC chip which can be located on the merchant's counter or on a table or on a wall.
  • the customer's terminal will detect the transaction via the merchant's terminals which emit BLE (radio frequency) waves. The reception of these waves triggers the emission of a notification in the application and by clicking on the notification the application will open so that the customer can arrive at the interface allowing the transaction to be validated.
  • BLE radio frequency
  • the customer Through the C1 application and prior authentication of the customer, the customer enters the 6-digit code associated with the imprint presented by the merchant on his T1 terminal. The amount requested by the merchant is then displayed and the C1 customer has the option to validate or cancel the transaction.
  • the transaction is immediate and lasted a maximum of two seconds. This streamlines payments and makes the checkout process easier.
  • the validated transaction triggers a generation (step 112) by the customer's terminal T1 of a sales message M2 followed by its transmission (step 113) to the payment server SP.
  • the sales message M2 includes in particular information relating to the amount of the transaction, information relating to a customer's identity and information relating to a merchant's identity. Such a M2 sales message will allow the payment SP server to process the transaction by clearly identifying all parties involved in the transaction
  • the received M2 sales message (step 114) is then decoded (step 115) by the payment server SP to extract the information relating to the transaction.
  • the payment server SP then performs a comparison (step 116) of the transaction amount with a payment capacity entered in its customer account 10.
  • a capacity is defined when the customer account 10 is created and is variable according to the information communicated by the customer, depending on the financial data collected.
  • the payment capacity can be between 0 and 200 euros by default and beyond after a solvency study of the customer. This study can be done, for example, by sending the customer's last three bank statements or via a connection with their bank, allowing the payment server to retrieve banking data over the last three months.
  • the customer's external account must be confirmed for the amount of their payment facility to increase from €50 to €200 (this is particularly valid in the context of a registration made without a DSP2 connection).
  • the payment server SP sends a message to the merchant terminal T2 as well as to the customer terminal T1.
  • the customer C1 and the merchant C2 are thus notified simultaneously of the refusal of the transaction (step 117, step 118).
  • the payment server SP sends (step 121) to the central server SC a transfer message M3 which allows the central server SC to execute the following operations (step 122): credit the merchant's operating account 22 with the amount of the transaction less a commission which is transferred to a central operating account 30 also stored in the central server SC, debit the customer's operating account 12 with the amount of the transaction.
  • the transaction is completed and the merchant C2 is notified (step 123) by the payment server SP.
  • the customer's operating account is therefore in debit for the amount of the transaction while the merchant's operating account is in positive for this amount less the amount of the commission.
  • the bank transfer session is initiated at a variable frequency or at each transaction. For example, the session is initiated every day (end of day), every month (end of month), every week (end of week), etc.
  • the idea is that it does not interfere with the customer's validation of the payment and does not slow down the transaction as such.
  • the payment server SP issues a first collection order (step 124) to the central server SC of the central banking institution EC.
  • This first order aims to recover the debit(s) from the customer operating account 12.
  • the central server SC then executes a collection of the total of the debits from the customer operating account according to the known standards in force.
  • the execution of this first collection order implies that the central server SC sends the first order to the customer banking institution E1 and in particular to the server S1 of the customer banking institution.
  • the server of the customer banking institution S1 therefore transfers (step 126) from the customer's bank account 11 to the central operating account 30 the total of the debits from the customer operating account 12.
  • the payment server SP is then notified of the coverage of the customer's debits (step 127, step 128).
  • the amounts credited to the merchant's operating account 22 during each transaction are then transferred to the merchant bank account 21 (step 125).
  • This operation is issued by the payment server SP (step 129) to the central server SC of the central banking institution EC.
  • This second order aims to credit the merchant bank account 21 with the amount credited to its operating account 22.
  • the central server SC then executes (step 131) a transfer from the merchant's operating account 22 of the amount to be credited to the merchant's bank account 21 (step 132).
  • the merchant is assured of receiving the funds from his sales since the compensation of funds is dissociated from the payment of merchants and is covered by the banking establishment associated with the central server (SC).
  • SC central server
  • an electronic payment method in accordance with the present disclosure comprises the following steps, implemented by a payment server: a) receiving a sales message from a client terminal, the sales message comprising information relating to an amount of a transaction and information relating to an identity of a merchant; b) comparing the amount of the transaction to a payment capacity contained in a client account stored in the payment server and if the amount of the transaction is less than or equal to the payment capacity; b) sending to a central server a message transferring the amount of the transaction so that the central server credits an operating account of the merchant with the amount of the transaction less a commission, debits an operating account of the customer and credits a central operating account with the commission; c) sending to the central server an order to withdraw the debit balance of the customer operating account from the customer bank account to the central operating account of the central banking institution; d) sending an order to transfer the balance of the operating account of the merchant to the merchant bank account; e) receipt from the central server of a notification that the debit balance of the
  • step a) a0) receiving a transaction message from a merchant terminal, the transaction message comprising an amount of a sale; a1) generating a transaction imprint from the received transaction message, the imprint comprising the amount of the sale and an identity of the merchant known to the payment server; a2) transmitting the generated imprint to the merchant terminal.
  • the imprint is a QR code, a near field communication label, a 6-digit numeric code or a communication label (NFC) or by Bluetooth Low Energy (BLE).
  • the collection order is issued for each transaction or periodically at a specific frequency.

Landscapes

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

Abstract

L'invention concerne un procédé de paiement électronique, comprenant les étapes suivantes, mises en oeuvre par un serveur de paiement : - réception d'un message de transaction issu d'un terminal commerçant, le message de transaction comprenant un montant d'une vente à un client le montant de la vente ayant été saisi au moyen d'un terminal commerçant; - génération d'une empreinte de transaction à partir du message de transaction reçu, l'empreinte comprenant le montant de la vente et une identité du commerçant connue du serveur de paiement sous la forme d'un format pouvant être acquis par des moyens d'acquisition d'un terminal client; - émission de l'empreinte générée au terminal commerçant, le terminal commerçant étant configuré pour présenter l'empreinte à un terminal client; - réception d'un message de vente issu d'un terminal client, le message de vente comprenant une information relative à un montant d'une transaction et une information relative à une identité d'un commerçant, le message de vente ayant été généré par le terminal client suite à l'acquisition de l'empreinte de transaction par le terminal client, une authentification du client et une validation de la transaction par le client au niveau du terminal client.

Description

DESCRIPTION
Procédé de paiement électronique
DOMAINE TECHNIQUE
L’invention concerne le domaine du paiement électronique et concerne notamment un procédé de paiement électronique ne nécessitant pas une carte bancaire.
ETAT DE LA TECHNIQUE
On connait le paiement par carte bancaire où un client présente à un terminal de paiement électronique (TPE) d’un commerçant sa carte bancaire.
Le paiement par carte bancaire présente toutefois un certain nombre d’inconvénients tant pour les commerçants que pour les consommateurs.
Pour les commerçants : il représente des frais de transaction élevés, il nécessite un grand nombre d’intermédiaires, il conduit à une transaction qui est relativement longue (environ 15s) il est sujet à une fraude à la carte bancaire qui est importante, il nécessite d’avoir un terminal de paiement pour encaisser les paiements par cartes bancaires (loué ou acheté), il conduit à une complexité des paiements sur internet en raison du système 3DSecure™ et une authentification forte requise pour valider les paiements, en raison de la complexité, il génère des frictions, ce qui a pour conséquence une perte de chiffre d’affaires pour les e-commerçants ou commerçants en raison d’un abandon de panier important au moment du paiement.
Pour les consommateurs : il nécessite une cotisation annuelle selon le type de carte bancaire, il est sujet à une facturation possible de frais sur les retraits d’espèces, la carte bancaire est parfois acceptée de manière limitée chez certains commerçants (exigence d’un montant minimum), la carte bancaire présente des plafonds de paiement et de retrait, il est impossible de faire des paiements entre particuliers, il n’est pas possible de pouvoir gérer sur une même carte un débit différé ou immédiat, il existe des plafonds de paiement pour les paiements sans contact.
Pour éviter l’utilisation de la carte bancaire, des solutions mettant en œuvre un smartphone (c’est-à-dire un téléphone intelligent), ont fait leur apparition. Ces solutions permettent de dématérialiser la carte bancaire mais présentent toujours les inconvénients du paiement par carte bancaire.
Il existe un besoin de simplifier les paiements en se soustrayant au dispositif de paiement par carte bancaire.
EXPOSE DE L’INVENTION
Le but de l’invention est de proposer une solution de paiement et d’encaissement qui soit simple, rapide, sécurisée qui n’utilise pas de carte bancaire pour des paiements réalisés aussi bien physiquement que pour des paiements en ligne.
A cet effet, l’invention propose selon un premier aspect un procédé de paiement électronique, comprenant les étapes suivantes, mises en œuvre par un serveur de paiement :
- réception d’un message de transaction issu d’un terminal commerçant, le message de transaction comprenant un montant d’une vente à un client le montant de la vente ayant été saisi au moyen d’un terminal commerçant ;
- génération d’une empreinte de transaction à partir du message de transaction reçu, l’empreinte comprenant le montant de la vente et une identité du commerçant connue du serveur de paiement sous la forme d’un format pouvant être acquis par des moyens d’acquisition d’un terminal client ;
- émission de l’empreinte générée au terminal commerçant, le terminal commerçant étant configuré pour présenter l’empreinte à un terminal client ;
- réception d’un message de vente issu d’un terminal client, le message de vente comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant, le message de vente ayant été généré par le terminal client suite à l’acquisition de l’empreinte de transaction par le terminal client, une authentification du client et une validation de la transaction par le client au niveau du terminal client.
De manière complémentaire, le procédé comprend les étapes suivantes, œuvre par un serveur de paiement :
- comparaison du montant de la transaction à une capacité de paiement contenu dans un compte client stocké dans le serveur de paiement et si le montant de la transaction est inférieur ou égal à la capacité de paiement ;
- émission vers un serveur central d’un message de transfert du montant de la transaction de manière que le serveur central crédite un compte de fonctionnement du commerçant du montant de la transaction minoré d’une commission, débite un compte de fonctionnement du client et crédite un compte de fonctionnement central de la commission ;
- émission vers le serveur central d’un ordre de prélèvement du solde débiteur du compte de fonctionnement client depuis le compte bancaire client (11) vers le compte de fonctionnement central de l’établissement bancaire central
- émission d’un ordre de transfert du solde du compte de fonctionnement du commerçant vers le compte bancaire commerçant ;
- réception du serveur central d’une notification que le solde débiteur du compte de fonctionnement du client a été prélevé.
Selon un mode de réalisation, l’empreinte est un QR code, une étiquette de communication par champ proche, un code numérique à 6 chiffres, une étiquette de communication par Bluetooth basse énergie.
Selon un mode de réalisation, si le montant de la transaction est supérieur à une capacité de paiement contenu dans le compte client, émission au terminal commerçant d’une notification d’abandon de la transaction et émission au terminal client d’une notification de refus de la transaction.
Selon un mode de réalisation, l’ordre de prélèvement est émis à chaque transaction ou bien périodiquement à une fréquence déterminée, une fois par jour ou une fois par mois ou en fin de journée ou en fin de mois.
Selon un mode de réalisation, le procédé comprend les étapes suivantes mises en œuvre par un terminal client : - acquisition de l’empreinte émise par le serveur de paiement et présentée au client au moyen d’un terminal commerçant ;
- authentification d’un client ;
- validation de la transaction du client par l’intermédiaire du terminal client ;
- génération du message de vente ;
- émission du message de vente vers le serveur de paiement.
Selon un mode de réalisation, l’acquisition de l’empreinte déclenche l’ouverture d’une application stockée sur le terminal du client, l’application permettant d’authentifier le client et de valider la transaction.
Selon un mode de réalisation, le procédé comprend les étapes suivantes mises en œuvre par un terminal commerçant :
- génération du message de transaction comprenant le montant de la vente
- émission du message de transaction vers le serveur de paiement
- présentation de l’empreinte, reçue du serveur de paiement, au client.
Selon un deuxième aspect, l’invention concerne un serveur de paiement comprenant une unité de traitement configurée pour mettre en œuvre un procédé selon le premier aspect de l’invention.
Selon un troisième aspect, l’invention concerne un procédé de paiement mis en œuvre par un terminal client comprenant des étapes suivantes :
- acquisition de l’empreinte émise par le serveur de paiement ;
- authentification d’un client ;
- validation de la transaction par le client ;
- génération du message de vente ;
- émission du message de vente vers un serveur de paiement selon le deuxième aspect de l’invention.
Selon un quatrième aspect, l’invention concerne un procédé de paiement comprenant les étapes suivantes mises en œuvre par un terminal commerçant :
- saisie d’une vente par le commerçant, la saisie comprenant le montant de la vente ;
- génération du message de transaction comprenant le montant de la vente
- émission du message de transaction vers un serveur de paiement selon le deuxième aspect de l’invention ;
- présentation de l’empreinte, reçue du serveur de paiement selon le deuxième aspect de l’invention, au client. Selon un cinquième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions, qui lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’un des aspects de l’invention.
Selon un sixième aspect, l’invention concerne un procédé de paiement électronique, comprenant les étapes suivantes :
- saisie d’une vente au moyen d’un terminal commerçant,
- génération par le terminal commerçant du message de transaction comprenant le montant de la vente
- émission par le terminal commerçant du message de transaction vers un serveur de paiement,
- réception par un serveur de paiement d’un message de transaction issu d’un terminal commerçant, le message de transaction comprenant un montant d’une vente à un client ;
- génération par un serveur de paiement d’une empreinte de transaction à partir du message de transaction reçu, l’empreinte comprenant le montant de la vente et une identité du commerçant connue du serveur de paiement ;
- émission par un serveur de paiement de l’empreinte généré au terminal commerçant configuré pour présenter l’empreinte à un client ;
- présentation au moyen du terminal commerçant de l’empreinte, reçue du serveur de paiement au client ;
- réception d’un message de vente issu d’un terminal client, le message de vente comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant, le message de vente ayant été généré par le terminal client suite à l’acquisition de l’empreinte de transaction par le terminal client, une authentification du client et une validation de la transaction par le client au niveau du terminal client.
L’invention selon un des aspects présentés ci-dessus présente les avantages suivants.
L’invention permet de s’affranchir définitivement de l’utilisation d’une carte bancaire présentée même dématérialisée à un terminal de paiement électronique.
L’invention ne requiert pas un rechargement préalable du compte, du fait du fonctionnement par prélèvements (à l'inverse des solutions basées sur la carte bancaire). L’invention identifie toutes les parties à la transaction, ce qui sécurise les transactions.
L’invention permet un paiement très rapide car en s’affranchissant de la carte bancaire, la solution s’affranchit de tous les intermédiaires habituels du paiement par carte bancaire.
L’invention permet un paiement plus sécurisée qu’un paiement par carte bancaire :
Utilisation des éléments de sécurité du terminal du porteur (code pin ou éléments d’identification biométrique),
Utilisation des éléments de sécurité de l’application du porteur (code pin ou éléments d’identification biométrique) pour les paiements supérieurs à un montant déterminé, par exemple 50 €,
Le montant du paiement sans code PIN est paramétrable entre 0 € et un montant déterminé, par exemple 50 € dans l’application selon les besoins de sécurité voulus par chaque porteur,
Il n’est plus nécessaire de saisir ou d’enregistrer ses codes de cartes bancaires pour réaliser des paiements en ligne.
Pas besoin d’enregistrer sa carte bancaire dans un portefeuille dématérialisé (appelé wallet, type Apple Pay™, Google Pay™),
- Aucune transmission au commerçant d’informations sensibles relatives au porteur (numéro de compte par exemple). En effet, la carte bancaire est un moyen de paiement qui tire de l’information depuis le système interbancaire grâce au numéro d’identification de la carte (code PAN pour Primary Account Number) alors qu’avec l’invention c’est le commerçant qui donne l’information de paiement au client qui valide la transaction. Le code PAN étant utilisée par les fraudeurs pour faire le lien entre le compte bancaire du client et sa carte. L’invention limite donc la fraude.
L’invention permet au client porteur de l’application de paiement selon l’invention de pouvoir gérer le débit de ses paiements en choisissant s’il souhaite basculer d’un paiement à débit différé vers un paiement à débit immédiat.
L’invention permet d’obtenir une capacité de dépense en fonction de ses ressources, déterminée de façon automatique lors du parcours d’inscription.
L’invention ne nécessite pas de précharger son compte depuis l’application pour réaliser des achats. L’invention ne nécessite aucune saisie du montant de la transaction par le client. Seul le commerçant effectue cette saisie.
PRESENTATION DES FIGURES
D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels :
- la figure 1 illustre une architecture de mise en œuvre d’un procédé de paiement électronique conforme à l’invention ;
- la figure 2 illustre des étapes d’un procédé de paiement électronique conforme à l’invention ;
- la figure 3 illustre un terminal client comprenant un écran et une zone d’acquisition d’un QR code.
Sur l’ensemble des figures les éléments similaires portent des références identiques.
DESCRIPTION DETAILLEE
Architecture
La figure 1 illustre une architecture de mise en œuvre d’un procédé de paiement électronique conforme à l’invention.
Un client C1 accède à un point de vente PdV d’un commerçant 02 pour effectuer un achat. Le client C1 possède un terminal électronique T1. Le terminal T1 électronique est de préférence un smartphone mais peut aussi être n’importe quel équipement adapté pour se connecter à un serveur de paiement SP : tablette tactile, ordinateur portable, console de jeux, smartwatch, etc.
Le point de vente PdV peut être un site Internet, un lieu physique, etc. Le point de vente PdV est notamment matérialisé par un terminal électronique T2 également adapté pour se connecter au serveur de paiement SP.
Les terminaux T1 , T2 peuvent se connecter au serveur de paiement SP au moyen d’une connexion sans fil par exemple par Internet R. Cette connexion peut être mise en œuvre par une liaison filaire (par exemple par une liaison par fibre optique, adsl, réseau, etc.) sans fil de type Wi-Fi ou via un réseau de communication mobile (3G, 4G, 5G, etc.).
Le serveur de paiement SP est typiquement configuré pour mettre en œuvre des traitements et comprend à ce titre un ou plusieurs calculateur(s). De préférence, le serveur de paiement SP et les terminaux T1 , T2 sont configurés pour échanger des données de manière sécurisées via la connexion Internet. Avantageusement, le serveur de paiement SP et les terminaux T1 , T2 sont configurés pour échanger des données de manière hautement sécurisée selon des standards de communication bien connus de l’homme du métier. En outre, le serveur de paiement SP comprend une ou plusieurs mémoires pour permettre le stockage de différentes données.
Pour accéder au serveur de paiement SP, une application de paiement est installée sur le terminal T1 du client 01 et le client C1 a créé un compte client 10 lui permettant d’utiliser l’application.
De manière similaire le commerçant 02 utilise une application dédiée pour lui permettre d’interagir avec le terminal T1 du client 01 , le commerçant 02 possédant un compte commerçant 20 pour accéder au serveur de paiement SP. Les comptes clients et commerçants respectivement 10 et 20 sont stockés par le serveur SP de paiement et comprennent toutes les informations relatives au client et au commerçant et permettent de tracer toutes les transactions.
Les applications client et commerçant utilisent des liens profonds qui assurent une sécurité accrue de la transaction. Ceci permet de limiter les risques liés aux attaques de l’homme du milieu (en anglais, man-in-the-middle attack, MITM) ou l’attaque de l’intercepteur qui a pour but d’intercepter et modifier des communications entre deux parties. En effet, le client et le commerçant ne communique jamais directement ensemble mais passent toujours par le serveur de paiement SP.
Le serveur de paiement SP est associé et connecté à un serveur central SC d’un établissement EC bancaire central qui permet de gérer des flux bancaires tels que des transferts interbancaires de fonds par virement bancaire notamment. La connexion entre le serveur central SC et le serveur de paiement SP est mise en œuvre de manière similaire à la connexion entre le serveur de paiement SP et les terminaux T1 , T2. Le serveur de paiement SP est associé au serveur central SC d’un établissement bancaire EC central qui va gérer tous les flux bancaires.
S’agissant d’une application permettant le paiement électronique, le client C1 possède un compte bancaire client 11 géré par un serveur S1 d’un établissement E1 bancaire client et le commerçant possède un compte bancaire commerçant 21 géré par un serveur S2 d’un établissement E2 bancaire commerçant.
Sur la figure 1 trois établissements bancaires distincts sont représentés mais un ou plusieurs établissements bancaires peuvent être confondus en fonction des préférences du client et du commerçant.
Comme on l’aura compris, les communications entre les différents serveurs et le terminal du commerçant et celui du client transitent par le réseau R Internet et sont sécurisées selon les standards bien connus de l’homme du métier. Les connexions mises en œuvre ne seront pas plus détaillées.
Le terminal T1 du client C1 et le terminal T2 du commerçant C2 peuvent par ailleurs être configurés pour communiquer entre eux selon la technologie de communication en champ proche (en anglais, Near Field Communication, NFC) ou bien par la technologie de communication Bluetooth basse énergie (Bluetooth Low Energy, BLE).
Inscription (en anglais, onboarding)
Comme présenté ci-dessus, un procédé de paiement électronique décrit en relation avec la figure 2, nécessite l’installation côté client C1 d’une application sur le terminal client T 1 pour accéder au service de paiement. Une fois l’application installée sur son terminal client T1 , pour pouvoir accéder au service de paiement, le client C1 s’inscrit au service (étape Insc C1) via l’application en créant son compte client 10.
De manière avantageuse, l’inscription (étape Insc C1) du client comprend les étapes suivantes :
- enregistrement du numéro de mobile du client ;
- enregistrement de l’adresse postale du client en se conformant le cas échéant à la législation en vigueur dans le pays d’utilisation du service (en France pour accéder à un tel service de paiement, le client doit renseigner son adresse fiscale) ; pour fluidifier une telle saisie, une recherche d’adresse automatisée est prévue ;
- enregistrement du lieu de naissance du client ;
- vérification de l’identité du client : une telle vérification peut comprendre la transmission d’un document d’identité du client (carte d’identité, passeport, carte de séjour, permis de conduire. La copie du document peut se faire à l’aide de l’appareil photo du terminal du client. Suite à la transmission du document d’identité, il est procédé à la capture du visage du client pour vérifier la correspondance entre le visage du client et celui présent sur le document d’identité ;
- de manière optionnelle, enregistrement de la situation professionnelle et d’un montant de revenus. S’agissant de la situation professionnelle une liste fermée est proposée au client pour qu’il choisisse celle qui lui correspond le mieux ;
- enregistrement des coordonnées bancaires du client soit par saisie de ses coordonnées bancaires (saisie de 1’1 BAN) soit par recueil direct des coordonnées auprès de l’établissement bancaire du client (avec une connexion de type DSP2). Les coordonnées bancaires ainsi enregistrées constituent une autorisation bancaire de prélèvement du compte bancaire 11 du client hébergé dans l’établissement E1 bancaire qui peut être quelconque. En effet, le service de paiement fonctionne en mettant en œuvre des prélèvements bancaires.
- acceptation des conditions d’accès au service par le client et signification à ce dernier d’un délai de rétraction ;
- configuration d’une code PIN confidentiel pour sécuriser les transactions au cours de l’utilisation du service et notamment pour accéder à l’application mettant en œuvre le service.
On constate que le client C1 n’a pas à posséder de carte bancaire pour s’enregistrer pour finaliser son inscription et l’ouverture de son compte client.
Toutes les données enregistrées sont attachées au compte client 10 qui est stocké dans le serveur de paiement SP et comporte outre les données enregistrées (notamment l’identité et les coordonnées bancaires), une capacité de paiement. Une telle capacité paiement limite le montant que le client peut utiliser mensuellement (en une ou plusieurs transactions) pour utiliser le service et mettre en œuvre le procédé de paiement électronique ici décrit. Cette capacité de paiement est de préférence initialement plafonnée à une faible valeur et relevée une fois le compte bancaire client 11 confirmé.
L’inscription du client est optimisée en termes de nombre de saisies manuelles et de validation. En effet, le client n’a que peu d’éléments à compléter manuellement ce qui diminue le risque d’erreur et accélère l’inscription. En outre, une fois l’enregistrement terminé, le client peut utiliser le service (même s’il n’a pas associé automatiquement son compte bancaire via DSP2) même si son compte client bancaire extérieur n’est pas confirmé. Il n’y a donc pas d’attente, le service est utilisable immédiatement pour effectuer un paiement.
De manière similaire, le commerçant C2 s’inscrit au service (étape Insc C2) et possède un compte commerçant 20 stocké dans le serveur de paiement SP. Ce compte commerçant 20 comporte l’identité du commerçant mais aussi ses coordonnées bancaires associées à son compte bancaire commerçant 21.
De manière avantageuse, l’inscription (étape Insc C2) du commerçant comprend les étapes suivantes :
- enregistrement d’informations d’identité et de contact du commerçant : nom, prénom, numéro de téléphone, adresse postale, adresse électronique, mot de passe pour accéder au compte commerçant ;
- optionnellement, un message électronique est émis et contient un code que le commerçant doit renseigner afin de vérifier son adresse électronique ; ceci permet de vérifier que l’adresse électronique est correcte ;
- enregistrement de la dénomination de l’entreprise (en France au moyen du numéro SIREN) ;
- affichage des informations enregistrées pour validation par le commerçant ;
- enregistrement des coordonnées bancaires du commerçant par saisie de l’IBAN
- vérification de l’identité du commerçant : une telle vérification peut comprendre la transmission d’un document d’identité du commerçant (carte d’identité, passeport, carte de séjour. La copie du document peut se faire à l’aide de l’appareil photo du terminal du commerçant. Suite à la transmission du document d’identité, il est procédé à la capture du visage du commerçant pour vérifier la correspondance entre le visage du commerçant et celui présent sur le document d’identité ;
- enregistrement du lieu de naissance du commerçant ;
- acceptation des conditions d’accès au service par le commerçant.
L’inscription du client et du commerçant permet de pouvoir identifier de manière non ambiguë les deux parties participantes d’une transaction. Ceci permet de sécuriser la transaction. Ceci est particulièrement utile lorsqu’il s’agit de lutter contre le blanchiment d’argent et le financement du terrorisme. Les coordonnées bancaires vont permettre l’initiation d’opérations bancaires requises par le serveur de paiement SP au serveur central SC qui est habilité à mettre en œuvre ce type d’opérations.
Pour ce faire, à la création des comptes client et commerçant 10, 20, un compte de fonctionnement client 12 (type compte de paiement) et un compte de fonctionnement commerçant 22 (type compte de paiement) sont créés dans le serveur central SC de l’établissement bancaire central EC auquel le serveur de paiement SP est associé. Ces comptes de fonctionnement vont permettre de gérer les flux bancaires de manière transparente pour le client et le commerçant le moment venu.
Initiation d’un paiement
On décrit maintenant une utilisation du service de paiement par la mise en œuvre du procédé de paiement électronique dont un mode de réalisation préférentiel est illustré sur la figure 2.
Un client C1 se rend dans un point PDV de vente pour acheter un ou plusieurs bien(s) (étape 100). Le client C1 se présente au point de vente PDV pour que le commerçant C2 saisisse la vente (étape 101). Il s’agit par exemple ici d’un passage en caisse classique. La saisie de la vente est faite par le commerçant C2 sur son terminal T2 commerçant et conduit à la génération d’un message M1 de transaction comprenant le montant de la vente (étape 102). Le message M1 de transaction comprend aussi l’identité du commerçant pour que le serveur du paiement SP l’identifie.
Le commerçant C2 via son terminal T2 valide la vente ce qui déclenche l’émission (étape 103) du message M1 de transaction vers le serveur SP de paiement. Seul le commerçant C2 saisit le montant de la transaction, le client n’a donc pas à saisir un tel montant.
A la réception (étape 104) de ce message M1 de transaction, le serveur SP de paiement génère (étape 105) une empreinte EP1 de transaction destinée à être acquise/reçue par le terminal T1 client.
L’empreinte EP de transaction peut prendre plusieurs formes.
Selon un mode de réalisation l’empreinte EP1 de transaction est un QR code.
Selon un mode de réalisation l’empreinte EP1 de transaction est une étiquette de communication par champ proche (NFC). Selon un mode de réalisation, l’empreinte EP1 de transaction est un code numérique à 6 chiffres.
Selon un mode de réalisation, l’empreinte EP1 est une étiquette de communication par BLE (Bluetooth Low Energy).
Cette empreinte EP1 contient le montant de la vente ainsi que l’identité du commerçant C2 connue du serveur SP de paiement.
Cette empreinte EP1 est stockée (étape 106) dans le serveur de paiement SP pour permettre une traçabilité des transactions et est retournée (étape 107) au terminal T2 du commerçant C2 pour effectuer la transaction avec le client C1.
En pratique, l’empreinte EP1 provenant directement du commerçant ce dernier est clairement identifié par le client.
De manière alternative, dans le cas d’un paiement en distanciel l’empreinte EP1 est montrée au client via le site du commerçant. De la sorte, le commerçant est capable de créer une transaction dans différents contextes d’encaissement.
En proposant l’empreinte EP1 , le commerçant s’affranchit de l’utilisation d’un terminal de paiement électronique (TPE) ce qui diminue les coûts pour le commerçant en termes d’équipements et en ressources informatiques et donc en énergie. En outre, l’empreinte EP1 pouvant prendre plusieurs formes, le commerçant n’est pas limité technologiquement. Ainsi, il très facile pour un commerçant de proposer un tel service de paiement.
Session de transaction
L’empreinte EP1 est présentée / émise au client C1 (étape 108) notamment par l’intermédiaire du terminal commerçant T2, la transaction peut être effectuée en physique ou à distance.
Puis, le client C1 confirme la transaction de la manière suivante en fonction du type d’empreinte EP1.
Paiement par QR code
Le client C1 procède à la lecture du QR code au moyen du terminal T1. Il peut soit lire le QR code directement avec son appareil photo soit avec l’application de paiement installée sur son terminal T1 . La figure 3 illustre un terminal T 1 client avec l’application en cours d’utilisation. On voit sur cette figure l’écran S montrant la zone Z d’acquisition du QR code.
En utilisant l’appareil photo, la lecture du QR code va déclencher l’ouverture de l’application de paiement installée sur son terminal T 1 .
Une fois l’application ouverte, une authentification préalable du client C1 est mise en œuvre par le terminal T1 du client avant de pouvoir valider une transaction. Cette authentification peut se faire par exemple par une reconnaissance d’une empreinte digitale ou une reconnaissance faciale ou encore par saisie d’un code.
Ensuite, le client C1 approche son terminal T1 client du terminal T2 pour procéder à l’acquisition (étape 109) de l’empreinte EP1. Le terminal T1 procède à la lecture du QR code par acquisition d’une image du QR code. L’acquisition de l’empreinte de transaction déclenche une requête de validation de la transaction par le client C1 qui prend la forme d’une authentification du client C1 (étape 110). On note que si le client ne possède pas l’application, l’acquisition de l’empreinte renverra à un lien de téléchargement de l’application pour accéder au service.
Par ailleurs, le QR code porte un lien profond qui permet directement d’accéder à l’application.
En outre, l’utilisation d’un QR code assure une sécurité au client puisque l’empreinte renvoie systématiquement vers des adresses sécurisées et certifiées sinon une erreur est renvoyée au client.
Paiement sans contact par NFC ou BLE
Le client C1 approche son terminal T1 client du terminal T2 pour procéder à l’acquisition (étape 109) de l’empreinte EP1. Le terminal T1 procède à la lecture par liaison NFC de l’empreinte. Dans le cas du NFC, l’acquisition de l’empreinte déclenche l’ouverture d’une application de paiement sur le terminal client T1 qui demande une authentification du client C1. Cette authentification est mise en œuvre par le terminal T1 du client par exemple par une reconnaissance d’une empreinte digitale ou une reconnaissance faciale ou encore par saisie d’un code. L’acquisition de l’empreinte de transaction déclenche une requête de validation de la transaction par le client C1 qui prend la forme d’une authentification du client C1 (étape 110). La réception par NFC de l’empreinte EP1 si l’application n’est pas déjà ouverte déclenche l’ouverture de l’application. Ainsi :
- dans le cadre du paiement sans contact par N FC : le client doit approcher son terminal prêt d'une puce NFC (pouvant se trouver sur le comptoir du commerçant ou sur une table ou sur un mur). Aussi, le client arrive directement sur l’interface permettant de valider la transaction, il arrivera automatiquement sur cette interface quand le téléphone détectera une puce NFC ;
- dans le cadre du paiement sans contact en BLE : le terminal du client détectera la transaction via les bornes du commerçant qui émettent des ondes BLE (radio-fréquence). La réception de ces ondes déclenche l’émission d’une notification dans l’application et en cliquant sur la notification l’application s'ouvrira pour que le client puisse arriver sur l’interface permettant de valider la transaction.
Paiement par saisie d’un code de transaction
Par l’intermédiaire de l’application et authentification préalable du client C1 , le client saisi le code à 6 chiffres associé à l’empreinte présentée par le commerçant sur son terminal T1 . Le montant demandé par le commerçant est alors affiché et le client C1 a la possibilité de valider ou d’annuler la transaction.
Une fois le client C1 authentifié, ce dernier valide la transaction (étape 111).
A ce stade, le client a procédé au paiement. La transaction est immédiate et a duré au maximum deux secondes. Ceci fluidifie les paiements et facilite le passage en caisse.
On remarque que le nombre d’étapes pour valider la transaction est au maximum de trois (ouverture de l’application comprise) ce qui améliore l’expérience client et simplifie la prise en main du paiement mais rend aussi plus rapide le paiement. Un gain de temps est ainsi clairement obtenu pour finaliser une vente.
Les étapes suivantes sont ensuite transparentes pour le commerçant et le client puisqu’il s’agit d’échanges entre les serveurs impliqués dans le procédé de paiement. On remarquera qu’à ce stade qu’aucune communication avec un établissement bancaire n’est requise et que notamment aucun flux bancaire visant à créditer ou débiter un compte bancaire n’est utilisé.
La transaction validée (étape 111) déclenche une génération (étape 112) par le terminal T1 du client d’un message de vente M2 suivi de son émission (étape 113) vers le serveur SP de paiement. Le message de vente M2 comporte notamment une information relative au montant de la transaction, une information relative à une identité du client et une information relative à une identité d’un commerçant. Un tel message de vente M2 va permettre au serveur SP de paiement de traiter la transaction en identifiant clairement toutes les parties impliquées à la transaction
Le message de vente M2 reçu (étape 114) est ensuite décodé (étape 115) par le serveur SP de paiement pour extraire les informations relatives à la transaction. De manière avantageuse, le serveur SP de paiement procède alors à une comparaison (étape 116) du montant de la transaction à une capacité de paiement renseignée dans son compte client 10. Une telle capacité est définie à la création du compte client 10 et est variable selon les informations communiquées par le client, en fonction des données financières collectées. La capacité de paiement peut être comprise entre 0 et 200 euros par défaut et au-delà après une étude de solvabilité du client. Cette étude peut être faite, par exemple, grâce à l’envoi des trois derniers relevés de compte du client ou via une connexion avec sa banque, permettant au serveur de paiement de récupérer les données bancaires sur les trois derniers mois.
Dans tous les cas, le compte externe du client doit être confirmé pour que le montant de sa facilité de paiement passe de 50€ à 200€ (ceci est particulièrement valable dans le cadre d'une inscription faite sans connexion DSP2).
Si le montant de la transaction est supérieur à la capacité de paiement du client, la transaction est abandonnée, le serveur de paiement SP émet au terminal commerçant T2 un message ainsi qu’au terminal T1 client. Le client C1 et le commerçant C2 sont ainsi notifiés simultanément du refus de la transaction (étape 117, étape 118).
Si le montant de la transaction est inférieur ou égal à la capacité de paiement du client C1 alors le serveur SP de paiement émet (étape 121) au serveur central SC un message de transfert M3 qui permet au serveur central SC d’exécuter les opérations suivantes (étape 122) : créditer le compte de fonctionnement du commerçant 22 du montant de la transaction minoré d’une commission qui est transféré un compte de fonctionnement central 30 également stocké dans le serveur central SC, débiter le compte de fonctionnement du client 12 du montant de la transaction.
Une fois le transfert effectué sur le compte de fonctionnement du commerçant 22, la transaction est terminée et le commerçant C2 est notifié (étape 123) par le serveur de paiement SP.
Entre la validation de transaction par le client 11 et la notification du commerçant 22 une durée de tout au plus 2 secondes s’est écoulée. Ceci améliore aussi l’expérience client et simplifie la prise en main du paiement mais rend aussi plus rapide le paiement. Un gain de temps est ainsi clairement obtenu pour finaliser une vente.
A l’issue de la transaction, le compte de fonctionnement du client est donc débiteur du montant de la transaction tandis que celui du compte de fonctionnement du commerçant est positif de ce montant minoré du montant de la commission.
On comprend que plusieurs transactions peuvent être portées au crédit ou au débit des comptes de fonctionnement commerçant et client.
Session transfert bancaire
La session de transfert bancaire est initiée à une fréquence variable ou à chaque transaction. La session est par exemple initiée chaque jour (en fin de journée), chaque mois (en fin de mois), chaque semaine (en fin de semaine), etc. L’idée et qu’elle n’interfère pas avec la validation du paiement par le client et ne ralentisse pas la transaction en tant que telle.
Au moment souhaité, le serveur de paiement SP émet un premier ordre de prélèvement (étape 124) au serveur central SC de l’établissement bancaire central EC. Ce premier ordre vise à recouvrir le ou les débit(s) du compte de fonctionnement client 12.
Le serveur central SC exécute alors un prélèvement du total des débits du compte de fonctionnement client selon les standards en vigueur connus. L’exécution de ce premier ordre de prélèvement implique que le serveur central SC envoie le premier ordre à l’établissement bancaire client E1 et en particulier au serveur S1 de l’établissement bancaire client. Le serveur de l’établissement bancaire client S1 transfère (étape 126) donc depuis le compte bancaire du client 11 vers le compte de fonctionnement central 30 le total des débits du compte de fonctionnement client 12. Le serveur de paiement SP est alors notifié de la couverture des débits du client (étape 127, étape 128).
Parallèlement, les sommes créditées sur le compte de fonctionnement 22 du commerçant lors de chaque transaction sont ensuite virées sur le compte bancaire commerçant 21 (étape 125). Cette opération est émise par le serveur de paiement SP (étape 129) vers le serveur central SC de l’établissement bancaire central EC. Ce deuxième ordre vise à créditer le compte bancaire commerçant 21 du montant au crédit de son compte de fonctionnement 22. Le serveur central SC exécute (étape 131) alors un virement du compte de fonctionnement du commerçant 22 du montant à créditer au compte bancaire commerçant 21 (étape 132).
Le commerçant est assuré de percevoir les fonds de ses ventes puisque la compensation des fonds est dissociée du paiement des commerçants et est couvertes par l’établissement bancaire associé au serveur central (SC).
Autres aspects :
Selon premier exemple de réalisation, un procédé de paiement électronique conforme au présent exposé, comprend les étapes suivantes, mises en œuvre par un serveur de paiement : a) réception d’un message de vente issu d’un terminal client, le message de vente comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant ; b) comparaison du montant de la transaction à une capacité de paiement contenu dans un compte client stocké dans le serveur de paiement et si le montant de la transaction est inférieur ou égal à la capacité de paiement ; b) émission vers un serveur central d’un message de transfert du montant de la transaction de manière que le serveur central crédite un compte de fonctionnement du commerçant du montant de la transaction minoré d’une commission, débite un compte de fonctionnement du client et crédite un compte de fonctionnement central de la commission ; c) émission vers le serveur central d’un ordre de prélèvement du solde débiteur du compte de fonctionnement client depuis le compte bancaire client vers le compte de fonctionnement central de l’établissement bancaire central d) émission d’un ordre de transfert du solde du compte de fonctionnement du commerçant vers le compte bancaire commerçant ; e) réception du serveur central d’une notification que le solde débiteur du compte de fonctionnement du client a été prélevé.
Le procédé selon le premier exemple est avantageusement complété par les caractéristiques suivantes, prises seules ou en une quelconque de leur combinaison techniquement possible :
- préalablement à l’étape a) : a0) réception d’un message de transaction issu d’un terminal commerçant, le message de transaction comprenant un montant d’une vente ; a1) génération d’une empreinte de transaction à partir du message de transaction reçu, l’empreinte comprenant le montant de la vente et une identité du commerçant connue du serveur de paiement ; a2) émission de l’empreinte généré au terminal commerçant.
- l’empreinte est un QR code, une étiquette de communication par champ proche, un code numérique à 6 chiffres ou d’une étiquette de communication (NFC) ou par Bluetooth Low Energie (BLE).
- la réception du message de vente est consécutive à une validation de la transaction par le client par l’intermédiaire du terminal client à la suite d’une lecture par le terminal client de l’empreinte et à une authentification du client au niveau du terminal client.
- si le montant de la transaction est supérieur à une capacité de paiement contenu dans le compte client, émission au terminal commerçant d’une notification d’abandon de la transaction et émission au terminal client d’une notification de refus de la transaction.
- l’ordre de prélèvement est émis à chaque transaction ou bien périodiquement à une fréquence déterminée.

Claims

REVENDICATIONS
1 . Procédé de paiement électronique, comprenant les étapes suivantes, mises en œuvre par un serveur (SP) de paiement :
- réception (104) d’un message de transaction (M1) issu d’un terminal commerçant (T2), le message de transaction (M1) comprenant un montant d’une vente à un client (C1) le montant de la vente ayant été saisi au moyen d’un terminal commerçant (T2) ;
- génération (105) d’une empreinte (EP1) de transaction à partir du message de transaction (M1) reçu, l’empreinte (EP1) comprenant le montant de la vente et une identité du commerçant (C2) connue du serveur (SP) de paiement sous la forme d’un format pouvant être acquis par des moyens d’acquisition d’un terminal client (T1) ;
- émission (107) de l’empreinte (EP1) générée au terminal commerçant (T2), le terminal commerçant (T2) étant configuré pour présenter l’empreinte (EP1) à un terminal client ;
- réception (114) d’un message de vente (M2) issu d’un terminal (T1) client, le message de vente (M2) comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant, le message de vente (M2) ayant été généré par le terminal client (T1) suite à l’acquisition (109) de l’empreinte (EP1) de transaction par le terminal (T1) client, une authentification (110) du client (C1) et une validation (111) de la transaction par le client (C1) au niveau du terminal client (T1).
2. Procédé selon la revendication 1 , comprenant les étapes suivantes, mises en œuvre par un serveur (SP) de paiement :
- comparaison (116) du montant de la transaction à une capacité de paiement contenu dans un compte client stocké dans le serveur de paiement (SP) et si le montant de la transaction est inférieur ou égal à la capacité de paiement ;
- émission (121) vers un serveur central (SC) d’un message (M3) de transfert du montant de la transaction de manière que le serveur (SC) central crédite un compte de fonctionnement du commerçant du montant de la transaction minoré d’une commission, débite un compte de fonctionnement du client et crédite un compte de fonctionnement central de la commission ;
- émission (124) vers le serveur central (SC) d’un ordre de prélèvement du solde débiteur du compte de fonctionnement client depuis le compte bancaire client (11) vers le compte de fonctionnement central (30) de l’établissement bancaire central
- émission d’un ordre de transfert du solde du compte de fonctionnement du commerçant (22) vers le compte bancaire commerçant (21) ;
- réception (127) du serveur central d’une notification que le solde débiteur du compte de fonctionnement du client a été prélevé.
3. Procédé selon l’une des revendications 1 à 2, dans lequel l’empreinte (EP1) est un QR code, une étiquette de communication par champ proche (NFC), un code numérique à 6 chiffres, une étiquette de communication par Bluetooth basse énergie.
4. Procédé selon l’une des revendications 1 à 3, dans lequel si le montant de la transaction est supérieur à une capacité de paiement contenu dans le compte client, émission (117) au terminal (T2) commerçant d’une notification d’abandon de la transaction et émission (118) au terminal (T1) client d’une notification de refus de la transaction.
5. Procédé selon l’une des revendications 2 à 4, dans lequel l’ordre de prélèvement est émis à chaque transaction ou bien périodiquement à une fréquence déterminée, une fois par jour ou une fois par mois ou en fin de journée ou en fin de mois.
6. Procédé selon l’une des revendications précédentes, comprenant les étapes suivantes mises en œuvre par un terminal client (T1) :
- acquisition (109) de l’empreinte (EP1) émise par le serveur (SP) de paiement et présentée au client au moyen d’un terminal commerçant ;
- authentification (110) d’un client (C1) ;
- validation de la transaction (111) du client (C1) par l’intermédiaire du terminal client ;
- génération du message de vente (M2), ;
- émission (113) du message de vente (M2) vers le serveur (SP) de paiement.
7. Procédé selon la revendication précédente, dans lequel l’acquisition (109) de l’empreinte (EP1) déclenche l’ouverture d’une application stockée sur le terminal (T1) du client, l’application permettant d’authentifier le client et de valider la transaction.
8. Procédé selon l’une des revendications précédentes, comprenant les étapes suivantes mises en œuvre par un terminal commerçant (C2) :
- génération (102) du message de transaction comprenant le montant de la vente
- émission (103) du message (M1) de transaction vers le serveur de paiement
- présentation (108) de l’empreinte (EP1), reçue du serveur de paiement, au client (C1).
9. Serveur (SP) de paiement comprenant une unité de traitement configurée pour mettre en œuvre un procédé selon l’une des revendications 1 à 5.
10. Procédé de paiement mis en œuvre par un terminal client comprenant des étapes de :
- acquisition (109) de l’empreinte (EP1) émise par le serveur (SP) de paiement ;
- authentification (110) d’un client (C1) ;
- validation de la transaction (111) par le client (C1);
- génération du message de vente (M2), ;
- émission (113) du message de vente (M2) vers un serveur (SP) de paiement selon la revendication 9.
11. Procédé de paiement comprenant les étapes suivantes mises en œuvre par un terminal commerçant :
- saisie (101) d’une vente par le commerçant, la saisie comprenant le montant de la vente ;
- génération (102) du message de transaction comprenant le montant de la vente
- émission (103) du message (M1) de transaction vers un serveur de paiement selon la revendication 9 ; - présentation (108) de l’empreinte (EP1), reçue du serveur de paiement selon la revendication 9, au client (C1)
12. Produit programme d’ordinateur comprenant des instructions, qui lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une des revendications 1 à 11 .
13. Procédé de paiement électronique, comprenant les étapes suivantes :
- saisie (101) d’une vente au moyen d’un terminal commerçant ;
- génération (102) par le terminal commerçant du message de transaction comprenant le montant de la vente ;
- émission (103) par le terminal commerçant du message (M1) de transaction vers un serveur de paiement ;
- réception (104) par un serveur (SP) de paiement d’un message de transaction (M1) issu d’un terminal commerçant (T2), le message de transaction (M1) comprenant un montant d’une vente à un client (C1) ;
- génération (105) par un serveur (SP) de paiement d’une empreinte (EP1) de transaction à partir du message de transaction (M1) reçu, l’empreinte (EP1) comprenant le montant de la vente et une identité du commerçant (C2) connue du serveur (SP) de paiement ;
- émission (107) par un serveur (SP) de paiement de l’empreinte (EP1) généré au terminal commerçant (T2) configuré pour présenter l’empreinte (EP1) à un client ;
- présentation (108) au moyen du terminal commerçant de l’empreinte (EP1), reçue du serveur de paiement au client (C1) ;
- réception (114) d’un message de vente (M2) issu d’un terminal (T1) client, le message de vente (M2) comprenant une information relative à un montant d’une transaction et une information relative à une identité d’un commerçant, le message de vente (M2) ayant été généré par le terminal client (T1) suite à l’acquisition (109) de l’empreinte (EP1) de transaction par le terminal (T1) client, une authentification (110) du client (C1) et une validation (111) de la transaction par le client (C1) au niveau du terminal client (T1).
PCT/EP2024/066683 2023-06-16 2024-06-14 Procédé de paiement électronique Ceased WO2024256700A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP24732323.1A EP4728457A1 (fr) 2023-06-16 2024-06-14 Procédé de paiement électronique
AU2024304156A AU2024304156A1 (en) 2023-06-16 2024-06-14 Electronic payment method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2306170 2023-06-16
FR2306170A FR3150025B1 (fr) 2023-06-16 2023-06-16 Procédé de paiement électronique

Publications (1)

Publication Number Publication Date
WO2024256700A1 true WO2024256700A1 (fr) 2024-12-19

Family

ID=87889704

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/066683 Ceased WO2024256700A1 (fr) 2023-06-16 2024-06-14 Procédé de paiement électronique

Country Status (4)

Country Link
EP (1) EP4728457A1 (fr)
AU (1) AU2024304156A1 (fr)
FR (1) FR3150025B1 (fr)
WO (1) WO2024256700A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220405737A1 (en) * 2014-09-09 2022-12-22 Block, Inc. Anonymous Payment Transactions

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220405737A1 (en) * 2014-09-09 2022-12-22 Block, Inc. Anonymous Payment Transactions

Also Published As

Publication number Publication date
EP4728457A1 (fr) 2026-04-22
FR3150025B1 (fr) 2025-11-28
FR3150025A1 (fr) 2024-12-20
AU2024304156A1 (en) 2026-02-05

Similar Documents

Publication Publication Date Title
CA2971635C (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
EP0820620B1 (fr) Procede de paiement electronique permettant d'effectuer des transactions liees a l'achat de biens sur un reseau informatique
US20160098692A1 (en) Method for processing transaction statement inquiries via an atm
US20160098700A1 (en) Method for providing privacy through atm communication to consumer devices
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
US11676149B2 (en) Methods and systems for routing transactions between automated teller machines, points of sale, financial institutions, and software wallets
KR20100123896A (ko) 모바일 전화기 거래 시스템 및 방법
WO2015023172A2 (fr) Systemes et procedes de paiement mobile interpersonnel instantane (p2p)
US12250213B2 (en) Resource processing terminal device with enhanced secure resource transmissions based on image capture
KR20200048134A (ko) 비대면 계좌개설을 통한 간편결제 서비스 등록 방법
US20210326840A1 (en) Issuing a virtual value-bearing card associated with only non-personally identifying information from a kiosk
Hossain et al. Analysis of centralized payment eco-system: A systematic review on e-payments
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants
WO2024256700A1 (fr) Procédé de paiement électronique
EP3987390A1 (fr) Système d'applications de service pour terminaux de paiement
FR2837643A1 (fr) Procede de securisation d'un paiement par carte de credit
Hota Unified payments interface in India: Revolution in the making
EP2080160A1 (fr) Procédé et système de paiement à l'aide d'un téléphone mobile
BE1032816B1 (fr) Méthode de paiement en ligne par compte de paiement
EP1225549B1 (fr) Terminal et procédé de paiement électronique.
WO2002031612A2 (fr) Procede pour effectuer une transaction commerciale sur reseau
KR20170054131A (ko) 카드도용결제를 차단하는 온/오프라인 금융거래 결제 방법
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
KR20170118661A (ko) 카드도용결제를 차단하는 온/오프라인 금융거래 결제 방법
FR3049369A1 (fr) Procede de transfert de transaction, procede de transaction et terminal mettant en œuvre au moins l'un d'eux

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24732323

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112025027994

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: 1020267001346

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2024732323

Country of ref document: EP

Ref document number: AU2024304156

Country of ref document: AU

Ref document number: 829233

Country of ref document: NZ

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2024732323

Country of ref document: EP

Effective date: 20260116

ENP Entry into the national phase

Ref document number: 2024732323

Country of ref document: EP

Effective date: 20260116

WWE Wipo information: entry into national phase

Ref document number: 11202508538Y

Country of ref document: SG

WWP Wipo information: published in national office

Ref document number: 829233

Country of ref document: NZ

Ref document number: 11202508538Y

Country of ref document: SG

ENP Entry into the national phase

Ref document number: 2024732323

Country of ref document: EP

Effective date: 20260116

ENP Entry into the national phase

Ref document number: 2024304156

Country of ref document: AU

Date of ref document: 20240614

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2024732323

Country of ref document: EP

Effective date: 20260116

WWP Wipo information: published in national office

Ref document number: 2024732323

Country of ref document: EP