Electronic payment method

Abstract

The invention relates to an electronic payment method, which comprises the following steps, implemented by a payment server: - receiving a transaction message originating from a merchant device, the transaction message comprising an amount of a sale to a customer, the amount of the sale having been entered by means of a merchant device; - generating a transaction fingerprint on the basis of the received transaction message, the fingerprint comprising the amount of the sale and an identity of the merchant known to the payment server in the form of a format that can be acquired by acquisition means of a customer device; - transmitting the generated fingerprint to the merchant device, the merchant device being configured to present the fingerprint to a customer device; and - receiving a sale message originating from a customer device, the sale message comprising information relating to an amount of a transaction and information relating to an identity of a merchant, the sale message having been generated by the customer device following the acquisition of the transaction fingerprint by the customer device, an authentication of the customer and a validation of the transaction by the customer on the customer device.

Description

[0001] DESCRIPTION

[0002] Electronic payment method

[0003] TECHNICAL FIELD

[0004] The invention relates to the field of electronic payment and relates in particular to an electronic payment method not requiring a bank card.

[0005] STATE OF THE ART

[0006] We know about payment by bank card where a customer presents their bank card to a merchant's electronic payment terminal (EPT).

[0007] However, paying by bank card has a number of disadvantages for both merchants and consumers.

[0008] For merchants: it represents high transaction costs, it requires a large number of intermediaries, it leads to a transaction that is relatively long (around 15s) it is subject to significant credit card fraud, it requires having a payment terminal to collect credit card payments (rented or purchased), it leads to complexity of payments on the internet due to the 3DSecure™ system and strong authentication required to validate payments, due to the complexity, it generates friction, which results in a loss of turnover for e-merchants or merchants due to significant cart abandonment at the time of payment.

[0009] For consumers: it requires an annual fee depending on the type of bank card, it is subject to possible charges for cash withdrawals, the bank card is sometimes accepted on a limited basis by certain merchants (minimum amount requirement), 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.

[0010] To avoid using bank cards, solutions using smartphones (i.e., smart phones) have emerged. These solutions allow for the dematerialization of bank cards but still have the disadvantages of paying by bank card.

[0011] There is a need to simplify payments by moving away from the bank card payment system.

[0012] STATEMENT OF THE INVENTION

[0013] The aim of the invention is to propose a payment and collection solution that is simple, fast, secure and does not use a bank card for payments made both physically and online.

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

[0015] - receipt of a transaction message from a merchant terminal, the transaction message comprising an amount of a sale to a customer, the amount of the sale having been entered using a merchant terminal;

[0016] - generating a transaction fingerprint from the received transaction message, the fingerprint including 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;

[0017] - issuing the generated imprint to the merchant terminal, the merchant terminal being configured to present the imprint to a customer terminal;

[0018] - receipt of a sales message from a customer terminal, 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.

[0019] Additionally, the process includes the following steps, carried out by a payment server:

[0020] - comparison of the transaction amount with a payment capacity contained in a customer account stored in the payment server and if the transaction amount is less than or equal to the payment capacity;

[0021] - 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;

[0022] - sending to the central server an order to debit the debit balance of the customer operating account from the customer bank account (11) to the central operating account of the central banking establishment

[0023] - issue of an order to transfer the balance of the merchant's operating account to the merchant's bank account;

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

[0025] According to one embodiment, the fingerprint is a QR code, a near field communication tag, a 6-digit digital code, a Bluetooth low energy communication tag.

[0026] According to one embodiment, if 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.

[0027] According to one embodiment, 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.

[0028] According to one embodiment, the method comprises the following steps implemented by a client terminal: - acquisition of the imprint issued by the payment server and presented to the client by means of a merchant terminal;

[0029] - authentication of a client;

[0030] - validation of the customer transaction via the customer terminal;

[0031] - generation of the sales message;

[0032] - sending the sales message to the payment server.

[0033] According to one embodiment, 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.

[0034] According to one embodiment, the method comprises the following steps implemented by a merchant terminal:

[0035] - generation of the transaction message including the sale amount

[0036] - sending the transaction message to the payment server

[0037] - presentation of the imprint, received from the payment server, to the customer.

