Electronic payment method

Abstract

The invention relates to an electronic payment method, comprising the following steps, implemented by a payment server: a) receiving a sales message from a client terminal, the sales message including information relating to a transaction amount and information relating to a merchant's identity; b) comparing the transaction amount to a payment capacity contained in a client account stored in the payment server and determining if the transaction amount is less than or equal to the payment capacity; c) sending a transfer message to a central server for the transaction amount such that the central server credits a merchant's operating account with the transaction amount less a commission, debits a client's operating account, and credits a central operating account with the commission;c) Issuance to the central server of an order to debit the debit balance of the customer's operating account from the customer's bank account to the central bank's central operating account; d) Issuance of an order to transfer the balance of the merchant's operating account to the merchant's bank account; e) Receipt from the central server of a notification that the debit balance of the customer's operating account has been debited. No figure;

Description

Title of the invention: Electronic payment method technical field

[0001] The invention relates to the field of electronic payment and in particular to an electronic payment method not requiring a bank card. STATE OF THE ART

[0002] We know of payment by bank card where a customer presents his bank card to a merchant's electronic payment terminal.

[0003] However, payment by bank card presents a number of disadvantages for both merchants and consumers.

[0004] For traders: • high transaction fees, • It requires a large number of intermediaries, • A transaction takes relatively long (approximately 15 seconds) • Credit card fraud is significant, • The need to have a payment terminal to accept payments by bank cards (rented or purchased), • the complexity of online payments due to the 3DSecure™ system and strong authentication required to validate payments, • the loss of revenue for e-commerce merchants (or online merchants) due to a significant amount of shopping cart abandonment at the time of payment. • For consumers. • an annual fee depending on the type of bank card, • possible charges for cash withdrawals, • limited acceptance at some retailers (minimum purchase amount required), • payment and withdrawal limits, • the inability to make payments between individuals, • Inability to manage deferred and immediate debit on the same card • Payment limits for contactless payments.

[0005] To avoid the use of bank cards, solutions using a smartphone have emerged. These solutions allow for the dematerialization of the bank card but still present the drawbacks of payment by bank card.

[0006] There is a need to simplify payments by moving away from the bank card payment system. Description of the invention

[0007] One object of the invention is to offer a payment and collection solution that is simple, fast, secure and does not use a bank card for payments made both physically and online.

[0008] To this end, the invention proposes, according to a first aspect, an electronic payment method, comprising the following steps, implemented by a payment server:

[0009] a) receiving a sales message from a customer terminal, the sales message including information relating to the amount of a transaction and information relating to the identity of a merchant;

[0010] b) comparison of the transaction amount to a payment capacity contained in a customer account stored in the payment server and whether the transaction amount is less than or equal to the payment capacity;

[0011] b) sending to a central server a transfer message of the transaction amount so that the central server credits a merchant's operating account with the transaction amount less a commission, debits a customer's operating account and credits a central operating account with the commission;

[0012] c) issuing to the central server an order to debit the debit balance of the customer's operating account from the customer's bank account to the central banking institution's central operating account

[0013] d) issuing an order to transfer the balance of the merchant's operating account to the merchant's bank account;

[0014] e) receipt from the central server of a notification that the debit balance of the customer's operating account has been debited.

[0015] The invention, according to the first aspect, is advantageously complemented by the following features, taken alone or in any technically possible combination thereof:

[0016] - prior to step a):

[0017] aO) receipt of a transaction message from a merchant terminal, the transaction message including a sale amount;

[0018] al) generation of a transaction fingerprint from the received transaction message, the fingerprint including the sale amount and a merchant identity known to the payment server;

[0019] a2) emission of the generated fingerprint at the merchant terminal.

[0020] - the fingerprint is a QR code, a near-field communication tag or a 6-digit numeric code.

[0021] - the receipt of the sales message is subsequent to a validation of the transaction by the client via the client terminal following a reading by the client terminal of the fingerprint and authentication of the client at the client terminal level.

