WO2013045831A1 - Procede et systeme de paiement, application a la location automatisee de vehicules - Google Patents

Procede et systeme de paiement, application a la location automatisee de vehicules Download PDF

Info

Publication number
WO2013045831A1
WO2013045831A1 PCT/FR2012/052170 FR2012052170W WO2013045831A1 WO 2013045831 A1 WO2013045831 A1 WO 2013045831A1 FR 2012052170 W FR2012052170 W FR 2012052170W WO 2013045831 A1 WO2013045831 A1 WO 2013045831A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
request
data
server
Prior art date
Application number
PCT/FR2012/052170
Other languages
English (en)
Inventor
Raphaël BARROIS
Lionel PANHALEUX
Yousra CHEBBI
Juliette LAQUERRIERE épouse TALAGA
Christian FOSSORIER
Original Assignee
Ier Systems
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ier Systems filed Critical Ier Systems
Publication of WO2013045831A1 publication Critical patent/WO2013045831A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/045—Payment circuits using payment protocols involving tickets
    • G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically

Definitions

  • the present invention relates to a method of payments repeated over time, with the same means of payment, for the payment of a service, including purchases or rentals of goods. It also relates to a payment system implementing such a payment method. The invention also relates to an application of such a method to the rental of vehicles and a vehicle rental installation implementing such a system.
  • the field of the invention is the field of payments repeated over time with the same means of payment, for example a bank card, when buying or renting goods or services.
  • 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.
  • Automated vehicle rental is a growing field. Agglomerations wishing to reduce the number of vehicles on their territory are implementing automated vehicle rental systems.
  • the user when the user identifies for subsequent rentals, it verifies the authorization identifier and its validity and increments the rental account of the user. A few hours before the end of debit authorization, the amount of the rental account is debited from the user's card.
  • the debit authorizations are only valid for a predetermined duration, which is currently 30 days maximum. However, if the user has a one-year subscription, this payment system can not be used for the duration of the subscription without the user being obliged to represent his credit card regularly.
  • debit authorizations are only valid for a maximum amount authorized. However, if the user wishes to make a purchase or lease whose amount is greater than the maximum amount authorized, this payment system can not be used. As a result, either the user is obliged to represent his credit card at each transaction exceeding the maximum amount allowed, or it is necessary to choose a maximum amount of the authorization, which can be problematic for the user if this one reaches the ceiling of his bank card.
  • An object of the present invention is to overcome the aforementioned drawbacks.
  • Another object of the invention is to provide a method and a system of payments repeated over time, with the same means of payment more flexible.
  • Yet another object of the invention is to propose a method and a system of payments repeated over time, with the same means of payment, safer both for the operator providing the service / good and for the user.
  • Another object of the invention is to propose a method and a system of payments repeated over time, with the same means of payment, usable in new or existing payment facilities, both for the purchase and the rental of goods and / or services.
  • the invention proposes to achieve at least one of the aforementioned aims by a method for making payments repeated over time with the same means of payment, the payments being related to a service offered to a user, said method comprising:
  • initialization phase a first phase, called initialization phase, comprising the following steps:
  • a phase called a payment phase, comprising the following steps:
  • Both payment requests are considered to be performed according to separate protocols when they do not exactly understand the same data and / or the data are not presented in the same way.
  • the method according to the invention thus makes it possible to make repeated payments over time with the same means of payment in a flexible and more secure manner for both the user and the operator offering the service (in particular a purchasing service or rental). Indeed, with the method according to the invention it is possible to choose a first protocol of a rigorous payment that guarantees that the means of payment used is secure and valid and that it is used by the holder of the means of payment, and that the initial payment is made with the greatest amount of money. security for both the user and the operator. It is then possible to use a second, less rigorous and more flexible payment protocol for subsequent payment requests, so as to better adapt to the user's consumption.
  • the method according to the invention makes it possible to carry out a rigorous initial payment request with a first rigorous protocol in order to check security rules with a view to guaranteeing and securing payments, and then using a simplified payment protocol in order to achieve subsequent payments that are more flexible for both the user and the operator.
  • the user identifies each time he wishes to use the service, the use of this service being billed to an account associated with at least one data of the user, including an identifier thereof , the payment requests being each carried out according to the amount of the account of the user, in particular for an amount of the account of the user.
  • the so-called initial payment request can be made within the context of a type transaction by proximity payment or by payment type on a PLC, while each of the so-called subsequent payment requests is made in the context of a type transaction. by distance selling or recurring payment type by distance selling.
  • subsequent payment requests make it possible to request the payment of amounts not known in advance, ie rental services and additional invoices - invoices issued when an unforeseen event occurs, such as paying a deductible due to an accident of the user - and not only the payment of fixed and recurring charges, such as subscription levies.
  • Subsequent payment requests also make it possible to request the payment of a concatenation of amounts relating to several different types of benefits among the three listed below (rental services, recurring fixed benefits and additional invoices).
  • the method defined above is very wide application since it is suitable for any service in which several payments can be generated, whether these payments are fixed, dependent on the consumption of the user or unforeseen.
  • Examples of services for which the method according to the invention can be implemented are, in addition to the rental of vehicles in connection with which it is described, the so-called "contactless" hotel, catering, telecommunications, for example telephony or access to an Internet network, access to a leisure site (sports club, amusement park, etc.), video-on-demand rentals, etc.
  • the first payment protocol may be a payment protocol requiring the physical presence of the payment method in the payment terminal.
  • Such a payment protocol may be a payment protocol, of pre-authorized type.
  • such a payment protocol may in particular include the request for a security code or a secret code associated with the payment means.
  • This first payment protocol makes it possible to guarantee the physical presence of the payment method on the one hand and the holder of the means of payment on the other.
  • Such a payment protocol is certainly not flexible, but it makes it possible to guarantee the payment and to secure the payment for both the user and the operator. In addition, it is a security for subsequent payments since it is at least assured that the service has been requested by the cardholder.
  • a flow authorization is obtained comprising at least one pre-authorization data, the initial payment request comprising the pre-authorization data.
  • Such pre-authorization makes it possible to guarantee the payment, even when the financial situation of the user has changed between the issue of the pre-authorization and the request for payment and to ensure in fact a certain comfort for the operator of the service. at least the first consumption of the user will be paid in a certain way.
  • the amount and validity data are notably extracted from the pre-authorization.
  • the second payment protocol may be a payment protocol that does not require the physical presence of the payment method in a payment terminal, the subsequent payment request. being performed using only the data relating to the stored payment means.
  • Such a payment protocol may for example be a payment protocol type distance selling. It does not require the issuance of a pre-authorization and the subsequent payment request therefore does not include pre-authorization data.
  • Such a payment protocol has the advantage of being very flexible for the user who does not have to present the means of payment for each subsequent payment, while making a payment directly from an account associated with the means of payment, and without having to feed an intermediary account managed by the operator.
  • the method according to the invention makes it possible to use only the data coming from the means of payment, ie the data of the card, without additional input by the user of a cryptogram visible on the back of the card. This is usually not allowed in a public space such as a space in which a rental facility may be installed to which the invention is applied.
  • the method according to the invention may further comprise a step of generating an alias of the payment means, preferably before the step of reading the data relating to the payment means.
  • An alias is an identifier to identify the means of payment. It can in particular be a randomly generated number.
  • a step of storing said alias in association with the data relating to the payment means advantageously in a second server, said to be electronic, said electronic payment server being separate from the management server and being remote from the payment terminal.
  • the data relating to the means of payment, the identifier of the bearer and the alias of the means of payment are recorded on different servers.
  • the management server linked to the service and which, by its nature, has many interactions with external elements, does not exchange data relating to the means of payment. Thus, if this server is hacked, the hacker will not have data of means of payment. Likewise, it can make all communications to the outside without the security of these communications is greatly enhanced.
  • the payment server being the only one with the data relating to the means of payment and used only for payment, can be configured to be less accessible from the outside and secure in a suitable way to defeat any hacking attempt. This makes it possible to secure the payment data without slowing down the service dedicated to the user.
  • the method according to the invention may comprise for each payment made on behalf of a user with which an identifier is associated, the following steps: determination, in particular by the management server, of the alias of the payment method associated with the user according to said user identifier,
  • the method according to the invention may comprise, after at least one pre-authorization request or a payment request, in particular after each payment request (initial or subsequent), a transmission of payment warning data to a payment device. communication of said user through a communication network.
  • the warning data are in particular presented in the form of a virtual ticket, which includes all the information usually visible on a ticket printed by a payment terminal following a transaction of proximity payment type or by PLC.
  • a subsequent payment request may be issued to each new consumption, in particular each new identification, by the user. There will be as many subsequent payment requests as there are purchases or leases of goods or services
  • a subsequent payment request may be issued when:
  • a customer account associated with the user reaches a predetermined maximum amount, said method comprising a step of consulting said account with each new consumption, in particular identification, or at a given frequency, and / or
  • the previous payment request has been made for a predetermined maximum duration, said method comprising in in addition to consulting the date of said last payment request, such a previous payment request may be the initial payment request or a previous payment request.
  • the method according to the invention makes it possible to limit the number of payment requests and thus to reduce the number of bank transactions.
  • the method according to the invention also makes it possible to secure transactions by reducing fraud opportunities.
  • the method according to the invention makes it possible to increment an account associated with a user as the user makes purchases / rentals, until reaching the predetermined maximum amount or the predetermined maximum duration.
  • the user's customer account is reset.
  • the method according to the invention may further comprise a step of consulting a data, known as payment status, before a new request for use of the service, in particular identification, the use of the service being authorized or not authorized. according to said payment status data.
  • a data known as payment status
  • the consultation step is performed only after the initial payment request has taken place.
  • the method according to the invention may notably comprise an update of the payment status data item:
  • Such an update can be performed regularly, for example every day or on request for a consultation of the status data, namely before each new use of the service.
  • the method according to the invention may also include an update of the payment status data, after a payment request, the payment status data being modified or not according to the outcome of said payment request.
  • the method according to the invention makes it possible, thanks to such a payment status data item, to avoid authorizing the user's access to the service when the payment status of the user carrying the payment means does not allow it. if the means of payment is no longer valid, or the last payment request has been refused, the means of payment is opposed, the account associated with the means of payment is blocked, or because the user does not have enough money on his account so that a new payment request would be refused.
  • the data format used in the initial payment request may be different from the data format used to make a subsequent payment request.
  • the data format used in a subsequent payment request include data different from the data format used in the initial payment request.
  • Such a subsequent payment request does not include, for example, pre-authorization data.
  • the method according to the invention can be advantageously used for the payment of rental services, with or without subscription, of vehicles and more particularly electric vehicles offered for rental on one or more rental sites, each rental site being connected to a central management site coordinating the various steps of the process.
  • a payment system for making payments repeated over time with the same means of payment, the payments being relative to a service offered to the user, said system comprising:
  • storage means for storing said data relating to the payment means, for storing said data in association with at least one user data item;
  • said system further comprising means, called payment means, arranged to emit:
  • initial payment a request for payment, called initial payment, according to a first payment protocol
  • the identification means may advantageously comprise an RFID reader for reading an RFID identification card, an optical reader for reading a bar code identifier, a reader of a biometric identification means or the like.
  • identification means are arranged to read an identifier associated with a user from an identification means, of RFID type, for example, during purchases / initial or subsequent rentals.
  • the terminal for reading data relating to the payment means may be a payment terminal.
  • the means of payment may comprise:
  • a management server in particular linked to the service, comprising means for:
  • a second server said to be electronic, comprising means for:
  • the initial payment request further comprising at least one pre-authorization data.
  • the different servers can be in communication with the payment terminal and between them to exchange data.
  • the system according to the invention may further comprise means for encoding and decoding the data exchanged between the different organs of the system so as to secure these data.
  • the communication between the different organs can be partially or totally wired or wireless, through a communication network type Internet or GPRS.
  • all the servers can be replaced for a single server arranged to perform the initial and subsequent payment requests.
  • a vehicle rental facility comprising:
  • central 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
  • the reading terminal can be arranged on the rental site.
  • each rental site may further comprise an identification means and a reading terminal.
  • the means of payment may be arranged at the central management site.
  • the management server may be located at the central management site and the electronic payment server may be arranged at a bank of the operator. rental service or at another site, called electronic banking.
  • 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 simplified version 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.
  • FIGURE 5 is a schematic representation of a vehicle rental installation implementing a system according to the invention.
  • the elements common to several figures retain the same reference.
  • the means of payment is advantageously, but not exclusively, a bank card.
  • 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 and a payment server 108.
  • the management server 106 comprises means for storing a database 110
  • the electronic payment server also comprises a database 112 stored locally in a central bank. 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 perform an initial payment request 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.
  • 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,
  • UID user card alias
  • 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,
  • the electronic payment server 108 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.
  • the electronic payment server 108 generates a virtual ticket relating to the debit 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, of the response to the payment terminal 104.
  • the file is assigned by this server a unique identifier on 12 characters. This is a pre-authorization data or an error or refusal data.
  • the result of the authorization request can also be displayed on a display screen at the payment terminal 104;
  • PA8 The data is transmitted to the management server 106 (error return, or pre-authorization identifier (ID)). Eventually, when a virtual ticket is generated by the electronic payment server 108 following receipt of the response. of the carrying bank, the following steps can be carried out:
  • the management server 106 sends the payment server the virtual address of the user, either directly as shown in Figure 1, or through the intermediate server 114;
  • the electronic payment server transfers the virtual ticket and the electronic payment address of the user to the communication module:
  • 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,
  • 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 electronic 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 debit request;
  • the response received is relayed by the electronic payment server 108 to the first intermediate server 114, and
  • the response is relayed by the first intermediate server 114 to the management server 106;
  • 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;
  • the electronic payment server 108 transmits the generated virtual ticket and the digital address to the communication module 118;
  • 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 carry out the subsequent payment request are indicated below. and are shown in FIG. 1 with dashed arrows, each arrow indicating the direction of the information exchange.
  • the subsequent payment request is initiated by the management server 106 according to predetermined test criteria which will be described later and comprises the following steps:
  • the request is sent to the electronic payment server 108, which generates a subsequent payment request including the data of the payment means.
  • the payment server receives the response of the bank concerning the request debit authorization.
  • 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 server
  • 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;
  • the electronic payment server 108 transmits the generated virtual ticket and the digital address to the communication module 118;
  • the communication module 118 sends the virtual ticket to the digital address through the communication network 120.
  • 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 for example because the payment services are performed by different providers.
  • 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.
  • the electronic payment server and the management server can be integrated into a single server, in which case the exchange of information between these servers is not possible. made.
  • This embodiment however requires a heavy security management server, impractical.
  • system 100 includes a communication module for issuing virtual tickets.
  • this communication module is optional.
  • the system 100 comprises the reading terminal 104 connected to a single server, which may be called a payment server, and a storage means. 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.
  • the method 200 shown in FIG. 2 shows a first (initial) payment request according to a pre-authorization type proximity payment protocol, and a second (so-called subsequent) sales-to-distance payment request.
  • 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.
  • these data are transmitted to a management server, for example the management server 106 of FIG.
  • 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.
  • an identification means is provided to the user by the terminal, such as for example an RFID card.
  • 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.).
  • the steps 202 to 210 are not performed and are replaced by a step (not shown) of reading the user's identifier.
  • steps 202 to 210 constitute in any case the user identification steps.
  • 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
  • the management server then generates a payment method alias and records it in association with the identifier in step 216.
  • step 218 the server transmits the alias to the terminal, in association with other payment data, including the amount to be withdrawn.
  • 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.
  • step 222 the user inserts a payment means into the terminal.
  • the data relating to the means of payment are read in such a way classic, the user enters his PIN to verify that he is an authorized cardholder (PIN).
  • PIN authorized cardholder
  • 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.
  • 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.
  • step 226 the payment server records the alias in association with the data relating to the means of payment.
  • step 228, the electronic payment server sends a debit authorization request to the bank of the user, using the data of the payment means and other payment-related data transmitted by the terminal 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 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 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 of the outcome of the debit request.
  • 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.
  • 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
  • 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.
  • the management server tests at a given frequency whether the user's account should be debited or not (as will be described later).
  • the server determines that the user's account must actually be debited and the amount to be debited, the following steps are performed.
  • the management server sends the electronic payment server the pre-authorization data and the alias in step 242.
  • step 244 the electronic payment server sends a debit request to the bank of the user using the pre-authorization data and payment method data extracted from its database and obtained through 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.
  • step 246 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 248, possibly using a communication module, indicating the exact amount of the bit rate, which can 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.
  • the management server tests at a given frequency if a request for payment must be made as we will see later.
  • 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.
  • 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 include the pre-authorization data as it is not made in connection with such pre-authorization.
  • the payment server 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.
  • 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.
  • the virtual ticket sent to the user includes data relating to the result of the debit authorization request or the debit request, namely: - data of acceptance or rejection of an application for a debit authorization of a higher amount, or
  • the method 200 may not include the sending of virtual tickets, in this case the steps relating to the digital address and the sending of such a ticket are not carried out.
  • a single server can be used as a payment server and management server.
  • the method 200 does not include 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.
  • FIGURE 3 is a schematic representation in the form of a diagram of a simplified version of a method according to the invention.
  • the system comprises a payment terminal, a single payment server and storage means.
  • the method 300 comprises an initialization phase 302 comprising the following steps:
  • step 304 average insertion of payment in the reading terminal
  • step 306 reading and transmission to the payment server of the data relating to the means of payment;
  • step 308 storage of the data relating to the payment means at the payment server.
  • step 310 a transmission of a debit authorization request to a server of the user's bank with the data relating to the means of payment;
  • step 312 reception of a pre-authorization debit data item valid for a maximum amount and for a maximum duration and storage of this data item. Then, the payment server tests at a given frequency whether the user's account should be debited or not (as will be described later).
  • the server determines that the user's account must actually be debited and the amount to be debited, the following steps are performed.
  • phase 314 of the first payment request, or initial payment request comprising the following steps:
  • step 316 sending, to the user's bank, a payment request with the debit authorization data and the payment information, namely for example the exact amount of the debit:
  • step 318 reception of an acknowledgment of receipt issued by the user's bank and memorization of the acknowledgment of receipt.
  • Phase 314 of the first payment request is then completed.
  • the payment server tests at a given frequency whether or not the user's account is to be debited (as will be described later).
  • the server determines that the user's account must actually be debited and the amount to be debited, the following steps are performed.
  • the method 300 then comprises one or more payment request phases 320 carried out according to a payment protocol of the remote sale type and comprising the following steps: step 322: issuing, to the user's bank, a payment request with the data relating to the means of payment and the payment information, such as, for example, the exact amount of the debit;
  • step 324 acknowledgment of receipt issued by the user's bank and memorization.
  • FIGURE 4 is a schematic representation in the form of a flowchart of the steps for triggering payment requests.
  • the symbol SG denotes the management server 106 and the acronym SM designates the electronic payment server 108 of FIG.
  • 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.
  • a test step 404 is repeated every night.
  • the management server checks the following criteria:
  • this information on the period of validity is obtained thanks to a validity data of the pre-authorization
  • the server If one or more tests return a positive response, the server generates a first payment request in step 406. For this, it sends the payment server, possibly using a intermediate 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, 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.
  • step 412 the electronic payment server sends a virtual ticket to the user.
  • the management server deletes the authorization identifier or indicates that it is no longer valid. It retains the card alias.
  • the rental management server also checks the following criteria on a daily basis at step 414:
  • step 414 is reiterated daily until at least one of these criteria returns a positive response.
  • the server If one or more of the tests return a positive response, the server generates a second request in step 316. It will be noted that a second request is also generated almost simultaneously with the first request, allowing the initial payment to be obtained when the Account amount 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.
  • 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 amount requested, but does not include the authorization ID since it was cleared after the first debit 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.
  • the bank server returns to the electronic payment server, which transmits an error message to the management server.
  • 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.
  • the user can be prevented from renting a vehicle without having paid all his previous payments.
  • a new card alias can be generated which replaces the other.
  • steps are optional namely for example all the steps relating to the generation of an alias and the issuance of a virtual ticket.
  • 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.
  • the triggering of the issuing of debit requests can also be carried out differently from what has been determined (for example on a specific date of the month, every month).
  • 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.
  • each station 504 is connected to the central site 502 via two separate networks, which allows a continuous connection even if one of the networks is faulty.
  • Each rental station 504 comprises 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 station 504 through the network 506 or only to the subscription terminal and / or to the rental terminal and / or the charging terminals 512-516. .
  • 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.
  • intermediate servers are not represented, these intermediate servers being optional.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Coin-Freed Apparatuses For Hiring Articles (AREA)