[0038] 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.

[0039] According to a third aspect, the invention relates to a payment method implemented by a client terminal comprising the following steps:

[0040] - acquisition of the imprint issued by the payment server;

[0041] - authentication of a client;

[0042] - validation of the transaction by the customer;

[0043] - generation of the sales message;

[0044] - sending the sales message to a payment server according to the second aspect of the invention.

[0045] According to a fourth aspect, the invention relates to a payment method comprising the following steps implemented by a merchant terminal:

[0046] - seizure of a sale by the trader, the seizure including the amount of the sale;

[0047] - generation of the transaction message including the sale amount

[0048] - sending the transaction message to a payment server according to the second aspect of the invention;

[0049] - presentation of the imprint, received from the payment server according to the second aspect of the invention, to the customer. According to a fifth 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 method according to one of the aspects of the invention.

[0050] According to a sixth aspect, the invention relates to an electronic payment method, comprising the following steps:

[0051] - entry of a sale using a merchant terminal,

[0052] - generation by the merchant terminal of the transaction message including the sale amount

[0053] - transmission by the merchant terminal of the transaction message to a payment server,

[0054] - receipt by a payment server of a transaction message from a merchant terminal, the transaction message including an amount of a sale to a customer;

[0055] - generation by a payment server of a transaction imprint from the received transaction message, the imprint including the sale amount and an identity of the merchant known to the payment server;

[0056] - emission by a payment server of the generated imprint to the merchant terminal configured to present the imprint to a customer;

[0057] - presentation by means of the merchant terminal of the imprint, received from the payment server to the customer;

[0058] - receipt of a sales message from a customer terminal, 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.

[0059] The invention according to one of the aspects presented above has the following advantages.

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

[0061] 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.

[0062] 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 involved in bank card payments.

[0063] The invention allows for a more secure payment than payment by bank card:

[0064] Use of the security elements of the bearer's terminal (PIN code or biometric identification elements),

[0065] Use of the cardholder's application security elements (PIN code or biometric identification elements) for payments above a specific amount, for example €50,

[0066] The amount of the payment without PIN code can be set between €0 and a specific amount, for example €50 in the application depending on the security requirements of each cardholder,

[0067] It is no longer necessary to enter or save your bank card codes to make online payments.

[0068] No need to save your bank card in a dematerialized wallet (called a wallet, such as Apple Pay™, Google Pay™),

[0069] - No transmission to the merchant of sensitive information relating to the cardholder (account number for example). Indeed, the bank card is a means of payment which 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. The PAN code is used by fraudsters to make the link between the customer's bank account and his card. The invention therefore limits fraud.

[0070] 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.

[0071] The invention makes it possible to obtain a spending capacity based on one's resources, determined automatically during the registration process.

[0072] The invention does not require pre-loading your account from the app to make purchases. The invention does not require the customer to enter the transaction amount. Only the merchant does this.

[0073] PRESENTATION OF FIGURES

[0074] Other characteristics, aims and advantages of the invention will emerge from the following description, which is purely illustrative and non-limiting, and which must be read in conjunction with the appended drawings in which:

[0075] - figure 1 illustrates an implementation architecture of an electronic payment method in accordance with the invention;

[0076] - figure 2 illustrates steps of an electronic payment method in accordance with the invention;

[0077] - Figure 3 illustrates a client terminal comprising a screen and a QR code acquisition area.

[0078] In all figures, similar elements have identical references.

[0079] DETAILED DESCRIPTION

[0080] Architecture

[0081] Figure 1 illustrates an implementation architecture of an electronic payment method in accordance with the invention.

[0082] A customer C1 accesses a POS point of sale of a merchant 02 to make a purchase. Customer C1 has an electronic terminal T1. The electronic terminal T1 is preferably a smartphone but can also be any device suitable for connecting to a payment server SP: tablet, laptop, game console, smartwatch, etc.

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

[0084] 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 connection, ADSL, network, etc.), wireless Wi-Fi type or via a mobile communication network (3G, 4G, 5G, etc.).

[0085] The payment server SP is typically configured to implement processing and as such comprises one or more calculator(s). Preferably, the payment server SP and the terminals T1, T2 are configured to exchange data securely via the Internet connection. Advantageously, 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. In addition, the payment server SP comprises one or more memories to allow the storage of different data.

