FR2980891A1 - METHOD AND SYSTEM FOR PAYMENT SIGNALING, APPLICATION TO AUTOMATED RENTAL OF VEHICLES. - Google Patents

Abstract

The invention relates to a method for signaling payments made with a payment means, said method comprising the following steps: - storing a digital address in association with an identifier of the user carrying the payment means, - storing data relating to said means of payment, and - at least one payment request with said data relating to said means of payment; said method being characterized in that it comprises for each payment request a transmission, at said numerical address, data, called report, relating to the outcome of said payment request. The invention also relates to a system (100) implementing such a method and an application of such a method and such a system to the automated rental of vehicles.

Description

The present invention relates to a signaling method for the user of payments. It also relates to a payment signaling system implementing such a payment method. The invention also relates to an application of such a method and such a system to the rental of vehicles.

The field of the invention is the field of payments repeated over time with a means of payment, for example a bank card, when buying or renting goods or services. More particularly, the invention relates to the field of the signaling of repeated payments with the same means of payment, in particular repeated payments made in the context of a commercial relationship requiring: - the payment of an increased amount for a good or a service for a predetermined period, for example for a subscription, and - the payment of additional amounts on an ad hoc basis when the goods or services are consumed. The invention relates in particular, and not limited to, the field of automated rental of vehicles offered for rental in one or more rental sites.

State of the art Automated vehicle rental is a growing field. Agglomerations wishing to reduce the number of vehicles on their territory are implementing automated vehicle rental systems.

These systems require repeated payments over time to each vehicle rental in the form of regular payments to pay amounts related to a subscription taken out with the operator providing the rental service, but also payments of additional fees that may occur during the rental period. of each rental. - 2 - In processes and systems of the state of the art, it is therefore the question of the record of payments made by the user, especially during these purchases / rentals repeated over time. In the state of the art, when paying using a payment card, the card is inserted into a payment terminal, which, after a certain number of exchanges with a bank server, authorizes the transaction. and prints a physical payment ticket accounting for the transaction and including a number of legal notices, including the amount authorized to debit. This ticket recalls the transaction and its possession allows the holder of the credit card to challenge the payment in some cases. The payment receipt thus printed includes all the information relating to the transaction. However, in view of the average number of transactions carried out by a user, there is a real problem of archiving payment tickets. Many tickets are not kept or lost, which does not allow users to effectively detect any errors in the movement of money on their account. In addition, in the case of certain systems, such as vehicle rental systems, in which the user authorizes the collection of an increased amount in advance and does not resubmit his card once he has returned the vehicle, the amount levied may be different from the authorized amount and the amount levied is not known in advance. However, the payment voucher indicates the amount that has been authorized to be withdrawn, and not the amount actually taken. This can be confusing for the user and prevent him from properly checking the transactions he has made. An object of the present invention is to overcome the aforementioned drawbacks. Another object of the invention is to propose a method and a payment signaling system, especially for repeated payments over time, allowing a user a simple and clear tracking for payments made on his account. Yet another object of the invention is to propose a method and system for signaling payments made enabling a user to identify the payments actually made on his account. Finally, another object of the invention is to propose a method and a payment signaling system enabling a user to keep proof of payments actually made on his account. DISCLOSURE OF THE INVENTION The invention proposes to achieve at least one of the above-mentioned objects by a method of signaling payments made with a payment means of a user, said method comprising the following steps: reading relative data means of payment verification from said means of payment, - transmission to a bank server of a claim, using the data relating to said means of payment, said method being characterized in that it comprises a transmission, at a digital address obtained previously, data, called report, relating to the outcome of said claim.

The report data may also be called "virtual ticket" in this application. By "reading data from the means of payment", it is meant that a payment terminal is directly in contact with the means of payment and directly reads the information in this means of payment, without the user entering the data. Such a reading step is for example the reading of a chip or a magnetic strip of the payment means. Thus, the method according to the invention makes it possible to digitally send reports for payments actually made to its account. The method according to the invention is not limited in particular to indicate to the user the increased amount that he has authorized to withdraw from his account, which is generally different from the actual amount he has to pay. Thus, the method according to the invention makes it possible to communicate to the user the data relating to the actual sampling carried out on his account, enabling him to be able to challenge the sample if anomalies exist. The method according to the invention also makes it possible to follow in a simple and clear manner the withdrawals made on its account as and when the purchase or rental operations. The method according to the invention also allows the user to be aware of acts of theft or errors made in relation to a debit authorization that he has granted and for which he has not yet consumed.

Such a method also facilitates the archiving of credit card tickets for the user, and the search for such a ticket in case of conflict. Note that the method is described later in connection with a vehicle rental service but it can be applied to any type of payment using a physical payment means, such as a credit card, and regardless of the nature of the good or service that the user wishes to acquire and settle using the payment transaction. The data relating to the means of payment can be read by a reading terminal, more particularly a payment terminal, into which the payment means is inserted. Advantageously, the claims described below are made according to a first protocol requiring the physical presence of the means of payment in a payment terminal (in the case where there is a pre-authorization request and then an actual payment request, at least for the pre-authorization request). Such a payment protocol makes it possible to guarantee the payment in a secure manner because it makes it possible to obtain debit authorization data.