Abstract

L'invention concerne un procédé pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à un utilisateur, ledit procédé comprenant : une première phase, dite d'initialisation, comprenant les étapes suivantes : identification d'un utilisateur, lecture, par un terminal de paiement, de données relatives audit moyen de paiement depuis ledit moyen de paiement, et mémorisation desdites données relatives au moyen de paiement, en association avec au moins une donnée relative à l'utilisateur; et une phase, dite de paiement, comprenant les étapes suivantes : émission d'une demande de paiement, dite initiale, selon un premier protocole de paiement, et émission d'au moins une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement différent du premier protocole de paiement. L'invention concerne également un système mettant en œuvre un tel procédé et une application d'un tel procédé et d'un tel système à la location automatisée de véhicules.

Description

« Procédé et système de paiement, application à la location automatisée de véhicules »
La présente invention concerne un procédé de paiements répétés dans le temps, avec un même moyen de paiement, pour le paiement d'un service, notamment d'achats ou de locations de biens. Elle concerne également un système de paiement mettant en œuvre un tel procédé de paiement. L'invention concerne également une application d'un tel procédé à la location de véhicules et une installation de location de véhicule mettant en œuvre un tel système
Le domaine de l'invention est le domaine des paiements répétés dans le temps avec un même moyen de paiement, par exemple une carte bancaire, lors d'achat ou de locations de biens ou de services. L'invention concerne en particulier, et de manière non limitative, le domaine de la location automatisée de véhicules proposés à la location dans un ou plusieurs sites de locations.
Etat de la technique
La location automatisée de véhicule est un domaine en pleine croissance. Les agglomérations désirant diminuer le nombre de véhicules présents sur leur territoire mettent en place des systèmes de location automatisés de véhicule.
L'un des objectifs d'un service de location automatisé de véhicules est la fourniture d'un moyen de locomotion de manière sûre et flexible. Le paiement d'un tel service doit alors être également flexible et sûr à la fois pour l'utilisateur et pour l'opérateur. On connaît dans l'état de l'art, notamment du brevet FR 2 863 089, un système de location de cycles dans lequel l'utilisateur met sa carte bancaire dans un automate et compose son code. Ses données bancaires sont ensuite transmises de façon sécurisée à un serveur monétique. Une fois les données transmises, le serveur monétique retourne à la borne de location une autorisation de débit et un identifiant d'autorisation associé à cette autorisation et stocké par le système. Grâce à cet identifiant d'autorisation, il est possible de louer un cycle sans utiliser sa carte bancaire durant la durée de validité de l'autorisation. En effet, lorsque l'utilisateur s'identifie pour les locations ultérieures, on vérifie l'identifiant d'autorisation et sa validité et on incrémente le compte de location de l'utilisateur. Quelques heures avant la fin d'autorisation de débit, le montant du compte de location est débité depuis la carte de l'utilisateur. Or, un tel système de paiement n'est pas suffisamment flexible, ni pour l'utilisateur ni pour l'opérateur fournissant le service. En effet, les autorisations de débit ne sont valables qu'une durée prédéterminée, qui actuellement est de 30 jours au maximum. Or, si l'utilisateur dispose d'un abonnement d'un an, ce système de paiement ne peut pas être utilisé sur toute la durée de l'abonnement sans que l'utilisateur soit obligé de représenter sa carte bancaire régulièrement.
Par ailleurs, les autorisations de débit ne sont valables que pour un montant maximum autorisé. Or, si l'utilisateur désire réaliser un achat ou une location dont le montant est supérieur au montant maximum autorisé, ce système de paiement ne peut pas être utilisé. En conséquence, soit l'utilisateur est obligé de représenter sa carte bancaire à chaque transaction dépassant le montant maximum autorisé, soit on est obligé de choisir un montant maximal élevé de l'autorisation, ce qui peut être générateur de problèmes pour l'utilisateur si celui-ci atteint le plafond de sa carte bancaire.
Un but de la présente invention est de remédier aux inconvénients précités.
Un autre but de l'invention est de proposer un procédé et un système de paiements répétés dans le temps, avec un même moyen de paiement plus flexible.
Encore un autre but de l'invention est de proposer un procédé et un système de paiements répétés dans le temps, avec un même moyen de paiement, plus sûr à la fois pour l'opérateur fournissant le service/bien et pour l'utilisateur. Enfin, un autre but de l'invention est de proposer un procédé et un système de paiements répétés dans le temps, avec un même moyen de paiement, utilisables dans des installations de paiement nouvelles ou existantes, à la fois pour l'achat et la location de biens et/ou de services.
Exposé de l'invention
L'invention propose d'atteindre au moins l'un des buts précités par un procédé pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à un utilisateur, ledit procédé comprenant :
- une première phase, dite d'initialisation, comprenant les étapes suivantes :
- identification de l'utilisateur,
- lecture, par un terminal de paiement, de données relatives audit moyen de paiement depuis ledit moyen de paiement, et
- mémorisation desdites données relatives au moyen de paiement, en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur ; et - une phase, dite de paiement, comprenant les étapes suivantes :
- émission d'une demande de paiement, dite initiale, selon un premier protocole de paiement, et
- émission d'au moins une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement différent du premier protocole de paiement.
On considère que les deux demandes de paiement sont effectuées selon des protocoles distincts lorsqu'elles ne comprennent pas exactement les mêmes données et/ou que les données ne sont pas présentées de la même façon.
Le procédé selon l'invention permet ainsi de réaliser des paiements répétés dans le temps avec un même moyen de paiement de manière flexible et plus sûr à la fois pour l'utilisateur et pour l'opérateur proposant le service (notamment un service d'achat ou de location). En effet, avec le procédé selon l'invention il est possible de choisir un premier protocole de paiement rigoureux qui permet de garantir d'une part que le moyen de paiement utilisé est sûr et valide et qu'il est bien utilisé par le porteur du moyen de paiement, et d'autre part que le paiement initial est réalisé avec la plus grande sécurité à la fois pour l'utilisateur et pour l'opérateur. Il est ensuite possible, d'utiliser un deuxième protocole de paiement moins rigoureux et plus flexible lors des demandes de paiement ultérieures, de façon à mieux s'adapter aux consommations de l'utilisateur.
Autrement dit, le procédé selon l'invention permet de réaliser une demande de paiement initiale rigoureuse avec un premier protocole rigoureux afin de vérifier des règles de sécurité en vue de garantir et sécuriser les paiements, pour ensuite utiliser un protocole de paiement simplifié afin de réaliser des paiements ultérieurs plus flexibles à la fois pour l'utilisateur et pour l'opérateur.
De façon préférentielle, l'utilisateur s'identifie à chaque fois qu'il souhaite utiliser le service, l'utilisation de ce service étant facturée sur un compte associé à au moins une donnée de l'utilisateur, notamment un identifiant de celui-ci, les demandes de paiement étant chacune effectuée en fonction du montant du compte de l'utilisateur, notamment pour un montant du compte de l'utilisateur.
Lors de la phase de paiement, on peut aussi émettre une ou plusieurs demandes de paiement ultérieures selon le deuxième protocole et éventuellement encore une ou plusieurs autres demandes de paiement, selon un troisième, un quatrième, etc. protocoles de paiement différents du premier et du deuxième.
La demande de paiement dite initiale peut être effectuée dans le cadre d'une transaction de type par paiement de proximité ou de type par paiement sur automate, tandis que chacune des demandes de paiement dite ultérieure est effectuée dans le cadre d'une transaction de type par vente à distance ou de type par paiement récurrent par vente à distance.
On notera que les demandes de paiement ultérieures permettent de demander le paiement de montants non connus à l'avance, soit de prestations de location et de factures complémentaires - facture émises lorsqu'un imprévu survient, par exemple paiement de franchise du fait d'un accident de l'utilisateur - et non seulement le paiement de prélèvements fixes et récurrents, tels que des prélèvements d'abonnement. Les demandes de paiement ultérieures permettent également de demander le paiement d'une concaténation de montants relatifs à plusieurs types de prestations différentes parmi les trois cités ci-après (prestations de location, prestations fixes récurrentes et factures complémentaires).
Le procédé défini ci-dessus est d'application très large puisqu'il convient à tout service dans lequel plusieurs paiements peuvent être générés, que ces paiements soient fixes, dépendants de la consommation de l'utilisateur ou imprévus. Des exemples de services pour lesquels peut être mis en œuvre le procédé selon l'invention sont, outre la location de véhicules en relation avec laquelle il est décrit, l'hôtellerie dite sans contact, la restauration, les télécommunications, par exemple la téléphonie ou l'accès à un réseau Internet, l'accès à un site de loisirs (club de sport, parc d'attraction, etc.), la location de vidéos à la demande, etc.
Avantageusement, le premier protocole de paiement peut être un protocole de paiement nécessitant la présence physique du moyen de paiement dans le terminal de paiement.
Un tel protocole de paiement peut être un protocole de paiement, de type pré-autorisé.
Avantageusement, un tel protocole de paiement peut en particulier comprendre la demande d'un code de sécurité ou un code secret associé au moyen de paiement.
Ce premier protocole de paiement permet de garantir la présence physique d'une part du moyen de paiement, d'autre part du porteur du moyen de paiement. Un tel protocole de paiement n'est certes pas flexible mais il permet de garantir le paiement et de sécuriser le paiement à la fois pour l'utilisateur et pour l'opérateur. En outre, il constitue une sécurité pour les paiements ultérieurs puisqu'on est au moins assuré que le service a été demandé par le porteur de carte. Selon l'invention, lors de la phase d'initialisation, on obtient une pré- autorisation de débit comprenant au moins une donnée de pré-autorisation, la demande de paiement initiale comprenant la donnée de pré-autorisation. Une telle pré-autorisation permet de garantir le paiement, même lorsque la situation financière de l'utilisateur a changé entre l'émission de la préautorisation et la demande de paiement et d'assurer de fait un certain confort à l'opérateur du service puisqu'au moins les premières consommations de l'utilisateur seront payées de façon certaine.
Suite à la réception de la pré-autorisation, on stocke dans un serveur du système :
- une donnée de montant, définissant un montant maximal de validité de la pré-autorisation, et/ou
- une donnée de validité, définissant une durée de validité ou une date d'expiration de la pré-autorisation, et/ou
- une donnée de fin de contrat, relative à une date de fin de contrat de service,
la demande de paiement initiale étant émise dans l'un ou l'autre des cas suivants :
- lorsque l'on détermine, à l'aide de la donnée de validité, que la durée restante jusqu'à la date d'expiration de la pré-autorisation est inférieure à une durée prédéterminée, et/ou
- lorsque l'on détermine, à l'aide de la donnée de montant, que la différence entre le montant maximal et le montant du compte de l'utilisateur est inférieure à un montant prédéterminé, et/ou - lorsque l'on détermine, à l'aide de la donnée de fin de contrat que la durée restante jusqu'à la date de fin de contrat est inférieure à une durée prédéterminée.
Les données de montant et de validité sont notamment extraites de la pré-autorisation.
Avantageusement, le deuxième protocole de paiement peut être un protocole de paiement ne nécessitant pas la présence physique du moyen de paiement dans un terminal de paiement, la demande de paiement ultérieure étant réalisée à l'aide des seules données relatives au moyen de paiement mémorisées.
Un tel protocole de paiement peut par exemple être un protocole de paiement de type vente à distance. Il ne nécessite pas l'émission d'une pré- autorisation et la demande de paiement ultérieure ne comprend donc pas de donnée de pré-autorisation.
Un tel protocole de paiement présente l'avantage d'être très flexible pour l'utilisateur qui n'a pas à présenter le moyen de paiement à chaque paiement ultérieur, tout en réalisant un paiement directement depuis un compte associé au moyen de paiement, et sans avoir à alimenter un compte intermédiaire géré par l'opérateur.
On notera que le procédé selon l'invention permet de n'utiliser que les données issues du moyen de paiement, soit les données de la carte, sans saisie additionnelle par l'utilisateur d'un cryptogramme visible au dos de la carte. Cela n'est d'habitude pas autorisé dans un espace public tel qu'un espace dans lequel pourra être installé une installation de location à laquelle est appliquée l'invention .
Toutefois, dans le cas présent, cela est notamment possible sans mettre en jeu la sécurité du paiement, car la première demande de paiement est effectuée à l'aide d'un protocole sécurisé qui permet de s'assurer que le porteur de la carte est légitime. Les vérifications d'usage effectuées dans le cadre de la première demande de paiement remplacent donc l'opération de saisie additionnelle et permettent de se passer d'une intervention de l'utilisateur lors des demandes de paiement ultérieures.
Dans un mode de réalisation particulièrement avantageux, le procédé selon l'invention peut en outre comprendre une étape de génération d'un alias du moyen de paiement, de préférence avant l'étape de lecture des données relatives au moyen de paiement.
Un alias est un identifiant permettant d'identifier le moyen de paiement. Il peut notamment être un nombre généré aléatoirement.
Un tel alias permet de sécuriser les demandes de paiements ultérieures car il permet d'éviter le plus possible de manipuler les données relatives au moyen de paiement, ce qui permet de limiter le risque qu'elles soient dérobées et utilisées à des fins frauduleuses.
Le procédé selon l'invention peut avantageusement comprendre :
- une étape de mémorisation dudit alias en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur, par exemple dans un premier serveur, dit de gestion, notamment relatif au service, ce serveur de gestion pouvant être un serveur distant du terminal de paiement ; et
- une étape de mémorisation dudit alias en association avec les données relatives au moyen de paiement, avantageusement dans un deuxième serveur, dit monétique, ce serveur monétique étant distinct du serveur de gestion et pouvant être distant du terminal de paiement.
Ainsi, les données relatives au moyen de paiement, l'identifiant du porteur et l'alias du moyen de paiement sont enregistrés sur des serveurs différents.
Le serveur de gestion, lié au service et qui, de par sa nature, a de nombreuses interactions avec des éléments externes, n'échange pas de données relatives au moyen de paiement. Ainsi, si ce serveur est piraté, le pirate ne disposera pas des données de moyen de paiement. De même, il peut effectuer toutes les communications vers l'extérieur sans que la sécurité de ces communications soit considérablement renforcée. Au contraire, le serveur monétique, étant le seul muni des données relatives au moyen de paiement et servant uniquement pour le paiement, peut être configuré pour être moins accessible depuis l'extérieur et sécurisé de façon adaptée pour mettre en échec toute tentative de piratage. Cela permet de sécuriser les données de paiement sans que cela ne ralentisse le service dédié à l'utilisateur.
Le procédé selon l'invention peut comprendre pour chaque paiement réalisé pour le compte d'un utilisateur auquel est associé un identifiant, les étapes suivantes : - détermination, notamment par le serveur de gestion, de l'alias du moyen de paiement associé à l'utilisateur en fonction dudit identifiant de l'utilisateur,
- détermination, notamment par le serveur monétique, des données relatives au moyen de paiement associé audit alias, et
- émission, notamment par le serveur monétique, d'une demande de paiement ou de pré-autorisation avec lesdites données relatives audit moyen de paiement
Avantageusement, le procédé selon l'invention peut comprendre après au moins une demande de pré-autorisation ou une demande de paiement, notamment après chaque demande de paiement (initiale ou ultérieure), une émission de données d'avertissement de paiement vers un appareil de communication dudit utilisateur au travers d'un réseau de communication.
Ainsi, l'utilisateur est averti du paiement réalisé.
Les données d'avertissement sont notamment présentées sous la forme d'un ticket virtuel, qui comprend toutes les informations habituellement visibles sur un ticket imprimé par un terminal de paiement suite à une transaction de type paiement de proximité ou par automate.
Selon un premier mode de réalisation, une demande de paiement ultérieure peut être émise à chaque nouvelle consommation, notamment chaque nouvelle identification, par l'utilisateur. Il y aura ainsi autant de demandes de paiement ultérieures que d'opérations d'achat ou de location de biens ou de service
Dans un autre mode de réalisation particulièrement avantageux, une demande de paiement ultérieure peut être émise lorsque :
- un compte client associé à l'utilisateur atteint un montant maximum prédéterminé, ledit procédé comprenant une étape de consultation dudit compte à chaque nouvelle consommation, notamment identification, ou à une fréquence donnée, et/ou
- la précédente demande de paiement a été effectuée depuis une durée maximale prédéterminée, ledit procédé comprenant en outre une consultation de la date de ladite dernière demande de paiement, une telle demande de paiement précédente pouvant être la demande de paiement initiale ou une précédente demande de paiement ultérieure.
Ainsi, le procédé selon l'invention permet de limiter le nombre de demandes de paiement et ainsi de diminuer le nombre de transactions bancaires. Le procédé selon l'invention permet également de sécuriser les transactions en diminuant les occasions de fraude.
Dans ce cas, le procédé selon l'invention permet d'incrémenter un compte associé à un utilisateur au fur et à mesure que l'utilisateur réalise des achats/locations, jusqu'à atteindre le montant maximal prédéterminé ou la durée maximale prédéterminée.
A chaque demande de paiement ultérieur, le compte client de l'utilisateur est remis à zéro.
Avantageusement, le procédé selon l'invention peut en outre comprendre une étape de consultation d'une donnée, dite de statut de paiement, avant une nouvelle demande d'utilisation du service, notamment identification, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement.
De préférence, l'étape de consultation est effectuée uniquement après que la demande de paiement initiale ait eu lieu.
Le procédé selon l'invention peut notamment comprendre une mise à jour de la donnée de statut de paiement :
- par consultation des données relatives au moyen de paiement, par exemple la date de validité du moyen de paiement ; et/ou - par consultation des caractéristiques d'un compte bancaire associé au moyen de paiement.
Une telle mise à jour peut être réalisée de façon régulière, par exemple tous les jours ou sur requête d'une consultation de la donnée de statut, à savoir avant chaque nouvelle utilisation du service.
Le procédé selon l'invention peut également comprendre une mise à jour de la donnée de statut de paiement, après une demande de paiement, la donnée de statut de paiement étant modifiée ou non en fonction de l'issue de ladite demande de paiement.
Le procédé selon l'invention permet, grâce à une telle donnée de statut de paiement, d'éviter d'autoriser l'accès de l'utilisateur au service lorsque le statut de paiement de l'utilisateur porteur du moyen de paiement ne le permet pas, par exemple parce que le moyen de paiement n'est plus valide, ou que la dernière demande de paiement a été refusée, que le moyen de paiement fait l'objet d'une opposition, que le compte associé au moyen de paiement est bloqué, ou encore parce que l'utilisateur n'a pas assez d'argent sur son compte de telle sorte qu'une nouvelle demande de paiement serait refusée.
Selon l'invention, le format de données utilisé lors de la demande de paiement initiale peut être différent du format de données utilisé pour réaliser une demande de paiement ultérieure.
Le format de données utilisé dans une demande de paiement ultérieure comprendre des données différentes du format de données utilisé lors de la demande de paiement initiale. Une telle demande de paiement ultérieure ne comprend par exemple pas de donnée de pré-autorisation.
Le procédé selon l'invention peut être avantageusement utilisé pour le paiement de services de locations, avec ou sans abonnement, de véhicules et plus particulièrement de véhicules électriques proposés à la location sur un ou plusieurs sites de location, chaque site de location étant relié à un site central de gestion coordonnant les différentes étapes du procédé.
Selon un autre aspect de l'invention, il est proposé un système de paiement pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à l'utilisateur, ledit système comprenant :
- des moyens d'identification d'un utilisateur - un terminal de lecture de données relatives audit moyen de paiement depuis ledit moyen de paiement, et
- des moyens de mémorisation desdites données relatives au moyen de paiement, pour stocker ces données en association avec au moins une donnée de l'utilisateur ;
ledit système comprenant en outre des moyens, dits de paiement, agencés pour émettre :
- une demande de paiement, dite initiale, selon un premier protocole de paiement, et
- une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement différent du premier protocole de paiement.
Les moyens d'identification peuvent avantageusement comprendre un lecteur RFID pour lire une carte d'identification RFID, un lecteur optique pour lire un identifiant à code barre, un lecteur d'un moyen d'identification biométrique ou autre.
Ces moyens d'identification sont agencés pour lire un identifiant associé à un utilisateur depuis un moyen d'identification, de type RFID par exemple, lors de d'achats/locations initiales ou ultérieurs.
Le terminal de lecture de données relatives au moyen de paiement peut être un terminal de paiement.
Selon un mode de réalisation préféré mais nullement limitatif du système selon l'invention, les moyens de paiement peuvent comprendre :
- un premier serveur, dit de gestion, notamment lié au service, comprenant des moyens pour :
- générer un alias du moyen de paiement,
- mémoriser ledit alias avec un identifiant de l'utilisateur, - un deuxième serveur, dit monétique, comprenant des moyens pour :
- mémoriser ledit alias du moyen de paiement avec les données relatives audit moyen de paiement, - émettre des demandes de paiement en fonction desdites données relatives audit moyen de paiement, la demande de paiement initiale comprenant en outre au moins une donnée de pré-autorisation.
Les différents serveurs peuvent être en communication avec le terminal de paiement et entre eux pour échanger des données.
Le système selon l'invention peut en outre comprendre des moyens de codage et de décodage des données échangées entre les différents organes du système de sorte à sécuriser ces données.
La communication entre les différents organes peut être partiellement ou totalement filaire ou sans fil, au travers d'un réseau de communication de type Internet ou GPRS. Selon un autre mode de réalisation, tous les serveurs peuvent être remplacés pour un serveur unique agencé pour réaliser les demandes de paiement initiales et ultérieures.
Selon encore un autre aspect de l'invention il est proposé une installation de location de véhicule comprenant :
- un site de gestion, dit central,
- au moins un site de location de véhicule comprenant au moins un véhicule proposé à la location, ledit site de location étant connecté audit site central, et
- un système de paiement selon l'invention.
Le terminal de lecture peut être disposé sur le site de location. Avantageusement, chaque site de location peut en outre comporter un moyen d'identification et un terminal de lecture.
Les moyens de paiement peuvent être disposés au niveau du site de gestion central. Dans le cas où, les moyens de paiement comprennent un serveur de gestion et un serveur monétique, le serveur de gestion peut être disposé au niveau du site de gestion central et le serveur monétique peut être disposé au niveau d'une banque de l'opérateur du service de location ou encore au niveau d'un autre site, dit monétique.
D'autres avantages et caractéristiques apparaîtront à l'examen de la description détaillée de modes de réalisation nullement limitatifs, et des dessins annexés sur lesquels :
- la FIGURE 1 est une représentation schématique d'un système selon l'invention et des échanges entre les différents éléments du système ;
- la FIGURE 2 est une représentation schématique des étapes d'une première version d'un procédé selon l'invention appliqué à la location de véhicules ;
- la FIGURE 3 est une représentation schématique d'une version simplifiée d'un procédé selon l'invention ;
- la FIGURE 4 est une représentation sous la forme d'un diagramme des étapes de déclenchement des demandes de paiement ; et
- la FIGURE 5 est une représentation schématique d'une installation de location de véhicule mettant en œuvre un système selon l'invention. Sur les figures et dans la suite de la description, les éléments communs à plusieurs figures conservent la même référence.
Dans les exemples décrits ci-dessous le moyen de paiement est avantageusement, mais non limitativement, une carte bancaire.
On notera que, dans la suite, les termes « autorisation » et « préautorisation » peuvent être utilisés indifféremment, ainsi que les termes « demande de débit » et « demande de paiement » », ou « adresse numérique » et « adresse électronique ». La FIGURE 1 est une représentation schématique d'un système selon l'invention.
Le système 100 représenté sur la figure 1 comprend une borne 102, dite d'abonnement, comprenant des moyens d'identification, par exemple un lecteur de carte RFID. La borne d'abonnement peut comprendre d'autres moyens d'identification, notamment des moyens de saisie d'un code personnel.
Le système 100 comprend en outre un terminal de paiement 104 pour lire les données relatives à un moyen de paiement, tel qu'un lecteur de carte bancaire.
Le système 100 comprend également un serveur de gestion 106 et un serveur monétique 108. Le serveur de gestion 106 comprend des moyens de mémorisation d'une base de données 110, et le serveur monétique comprend également une base de données 112 mémorisée localement dans des moyens de mémorisation.
Le serveur monétique 108 est en communication avec le terminal de paiement par l'intermédiaire d'un premier serveur intermédiaire 114 gérant le terminal de paiement.
Le serveur de gestion 106 est en communication avec le serveur monétique 108 par l'intermédiaire d'un deuxième serveur intermédiaire 116, dit « cashpooler » dans le mode de réalisation ici décrit.
Le système 100 comprend en outre un module de communication 118 comprenant une carte SIM de connexion au réseau GPRS et agencé pour envoyer des données de compte-rendu ou un ticket virtuel relatives à l'issue de chaque demande de paiement. Ce module de communication 118 est directement relié au serveur monétique 108. On notera que, dans d'autres modes de réalisation, ce serveur pourrait être relié au serveur de gestion. On décrira un tel mode de réalisation plus loin.
Le système 100 est agencé et programmé pour réaliser une demande de paiement initiale selon un protocole de paiement de pré-autorisation et des demandes de paiement ultérieures selon un protocole de paiement de type vente à distance. On considère que les deux demandes de paiement sont effectuées selon des protocoles distincts car elles ne comprennent pas exactement les mêmes informations et/ou que les informations ne sont pas présentées de la même façon.
Les échanges d'informations entre les différents organes du système en vue de réaliser la demande de paiement initiale sont indiqués ci-dessous et sont représentés sur la figure 1 avec des flèches pleines, chaque flèche indiquant le sens de l'échange d'information. La procédure de paiement à l'aide de la demande initiale est initiée par le serveur de gestion 106 sous l'égide d'un téléconseiller, lors par exemple d'une procédure d'abonnement au service de location de véhicule.
Elle comprend les étapes suivantes :
- PA1 : Emission d'une requête de pré-autorisation avec montant et un alias de carte utilisateur (UID) de 12 caractères alphanumériques du serveur central 106 à la borne d'abonnement 102,
PA2 : Transmission de la requête au terminal de paiement 104 avec éventuel ajout des paramètres nécessaires. L'UID est ajouté et aligné,
- PA3 : Transmission de la requête au premier serveur intermédiaire 114,
- PA4 : Transmission de la requête au serveur monétique 108. L'UID est transmis au format ISO 8583. Le serveur monétique émet la demande de pré-autorisation de paiement vers la banque du porteur du moyen de paiement et reçoit la réponse de la banque suite à la demande de préautorisation. Eventuellement le serveur monétique 108 génère un ticket virtuel relatif à la demande d'autorisation de débit à envoyer à l'utilisateur ;
- PA5 : Réponse au premier serveur intermédiaire 114 du serveur monétique 108 en ce qui concerne la requête,
- PA6 : Transmission, par le premier serveur intermédiaire 114, de la réponse au terminal de paiement 104. Le dossier se voit assigner par ce serveur un identifiant unique sur 12 caractères. Il s'agit là d'une donnée de pré-autorisation ou une donnée d'erreur ou de refus. Lors de cette étape le résultat de la demande d'autorisation peut également être affiché sur un écran d'affichage au niveau du terminal de paiement 104 ;
- PA7 : La donnée est transmise à la borne de location 102 ;
- PA8 : La donnée est transmise au serveur de gestion 106 (retour d'erreur, ou identifiant (ID) de pré-autorisation), Eventuellement, lorsqu'un ticket virtuel est généré par le serveur monétique 108 suite à la réception de la réponse de la banque porteur, les étapes suivantes peuvent être réalisées :
- PA9 : le serveur de gestion 106 envoie au serveur monétique l'adresse virtuelle de l'utilisateur, soit directement tel que représenté sur la figure 1, soit par l'intermédiaire du serveur intermédiaire 114 ;
- PA10 : le serveur monétique transfère le ticket virtuel et l'adresse monétique de l'utilisateur au module de communication :
- PAU : le ticket virtuel est envoyé par le module de communication 118 à l'utilisateur, par exemple sous la forme d'un message texte, au travers d'un réseau de communication 120, par exemple de type GPRS.
La donnée de pré-autorisation est ensuite utilisée pour réaliser une demande de paiement, dite initiale, initiée par le serveur de gestion au moment voulu, selon les opérations suivantes :
- PP1 : Requête de paiement envoyée au premier serveur intermédiaire 114 en utilisant l'identifiant de préautorisation et l'alias UID,
- PP2 : La requête est relayée au serveur monétique 108. Le serveur monétique 108 génère et envoie la demande de paiement à la banque du porteur du moyen de paiement et reçoit une réponse en retour. Cette demande comprend, suite à l'intervention du serveur monétique, les données relatives au moyen de paiement. Le serveur monétique 108 génère alors un ticket virtuel récapitulant le résultat de la demande de débit ;
- PP3 : La réponse reçue est relayée par le serveur monétique 108 au premier serveur intermédiaire 114, et
- PP4 : La réponse est relayée par le premier serveur intermédiaire 114 au serveur de gestion 106 ;
- PP5 : Le serveur de gestion 106 transmet une adresse électronique de l'utilisateur au serveur monétique 108, soit directement telle que représenté sur la figure 1, soit par l'intermédiaire du premier serveur intermédiaire 114 ;
- PP6 : le serveur monétique 108 transmet le ticket virtuel généré et l'adresse numérique au module de communication 118 ; et
- PP7 : Le module de communication 118 envoie le ticket virtuel à l'adresse numérique au travers du réseau de communication 120. Les échanges d'informations entre les différents organes du système en vue de réaliser la demande de paiement ultérieure sont indiqués ci- dessous et sont représentés sur la figure 1 avec des flèches en pointillés, chaque flèche indiquant le sens de l'échange d'information. La demande de paiement ultérieure est initiée par le serveur de gestion 106 en fonction de critères de test prédéterminés qui seront décrits plus loin et comprend les étapes suivantes :
- VD1 : Requête de paiement envoyée par le serveur de
gestion 106 sur le deuxième serveur intermédiaire 116 (UID et montant)
- VD2 : La requête est envoyée au serveur monétique 108, qui génère une demande de paiement ultérieure comprenant les données du moyen de paiement. Le serveur monétique reçoit la réponse de la banque concernant la demande d'autorisation de débit. Le serveur monétique 108 génère un ticket virtuel à envoyer à l'utilisateur ;
- VD3 : La réponse de la banque est transmise par le serveur monétique 108 au deuxième serveur intermédiaire 116, et - VD4 : La réponse est relayée par le deuxième serveur
intermédiaire 116 au serveur de gestion 106 ;
- VD5 : Le serveur de gestion 106 transmet une adresse électronique de l'utilisateur au serveur monétique 108, soit directement tel que représenté sur la figure 1, soit par l'intermédiaire du deuxième serveur intermédiaire 116 ;
- VD6 : le serveur monétique 108 transmet le ticket virtuel généré et l'adresse numérique au module de communication 118 ; et
- VD7 : Le module de communication 118 envoie le ticket virtuel à l'adresse numérique au travers du réseau de communication 120.
Les étapes de transfert d'argent entre les banques ne sont pas décrites ici.
Dans ce mode de réalisation, il existe un serveur intermédiaire entre le terminal de paiement et le serveur monétique et un autre serveur intermédiaire, appelé « Cashpooler », entre le serveur de gestion et le serveur monétique. Ces serveurs sont représentés dans le schéma par exemple car les services de paiement sont effectués par différents prestataires. Toutefois, le serveur monétique pourrait être directement relié au terminal de paiement et au serveur de gestion de location sans présence de ces serveurs intermédiaires, ou en présence d'un unique serveur intermédiaire.
Par ailleurs, dans un autre mode de réalisation le serveur monétique et le serveur de gestion peuvent être intégrés dans un serveur unique, auquel cas les échanges d'informations entre ces serveurs ne sont pas réalisés. Ce mode de réalisation nécessite toutefois une sécurisation lourde du serveur de gestion, peu pratique.
En outre, le système 100 comprend un module de communication pour émettre des tickets virtuels. Cependant, dans la présente invention ce module de communication est optionnel.
Dans un mode de réalisation très simplifié, le système 100 comprend le terminal de lecture 104 relié à un serveur unique, qui peut être appelé, serveur de paiement, et un moyen de mémorisation. Tous les autres organes décrits plus haut en référence à la figure 1 sont optionnels et peuvent être ajoutés individuellement à un tel système simplifié.
La FIGURE 2 est une représentation sous la forme d'un diagramme d'un premier mode de réalisation d'un procédé selon l'invention, mis en œuvre dans un système dans lequel il n'y a pas de serveurs intermédiaires. Le procédé 200 représenté à la figure 2 montre une première demande de paiement (dite initiale) selon un protocole de paiement de proximité de type pré-autorisation, et une deuxième demande de paiement (dite ultérieure) de type vente-à-distance.
Le procédé 200 représenté sur la figure 2 comprend tout d'abord une phase d'initialisation 202.
La phase d'initialisation 202 comprend une étape 204 pendant laquelle l'utilisateur indique son identité et des informations personnelles, par exemple en scannant un papier d'identité qui peut par exemple être son permis de conduire. Pendant cette étape l'utilisateur indique également une adresse électronique à laquelle doivent être envoyées les données de compte-rendu ou le ticket virtuel.
Cette étape 204 est réalisée au niveau d'une borne d'abonnement à un service donné, tel qu'un service de location de véhicules, ou encore une caisse quelconque. Cette borne est bien évidemment reliée au serveur de gestion par l'intermédiaire d'un réseau, par exemple un réseau de type Internet. A l'étape 206 ces données sont transmises à un serveur de gestion, par exemple le serveur de gestion 106 de la figure 1.
Une fois ces formalités effectuées, le serveur de gestion mémorise un identifiant associé à l'utilisateur à l'étape 208 et mémorise également l'adresse électronique, et éventuellement les données d'identité fournies à l'étape 204. L'identifiant relatif à l'utilisateur peut être généré au niveau du serveur de gestion ou de la borne d'abonnement.
A l'étape 210, un moyen d'identification est fourni à l'utilisateur par la borne, tel que par exemple une carte RFID. On notera que le moyen d'identification reçu par l'utilisateur peut être d'un autre type que celui décrit (un code personnel, un code barre, une carte magnétique, etc.)
Lorsque l'utilisateur dispose déjà d'un identifiant et a déjà préalablement renseigné une adresse électronique, les étapes 202 à 210 ne sont pas réalisées et sont remplacées par une étape (non représentée) de lecture de l'identifiant de l'utilisateur.
Dans ce mode de réalisation, les étapes 202 à 210 constituent en tout cas les étapes d'identification de l'utilisateur. A l'étape 212, l'utilisateur choisit un abonnement auquel qu'il désire souscrire.
Le choix de l'abonnement est transmis au serveur de gestion à l'étape
214.
Le serveur de gestion génère alors un alias de moyen de paiement et l'enregistre en association avec l'identifiant à l'étape 216.
A l'étape 218, le serveur transmet l'alias à la borne, en association avec d'autres données de paiement, comprenant notamment le montant à prélever.
A l'étape 220, l'alias et les données liées au paiement sont transmis au terminal. Celui-ci dispose alors de tous les éléments pour initier la transaction.
A l'étape 222, l'utilisateur insère un moyen de paiement dans le terminal. Les données relatives au moyen de paiement sont lues de façon classique, l'utilisateur saisit son code confidentiel pour vérifier qu'il est un porteur autorisé de la carte (code PIN). Les interactions de l'utilisateur avec le terminal de paiement sont des interactions classiques. Si le code PIN est erroné, la carte est bloquée et la transaction est refusée et l'utilisateur en est informé. Si le code PIN est correct, le terminal de paiement extrait les données de la carte permettant d'effectuer le paiement (identifiant de la carte et date d'expiration notamment). Ces données peuvent éventuellement comprendre une adresse électronique enregistrée dans le moyen de paiement. Dans ce cas, il n'est pas nécessaire pour l'utilisateur de renseigner une adresse électronique lors de l'étape 202, cette adresse étant extraite des données lues depuis le moyen de paiement, envoyée au serveur de gestion et enregistrée au niveau au niveau de ce serveur.
L'alias et les données relatives au moyen de paiement sont alors transmis au serveur monétique lors de l'étape 224.
A l'étape 226, le serveur monétique enregistre l'alias en association avec les données relatives au moyen de paiement.
A l'étape 228, le serveur monétique émet une demande d'autorisation de débit auprès de la banque de l'utilisateur, à l'aide des données du moyen de paiement et des autres données liées au paiement transmises par le terminal et obtient la réponse de la banque. Suite à la réception de la réponse, le serveur monétique génère un accusé de réception et un ticket virtuel.
L'accusé de réception peut comprendre soit une donnée d'acceptation, sous la forme d'une donnée de pré-autorisation, soit un refus. Le ticket virtuel est généré en fonction du contenu de la réponse de la banque de l'utilisateur.
L'accusé de réception est transmis avec l'alias du moyen de paiement et le ticket virtuel au terminal de paiement à l'étape 230, qui peut éventuellement renseigner visuellement l'utilisateur sur l'issue de la demande de débit.
A l'étape 232, le terminal de paiement transmet l'accusé de réception, l'alias du moyen de paiement et le ticket virtuel au serveur de gestion par l'intermédiaire de la borne de paiement. Le serveur de gestion mémorise l'accusé de réception à l'étape 234 en association avec l'identifiant de l'utilisateur.
A l'étape 236, le serveur de gestion extrait l'adresse électronique de l'utilisateur de sa base de données.
Le serveur de gestion transmet le ticket virtuel à l'utilisateur à l'étape
238, éventuellement à l'aide d'un module de communication.
Les étapes 202 à 238 constituent la phase d'initialisation 202 du procédé 200. Suite à cette phase d'initialisation, qui ne dure que quelques dizaines de secondes, l'utilisateur peut retirer sa carte du terminal de paiement.
Puis, le serveur de gestion teste à une fréquence donnée si le compte de l'utilisateur doit être débité ou non (tel qu'il sera décrit plus loin).
Dès que le serveur détermine que le compte de l'utilisateur doit réellement être débité et le montant qui doit être débité, les étapes suivantes sont réalisées.
Il s'agit de la phase 240 de première demande de paiement, au demande de paiement initiale.
Le serveur de gestion envoie au serveur monétique la donnée de pré- autorisation et l'alias à l'étape 242.
A l'étape 244, le serveur monétique émet une demande de débit auprès de la banque de l'utilisateur à l'aide de la donnée de pré-autorisation et des données de moyen de paiement extraites de sa base de données et obtenues grâce à l'alias transmis par le serveur de gestion, et obtient la réponse de la banque. Suite à la réception de la réponse, le serveur monétique génère un accusé de réception et un ticket virtuel. La réponse à ce niveau ne peut être que positive puisque l'autorisation de débit a déjà été obtenue.
A l'étape 246, le serveur monétique transmet l'accusé de réception et le ticket virtuel au serveur de gestion qui le mémorise.
Comme décrit auparavant, le serveur de gestion transmet le ticket virtuel à l'utilisateur à l'étape 248, éventuellement à l'aide d'un module de communication, en indiquant le montant exact du débit, qui peut être différent du montant pour lequel une autorisation de débit avait été obtenue.
La phase 240 de demande de paiement initiale selon un premier protocole de paiement de type pré-autorisation est alors terminée.
Le procédé 200 comprend alors une ou plusieurs phases 250 de demande de paiement ultérieure selon un deuxième protocole de paiement de type vente à distance.
Dans ce cas, le serveur de gestion teste à une fréquence donnée si une demande de paiement doit être effectuée tel que nous le verrons plus loin.
Dès qu'une demande de paiement est à effectuer les étapes suivantes sont réalisées.
Le serveur de gestion envoie au serveur monétique les informations relatives au paiement, à savoir par exemple le montant à débiter, l'alias du moyen de paiement, à l'étape 252.
A l'étape 254, le serveur monétique émet une demande de paiement auprès de la banque de l'utilisateur, à l'aide des données de moyen de paiement extraites de sa base de données et obtenues grâce à l'alias transmis par le serveur de gestion. La demande de paiement ultérieure ne comprend pas la donnée de pré-autorisation puisqu'elle n'est pas effectuée en rapport avec une telle pré-autorisation. En fonction de la réponse obtenue, le serveur monétique génère un accusé de réception et un ticket virtuel. La réponse à ce niveau peut être positive ou négative.
A l'étape 256, le serveur monétique transmet l'accusé de réception et le ticket virtuel au serveur de gestion qui le mémorise.
Le serveur de gestion transmet le ticket virtuel à l'utilisateur à l'étape 258, éventuellement à l'aide d'un module de communication.
La phase 250 de demande de paiement ultérieure selon un deuxième protocole de type vente à distance est alors terminée.
Le ticket virtuel envoyé à l'utilisateur comprend des données relatives au résultat de la demande d'autorisation de débit ou la demande de débit, à savoir : - des données d'acceptation ou de refus d'une demande d'autorisation de débit d'un montant majoré, ou
- des données d'acceptation ou de refus d'une demande de transaction réelle, c'est-à-dire une demande débit, pour un montant réellement débité sur compte du client.
Dans un mode de réalisation simplifié, le procédé 200 peut ne pas comprendre l'envoi de tickets virtuels, dans ce cas les étapes relatives à l'adresse numérique et à l'envoi d'un tel ticket ne sont pas réalisées. De plus, un unique serveur peut être utilisé en tant que serveur monétique et serveur de gestion. Dans ce cas, le procédé 200 ne comprend pas toutes les étapes décrites plus haut consistant à la génération d'un alias et à la transmission de données, directement ou indirectement, entre le serveur de gestion et le serveur monétique.
La FIGURE 3 est une représentation schématique sous la forme d'un diagramme d'une version simplifiée d'un procédé selon l'invention.
Dans ce mode de réalisation le système comprend un terminal de paiement, un unique serveur, dit de paiement et des moyens de mémorisation.
Le procédé 300 comprend une phase d'initialisation 302 comprenant les étapes suivantes :
- étape 304 : insertion moyen de paiement dans le terminal de lecture ;
- étape 306 : lecture et transmission au serveur de paiement des données relatives au moyen de paiement ;
On pourrait envisager que l'insertion du moyen de paiement et la lecture de ces données constituent une étape d'identification de l'utilisateur. Toutefois, il est également possible que le procédé comprenne une étape préalable d'identification supplémentaire. En effet, les données de la carte peuvent être suffisantes pour identifier un utilisateur mais elles ont leur limite puisqu'elles ne sont valables que durant un période prédéterminée. - étape 308 : mémorisation des données relatives au moyen de paiement au niveau du serveur de paiement.
- étape 310 : une émission d'une demande de pré-autorisation de débit vers un serveur de la banque de l'utilisateur avec les données relatives au moyen de paiement ;
- étape 312 : réception d'une donnée de pré-autorisation de débit valable pour un montant maximum et pour une durée maximum et mémorisation de cette donnée. Puis, le serveur de paiement teste à une fréquence donnée si le compte de l'utilisateur doit être débité ou non (tel qu'il sera décrit plus loin).
Dès que le serveur détermine que le compte de l'utilisateur doit réellement être débité et le montant qui doit être débité, les étapes suivantes sont réalisées.
II s'agit de la phase 314 de première demande de paiement, ou demande de paiement initiale, comprenant les étapes suivantes :
- étape 316 : émission, vers la banque de l'utilisateur, d'une demande de paiement avec la donnée d'autorisation de débit et les informations de paiement, à savoir par exemple le montant exact du débit :
- étape 318 : réception d'un accusé de réception émis par la banque de l'utilisateur et mémorisation de l'accusé de réception.
La phase 314 de première demande de paiement est alors terminée.
Le serveur de paiement teste à une fréquence donnée si le compte de l'utilisateur doit être débité ou non (tel qu'il sera décrit plus loin).
Dès que le serveur détermine que le compte de l'utilisateur doit réellement être débité et le montant qui doit être débité, les étapes suivantes sont réalisées.
Le procédé 300 comprend ensuite une ou plusieurs phases 320 de demande de paiement réalisées selon un protocole de paiement de type vente à distance et comprenant les étapes suivantes : - étape 322 : émission, vers la banque de l'utilisateur, d'une demande de paiement avec les données relatives au moyen de paiement et les informations de paiement, telle que par exemple le montant exact du débit ;
- étape 324 : réception accusé de réception émis par la banque de l'utilisateur et mémorisation.
La FIGURE 4 est une représentation schématique sous la forme d'un organigramme des étapes de déclenchement des demandes de paiement.
Dans la figure 4 le sigle SG désigne le serveur de gestion 106 et le sigle SM désigne le serveur monétique 108 de la figure 1.
Dans le mode de réalisation décrit en référence à la figure 4, le procédé émet une première demande de paiement selon un protocole de paiement pré-autorisation et au moins une deuxième demande de paiement selon un protocole de paiement de type vente à distance.
Une première étape 402 permet de déterminer si une demande de paiement initiale a été générée.
Si non, une étape de test 404 est réitérée tous les soirs. Lors de cette étape 304 le serveur de gestion vérifie les critères suivants :
- que la durée de validité de l'autorisation est sur le point d'expirer (dans moins de 24 heures) : cette information sur la durée de validité est obtenue grâce à une donnée de validité de la préautorisation ;
- que le montant de compte dédié à l'utilisateur dépasse le montant maximal autorisé par l'autorisation ; cette information sur le montant maximum est obtenue grâce à une donnée de montant de la pré-autorisation , Si ces tests renvoient une réponse négative, aucune demande de paiement initiale n'est générée.
En revanche, si un ou plusieurs des tests renvoient une réponse positive, le serveur génère une première requête de paiement à l'étape 406. Pour cela, il envoie au serveur monétique, éventuellement à l'aide d'un serveur intermédiaire, de préférence également relié au terminal de paiement, un fichier contenant notamment l'identifiant de pré-autorisation préalablement obtenue, l'alias et l'adresse numérique. Le fichier comprend également le montant demandé, ce montant étant forcément inférieur ou égal au montant maximum indiqué dans l'autorisation.
Le serveur monétique génère ensuite, lors de l'étape 408, une demande de paiement, dite initiale, comprenant l'identifiant de préautorisation et des données relatives au moyen de paiement extraites de sa base de données à partir de l'alias et l'envoie à un serveur de la banque du porteur de la carte bancaire. Elle est envoyée au serveur de la banque du porteur de la carte bancaire dans un premier format prédéterminé.
Le serveur de la banque du porteur de la carte bancaire renvoie ensuite un accusé de réception au serveur monétique, qui le transmet au serveur de gestion à l'étape 410.
Le serveur de la banque du porteur commande le transfert du montant correspondant depuis le compte bancaire de l'utilisateur associé à la carte jusqu'au compte bancaire associé au service de location. Un compte-rendu est également envoyé au serveur de gestion par l'intermédiaire du serveur monétique.
A l'étape 412, le serveur monétique envoie un ticket virtuel à l'utilisateur.
Suite à la première demande de paiement, le serveur de gestion efface l'identifiant d'autorisation ou indique qu'il n'est plus valide. Il conserve en revanche l'alias de carte.
Si après l'étape 402, une première demande de paiement est déjà réalisée, le serveur de gestion de location vérifie également journalièrement les critères suivants à l'étape 414 :
- durée depuis le dernier paiement supérieure à une durée
prédéterminée ?
- montant du compte dédié à l'utilisateur supérieur à un montant prédéterminé ? Si ces tests renvoient une réponse négative, aucune requête de paiement n'est générée et l'étape 414 est réitérée journalièrement jusqu'à ce qu'au moins un de ces critères renvoie une réponse positive.
Si un ou plusieurs des tests renvoient une réponse positive, le serveur génère une seconde requête à l'étape 316. On notera qu'une seconde requête est également générée quasi-simultanément à la première requête, permettant l'obtention du paiement initial lorsque le montant du compte dédié à l'utilisateur dépasse le montant maximal autorisé dans l'autorisation et qu'aucun paiement n'a été effectué auparavant. Dans ce cas, la première demande de paiement générée par le serveur monétique est à hauteur du montant maximum autorisé par la pré-autorisation de débit et la deuxième demande de paiement est effectuée pour le montant restant du compte, qui n'aura pas été payé par la première demande de paiement. Pour générer la seconde requête, le serveur de gestion envoie, à l'étape 416, au serveur monétique, éventuellement à l'aide d'un serveur intermédiaire, qui peut être différent du serveur intermédiaire déjà évoqué en relation avec la première requête, un fichier contenant notamment l'alias de carte. Le fichier comprend également le montant demandé, mais ne comprend pas l'identifiant d'autorisation puisque ce dernier a été effacé après la première demande de débit.
Le serveur monétique génère une demande de paiement à partir des données associées à l'alias extraites de sa base de données et envoie la demande de paiement à un serveur de la banque du porteur de la carte bancaire à l'étape 418. La demande de paiement est envoyée au serveur de la banque du porteur de la carte bancaire dans un deuxième format prédéterminé, généralement distinct du premier format.
Le serveur de la banque du porteur de carte vérifie alors certaines données relatives à la carte à l'étape 420 : son existence, sa validité - date d'expiration postérieure, pas d'opposition -. Si la transaction est acceptée, le serveur de la banque du porteur renvoie ensuite, à l'étape 422, un accusé de réception au serveur monétique qui le transmet au serveur de gestion de location. Un ticket virtuel comprenant le résultat de la transaction est envoyé à l'utilisateur à l'étape 424.
Le serveur de la banque du porteur commande en outre le transfert du montant correspondant depuis le compte bancaire de l'utilisateur associé à la carte vers le compte bancaire associé au service de location. Un compte-rendu est également envoyé au serveur de gestion par l'intermédiaire du serveur monétique. Si ce transfert n'est pas possible, par exemple car le porteur n'a pas assez d'argent sur son compte ou car la carte de paiement est considérée comme non valable, le transfert est annulé, et le serveur monétique en est informé, à l'étape 426, ainsi que le serveur de gestion par son intermédiaire.
Dans ce cas, le serveur de la banque renvoie au serveur monétique, qui transmet au serveur de gestion un message d'erreur. A réception d'un tel message d'erreur, le serveur de gestion peut modifier, lors d'une étape 428, une donnée relative à l'utilisateur, notamment à l'alias de carte, par exemple une donnée de statut de paiement, indiquant que l'utilisateur n'est plus en mesure de payer avec sa carte.
Un ticket virtuel est également envoyé à l'utilisateur à l'étape 430 indiquant le résultat de la transaction.
La donnée de statut de paiement, ainsi par exemple qu'une donnée d'expiration de la carte, transmise du serveur monétique au serveur de gestion peut être vérifiée avant toute demande de location/achat ultérieur de l'utilisateur. Ainsi, on peut empêcher l'utilisateur de louer un véhicule sans qu'il ait honoré tous ses paiements précédents.
Lorsque l'utilisateur remet une carte de paiement dans le terminal de paiement pour effectuer à nouveau la séquence d'initialisation, un nouvel alias de carte peut être généré qui remplace l'autre. On notera que de nombreuses étapes sont optionnelles à savoir par exemple toutes les étapes relatives à la génération d'un alias et à l'émission d'un ticket virtuel. II est également possible que les différents fichiers transmis par le serveur de gestion soient du même format. Mais les informations contenues dans ces fichiers ne seront pas les mêmes et elles ne déclencheront pas les mêmes opérations au niveau des échanges entre le serveur monétique et le serveur de la banque du porteur de la carte de paiement. C'est pour cela qu'on considère que les demandes de paiement ne sont pas effectuées à l'aide du même protocole.
Il est également possible que les serveurs monétiques et de gestion soient confondus, l'existence de l'alias de carte n'étant alors pas nécessaire.
Le déclenchement de l'émission des demandes de débit peut également être effectué de façon différente de ce qui a été déterminé (par exemple à une date précise du mois, tous les mois).
En variante, à chaque identification de l'utilisateur, on émet une demande de paiement, en ayant préférablement vérifié si le montant du compte de l'utilisateur était supérieur à un montant prédéterminé (0€).
La FIGURE 5 est une représentation schématique d'une installation de location automatisée de véhicules électriques mettant en œuvre un système selon l'invention.
L'installation 500 représenté sur la figure 1 comprend un site central 502 (également appelé organe central dans la suite de la description) connecté à plusieurs sites - ou stations - 504i-504n, dits de location au travers d'un réseau de communication 506 sans fil, par exemple GPRS, ou d'un réseau filaire, par exemple de type DSL. De préférence, chaque station 504 est reliée au site central 502 par l'intermédiaire de deux réseaux distincts, ce qui permet une connexion en continu même si l'un des réseaux est défaillant. Chaque station de location 504 comprend une borne d'abonnement 102 pour l'enregistrement d'un nouvel abonné, une borne de location 510 pour la location d'un véhicule et plusieurs bornes de charge 512-516, chaque borne de charge étant prévue pour charger un véhicule muni d'une batterie électrique à un emplacement de stationnement.
Le site central 502 peut être connecté directement à chacune des bornes d'une station de location 504 au travers du réseau 506 ou seulement à la borne d'abonnement et/ou à la borne de location et/ou aux bornes de charge 512-516.
Au moins deux bornes d'une station de location 504 sont connectées entre elles au travers d'une connexion filaire (non représentée). Le site central 502 comprend le serveur de gestion 106, le serveur monétique 108 ainsi que les moyens de mémorisation 110 et 112 dans lesquels sont mémorisées les différentes données décrites plus haut en référence à la figure 1. Le site central comprend en outre le module communication 118.
Certains sites de location 504 comprennent une borne d'abonnement équipée d'un terminal de paiement 104. Chaque borne d'abonnement comprend des moyens (non représentés) pour lire un identifiant d'un utilisateur ainsi que des moyens (non représentés) pour recevoir et transmettre au site central des données d'identité d'un utilisateur.
Sur cette figure les serveurs intermédiaires ne sont pas représentés, ces serveurs intermédiaires étant optionnels.
Bien entendu l'invention n'est pas limitée aux exemples qui viennent d'être décrits.