[0086] To access the SP payment server, a payment application is installed on the T1 terminal of customer 01 and customer C1 has created a customer account 10 allowing him to use the application.

[0087] Similarly, the merchant 02 uses a dedicated application to allow him 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.

[0088] The client and merchant applications use deep links that ensure increased transaction security. This helps mitigate the risks associated with man-in-the-middle attacks (MITM) or man-in-the-middle attacks, which aim to intercept and modify communications between two parties. Indeed, the client and the merchant never communicate directly with each other but always pass through the SP payment server.

[0089] The payment server SP is associated and connected to a central server SC of a central EC banking establishment which allows the management of 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 establishment which will manage all banking flows.

[0090] In the case of an application enabling electronic payment, the client C1 has a client bank account 11 managed by a server S1 of a client banking establishment E1 and the merchant has a merchant bank account 21 managed by a server S2 of a merchant banking establishment E2.

[0091] In Figure 1 three separate banking institutions are represented but one or more banking institutions may be combined depending on customer and merchant preferences.

[0092] As will be understood, communications between the various servers and the merchant's terminal and that of the customer 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 detailed further.

[0093] 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.

[0094] Registration (in English, onboarding)

[0095] As presented above, 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.

[0096] Advantageously, the registration (step Insc C1) of the customer includes the following steps:

[0097] - registration of the customer's mobile number;

[0098] - recording the customer's postal address, in compliance, where applicable, with the legislation in force in the country where the service is used (in France, to access such a payment service, the customer must provide their tax address); to streamline such entry, an automated address search is provided;

[0099] - registration of the customer's place of birth;

[0100] - verification of the customer's identity: such verification may include the transmission of a customer's identity document (identity card, passport, residence permit, driving license). The copy of the document may be made using the camera on the customer's terminal. Following the transmission of the identity document, the customer's face is captured to verify the correspondence between the customer's face and the one on the identity document;

[0101] - optionally, recording of the professional situation and an amount of income. Regarding the professional situation, a closed list is offered to the client so that he can choose the one that best suits him;

[0102] - recording of the customer's bank details either by entering their bank details (entering 1'1 BAN) or by directly collecting the details from the customer's banking institution (with a DSP2 type connection). 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. In fact, the payment service operates by implementing bank debits.

[0103] - acceptance of the conditions of access to the service by the customer and notification to the latter of a withdrawal period;

[0104] - configuration of a confidential PIN code to secure transactions during use of the service and in particular to access the application implementing the service.

[0105] We note that customer C1 does not need to have a bank card to register to finalize his registration and the opening of his customer account.

[0106] All recorded data is attached to the customer account 10 which is stored in the payment server SP and includes, in addition to the recorded data (in particular identity and bank details), a payment capacity. Such 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.