Moreover, such a payment protocol makes it possible to ensure that the means of payment is used by the holder of the payment means, for example by requesting the entry of a PIN code or a secret security code associated with the card. . The method also includes a step of receiving a response from the banking server to the claim, the report data being generated based on the claim and / or response.

In a particularly advantageous embodiment, the method comprises the following steps: - transmission to the banking server of a pre-authorization request, using the data relating to said means of payment, and then - if the pre-authorization has obtained, issuing an actual payment request to the bank server, using the data relating to said means of payment and a pre-authorization data characteristic of the pre-authorization, the claim being constituted by one or both of the requests for pre-authorization and actual payment. The method may comprise a step of issuing a report after each of the pre-authorization request and actual payment steps or only after the pre-authorization request, for example.

As a variant, the pre-authorization and actual payment requests being each issued for a predetermined amount, it comprises a step of comparing the amount of these requests, the step of issuing a report being carried out: the pre-authorization request, - in addition, for the actual payment request if and only if the amounts of the two applications are different. Thus, in addition to the advantages mentioned above, the method according to the invention makes it possible in this case to avoid to the user the confusion that can create a situation in which it is informed only of the increased amount that it has authorized to collect. on his account and not the amount actually taken. The methods and systems of the state of the art do not actually inform the amount actually taken. - 6 - It can also be envisaged that, in addition to the actual initial payment request, which is carried out according to a first payment protocol and detailed above, the method comprises the issue of at least one other payment request. effective, said subsequent, according to a second payment protocol, in particular independent of the request for pre-authorization. This request for subsequent payment can be made according to a payment protocol that does not require the physical presence of the means of payment in a payment terminal, such as for example a payment protocol type distance selling. Such a payment protocol has the advantage of being flexible because it makes it possible to make a payment without the physical presence of the means of payment in a payment terminal for example. Preferably, the method according to the invention also comprises a step of identifying the user and storing data relating to the payment means in association with at least one user data. In this way, subsequent payment requests can be made without the user having to resubmit his payment method.

Such a combination of payment request according to two different protocols makes it possible to perform a plurality of secure payment requests both for the holder of the payment means and for the operator providing the good or the service, and flexible because the user not to present the means of payment for each payment request.

Advantageously, a reporting data transmission step is also performed following the subsequent payment request. The user is thus notified of all transactions made on his account even if he does not need to present his method of payment. When the procedure is implemented in the case of repeated payments, a claim, including an actual payment request, may be triggered in one or more of the following cases: - 7 - - at each use of the service provided by the user, and / or - when a customer account, associated with the user and incremented each time the service is used, reaches a predetermined maximum amount, said method further comprising a step of consulting an amount associated with said account with each new purchase or rental transaction or at a given frequency, and / or - when the previous payment request for said user has been made for a predetermined maximum duration, said method further comprising a consultation of the date of said last request each new purchase or lease transaction or frequency, and / or - when a predetermined date, linked to a date of end of service contract for example, is reached, said method further comprising a consultation of said date for each new purchase or rental operation or at a given frequency, said user identifying each time using his identifier . The first case has the advantage of detecting a situation of default of payment quickly and to avoid the failure to pay a large amount and to limit the losses of the operator. The second and third cases have the advantage of reducing the number of payment requests and thus the banking transactions carried out.

Advantageously, the reporting data may include data relating to: - the type of payment request, and / or - by means of payment, and / or - to the recipient of the transaction, and / or - to the amount, and / or - at the date or time of the transaction, and / or - at the end of the payment request, - 8 - the report data may notably be presented in the form of a virtual ticket including most notably all the information visible on a ticket issued by a payment terminal following a request for pre-authorization or payment by this terminal.

The data may also, in addition or in replacement, be related to an Internet address, including a link, to consult to obtain a report of the outcome of the claim. Such a virtual ticket may then be available at the address indicated in the message.

The digital address associated with the user may comprise: an email address, the report data being then transmitted in particular via an Internet-type network, and / or a mobile telephone number, the data of This report is then sent in particular via a GPRS type network, and / or any other digital coordinate such as, for example, a fax number, a social network address, etc. Such a digital address can be modified, deleted or added remotely or from an operator site at any time through a user interface. Advantageously, the digital address may include an address entered by the user before the first payment request step, for example during a subscription step to a rental service or a sales service. The address can be entered at the time of or just before the step of reading the means of payment and be for single use. The digital address can also be stored in a database (remote or not) and extracted from the database, for example a database of a service management server. It is then filled once by the user and extracted with each new transaction. The digital address may also or instead include an address entered in an identification means, the method further comprising a step of extracting said digital address from the identification means. This step can be carried out simultaneously with the step of reading the data of means of payment, the means of identification being for example presented at the time of or just before the presentation of the means of payment. It can also be considered in this case that the means of payment is the means of identification.

Thus, by a single reading step, the method makes it possible to read both the digital address and the data relating to the means of payment. According to an advantageous version, the method according to the invention may further comprise a step of consulting a data, known as payment status, before triggering a new request for use of the service, in particular following the identification. of the user, the use of the service being authorized or not according to said payment status data. This step is performed after the first claim has been issued.