[0022] - if the transaction amount exceeds a payment capacity contained in the customer account, sending to the merchant terminal a notification of the abandoned transaction and sending to the customer terminal a notification of the refused transaction.

[0023] - the debit order is issued for each transaction or periodically at a determined frequency.

[0024] According to a second aspect, the invention relates to a payment server comprising a processing unit configured to implement a method according to the first aspect of the invention.

[0025] According to a third aspect, 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 process according to the first aspect of the invention.

[0026] The invention makes it possible to definitively do away with the use of a bank card presented, even in a dematerialized form, to an electronic payment terminal.

[0027] The invention allows: - a very fast payment because by doing away with the bank card, the solution eliminates all the usual intermediaries of bank card payment. - A more secure payment method than payment by bank card: • Use of the security features of the cardholder's terminal (PIN code or biometric identification elements), • Use of the cardholder's application security features (PIN code or biometric identification elements) for payments exceeding a certain amount, for example €50, • The payment amount without a PIN code can be set between €0 and a specific amount, for example €50, within the application, according to the security needs of each cardholder. • It is no longer necessary to enter or save your bank card details to make online payments. • No need to register your bank card in a digital wallet (such as Apple Pay™ or Google Pay™), • No sensitive information relating to the cardholder (account number, for example) will be transmitted to the merchant - The customer using the payment application according to the invention will be able to manage the debiting of their payments by choosing whether they wish to switch from deferred debit to immediate debit. - To obtain a spending capacity based on one's resources, determined automatically during the registration process. - It is not necessary to preload your account from the application according to the invention in order to make purchases PRESENTATION OF THE FIGURES

[0028] Other features, objectives and advantages of the invention will become apparent from the following description, which is purely illustrative and not limiting, and which should be read in conjunction with the accompanying drawings on which:

[0029] - Fig. 1 illustrates an implementation architecture for a payment process electronics conforming to the invention;

[0030] - Figure 2 illustrates steps in an electronic payment process conforming to the invention.

[0031] In all figures, similar elements bear identical references. DETAILED DESCRIPTION Architecture

[0032] Fig. 1 illustrates an implementation architecture for an electronic payment process according to the invention.

[0033] A customer Cl accesses a point of sale (POS) of a merchant C2 to make a purchase. Customer Cl possesses an electronic terminal Tl such as a smartphone. More generally, the terminal Tl is any device suitable for connecting to a payment server SP: touchscreen tablet, laptop, game console, etc.

[0034] The point of sale (POS) can be a website, a physical location, etc. The POS is notably materialized by a T2 electronic terminal also adapted to connect to the SP payment server.

[0035] 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 via a fiber optic, ADSL, network connection, etc.) wirelessly such as Wi-Fi or via a mobile communication network (3G, 4G, 5G, etc.).

[0036] The SP payment server is typically configured to implement processing and, as such, includes a calculator. Preferably, the payment server SP and T1 / T2 terminals are configured to exchange data securely via the internet connection. Advantageously, the SP payment server and T1 / T2 terminals are configured to exchange data in a highly secure manner according to communication standards well-known to those in the field. Furthermore, the SP payment server includes one or more memory slots to allow for the storage of various types of data.

[0037] To access the payment server SP, a payment application is installed on the terminal Tl of the client Cl and the client Cia creates a client account 10 allowing him to use the application.

[0038] Similarly, merchant C2 uses a dedicated application to interact with customer terminal T1, with merchant C2 having a merchant account 20 to access the payment server SP. Customer and merchant accounts 10 and 20, respectively, are stored by the payment server SP and contain all customer and merchant information, enabling the tracking of all transactions.

[0039] The payment server SP is associated with and connected to a central server SC of a central banking institution EC, which manages banking flows such as interbank fund transfers, particularly bank wire transfers. The connection between the central server SC and the payment server SP is implemented similarly to the connection between the payment server SP and T1 and T2 terminals. The payment server SP is associated with the central server SC of a central banking institution EC, which will manage all banking flows.