[0107] Customer registration is optimized in terms of the number of manual entries and validations. Indeed, the customer has only a few elements to complete manually, which reduces the risk of error and speeds up registration. In addition, once registration is complete, the customer can use the service (even if they have not automatically linked 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.

[0108] Similarly, 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.

[0109] Advantageously, the registration (step Insc C2) of the trader includes the following steps:

[0110] - recording of the merchant's identity and contact information: surname, first name, telephone number, postal address, email address, password to access the merchant account;

[0111] - optionally, an electronic message is sent and contains a code that the merchant must enter in order to verify his electronic address; this makes it possible to verify that the electronic address is correct;

[0112] - registration of the company name (in France using the SIREN number);

[0113] - display of recorded information for validation by the merchant;

[0114] - recording of the merchant's bank details by entering the IBAN

[0115] - verification of the merchant's identity: such verification may include the transmission of an identity document of the merchant (identity card, passport, residence permit). The copy of the document can be made using the camera of the merchant's terminal. Following the transmission of the identity document, the merchant's face is captured to verify the correspondence between the merchant's face and the one on the identity document;

[0116] - registration of the trader's place of birth;

[0117] - acceptance of the conditions of access to the service by the merchant.

[0118] Customer and merchant registration allows for unambiguous identification of both parties involved in a transaction. This helps secure the transaction. This is particularly useful when combating money laundering and terrorist financing. Bank details will allow the initiation of banking transactions required by the payment server (SP) to the central server (SC), which is authorized to implement this type of transaction.

[0119] To do this, when creating customer and merchant accounts 10, 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 to 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.

[0120] Initiating a payment

[0121] We now describe a use of the payment service by implementing the electronic payment method, a preferred embodiment of which is illustrated in Figure 2.

[0122] 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, for example, 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 sale amount (step 102). The transaction message M1 also includes the identity of the merchant so that the payment server SP can identify them.

[0123] Merchant C2 validates the sale via their terminal T2, which triggers the transmission (step 103) of the transaction message M1 to the payment server SP. Only merchant C2 enters the transaction amount; the customer therefore does not have to enter such an amount.

[0124] 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.

[0125] The transaction EP footprint can take several forms.

[0126] According to one embodiment, the transaction imprint EP1 is a QR code.

[0127] According to one embodiment, the transaction fingerprint EP1 is a near field communication (NFC) tag. According to one embodiment, the transaction fingerprint EP1 is a 6-digit numeric code.

[0128] According to one embodiment, the EP1 fingerprint is a BLE (Bluetooth Low Energy) communication tag.

[0129] This EP1 fingerprint contains the amount of the sale as well as the identity of the C2 merchant known to the SP payment server.

[0130] 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.

[0131] In practice, the EP1 imprint coming directly from the merchant is clearly identified by the customer.

[0132] Alternatively, in the case of a remote payment, the EP1 fingerprint is displayed to the customer via the merchant's website. In this way, the merchant is able to create a transaction in different payment contexts.

[0133] By offering the EP1 footprint, the merchant frees itself 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. In addition, since 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.

[0134] Transaction session

[0135] 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.

[0136] Then, client C1 confirms the transaction in the following manner depending on the EP1 fingerprint type.

[0137] Payment by QR code

[0138] Customer C1 reads the QR code using terminal T1. They can either read the QR code directly with their camera or with the payment application installed on their terminal T1. Figure 3 illustrates a customer terminal T1 with the application in use. This figure shows screen S showing the QR code acquisition zone Z.

[0139] Using the camera, reading the QR code will trigger the opening of the payment application installed on its T 1 terminal.

[0140] Once the application is opened, a pre-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.

[0141] Then, the client C1 approaches his client terminal T1 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.

[0142] Furthermore, the QR code carries a deep link that allows direct access to the application.

[0143] In addition, the use of a QR code ensures security for the customer since the fingerprint systematically refers to secure and certified addresses, otherwise an error is returned to the customer.

[0144] Contactless payment by NFC or BLE

[0145] The client C1 brings his client terminal T1 close to the terminal T2 to acquire (step 109) the fingerprint EP1. The terminal T1 reads the fingerprint via NFC. In the case of 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. Thus:

[0146] - in the context of contactless payment by NFC: the customer must bring their terminal close to 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 at the interface allowing the transaction to be validated, they will automatically arrive at this interface when the phone detects an NFC chip;

[0147] - in the context of contactless payment in BLE: the customer's terminal will detect the transaction via the merchant's terminals which emit BLE waves (radio frequency). 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.

[0148] Payment by entering a transaction code

[0149] 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.

[0150] Once client C1 is authenticated, the latter validates the transaction (step 111).

[0151] At this point, the customer has made payment. The transaction is immediate and lasts a maximum of two seconds. This streamlines payments and facilitates checkout.

[0152] It's worth noting that the number of steps required to validate a transaction is a maximum of three (including opening the app), which improves the customer experience and simplifies payment handling, but also makes payment faster. This clearly saves time when finalizing a sale.

[0153] The following steps are then transparent for both the merchant and the customer since they involve exchanges between the servers involved in the payment process. It should be noted that at this stage no communication with a banking institution is required and that in particular no bank flow intended to credit or debit a bank account is used.

[0154] The validated transaction (step 111) 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 the identity of the customer and information relating to the identity of a merchant. Such a sales message M2 will allow the payment server SP to process the transaction by clearly identifying all the parties involved in the transaction.

[0155] 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. Advantageously, the payment server SP then performs a comparison (step 116) of the transaction amount with a payment capacity entered in its customer account 10. Such 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 account statements or via a connection with their bank, allowing the payment server to retrieve banking data over the last three months.

[0156] In all cases, 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).