Such status data enables the method according to the invention to trigger a payment request which will probably be refused or to accept a purchase or rental request for which the operator will probably not be paid. The payment status data can be updated: - at each request for consultation of the status data, namely before each new use of the service, - after each payment request according to the outcome of the payment request , and / or - regularly at a determined frequency. In this case, the method according to the invention may further comprise a step of consulting the bank carrying the payment means, on a regular basis to determine the payment capacity of the bearer of the means of payment, data relating to the means of payment such as the date of validity, and / or the situation of the means of payment, for example whether or not there is an opposition against the means of payment. The payment status data is updated according to the result of said consultation.

In a particular embodiment, the method further comprises a step of generating an alias of the payment means, preferably before the step of reading the data relating to the payment means. It can then also comprise: a step of identifying the user, a step of storing said alias in association with at least one data item relating to the user, in particular an identifier of the user, in a management server. , in particular related to the proposed service; and a step of storing said alias in association with the data relating to the payment means, in a payment server separate from the management server; in this case, for each payment, the following steps: - determination by the management server of the alias of the payment method associated with the user according to said user identifier, - determination by the electronic payment server of the relative data. by means of payment associated with said alias, and - issuing, by the electronic payment server, an effective payment request with said data relating to said payment means. The step of storing the alias may in particular be carried out just before the pre-authorization request step by the electronic payment server. Such an embodiment makes it possible to secure the method because the card data are not stored in association with the data concerning the service. When the method is implemented in such an architecture, the method may comprise the following steps: the electronic payment server obtains the report data of the claim, transfers it to the management server, the management server implementing the transmission step to the digital address of the user. Alternatively or additionally, the management server stores in a database the digital address of the user and transfers it to the electronic payment server, which implements the transmission step to the digital address of the user. 'user. The method according to the invention can advantageously be used in a vehicle rental facility offered for rental on at least one rental site to carry out the signaling of payments made. According to another aspect of the invention, there is provided a system for signaling payments made with a means of payment of a user, said system comprising: means for reading data relating to said means of payment from said means of payment means for sending to a banking server a claim, using the data relating to said means of payment. The system further comprises means, said communication, arranged to achieve, for at least one claim, preferably for each request, a transmission, to a previously obtained digital address, of data, called report, the outcome of the said claim. The system according to the invention comprises a reading terminal, and more particularly a payment terminal, into which the payment means is inserted and arranged to read the data relating to the means of payment. The numerical address can be obtained by means of input means, by means of means for reading an identification means or means for consulting a database in which it is stored. According to a first mode of the system according to the invention, the payment request means may comprise: a first server comprising means for: generating an alias of the payment means; storing said alias with an identifier of the user, - a second server, said to be electronic, comprising means for: - storing said alias of the payment means with the data relating to said means of payment, - issuing claims; the communication means further comprising a module, said communication, arranged in the first server or in the second server or in a server of a bank carrying the payment means.

Thus, the data relating to the means of payment and the user's identifier are not recorded on the same server, which makes it possible to protect these data against fraudulent use. According to a second embodiment of the system according to the invention, the payment request means comprise: a server, comprising means for: storing the data relating to the payment means in association with the user's identifier; , and - issue claims; The communication means further comprising a communication module arranged in said server or in a server of a bank carrying the payment means. This embodiment makes it possible to reduce the exchange of information between the members of the system according to the invention, and to avoid adding to the steps of payment and reporting requests. This embodiment also makes it possible to reduce the costs of such a signaling system. Advantageously, the communication module may comprise a SIM card for making a connection to a GPRS network, a modem for connecting to the Internet network in a wired manner, via Bluetooth® or by Wifi, and / or a connection means to the network. wired telephone.

Advantageously, the reading terminal may be in direct communication, via another organ, with the storage means and / or the payment request means.

According to yet another aspect of the invention there is provided a vehicle rental facility comprising: a central management site, at least one vehicle rental site comprising at least one vehicle proposed for rental, said site rental being connected to said central site, and - a signaling system according to the invention. In a particularly advantageous embodiment, the signaling system payment request means may be arranged at the central management site as well as the communication means and the storage means. In this preferred embodiment, the system may further comprise a read terminal disposed at each rental site.

Other advantages and characteristics will appear on examining the detailed description of non-limiting embodiments, and the appended drawings in which: FIG. 1 is a schematic representation of a system according to the invention and exchanges between the different elements of the system; - FIGURE 2 is a schematic representation of the steps of a first version of a method according to the invention applied to the rental of vehicles; FIG. 3 is a schematic representation of a second embodiment of a method according to the invention; FIGURE 4 is a representation in the form of a diagram of the steps for triggering payment requests according to the invention; and FIG. 5 is a schematic representation of a vehicle rental installation implementing a system according to the invention.

In the figures and in the following description, the elements common to several figures retain the same reference. In the examples described below, the means of payment is advantageously, but not exclusively, a bank card.

It will be noted that, in the following, the terms "authorization" and "pre-authorization" can be used interchangeably, as well as the terms "debit request" and "request for payment", or "digital address" and "e-mail address". ".

FIGURE 1 is a schematic representation of a system according to the invention. The system 100 shown in Figure 1 comprises a terminal 102, called subscription, comprising identification means, for example an RFID card reader. The subscription terminal may include other means of identification, including means for entering a personal code. The system 100 further comprises a payment terminal 104 for reading data relating to a payment means, such as a credit card reader.