Claims

REVENDICATIONS
1. Procédé (200 ; 300) pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à un utilisateur, ledit procédé comprenant :
- une première phase (202 ; 302), dite d'initialisation, comprenant les étapes suivantes :
- identification d'un utilisateur par un lecteur,
- lecture (224 ; 306), par un terminal de paiement ( 104), de données relatives audit moyen de paiement depuis ledit moyen de paiement, et
- mémorisation (226 ; 308) desdites données relatives au moyen de paiement en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur, dans un serveur distant du lecteur; et
- une phase, dite de paiement, comprenant les étapes suivantes :
- émission (240 ; 314) d'une demande de paiement, dite initiale, selon un premier protocole de paiement nécessitant la présence dudit moyen de paiement dans le terminal de paiement, et
- émission (250 ; 320) d'au moins une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement, différent dudit premier protocole de paiement, et ne nécessitant pas la présence dudit moyen de paiement dans un terminal de paiement ;
chacune desdites étapes d'émission comprenant une émission de données relatives audit moyen de paiement vers un serveur bancaire distant.
2. Procédé (200,300) selon la revendication 1, caractérisé en ce que l'utilisateur s'identifie à chaque fois qu'il souhaite utiliser le service, l'utilisation de ce service étant facturée sur un compte associé à au moins une donnée de l'utilisateur, les demandes de paiement étant chacune effectuées en fonction du montant du compte de l'utilisateur.
3. Procédé (200 ; 300) selon l'une quelconque des revendications précédentes, caractérisé en ce que la phase d'initialisation comprend l'obtention d'une pré-autorisation de débit comprenant au moins une donnée de pré-autorisation, la demande de paiement initiale comprenant la donnée de pré-autorisation.
4. Procédé (200,300) selon la revendication 3, dans lequel suite à la réception de la pré-autorisation, on stocke :
- une donnée de montant, définissant un montant maximal de validité de la pré-autorisation, et/ou
- une donnée de validité, définissant une durée de validité ou une date d'expiration de la pré-autorisation, et/ou
- une donnée de fin de contrat, relative à une date de fin de contrat de service,
la demande de paiement initiale étant émise dans l'un où l'autre des cas suivants :
- lorsque l'on détermine, à l'aide de la donnée de validité, que la durée restante jusqu'à la date d'expiration de la pré-autorisation est inférieure à une durée prédéterminée, et/ou
- lorsque l'on détermine, à l'aide de la donnée de montant, que la différence entre le montant maximal et le montant du compte de l'utilisateur est inférieure à un montant prédéterminé, et/ou lorsque l'on détermine, à l'aide de la donnée de fin de contrat, que la durée restante jusqu'à la date de fin de contrat est inférieure à une durée prédéterminée.
5. Procédé (200 ; 300) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape (216) de génération d'un alias du moyen de paiement, de préférence avant l'étape de lecture des données relatives au moyen de paiement.
6. Procédé (200 ; 300) selon la revendication 5, caractérisé en ce qu'il comprend en outre : - une étape (216) de mémorisation dudit alias en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur, dans un serveur de gestion notamment lié au service proposé ; et
- une étape (226) de mémorisation dudit alias en association avec les données relatives au moyen de paiement, dans un serveur monétique distinct du serveur de gestion,.
7. Procédé (200 ; 300) selon la revendication 6, caractérisé en ce qu'il comprend, pour chaque demande paiement pour un utilisateur auquel est associé un identifiant, les étapes suivantes :
- détermination par le serveur de gestion de l'alias du moyen de paiement associé à l'utilisateur en fonction dudit identifiant de l'utilisateur,
- détermination par le serveur monétique des données relatives au moyen de paiement associé audit alias, et
- émission, par le serveur monétique, d'une demande de paiement avec lesdites données relatives audit moyen de paiement.
8. Procédé (200) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, après au moins une demande de préautorisation ou une demande de paiement, une émission (238, 248, 258) de données d'avertissement de paiement, par exemple d'un ticket virtuel, vers un appareil de communication dudit utilisateur au travers d'un réseau de communication.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une demande de paiement ultérieure est émise à chaque nouvelle consommation par l'utilisateur, notamment à chaque nouvelle identification de l'utilisateur.
10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une demande de paiement ultérieure est émise lorsque : - un compte associé à l'utilisateur atteint un montant maximum prédéterminé, ledit procédé comprenant en outre une étape de consultation dudit compte à chaque nouvelle consommation, notamment identification, ou à une fréquence donnée, et/ou - la précédente demande de paiement a été effectuée depuis une durée maximale prédéterminée, ledit procédé comprenant en outre une consultation de la date de ladite dernière demande de paiement.
11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape de consultation d'une donnée, dite de statut de paiement, avant une nouvelle demande d'utilisation du service, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement.
12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le format de données utilisé lors de la demande de paiement initiale est différent du format de données utilisé pour réaliser une demande de paiement ultérieure.
13. Application du procédé selon l'une quelconque des revendications précédentes à un service consistant en la location avec ou sans abonnement de véhicules proposés à la location sur un ou plusieurs sites de location (404), chaque site de location (404) étant relié à un site central de gestion (402).
14. Système (100) de paiement pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à l'utilisateur ledit système comprenant :
- des moyens d'identification d'un utilisateur
- un terminal (104) de lecture de donnes relatives audit moyen de paiement depuis ledit moyen de paiement, et - un serveur comprenant des moyens de mémorisation (112) desdites données relatives au moyen de paiement, en association avec au moins une donnée de l'utilisateur ; et
ledit système (100) comprenant en outre des moyens (106,108), dits de paiement, agencés pour émettre vers un serveur bancaire distant :
- une demande de paiement, dite initiale, selon un premier protocole de paiement nécessitant la présence physique dudit moyen de paiement dans ledit terminal de paiement, et
- une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement, différent du premier protocole de paiement, ne nécessitant pas la présence physique dudit moyen de paiement dans un terminal de paiement.
15. Système (100) de paiement selon la revendication 14, caractérisé en ce que les moyens de paiement comprennent :
- un premier serveur (106), dit de gestion, comprenant des moyens pour :
- générer un alias du moyen de paiement,
- mémoriser ledit alias avec un identifiant de l'utilisateur,
- un deuxième serveur (108), dit monétique, comprenant des moyens pour :
- mémoriser ledit alias du moyen de paiement avec les données relatives audit moyen de paiement,
- émettre des demandes de paiement en fonction desdites données relatives audit moyen de paiement, la demande de paiement initiale comprenant en outre au moins une donnée de pré-autorisation.
16. Installation (400) de location de véhicule comprenant :
- un site (402) de gestion, dit central, - au moins un site (404) de location de véhicule comprenant au moins un véhicule proposé à la location, ledit site (404) de location étant connecté audit site (402) central, et
- un système de paiement selon l'une quelconque des revendications 14 ou 15.
PCT/FR2012/052170 2011-09-30 2012-09-27 Procede et systeme de paiement, application a la location automatisee de vehicules WO2013045831A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1158782 2011-09-30
FR1158782A FR2980890B1 (fr) 2011-09-30 2011-09-30 Procede et systeme de paiement, application a la location automatisee de vehicules.