[0157] If the transaction amount is greater than the customer's payment capacity, the transaction is abandoned, 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 transaction refusal (step 117, step 118).

[0158] If the amount of the transaction is less than or equal to the payment capacity of the client C1 then 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.

[0159] Once the transfer is made to the operating account of merchant 22, the transaction is completed and merchant C2 is notified (step 123) by the payment server SP.

[0160] Between the transaction validation by the customer 11 and the merchant's notification 22, a time of at most 2 seconds elapsed. This also improves the customer experience and simplifies payment handling, but also makes payment faster. This clearly saves time when finalizing a sale.

[0161] At the end of the transaction, 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.

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

[0163] Bank transfer session

[0164] The bank transfer session is initiated at a variable frequency or for each transaction. For example, the session is initiated daily (end of day), monthly (end of month), weekly (end of week), etc. The idea is that it does not interfere with the customer's payment validation and does not slow down the transaction itself.

[0165] At the desired time, the payment server SP issues a first debit 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.

[0166] The central server SC then executes a collection of the total 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 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).

[0167] At the same time, the amounts credited to the merchant's operating account 22 during each transaction are then transferred to the merchant's 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's 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).

[0168] The merchant is assured of receiving the funds from his sales since the clearing of funds is separate from the payment of merchants and is covered by the banking establishment associated with the central server (SC).

[0169] Other aspects:

[0170] According to a first exemplary embodiment, 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 with 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 client and credits a central operating account with the commission;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; d) issuing an order to transfer the balance of the merchant's operating account to the merchant's bank account; e) receiving from the central server a notification that the debit balance of the customer's operating account has been debited.;

[0171] The method according to the first example is advantageously supplemented by the following characteristics, taken alone or in any of their technically possible combinations:

[0172] - prior to step a): a0) receiving a transaction message from a merchant terminal, the transaction message comprising a sale amount; a1) generating a transaction fingerprint from the received transaction message, the fingerprint comprising the sale amount and an identity of the merchant known to the payment server; a2) transmitting the generated fingerprint to the merchant terminal.

[0173] - the fingerprint is a QR code, a near field communication tag, a 6-digit numeric code or a communication tag (NFC) or by Bluetooth Low Energy (BLE).

[0174] - receipt of the sales message follows validation of the transaction by the customer via the customer terminal following reading of the imprint by the customer terminal and authentication of the customer at the customer terminal.

[0175] - if the amount of the transaction is greater than the payment capacity contained in the customer account, a notification of abandonment of the transaction is sent to the merchant terminal and a notification of refusal of the transaction is sent to the customer terminal.

[0176] - the collection order is issued for each transaction or periodically at a specific frequency.

Claims

CLAIMS 1. Electronic payment method, comprising the following steps, implemented by a payment server (SP): - receiving (104) a transaction message (M1) from a merchant terminal (T2), the transaction message (M1) comprising an amount of a sale to a customer (C1), the amount of the sale having been entered by means of a merchant terminal (T2); - generation (105) of a transaction imprint (EP1) from the received transaction message (M1), the imprint (EP1) comprising the amount of the sale and an identity of the merchant (C2) known to the payment server (SP) in the form of a format that can be acquired by acquisition means of a client terminal (T1); - transmission (107) of the generated imprint (EP1) to the merchant terminal (T2), the merchant terminal (T2) being configured to present the imprint (EP1) to a customer terminal; - reception (114) of a sales message (M2) from a client terminal (T1), the sales message (M2) comprising information relating to an amount of a transaction and information relating to an identity of a merchant, the sales message (M2) having been generated by the client terminal (T1) following the acquisition (109) of the transaction imprint (EP1) by the client terminal (T1), an authentication (110) of the client (C1) and a validation (111) of the transaction by the client (C1) at the client terminal (T1).