The system 100 also comprises a management server 106, a payment server 108. The management server 106 comprises means for storing a database 110, and the electronic payment server also comprises a database 112 stored locally in a means memorisation. The electronic payment server 108 is in communication with the payment terminal via a first intermediate server 114 managing the payment terminal. The management server 106 is in communication with the electronic payment server 108 via a second intermediate server 116, called "cashpooler" in the embodiment described here. The system 100 further comprises a communication module 118 comprising a SIM card for connection to the GPRS network and arranged to send the report data or a virtual ticket relating to the outcome of each payment request. This communication module 118 is directly connected to the electronic payment server 108. It will be noted that, in other embodiments, this server could be connected to the management server. Such an embodiment will be described later.

The system 100 is arranged and programmed to make a payment request (subsequently used for actual payment) according to a pre-authorization payment protocol and subsequent payment requests according to a remote sale payment protocol. It is considered that the two payment requests are made according to separate protocols because they do not include exactly the same information and / or that the information is not presented in the same way. The exchange of information between the various organs of the system in order to carry out the initial payment request is indicated below and are represented in FIG. 1 with full arrows, each arrow indicating the direction of the exchange of information. The payment procedure using the initial request is initiated by the management server 106 under the aegis of a call center, for example, a subscription procedure to the vehicle rental service.

It comprises the following steps: PA1: Issuing a pre-authorization request with amount and a user card alias (UID) of 12 alphanumeric characters from the central server 106 to the subscription terminal 102, - 16 - - PA2 : Transmission of the request to the payment terminal 104 with possible addition of the necessary parameters. The UID is added and aligned, - PA3: Transmission of the request to the first intermediate server 114, - PA4: Transmission of the request to the electronic payment server 108. The UID is transmitted in ISO 8583 format. The electronic payment server issues the request for payment. pre-authorization of payment to the bank of the holder of the means of payment and receives the response of the bank following the request for pre-authorization. Optionally the electronic payment server 108 generates a virtual ticket relating to the payment authorization request to be sent to the user, - PA5: Response to the first intermediate server 114 of the electronic payment server 108 with regard to the request, - PA6: Transmission, by the first intermediate server 114, the response to the payment terminal 104. The folder is assigned by this server a unique identifier on 12 characters. This is a pre-authorization data or an error or refusal data. During this step the result of the authorization request can also be displayed on a display screen at the payment terminal 104, - PA7: The data is transmitted to the rental terminal 102, - PA8: The data is transmitted to the management server 106 (error return, or pre-authorization identifier (ID)). Optionally, when a virtual ticket is generated by the electronic payment server 108 following receipt of the response from the carrier bank, the following steps can be performed: PA 9: the management server 106 sends the electronic payment server the virtual address of the user, either directly as shown in Figure 1, or through the intermediary server 114, - 17 - - PA10: the payment server transfers the virtual ticket and the electronic payment address of the user to the communication module , PA11: the virtual ticket is sent by the communication module 118 to the user, for example in the form of a text message, through a communication network 120, for example of the GPRS type. The pre-authorization data is then used to carry out a so-called initial payment request initiated by the management server at the desired time, according to the following operations: PP1: Payment request sent to the first intermediate server 114 using the pre-authorization identifier and the alias UID, - PP2: The request is relayed to the electronic payment server 108. The electronic payment server 108 generates and sends the payment request to the bank of the holder of the payment means and receives a return reply. This request includes, following the intervention of the payment server, the data relating to the means of payment. The electronic payment server 108 then generates a virtual ticket summarizing the result of the payment request, - PP3: The received response is relayed by the electronic payment server 108 to the first intermediate server 114, and - PP4: The response is relayed by the first intermediate server 114 to the management server 106, - PP5: the management server 106 transmits an electronic address of the user to the payment server 108, either directly as shown in FIG. 1, or via the first intermediate server 114, PP6: the electronic payment server 108 transmits the generated virtual ticket and the digital address to the communication module 118, and - 18 - - PP7: The communication module 118 sends the virtual ticket to the digital address through the communication network 120 .

The exchanges of information between the various organs of the system in order to realize the subsequent payment request are indicated below and are represented in FIG. 1 with dashed arrows, each arrow indicating the direction of the exchange of information. . The payment procedure using a subsequent request is initiated by the management server 106 according to predetermined test criteria which will be described later and comprises the following steps: - VD1: Payment request sent by the server of management 106 on the second intermediate server 116 (UID and amount); - VD2: the request is sent to the payment server 108, which generates a subsequent payment request including the data of the payment means. The payment server receives the response from the bank concerning the debit authorization request. The electronic payment server 108 generates a virtual ticket to be sent to the user; - VD3: the response of the bank is transmitted by the electronic payment server 108 to the second intermediate server 116, and - VD4: the response is relayed by the second intermediate server 116 to the management server 106; - VD5: the management server 106 transmits an electronic address of the user to the payment server 108, either directly as shown in Figure 1, or through the second intermediate server 116; - VD6: the electronic payment server 108 transmits the generated virtual ticket and the digital address to the communication module 118; and - VD7: the communication module 118 sends the virtual ticket to the digital address through the communication network 120. The money transfer steps between the banks are not described here.

In this embodiment, there is an intermediate server between the payment terminal and the electronic payment server and another intermediate server, called "Cashpooler", between the management server and the payment server. These servers are represented in the diagram by examples because the payment services are performed by different providers. However, the payment server could be directly connected to the payment terminal and the rental management server without the presence of these intermediate servers, or in the presence of a single intermediate server.

