WO2024256700A1 - Electronic payment method - Google Patents

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

DESCRIPTION

Electronic payment method

TECHNICAL AREA

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

STATE OF THE ART

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

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

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 bank card fraud, it requires having a payment terminal to collect bank 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-retailers or merchants due to significant cart abandonment at the time of payment.

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.

To avoid using a bank card, solutions using a smartphone (i.e. a smart phone) have appeared. These solutions allow the bank card to be dematerialized but still have the disadvantages of paying by bank card.

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

PRESENTATION OF THE INVENTION

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.

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

- 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;

- generating a transaction imprint from the received transaction message, 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;

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

- receipt of a sales message from 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.

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

- comparison of the transaction amount with 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;

- 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;

- sending to the central server an order to collect the debit balance of the customer operating account from the customer bank account (11) to the central operating account of the central banking institution

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

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

According to one embodiment, the imprint is a QR code, a near field communication label, a 6-digit digital code, a low energy Bluetooth communication label.

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.

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.

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 customer using a merchant terminal;

- authentication of a client;

- validation of the customer transaction via the customer terminal;

- generation of the sales message;

- sending the sales message to the payment server.

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.

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

- generation of the transaction message including the sale amount

- sending the transaction message to the payment server

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

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.

According to a third aspect, the invention relates to a payment method implemented by a customer terminal comprising the following steps:

- acquisition of the imprint issued by the payment server;

- authentication of a client;

- validation of the transaction by the customer;

- generation of the sales message;

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

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

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

- generation of the transaction message including the sale amount

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

- presentation of the imprint, received from the payment server according to the second aspect of the invention, to the client. 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.

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

- entry of a sale using a merchant terminal,

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

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

- 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;

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

- issuance by a payment server of the imprint generated to the merchant terminal configured to present the imprint to a customer;

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

- 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.

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

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:

Use of security elements of the bearer’s terminal (PIN code or biometric identification elements),

Use of the security elements of the cardholder’s application (PIN code or biometric identification elements) for payments over a specific amount, for example €50,

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,

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

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

- 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 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. 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.

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.

PRESENTATION OF FIGURES

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

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

- figure 2 illustrates steps of an electronic payment method according to the invention;

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

In all figures, similar elements bear identical references.

DETAILED DESCRIPTION

Architecture

Figure 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. 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.

To access the payment server SP, 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.

Similarly, 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.

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.

As this is an application enabling electronic payment, 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.

In Figure 1 three separate banking institutions are shown but one or more banking institutions may be confused depending on customer and merchant preferences.

As will have been understood, communications between the different 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.

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.

Registration (in English, onboarding)

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.

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

- registration of the customer's mobile number;

- 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 make such entry more fluid, an automated address search is provided;

- registration of the customer's place of birth;

- verification of the customer's identity: 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. 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;

- 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;

- recording 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.

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

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

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.

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. 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.

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. In addition, once registration is complete, 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.

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.

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

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

- optionally, 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;

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

- display of recorded information for validation by the merchant;

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

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

- registration of the trader's place of birth;

- acceptance of the conditions of access to the service by the merchant.

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.

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 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.

Initiating a payment

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.

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). For example, 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.

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.

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

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

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

In practice, the EP1 imprint coming directly from the trader is clearly identified by the customer.

Alternatively, in the case of a remote payment, 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.

By offering the EP1 footprint, 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. 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.

Transaction session

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.

Then, client C1 confirms the transaction in the following manner based on the EP1 fingerprint type.

Payment by QR code

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.

Using the camera, reading the QR code will trigger the opening of the payment application installed on the T1 terminal.

Once the application is opened, 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.

Then, 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.

In addition, the QR code carries a deep link that allows direct access to the application.

In addition, the use of a 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.

Contactless payment by NFC or BLE

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. 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. So :

- 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;

- in the context of contactless payment in BLE: 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.

Payment by entering a transaction code

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.

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

At this point, the customer has made the payment. The transaction is immediate and lasted a maximum of two seconds. This streamlines payments and makes the checkout process easier.

We note that the number of steps to validate the transaction is a maximum of three (including opening the application), which improves the customer experience and simplifies the handling of the payment but also makes the payment faster. A time saving is thus clearly obtained to finalize a sale.

The following steps are then transparent for 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 aimed at crediting or debiting a bank account is used.

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 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. 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 bank statements or via a connection with their bank, allowing the payment server to retrieve banking data over the last three months.

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).

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 refusal of the transaction (step 117, step 118).

If the transaction amount 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.

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

Between the validation of the transaction by the customer 11 and the notification of the merchant 22 a duration of at most 2 seconds has elapsed. This improves also the customer experience and simplifies the handling of payment but also makes payment faster. A time saving is thus clearly obtained to finalize a sale.

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.

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

Bank transfer session

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.

At the desired time, 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).

At the same time, 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).

Other aspects:

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 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 customer's operating account has been debited.

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

- prior to 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).

- 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.

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

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

Claims

1. Electronic payment method, comprising the following steps, implemented by a payment server (SP): - reception (104) of 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 using a merchant terminal (T2); - generation (105) 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) 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 the 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 reduced by a commission, debits a customer operating account and credits a central commission operating account; - sending (124) to the central server (SC) an order to collect 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 collected. 3. Method according to one of claims 1 to 2, in which the imprint (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, sending (117) to the merchant terminal (T2) a notification of abandonment of the transaction and sending (118) to the customer terminal (T1) 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 sale amount - 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 sale amount - sending (103) 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 using 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).