Publications (1)

Publication Number Publication Date
WO2013045831A1 true WO2013045831A1 (fr) 2013-04-04

Family

ID=47221443

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052170 WO2013045831A1 (fr) 2011-09-30 2012-09-27 Procede et systeme de paiement, application a la location automatisee de vehicules

Country Status (2)

Country Link
FR (1) FR2980890B1 (fr)
WO (1) WO2013045831A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107103456A (zh) * 2013-08-02 2017-08-29 东芝泰格有限公司 信息处理装置及电子票据系统
WO2022241116A1 (fr) * 2021-05-12 2022-11-17 Fortune Vieyra Système et procédé pour un marché de services professionnels

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715399A (en) * 1995-03-30 1998-02-03 Amazon.Com, Inc. Secure method and system for communicating a list of credit card numbers over a non-secure network
FR2806229A1 (fr) * 2000-03-13 2001-09-14 Mathieu Schnee Procede d'interaction ou de transaction entre un utilisateur et un fournisseur de produits ou de services et systeme pour la mise en oeuvre de ce procede
US20020091646A1 (en) * 2000-11-03 2002-07-11 Lake Lawrence L. Method and system for verifying the identity of on-line credit card purchasers through a proxy transaction
US20020133462A1 (en) * 2001-03-16 2002-09-19 Koninklijke Philips Electronics N.V. Instant electronic notification of credit card use serves as deterrent
US20030233334A1 (en) * 2002-06-14 2003-12-18 Smith Michael S. Methods and apparatus for facilitating a transaction
FR2863089A1 (fr) 2003-12-01 2005-06-03 Jcdecaux Sa Procede et systeme de location automatique d'articles.

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715399A (en) * 1995-03-30 1998-02-03 Amazon.Com, Inc. Secure method and system for communicating a list of credit card numbers over a non-secure network
FR2806229A1 (fr) * 2000-03-13 2001-09-14 Mathieu Schnee Procede d'interaction ou de transaction entre un utilisateur et un fournisseur de produits ou de services et systeme pour la mise en oeuvre de ce procede
US20020091646A1 (en) * 2000-11-03 2002-07-11 Lake Lawrence L. Method and system for verifying the identity of on-line credit card purchasers through a proxy transaction
US20020133462A1 (en) * 2001-03-16 2002-09-19 Koninklijke Philips Electronics N.V. Instant electronic notification of credit card use serves as deterrent
US20030233334A1 (en) * 2002-06-14 2003-12-18 Smith Michael S. Methods and apparatus for facilitating a transaction
FR2863089A1 (fr) 2003-12-01 2005-06-03 Jcdecaux Sa Procede et systeme de location automatique d'articles.

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107103456A (zh) * 2013-08-02 2017-08-29 东芝泰格有限公司 信息处理装置及电子票据系统
WO2022241116A1 (fr) * 2021-05-12 2022-11-17 Fortune Vieyra Système et procédé pour un marché de services professionnels
US20220366459A1 (en) * 2021-05-12 2022-11-17 Fortune Vieyra System and method for a professional services marketplace