Moreover, in another embodiment, the electronic payment server and the management server can be integrated in a single server, in which case the exchange of information between these servers is not carried out. This embodiment however requires a heavy security management server, impractical.

In a very simplified embodiment, the system according to the invention comprises only a payment terminal provided with reading means, a payment server carrying out the payment requests from the user's bank, a storage means, and a communication module arranged to send the virtual tickets. All other members described above with reference to Figure 1 are optional and can be added individually to such a simplified system. FIGURE 2 is a representation in the form of a diagram of a first embodiment of a method according to the invention, implemented in a system in which there are no intermediate servers. In this method, contrary to what has been indicated in the architecture shown in FIG. 1, it is the management server 106 which is the issuer of the virtual ticket. The communication module 118 is therefore connected to this server 106 and not to the payment server 108. The method 200 shown in FIG. 2 comprises, first of all, an initialization phase 202.

The initialization phase 202 includes a step 204 during which the user indicates his identity and personal information, for example by scanning an identity paper which may for example be his driver's license. During this step the user also indicates an electronic address to which the report data or the virtual ticket must be sent. This step 204 is performed at a subscription terminal to a given service, such as a vehicle rental service, or any cash. This terminal is obviously connected to the management server via a network, for example an Internet type network. In step 206 these data are transmitted to a management server, for example the management server 106 of FIG. 1. Once these formalities have been carried out, the management server stores an identifier associated with the user at step 208 and also stores the email address, and possibly the identity data provided in step 204. The user-related identifier can be generated at the management server or the subscription terminal. In step 210, an identification means is provided to the user by the terminal, such as for example an RFID card. It will be noted that the identification means received by the user may be of a type other than that described (a personal code, a bar code, a magnetic card, etc.). When the user already has an identifier and has previously filled in an e-mail address, the steps 202 to 210 are not performed and are replaced by a step (not shown) of reading the user's identifier. In this embodiment, steps 202 to 210 constitute in any case the user identification steps. In step 212, the user chooses a subscription to which he wishes to subscribe. The choice of the subscription is transmitted to the management server in step 214.

The management server then generates a payment method alias and records it in association with the identifier in step 216. In step 218, the server transmits the alias to the terminal, in association with other payment data, including the amount to be charged.

In step 220, the alias and the data related to the payment are transmitted to the terminal. He then has all the elements to initiate the transaction. In step 222, the user inserts a payment means into the terminal. The data relating to the means of payment are read in a conventional manner, the user enters his PIN to verify that he is an authorized cardholder (PIN). The user's interactions with the payment terminal are conventional interactions. If the PIN code is wrong, the card is blocked and the transaction is refused and the user is informed. If the PIN code is correct, the payment terminal extracts the data from the card to make the payment (card identifier and expiration date in particular). This data may possibly include an electronic address registered in the payment means. In this case, it is not necessary for the user to enter an e-mail address during step 202, this address being extracted from the data read from the payment means, sent to the management server and recorded at the level of the e-mail address. from this server. The alias and the data relating to the means of payment are then transmitted to the electronic payment server during step 224.

In step 226, the payment server records the alias in association with the data relating to the means of payment. In step 228, the electronic payment server sends a request for payment authorization to the bank of the user, using the payment method data and other payment related data transmitted by the terminal. and gets the answer from the bank. Following reception of the response, the electronic payment server generates an acknowledgment of receipt and a virtual ticket.

The acknowledgment of receipt may include either an acceptance data, in the form of pre-authorization data, or a refusal. The virtual ticket is generated based on the content of the response from the user's bank. The acknowledgment of receipt is transmitted with the alias of the payment means 10 and the virtual ticket to the payment terminal in step 230, which may optionally visually inform the user of the outcome of the payment request. In step 232, the payment terminal transmits the acknowledgment, the alias of the payment means and the virtual ticket to the management server via the payment terminal. The management server stores the acknowledgment in step 234 in association with the user's identifier. In step 236, the management server extracts the user's email address from its database. The management server transmits the virtual ticket to the user at step 238, possibly using a communication module. Steps 202 to 238 constitute the initialization phase 202 of the method 200. Following this initialization phase, which lasts only a few tens of seconds, the user can withdraw his card from the payment terminal. Then, the management server tests at a given frequency whether the user's account should be debited or not (as will be described later). Once the server determines that the user's account is actually to be debited and the amount to be debited, the following steps are performed. This is phase 240 of the first payment request, at the initial payment request. The management server sends the electronic payment server the pre-authorization data and the alias in step 242. In step 244, the electronic payment server sends a payment request to the bank of the user at the bank. using the pre-authorization data and the means of payment data extracted from its database and obtained by means of the alias transmitted by the management server, and obtains the response from the bank. Following reception of the response, the electronic payment server generates an acknowledgment of receipt and a virtual ticket. The answer at this level can only be positive since the debit authorization has already been obtained. In step 246, the electronic payment server transmits the acknowledgment of receipt and the virtual ticket to the management server which stores it. As previously described, the management server transmits the virtual ticket to the user in step 248, possibly using a communication module, indicating the exact amount of the debit, which may be different from the amount for which a debit authorization had been obtained. Phase 240 of the initial payment request according to a first pre-authorization payment protocol is then completed.