[0040] As an application enabling electronic payment, the client Cl has a client bank account 11 managed by a server SI of a client banking establishment El and the merchant has a merchant bank account 21 managed by a server S2 of a merchant banking establishment E2.

[0041] In [Fig.1] three distinct banking establishments are represented but one or more banking establishments may be confused depending on the preferences of the customer and the merchant.

[0042] As will be understood, communications between the various servers and the merchant's and customer's terminals pass through the R Internet network and are secured according to standards well known to those skilled in the art. The connections implemented will not be described in further detail.

[0043] The terminal T1 of customer Cl and the terminal T2 of merchant C2 can also be configured to communicate with each other using Near Field Communication (NFC) technology. Electronic payment method Initialization

[0044] An electronic payment method described in relation to [Fig. 2] requires the installation of a client-side application Cl on the client terminal Tl. Once the application is installed to access the payment service, the client Cl registers (step Init Cl) on the application by creating their client account 10. To do this, they need to enter their identity and provide authorization to debit their bank account 11 hosted at the banking institution El, which can be any bank. It is noted that the client Cl does not need to possess a bank card to register and finalize the opening of an account. The client account 10 is stored on the payment server SP and includes, in addition to the client's identity and bank details, a payment limit. This payment limit restricts the amount the client can spend monthly (in one or more transactions) implementing the electronic payment method described herein.This payment capacity is initially capped at a low value and increased once the customer's external bank account 11 is confirmed.

[0045] Similarly, merchant C2 registered for the service (Init C2 step) and has a merchant account 20 stored in the payment server SP. This merchant account 20 contains the merchant's identity as well as their bank details associated with their merchant bank account 21.

[0046] The bank details will enable 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.

[0047] To this end, upon creation of customer and merchant accounts 10 and 20, 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. These operating accounts will allow the management of bank flows initiated exclusively at the time of payment, in a manner transparent to the customer and the merchant. Initiating a payment

[0048] As illustrated in relation to [Fig. 2], a customer C1 goes to a point of sale (POS) to purchase one or more items (step 100). Customer C1 goes to the POS so that the merchant C2 can record the sale (step 101). This is, for example, a standard checkout transaction. The sale is recorded by the merchant C2 on their merchant terminal T2, which leads to the generation of a transaction message M1 containing the sale amount (step 102). The merchant C2 validates the sale via their T2 terminal, which triggers the transmission (step 103) of the transaction message M1 to the payment server SP.

[0049] Upon receipt (step 104) of this transaction message M1, the payment SP server generates (step 105) a transaction EPI fingerprint such as a QR code or an NFC tag. This EPI fingerprint contains the sale amount as well as the identity of the merchant C2 known to the payment SP server.

[0050] This EPI fingerprint is stored (step 106) in the payment server SP to enable traceability of transactions and is returned (step 107) to the merchant C2's T2 terminal to carry out the transaction with customer Cl. Transaction session

[0051] The PPE fingerprint is presented to customer Cl (step 108), notably via the merchant terminal T2. Then, customer Cl confirms the transaction using one of the following methods: - QR code payment: Prior authentication of the client (Cl) is performed by the client's terminal (Tl) before a transaction can be validated. This authentication can be done, for example, by fingerprint recognition, facial recognition, or by entering a code. The client (Cl) brings their terminal (Tl) close to the terminal (T2) to acquire the EPI fingerprint (step 109). The terminal (Tl) reads the QR code by acquiring an image of it. Acquiring the transaction fingerprint triggers a transaction validation request from the client (Cl), which takes the form of client authentication (step 110). In practice, acquiring the fingerprint triggers the opening of the payment application on the client terminal (Tl), which requests authentication of the client (Cl). - Contactless payment via NFC: Customer Cl brings their terminal Tl close to terminal T2 to acquire the EPI fingerprint (step 109). Terminal Tl reads the fingerprint via NFC. In practice, acquiring the fingerprint triggers the opening of a payment application on the customer terminal Tl, which requests authentication from customer CL. This authentication is performed by the customer's terminal Tl, for example, through fingerprint or facial recognition, or by entering a code. Acquiring the transaction fingerprint triggers a transaction validation request from customer Cl, which takes the form of customer authentication (step 110). - Payment by entering a transaction code: The customer enters the 6-digit code associated with the fingerprint presented by the merchant on their terminal. The amount requested by the merchant is then displayed and the customer has the possibility to validate or cancel the transaction.

