WO2013045832A1

WO2013045832A1 - Payment reporting method and system, and use for automated vehicle rental

Info

Publication number: WO2013045832A1
Application number: PCT/FR2012/052171
Authority: WO
Inventors: Raphaël BARROIS; Lionel PANHALEUX; Yousra CHEBBI; Juliette LAQUERRIERE épouse TALAGA; Christian FOSSORIER
Original assignee: Ier Systems
Priority date: 2011-09-30
Filing date: 2012-09-27
Publication date: 2013-04-04
Also published as: FR2980891A1

Abstract

The invention relates to a method for reporting payments made with a payment means, said method including the following steps: storing a digital address associated with an identifier for the user holding the payment means, storing data relating to said payment means, and at least one payment request using said data relating to said payment means; said method being characterized in that, for each payment request, same includes the sending of so-called reporting data relating to the outcome of said payment request to said digital address. The invention likewise relates to a system (100) implementing such a method and to a use of such a method and such a system for automated vehicle rental.

Description

"Method and system of payment signaling,

application to the automated rental of vehicles »

The present invention relates to a method of signaling 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. In the processes and systems of the state of the art, there is therefore the question of the account 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.

Presentation of the invention

The invention proposes to achieve at least one of the aforementioned objects by a method of signaling payments made with a payment means of a user, said method comprising the following steps:

reading data relating to said means of payment from said means of payment,

- sending to a bank server of a claim, using data relating to said means of payment,

said method being characterized in that it comprises a transmission, to a previously obtained digital address, of 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 allowing him to challenge the levy 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, wherein the report data is generated based on the claim and / or response.

In a particularly advantageous embodiment, the method comprises the following steps:

- issuing to the banking server a pre-authorization request, using data relating to said means of payment, and then

if the pre-authorization has been obtained, transmission to the banking server of an actual payment request, using data relating to said means of payment and pre-authorization data characteristic of the pre-authorization,

the claim being constituted by one and / or the other of the pre-authorization and actual payment requests.

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:

- for 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. 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 actual payment request, so-called subsequently, 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 process is implemented in the case of repeated payments, a claim, including actual payment, may be initiated in one or more of the following circumstances: - 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 said account with each new purchase transaction or rental or at a given frequency, and / or

when the preceding 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 with each new purchase or rental transaction or at a given frequency , and or

when a predetermined date, linked to a date of end of a service contract for example, is reached, said method furthermore comprising a consultation of said date with each new purchase or rental operation or at a given frequency,

said user identifying with each use through 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 report data may include data relating to:

- the type of payment request, and / or

- by means of payment, and / or

- the recipient of the transaction, and / or

- the amount, and / or

- the date or time of the transaction, and / or

- at the end of the payment request, the report data can 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 include:

an email address, the report data then being transmitted in particular via an Internet-type network, and / or

a mobile telephone number, the report data then being transmitted 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:

each request for consultation of the status data, namely before each new use of the service,

- after each request for payment depending on the outcome of the payment request, and / or

- regularly at a specified 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 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.

He can then also understand:

a step of identifying the user,

a step of storing 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 linked 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 data relating to the payment means associated with said alias, and

- issuing, by the payment server, an effective payment request with said data relating to said means of payment.

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 payment server obtains the report data from the claim, transfers it to the management server, the management server implementing the issuing step to the user's digital address.

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 payment means,

means for sending a payment request to a bank server, using 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, data, called report, relative at the end of the said claim.

The system according to the invention comprises a reading terminal, and more particularly a payment terminal, in which the payment means is inserted and arranged to read the data relating to the means of payment.

The numerical address can be obtained using input means, using means for reading an identification means or means for consulting a database in which it is stored. According to a first embodiment of the system according to the invention, the payment request means may comprise:

a first server comprising means for:

- generate an alias of the payment method,

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,

- issue 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 means of payment in association with the identifier of the user, and

- issue claims;

the communication means further comprising a module, said communication, arranged in said server or in a server of a bank carrying the payment means.

This embodiment makes it possible to reduce the exchanges of information between the organs 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 connection modem to the Internet network wired, by Bluetooth® or by Wifi, and / or a connection means to the wired telephone network.

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 management site, called central,

at least one vehicle rental site comprising at least one vehicle offered for rental, said rental site 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:

- FIGURE 1 is a schematic representation of a system according to the invention and exchanges between the various 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

- FIGURE 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 includes 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, 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 sends the request for pre-authorization of payment to the bank of the holder of the means of payment and receives the response from the bank following the pre-authorization request. 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 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 FIG. 1 or via the intermediary server 114, - PA10: the electronic payment server transfers the virtual ticket and the electronic payment address of the user to the communication module,

- PAU: 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 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 UID alias,

- 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 means of payment and receives a return response. 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 response received 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 - PP7: The communication module 118 sends the virtual ticket to the digital address through the communication network 120.

The exchange of information between the various organs of the system in order to realize the subsequent payment request is 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 answer is relayed by the second server

intermediate 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 steps of transferring money between 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, firstly, 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.