The method 200 then comprises one or more phases 250 of subsequent payment request according to a second payment protocol of the remote sale type. In this case, the management server tests at a given frequency whether a payment request should be made as we will see later. As soon as a payment request is to be made the following steps are carried out. The management server sends the electronic payment information server, namely for example the amount to be debited, the alias of the means of payment, at step 252. At step 254, the payment server issues a request for payment. payment to the bank of the user, using the payment means data extracted from its database and obtained through the alias transmitted by the management server. The subsequent payment request does not include the pre-authorization data since it is not made in connection with such pre-authorization. Depending on the response obtained, the payment server generates an acknowledgment and a virtual ticket. The answer at this level can be positive or negative.

In step 256, the electronic payment server transmits the acknowledgment of receipt and the virtual ticket to the management server which stores it. The management server transmits the virtual ticket to the user in step 258, possibly using a communication module. Phase 250 of subsequent payment request according to a second remote sale type protocol is then completed. In another embodiment, the method 200 may comprise only payment requests according to the pre-authorization protocol. In this case, the phase 256 is not performed and the phase 228 can be repeated several times. In yet another embodiment, a single server is used as a payment server and management server. In this case, it is not necessary to perform all the steps described above consisting of the generation of an alias and the transmission of data, directly or indirectly, between the management server and the payment server. In the case where the architecture comprises a management server, a payment server and possibly at least one intermediate server, it will be noted that the virtual ticket may be issued by the electronic payment server or by an intermediate server, in particular that associated with the payment terminal. payment. All embodiments may be combined with each other in a non-limiting manner.