[0052] Once the client Cl is authenticated, the client validates the transaction (step 111), which triggers the generation (step 112) by the client's terminal Tl 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 transaction amount, information relating to the client's identity, and information relating to the merchant's identity. This sales message M2 allows the payment server SP to process the transaction.

[0053] The sales message M2 received (step 114) is then decoded (step 115) by the payment SP server to extract the transaction information. The payment SP server then compares (step 116) the transaction amount to a payment capacity entered in its customer account 10. This capacity is defined when the customer account 10 is created and varies according to the information provided by the customer, based on the financial data collected. The payment capacity can be between 0 and 200 euros by default and higher after analysis of the collected data and confirmation of the bank account (11).

[0054] If the transaction amount exceeds the customer's payment capacity, the transaction is abandoned, and the payment server SP sends a message to both the merchant terminal T2 and the customer terminal T1. Customer C1 and merchant C2 are thus simultaneously notified of the transaction refusal (step 117, step 118).

[0055] If the amount of the transaction is less than or equal to the payment capacity of the customer Cl then the payment server SP sends (step 121) to the central server SC a transfer message M3 which allows the central server SC to perform 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.

[0056] Once the transfer has been made to the operating account of merchant 22, the transaction is completed and merchant C2 is notified (step 123).

[0057] At the end of the transaction, the customer's operating account is therefore debited by the amount of the transaction while the merchant's operating account is positive by this amount less the amount of the commission.

[0058] It is understood that several transactions can be credited or debited to the merchant and customer operating accounts. Bank transfer session

[0059] When the transaction is complete, the payment server SP issues an initial debit order (step 124) to the central server SC of the central banking institution EC. This initial order aims to recover the debit(s) from the customer operating account 12. Such a debit order can be initiated daily or monthly.

[0060] The central server SC then performs a debit of the total debits from the customer's operating account according to the known applicable standards. The execution of this first debit order implies that the central server SC sends the first order to the customer bank El and, in particular, to the customer bank's server SI. The customer bank's server SI therefore transfers (step 126) the total debits from the customer's bank account 11 to the central operating account 30. The payment server SP is then notified that the customer's debits have been covered (steps 127 and 128).

[0061] Simultaneously, the amounts credited to the merchant's operating account 22 during each transaction are then transferred to the merchant's bank account 21. This operation is initiated by the payment server SP (step 129) to the central server SC of the central banking institution EC. This second order credits the merchant's bank account 21 with the amount credited to its operating account 22.

[0062] 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).

Claims