Once these formalities have been carried out, the management server stores an identifier associated with the user in step 208 and also stores the electronic address, and possibly the identity data provided in step 204. The identifier relating to the user 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 at the 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 withdrawn.

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 payment authorization request to the bank of the user, using data from the payment method and other payment-related data transmitted by the terminal and obtains the bank's answer. 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 means of payment and the virtual ticket to the payment terminal in step 230, which may optionally visually inform the user on the outcome of the payment request.

In step 232, the payment terminal transmits the acknowledgment of receipt, 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 the 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 must actually 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 issues a payment request to the user's bank using the pre-authorization data and payment method data extracted from its database and obtained by means of the alias transmitted by the management server, 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 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 payment information server to the payment server, namely for example the amount to be debited, the alias of the payment method, at step 252.

In step 254, the electronic payment server sends a payment request to the bank of the user, using the payment means data extracted from its database and obtained thanks to the alias transmitted by the server. Management. The subsequent payment request does not does not include the pre-authorization data since it is not carried out in connection with such a 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: - data of acceptance or rejection of an application for a debit authorization of a higher amount, or

- data of acceptance or refusal of a real transaction request, that is to say a request for payment, for an amount actually debited on the customer's account.

It may also include data relating to:

- the type of payment request, and / or

- by means of payment (hidden number of the credit card in particular), and / or

- the recipient of the transaction (sign of the recipient, SIRET number of the recipient, etc.), and / or

- the amount (expressed in figures and / or 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 numerical address can notably 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 e-mail over 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. A very simplified embodiment 300 of a method according to the invention will now be described with reference to FIG.

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 account data of the payment request;

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.

In the embodiment described with reference to FIG. 4, the method issues a first payment request according to a pre-authorization payment protocol and at least a 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 thanks to a validity data of the pre-authorization;

- 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 tests return a positive response, the server generates a first payment request in step 406. For this, it sends to the electronic payment server, possibly using an intermediate server, preferably also connected to the payment terminal, a file containing in particular the previously obtained pre-authorization identifier, the alias and the address. digital. 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, a payment request, called initial, including the pre-authorization identifier and data relating to the payment means extracted from its database from the alias and the sends to a server of the bank the holder of the credit card. 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 in step 410.

The server of the bearer's bank orders the transfer of the corresponding amount from the bank account of 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 has already been 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 duration

predetermined?

- 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 reiterated 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 electronic payment server is up to the maximum amount authorized by the pre-authorization of debit 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 server of the bearer's bank also orders the transfer of the corresponding amount from the bank account of 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. 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. Note that many steps are optional namely for example all the steps relating to the generation of an alias and the issuance of a virtual ticket. It is also possible that the different files transmitted 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).

As a variant, 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 (0 €).

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 central unit in the remainder of the description) connected to several sites - or stations - 504i-504 _n , called rental via 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 the 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 terminal being provided for charge 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

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, of data relating to said means of payment from said means of payment,

- sending to a bank server of a claim, using the 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, 264; 520), to a previously obtained digital address, of data, called report, relating to the outcome of said claim, such as than a virtual ticket.

The method of claim 1, comprising the steps of:

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 actual payment request (256), referred to as a second payment protocol, in particular independent of the pre-authorization request.

4. The method of claim 3, wherein a step of transmitting report data is also performed following 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, 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 said account with each new purchase transaction rental or at a given frequency, and / or

when the preceding 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 with each new purchase or rental transaction or at a given frequency ;

said user identifying with each use through his identifier.

Method according to (200; 500) according to one of the preceding claims, characterized in that the report data comprises data relating to:

- the type of payment request, and / or

- by means of payment, and / or

- the recipient of the transaction, and / or

- the amount, and / or

- the date or time of the transaction, and / or - at the end of the payment request,

- an Internet address, including a link, to be consulted for a report of the outcome of the claim.

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 being then transmitted through an Internet-type network, and / or

- A mobile phone number, the report data then being sent through a network type GPRS.

8. Method (200; 500) according to any one of the preceding claims, characterized in that the numerical address comprises an address entered by the user before the request for payment 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 numerical 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, called payment status, before a new request for use of the service, the use whether the service is authorized or not based on said payment status data.

11. Process (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 then 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 linked 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:

13. The method as claimed in claim 11, in which the electronic payment server obtains the report data from 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 a facility (400) rental of vehicles offered 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,

means for storing a digital address in a remote server of said payment terminal,

means for sending a payment request to a bank server, using data relating to said payment means, said system (100) being characterized in that it further comprises means (118), said communication, arranged to achieve, for at least one claim, preferably for each request an issue, to a previously obtained digital address, data, said report, relating to the outcome of said claim .

17. Payment system (100) according to claim 16, characterized in that the means of claim include:

a first server (106), comprising the means for:

- generate an alias of the payment method,

storing said alias with an identifier of the user,

a second server (108), said to be electronic, comprising the means for:

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

Vehicle rental facility (400) comprising:

a site (402) of management, called central,

at least one vehicle rental site (404) comprising at least one vehicle offered for rental, said rental site (404) being connected to said central site (402), and - A signaling system (100) according to any one of claims 16 or 17.