Thus, the virtual ticket sent to the user comprises at least data relating to the result of the debit authorization request or the payment request, namely: -25- - data of acceptance or refusal of a request for debit authorization of an increased amount, or - data of acceptance or refusal of a real transaction request, ie a request for payment, for an amount actually debited to the account of the customer. It may also include data relating to: - the type of payment request, and / or - the payment method (hidden number of the credit card in particular), and / or - the addressee of the transaction (recipient's sign, number of SIRET of the recipient, etc.), and / or - the amount (expressed in figures and / or in letters), and / or - the date or time of the transaction, and / or - at the end of the payment request. It may also include a file number and / or a transaction number or other information. Note that the server can generate two versions of the virtual ticket depending on the type of the digital address chosen by the user. The digital address may not be provided by the user but by the bank of the user during the payment request issued by the payment server.

The digital address can in particular be: - a telephone number, in which case the virtual ticket is sent via SMS over a GPRS network, and preferably in condensed form, - an e-mail address, in which case the virtual ticket is sent by email through an Internet-type network, and preferably in complete form. The sender of the message containing the virtual ticket is preferably always the same to facilitate archiving by the user. Referring now to FIGURE 3, a very simplified embodiment 300 of a method according to the invention will now be described. The system implementing the method described with reference to FIG. 3 comprises a single payment server, provided with storage means and a communication module, and a payment terminal comprising means for reading a medium. payment method such as a credit card. All other members described above with reference to Figure 1 are optional and can be added individually to such a simplified system. The method 300 comprises the following steps: step 302: the user enters at the payment terminal a digital address to which he wishes to receive a virtual ticket; - Step 303: the user inserts into the payment terminal his credit card. He may enter a PIN code to verify that he is the cardholder. It should be noted that steps 302 and 303 can be reversed. The virtual address could also already be stored in the payment server or extracted from the bank card. step 304: sending by the payment terminal of the bank data to the payment server, and the digital address; a step 306: storage by the payment server of the bank data in association with the digital address and possibly with other data; a step 308: transmission by the server of an actual payment request including the bank data; a step 310: reception of the response from the bank of the user with an acknowledgment and memorization of the acknowledgment of receipt. ; and a step 312: generating the virtual ticket from the acknowledgment of receipt. One could also consider that the virtual ticket is the acknowledgment of receipt; A step 314: transmission to the user (via his digital address) of a virtual ticket including the data of the report of the request for payment; an optional step 316, in which the acknowledgment of receipt (or even the virtual ticket) is also transferred towards the payment terminal, so that the addressee of the transaction can also obtain the data relating thereto.

FIGURE 4 is a schematic representation in the form of a flowchart of the steps for triggering payment requests. In FIG. 4, the symbol SG denotes the management server 106 and the acronym SM designates the electronic payment server 108 of FIG. 1. In the embodiment described with reference to FIG. 4, the method issues a first payment request according to FIG. a pre-authorization payment protocol and at least one second payment request according to a remote sale payment protocol. A first step 402 determines whether an initial payment request has been generated. If not, a test step 404 is repeated every night. In this step 304 the management server checks the following criteria: - that the period of validity of the authorization is about to expire (in less than 24 hours): this information on the period of validity is obtained through pre-authorization validity data; - the amount of account dedicated to the user exceeds the maximum amount authorized by the authorization; this information on the maximum amount is obtained thanks to a pre-authorization amount data. If these tests return a negative answer, no initial payment request is generated. On the other hand, if one or more of the tests return a positive response, the server generates a first payment request in step 406. To this end, it sends to the electronic payment server, possibly using an intermediary server. , preferably also connected to the payment terminal, a file containing in particular the previously obtained pre-authorization identifier, the alias and the numerical address. The file also includes the amount requested, this amount being necessarily less than or equal to the maximum amount indicated in the authorization. The payment server then generates, during step 408, an initial payment request, comprising the pre-authorization identifier and data relating to the payment means extracted from its database from the alias and sends it to a server of the bank of the cardholder. It is sent to the bank card holder's bank server in a first predetermined format. The bank card holder's server then sends an acknowledgment to the payment server, which transmits it to the management server at step 410. The server of the bearer's bank orders the transfer of the corresponding amount from the account. bank from the user associated with the card to the bank account associated with the rental service. A report is also sent to the management server via the payment server. In step 412, the electronic payment server sends a virtual ticket to the user. Following the first payment request, the management server deletes the authorization identifier or indicates that it is no longer valid. It retains the card alias. If after step 402, a first payment request is already made, the rental management server also checks the following criteria on a daily basis at step 414: - duration since the last payment greater than a predetermined duration? - amount of the account dedicated to the user higher than a predetermined amount? If these tests return a negative response, no payment request is generated and step 414 is repeated daily until at least one of these criteria returns a positive response. If one or more tests return a positive response, the server generates a second request in step 416. Note that a second request is also generated almost simultaneously with the first when the amount of the account dedicated to the user exceeds the maximum amount allowed in the authorization and no payment has been made before. In this case, the first payment request generated by the payment server is up to the maximum amount authorized by the debit authorization and the second payment request is made for the remaining amount of the account, which has not been paid. by the first payment request.

To generate the second request, the management server sends, in step 416, to the electronic payment server, possibly using an intermediate server, which may be different from the intermediate server already mentioned in relation to the first request, a file containing the map alias. The file also includes the requested amount, but does not include the authorization ID since it was deleted after the first payment request. The payment server generates a payment request from the data associated with the alias extracted from its database and sends the payment request to a server of the bank card holder's bank at step 418. The request for payment payment is sent to the bank card holder's bank server in a second predetermined format, generally distinct from the first format. The cardholder bank server then verifies certain data relating to the card in step 420: its existence, its validity - later expiry date, no opposition -. If the transaction is accepted, the server of the bearer's bank then returns, in step 422, an acknowledgment to the electronic payment server that transmits it to the rental management server. A virtual ticket including the result of the transaction is sent to the user at step 424. The bearer's bank server also controls the transfer of the corresponding amount from the user's bank account associated with the transaction. card to the bank account associated with the rental service. A report is also sent to the management server via the payment server.

If this transfer is not possible, for example because the holder does not have enough money on his account or because the credit card is considered invalid, the transfer is canceled, and the payment server is informed, in step 426, as well as the management server through it.

In this case, the bank server returns to the electronic payment server, which transmits an error message to the management server. Upon receipt of such an error message, the management server can modify, during a step 428, a data item relating to the user, in particular to the card alias, for example a payment status data item, indicating that the user is no longer able to pay with his card. A virtual ticket is also sent to the user at step 430 indicating the result of the transaction. The payment status data, for example, that card expiration data transmitted from the payment server to the management server can be verified before any request for rental / subsequent purchase of the user. Thus, the user can be prevented from renting a vehicle without having paid all his previous payments. When the user hands a credit card into the payment terminal to perform the initialization sequence again, a new card alias can be generated which replaces the other. It will be noted that many steps are optional, for example all the steps relating to the generation of an alias and the issuing of a virtual ticket.

It is also possible that the different files sent by the management server are of the same format. But the information in these files will not be the same and they will not trigger the same transactions at the level of exchanges between the payment server and the server of the bank of the cardholder. This is why we consider that payment requests are not made using the same protocol. It is also possible that the payment and management servers are confused, the existence of the card alias then not being necessary.

The triggering of the issuing of payment requests may also be carried out differently from what has been determined (for example on a specific date of the month, every month). Alternatively, at each identification of the user, a payment request is issued, having preferably checked whether the amount of the user's account was greater than a predetermined amount (0E). FIGURE 5 is a schematic representation of an automated rental facility for electric vehicles implementing a system according to the invention. The installation 500 shown in FIG. 1 comprises a central site 502 (also called a central unit in the remainder of the description) connected to several sites - or stations - 5041-504n, said to be leased through a communication network 506. wireless, for example GPRS, or a wired network, for example of the DSL type. Preferably, each site 504 is connected to the central site 502 via two separate networks, allowing a continuous connection even if one of the networks is faulty. Each rental site 504 includes a subscription terminal 102 for registration of a new subscriber, a rental terminal 510 for the rental of a vehicle and a plurality of charging terminals 512-516, each charging station. being provided for charging a vehicle with an electric battery to a parking space. The central site 502 can be connected directly to each of the terminals of a rental site 504 through the network 506 or only to the subscription terminal and / or to the rental terminal and / or the charging terminals 512-516. . At least two terminals of a rental site 504 are connected to each other through a wired connection (not shown).

The central site 502 comprises the management server 106, the electronic payment server 108 as well as the storage means 110 and 112 in which the various data described above are stored with reference to FIG. 1. The central site furthermore comprises the communication module. 118.

Some rental sites 504 include a subscription terminal equipped with a payment terminal 104. Each subscription terminal includes means (not shown) for reading a user's identifier and means (not shown) for receiving and transmitting to the central site a user's identity data.

In this figure the intermediate servers are not represented, these intermediate servers being optional. Naturally, the invention is not limited to the examples which have just been described.

Claims (18)

REVENDICATIONS1. A method (200; 500) for signaling payments made with a payment means of a user, said method comprising the steps of: reading, by a payment terminal, data relating to said payment means from said payment means; transmitting to a banking server a claim, using data relating to said means of payment; said method further comprising, prior to said step of issuing the claim, a step of storing said digital address in a remote server of the payment terminal; said method being characterized in that it comprises a transmission (246, 254, 15 264; 520), to a previously obtained digital address, of data, called report, relating to the outcome of said claim, such as a virtual ticket. 2. Method according to claim 1, comprising the following steps: issuing a pre-authorization request to the banking server, using the data relating to said means of payment, and then - if the pre-authorization has been obtained, issuing an effective payment request to the banking server, using the data relating to said means of payment and pre-authorization data characteristic of the pre-authorization, the claim being constituted by one or both of the requests for pre-authorization and actual payment. 30 3. Method (200) according to claim 2, characterized in that the actual payment request (228), said initial, is carried out according to a first payment protocol, the method further comprising the issue of at least one other effective payment request (256), said subsequent, according to 34 - a second payment protocol, in particular independent of the request for pre-authorization. The method of claim 3, wherein a step of transmitting report data is also performed subsequent to the subsequent payment request. 5. Method according to one of claims 3 and 4, implemented in the case of repeated payments, characterized in that a claim, 10 including effective payment, is triggered: - at each use of the service performed by the user, and / or - when a customer account, associated with the user and incremented with each use of the service, reaches a predetermined maximum amount, said method further comprising a step of consulting an amount associated with audit account at each new purchase or rental transaction or at a given frequency, and / or - when the previous payment request for said user has been made for a predetermined maximum duration, said method further comprising a consultation of the date of said last payment request for each new purchase or lease transaction or frequency; Said user identifying himself during each use by his identifier. Method according to (200; 500) according to one of the preceding claims, characterized in that the reporting data comprise data relating to: - the type of payment request, and / or - the payment method, and / or - at the addressee of the transaction, and / or the amount, and / or - at the date or time of the transaction, and / or at the end of the request for payment, - at a Internet address, including a link, to view for a review of the outcome of the claim. 5 7. Method (200,500) according to any one of the preceding claims, characterized in that the numerical address comprises: - an email address, the report data then being transmitted through an Internet-type network, and or 10 - a mobile telephone number, the report data then being transmitted through a GPRS type network. A method (200; 500) according to any of the preceding claims, characterized in that the digital address comprises an address entered by the user prior to the payment request step. 9. Method according to any one of the preceding claims, characterized in that the numerical address comprises an address entered in an identification means, the method further comprising a step of extracting said digital address from the means of identification. 'identification. 10. Method according to any one of the preceding claims, characterized in that it comprises a step (332) of consulting a data, known as payment status, before a new request for use of the service, the whether the service is authorized or not based on said payment status data. 11. Method (200; 500) according to any one of the preceding claims, characterized in that it further comprises: a step of identifying the user, steps of generating an alias and then memorizing said alias in association with at least one data relating to the user, in particular an identifier of the user, in a management server, in particular related to the proposed service; and a step of storing said alias in association with the data relating to the payment means, in a payment server separate from the management server. 12. Method (200; 500) according to claim 11, characterized in that it comprises, for each payment, the following steps: determination by the management server of the alias of the payment means associated with the user based of said user identifier, determination by the electronic payment server of the data relating to the payment means associated with said alias, and transmission by the payment server of an effective payment request with said data relating to said payment means. 13. The method as claimed in claim 11, in which the electronic payment server obtains the report data of the claim, transfers it to the management server, the management server implementing step d. transmission to the digital address of the user. 14. Method according to any one of claims 11 and 12, wherein the management server stores in a database the digital address of the user and transfers it to the payment server, which implements the step of transmission to the user's digital address. 15. Application of the method according to any one of the preceding claims in an installation (400) for rental of vehicles proposed for rental on at least one rental site (404). 16. System (100) for signaling payments made with a means of payment of a user, said system comprising: means for reading data relating to said payment means from said payment means, said reading means comprising a payment terminal; payment, means for storing a digital address in a remote server of said payment terminal, means for sending to a bank server of a claim, using data relating to said payment means, said system (100) being characterized in that it further comprises means (118), called communication means, arranged to perform, for at least one request for payment, preferably for each request a transmission, to a numerical address obtained previously, data, called report, relating to the outcome of said claim. 15 A payment system (100) according to claim 16, characterized in that the claiming means comprises: a first server (106), comprising means for: - generating an alias of the payment means, storing said alias with an identifier of the user, - a second server (108), said electronic money, comprising means for: - storing said alias of the payment means with the data relating to said means of payment, 25 - issue claims; the communication means comprising a module (118), said communication, arranged in the first server (106) or in the second server (108) or in a server of a bank carrying the payment means. 30 18. A vehicle rental facility (400) comprising: - a central management site (402), - at least one vehicle rental site (404) comprising at least one vehicle proposed for rental, said site (404) being connected to said central site (402), and a signaling system (100) according to any of claims 16 or 17.