2. Method according to claim 1, comprising the following steps, implemented by a payment server (SP): - comparison (116) of the transaction amount with 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; - sending (121) to a central server (SC) a message (M3) transferring the amount of the transaction so that the central server (SC) credits an operating account of the merchant with the amount of the transaction less a commission, debits a customer operating account and credits a central commission operating account; - sending (124) to the central server (SC) an order to withdraw the debit balance of the customer operating account from the customer bank account (11) to the central operating account (30) of the central banking establishment - issue of an order to transfer the balance of the merchant's operating account (22) to the merchant's bank account (21); - receipt (127) from the central server of a notification that the debit balance of the customer's operating account has been debited.

3. Method according to one of claims 1 to 2, in which the fingerprint (EP1) is a QR code, a near field communication (NFC) tag, a 6-digit digital code, a low energy Bluetooth communication tag.

4. Method according to one of claims 1 to 3, in which if the amount of the transaction is greater than a payment capacity contained in the customer account, transmission (117) to the merchant terminal (T2) of a notification of abandonment of the transaction and transmission (118) to the customer terminal (T1) of a notification of refusal of the transaction.

5. Method according to one of claims 2 to 4, in which 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.

6. Method according to one of the preceding claims, comprising the following steps implemented by a client terminal (T1): - acquisition (109) of the imprint (EP1) issued by the payment server (SP) and presented to the customer by means of a merchant terminal; - authentication (110) of a client (C1); - validation of the transaction (111) of the customer (C1) via the customer terminal; - generation of the sales message (M2),; - transmission (113) of the sales message (M2) to the payment server (SP).

7. Method according to the preceding claim, in which the acquisition (109) of the fingerprint (EP1) triggers the opening of an application stored on the client's terminal (T1), the application making it possible to authenticate the client and validate the transaction.

8. Method according to one of the preceding claims, comprising the following steps implemented by a merchant terminal (C2): - generation (102) of the transaction message including the amount of the sale - sending (103) of the transaction message (M1) to the payment server - presentation (108) of the imprint (EP1), received from the payment server, to the client (C1).

9. Payment server (SP) comprising a processing unit configured to implement a method according to one of claims 1 to 5.

10. Payment method implemented by a customer terminal comprising steps of: - acquisition (109) of the imprint (EP1) issued by the payment server (SP); - authentication (110) of a client (C1); - validation of the transaction (111) by the client (C1); - generation of the sales message (M2),; - transmission (113) of the sales message (M2) to a payment server (SP) according to claim 9.

11. Payment method comprising the following steps implemented by a merchant terminal: - seizure (101) of a sale by the trader, the seizure including the amount of the sale; - generation (102) of the transaction message including the amount of the sale - transmission (103) of the transaction message (M1) to a payment server according to claim 9; - presentation (108) of the imprint (EP1), received from the payment server according to claim 9, to the client (C1) 12. Computer program product comprising instructions, which when the program is executed by a computer, cause the latter to implement the steps of the method according to one of claims 1 to 11.

13. Electronic payment method, comprising the following steps: - entry (101) of a sale by means of a merchant terminal; - generation (102) by the merchant terminal of the transaction message including the amount of the sale; - transmission (103) by the merchant terminal of the transaction message (M1) to a payment server; - reception (104) by a payment server (SP) of a transaction message (M1) from a merchant terminal (T2), the transaction message (M1) comprising an amount of a sale to a customer (C1); - generation (105) by a payment server (SP) of a transaction imprint (EP1) from the transaction message (M1) received, the imprint (EP1) comprising the amount of the sale and an identity of the merchant (C2) known to the payment server (SP); - emission (107) by a payment server (SP) of the imprint (EP1) generated at the merchant terminal (T2) configured to present the imprint (EP1) to a customer; - presentation (108) by means of the merchant terminal of the imprint (EP1), received from the payment server to the customer (C1); - reception (114) of a sales message (M2) from a client terminal (T1), the sales message (M2) comprising information relating to an amount of a transaction and information relating to an identity of a merchant, the sales message (M2) having been generated by the client terminal (T1) following the acquisition (109) of the transaction imprint (EP1) by the client terminal (T1), an authentication (110) of the client (C1) and a validation (111) of the transaction by the client (C1) at the client terminal (T1).

Images