Also Published As

Publication number Publication date
FR2980890A1 (fr) 2013-04-05
FR2980890B1 (fr) 2020-04-24

Similar Documents

Publication Publication Date Title
WO2013045832A1 (fr) Procede et systeme de signalisation de paiement, application a la location automatisee de vehicules
WO2006010800A1 (fr) Procede et systeme de paiement electronique universel
WO2016020021A1 (fr) Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule
WO2005073931A2 (fr) Dispositif transactionnel a pre-traitement anticipe
WO2001043092A1 (fr) Procede et systeme de gestion d'une transaction securisee a travers un reseau de communication
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
WO2013050496A1 (fr) Procede de paiement d'un produit ou d'un service sur un site marchand par l'intermediaire d'une connexion internet et terminal correspondant
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
WO2013045831A1 (fr) Procede et systeme de paiement, application a la location automatisee de vehicules
WO2005052869A1 (fr) Procede et systeme de paiement electronique de biens ou services distribues par un automate avec conciliation asynchrone
CA2323002A1 (fr) Systeme de telephonie mobile avec carte de prepaiement
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
FR2823882A1 (fr) Procede et systeme de validation de paiement
WO2009077380A1 (fr) Procede pour communiquer, depuis un terminal de transaction, a un serveur, terminal, serveur et systeme electroniques correspondants
EP2800072A2 (fr) Procédé de délivrance par un automate de cartes de téléphonie mobile SIM à abonnement prépayé ou postpayé
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
WO2013045833A1 (fr) Procede et systeme de paiement de consommations repetees dans le temps et application a la location de vehicules
FR2815439A1 (fr) Procede pour effectuer une transaction commerciale sur reseau
EP4359986A1 (fr) Procédé et dispositif de paiement par chaînes de blocs
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants
WO2002075674A2 (fr) Systeme et methode de renouvellement de donnees d'identification sur un dispositif de transaction portatif
FR2750275A1 (fr) Procede de gestion dans un systeme telematique distribue et systeme de mise en oeuvre de ce procede
FR2858441A1 (fr) Systeme et procede de paiement electronique
FR2808144A1 (fr) Procede et systeme de paiement electronique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12790582

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12790582

Country of ref document: EP

Kind code of ref document: A1