1. Demands An electronic payment method, implemented in an architecture comprising a payment server (SP) connected to a central server (SC) of a central banking institution (EC), which is connected to a server (SI) of a customer's bank and to a server (S2) of a merchant's bank, the central server (SC) being configured to exchange banking flows with the server (SI) of the customer's bank and the server (S2) of the merchant's bank, the method comprising a) receipt (104), by the payment server (SP), of a transaction message (M1) from a merchant terminal (T2), the transaction message (M1) including an amount of a sale; b) generation (105), by the payment server (SP), of a transaction fingerprint (EPI) from the received transaction message (M1), the fingerprint (EPI) including the sale amount and a merchant identity (C2) known to the payment server (SP); c) Issuance (107), by the payment server (SP), of the fingerprint (EPI) generated at the merchant terminal (T2), the merchant terminal (T2) being configured to present the fingerprint (EPI) to a customer; d) Receipt (114), by the payment server (SP), of a sales message (M2) issued by a customer terminal (Tl), the sales message (M2) including information relating to a transaction amount, information relating to a merchant's identity, the sales message (M2) having been generated (112) by the customer terminal (Tl) following: - the acquisition (109) of the transaction fingerprint (EPI) by the client terminal (Tl); - an authentication (110) of the client (Cl); - a validation (111) of the transaction by the customer (Cl) using the customer terminal (Tl); e) comparison (116), by the payment server (SP), of the transaction amount to a payment capacity contained in a customer account stored in the payment server (SP) and if the transaction amount is less than or equal to the payment capacity;

2. f) issuance (121), by the payment server (SP), to the central server (SC) of a message (M3) transferring the amount of the transaction so that g) the central server (SC), upon receipt of the message (M3), performs the following operations: gl) credit a merchant's operating account with the amount of the transaction less a commission, the merchant's operating account being stored in the central server (SC), g2) debit a customer operating account stored in the central server (SC); g3) credit (122) a central operating account of the commission, the central operating account being stored in the central server (SC), g4) notification to the merchant that the transaction is complete, h) issuance (124) by the payment server (SP) to the central server (SC) of an order to debit the debit balance of the customer's operating account from a customer bank account (11) to the central operating account (30) of the central banking institution (EC), the customer bank account (11) being stored in the server (SI) of the customer's bank institution (E1), i) issuance (129) by the payment server (SP) of an order to transfer the balance of the merchant's operating account (22) to the merchant's bank account (21), the merchant's bank account (22) being stored in the server (S2) of the merchant's bank institution (E2), j) receipt (127) by the payment server (SP) from the central server (SC) of a notification that the debit balance of the customer's operating account has been debited. if the transaction amount exceeds the payment limit in the customer's account, k) issuance (117), by the payment server (SP) to the merchant terminal (T2) of a notification of transaction abandonment and 1) Issuance (118), by the payment server (SP), to the client terminal (Tl) of a notification of refusal of the transaction. Method according to claim 1, wherein the imprint (EPI) is a QR code, a near field communication (NFC) label or a 6-digit numeric code.

3. A method according to any one of claims 1 to 2, wherein the sampling order is issued periodically at a determined frequency, either daily or monthly.

4. A method according to any one of the preceding claims, comprising the following steps implemented by a client terminal (Tl) - acquisition (109) of the fingerprint (EPI) issued by the payment server (SP), - authentication (110) of a client (Cl); - validation of the transaction (111) by the client (Cl); - generation of the sales message (M2), - transmission (113) of the sales message (M2) to the payment server (SP).

5. A method according to any one of the preceding claims, comprising the following steps implemented by a merchant terminal (C2): - generation (102) of the transaction message including the sale amount - transmission (103) of the transaction message (M1) to the payment server - presentation (108) of the fingerprint (EPI), received from the payment server, to the customer (C1).

6. Payment server (SP) comprising a processing unit configured to implement a method according to any one of claims 1 to 3.

7. Payment method implemented by a client terminal comprising steps of: - acquisition (109) of the fingerprint (EPI) issued by the payment server (SP); - authentication (110) of a client (Cl); - validation of the transaction (111) by the client (Cl); - generation of the sales message (M2); - transmission (113) of the sales message (M2) to a payment server (SP) according to claim 6.

8. Payment method implemented by a merchant terminal, of the steps of - generation (102) of the transaction message including the sale amount - transmission (103) of the transaction message (M1) to a payment server according to claim 6

9. - presentation (108) of the fingerprint (EPI), received from the payment server according to claim 6, to the client (Cl). Product computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the process according to any one of claims 1 to 3.

Images