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
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable devices
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
  • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/327—Short range or proximity payments by means of M-devices
  • G06Q20/3278—RFID or NFC payments by means of M-devices
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
  • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
• • 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/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
• • 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/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3821—Electronic credentials
  • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
• • 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/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
• • 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/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
• • 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
  • G06Q2220/00—Business processing using cryptography
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

• the invention relates to payment via user devices.
• the invention relates more particularly to the payment using a user device which comprises means for the implementation of a payment via a digital wallet (also called electronic wallet), which is least partially associated with the user device.
• a user device may be in the form of a mobile terminal.
• the first form uses a specific application of the terminal that contains banking data, an application that uses so-called "contactless" data transmission capabilities to physically connect to a merchant's payment terminal and perform a payment transaction (it this is an alternative to the introduction of a payment card in a payment terminal, with sub without the use of a PIN).
• the second form uses an identifier associated with the mobile terminal of the user. This identifier is used by the owner of the mobile terminal, together with a PIN, to validate the transaction on the payment terminal of the merchant (this is again an alternative to the introduction of a payment card in the merchant's terminal). These payment types are used to replace the payment card to physically make purchases.
• a payment service provider to which the user of the mobile terminal entrusted banking data, is responsible for making the payment on behalf of the user of the terminal.
• This payment service provider is often different from the banking establishment where the user is a customer.
• the user has a digital wallet ("Wallet"), which is installed on his computer. terminal (or within a dedicated payment card).
• Wallet digital wallet
• the merchant has on his terminal, an application associated with the payment service provider to validate the payment.
• This type of payment through a payment service provider, is also made "contactless", using a technology called "N FC”.
• Payment service providers that offer e-wallets each have a particular data processing architecture. It is therefore necessary that the payment terminal (for example of the NFC type) of the merchant also has a particular application adapted to each payment service provider.
• the architecture of "Google TM Wallet” is not the same as the architecture of "Paypal TM" Wallet.
• PayPal TM stores customer data on a cloud.
• One of the problems encountered relates to the management of payment terminal parks. Indeed, when a payment service provider decides to change the way the payment is managed through his digital wallet, the payment terminal manufacturer has the obligation to modify the application that is used. for this provider in all the terminals of the park. Another problem encountered is the obligation to insure a transaction in a given time.
• PayPal TM the numerous exchanges that occur at the network level (the cloud) require, in order to be able to carry out the transaction in a given time, to have efficient communication networks capable of transmitting and receive information quickly. This increases the costs of management of digital portfolios at the merchant, without the latter having an opportunity to pass on this cost. In other words, a portion of the processing cost of this type of payment must be borne by the merchant.
• the present technique solves at least in part the aforementioned problems. More particularly, the present technique relates to a method of processing a transaction, within a server, called intermediate server.
• the method comprises:
• a server which can be described as intermediate server or proxy server, to which the payment terminal transmits a standardized request, which includes at least some of the data necessary for the implementation of the transaction . It is therefore no longer necessary to have, within the payment terminal, a plurality of applications each adapted to a particular payment service provider.
• the optional character of the specific parameters varies depending on the requirements of the transactional server.
• said method further comprises a step of decrypting the processing request using a private key specific to said server.
• the request is first encrypted by the payment terminal before being transmitted to the intermediate server.
• said step of implementation, by the server, of a payment transaction from data of said processing request comprises: a step of identification in a database, of a type digital wallet associated with a user of a terminal, using said digital wallet identifier transmitted by the payment terminal;
• the intermediate server acts vis-à-vis the transactional server as if it were a payment terminal.
• the transaction is carried out normally, without modification of the procedures.
• said step of implementing, by the server, a payment transaction from data of said processing request further comprises:
• said at least one complementary data belongs to the group comprising:
• the present technique also relates to a transactional payment data processing server from a digital wallet.
• Such a processing server of a transaction comprises:
• the present technique also relates to a payment terminal capable of managing payments using data provided by a digital wallet.
• the digital wallet can for example be materialized by a smartphone, which includes, depending on the architectures, all or part of the data needed to implement the digital wallet.
• the smartphone can also be replaced by any other device to fulfill the above functions, and in particular to implement a digital portfolio, such as a smart watch (“SmartWtach”) or a pair of smart glasses (“SmartGlass”), a contactless card (which in this case acts passively) or a QR code card in one or two dimensions.
• the technique also relates to a method for obtaining transactional data, within a payment terminal.
• This method comprises the following steps, after a step of obtaining a transaction amount:
• the proposed technique also relates to a device for obtaining transactional data, installed within a payment terminal.
• Such a device comprises:
• the various steps of the methods according to the described technique are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the technique. described and being designed to control the execution of the different process steps.
• the technique described also relates to a program that can be executed by a computer or by a data processor, this program comprising instructions for controlling the execution of the steps of a method as mentioned above.
• This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
• the described technique also aims at a data carrier readable by a data processor, and including instructions of a program as mentioned above.
• the information carrier may be any entity or device capable of storing the program.
• the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
• the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
• the program according to the technique described can be in particular downloaded on an Internet type network.
• the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
• the technique described is implemented by means of software and / or hardware components.
• module may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
• a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned.
• Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is able to access the hardware resources of this entity physical (memories, recording media, communication buses, electronic I / O boards, user interfaces, etc.).
• a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc.
• FIG. 1 is a sequence diagram describing the proposed technique
• Figure 2 is a sequence diagram describing the implementation of the transaction from the intermediate server
• Fig. 3 is a sequence diagram illustrating a second embodiment of the proposed technique
• Figure 4 schematically illustrates the technical architecture of an intermediate server
• Figure 5 schematically illustrates the technical architecture of a payment terminal.
• the general principle of the described technique consists in a way of abstracting the payment terminal from the payment chain when implementing a payment via a digital wallet, while retaining the benefits of its presence (for example to obtain additional data, for the securing the transaction or simply to reassure the trader and his customers).
• the merchant who is ultimately the natural person on whom the most constraints regarding the use of electronic wallets (since he must accept all the existing portfolios)
• it is important that the payment provided by the banking organization with which he works is not the weak link in the payment chain.
• the solution to this problem is to ensure that the payment terminal is not in charge of managing multiple applications to allow payment via a digital wallet. This also provides a clear advantage for the merchant: the merchant has no obligation to sign contracts with all payment service providers.
• an intermediary server which replaces the payment terminal, acts as a "meta-walker" vis-à-vis the payment service providers, thus simplifying the task of the merchant who has only one contract to sign with the manager of the "meta-marchant” to accept all types of digital portfolios managed by this manager.
• a so-called generic application is implemented within the payment terminal.
• This generic application is able to obtain and process specific data.
• This generic application includes means for obtaining at least two data: a digital wallet identifier (payment service provider's service identification code, which makes it possible to know to which payment service provider it is necessary to address to process the transaction) and a user identifier (these two data are for example transmitted by the user device, which may be a smartphone, a contactless card, a card based on Q code).
• the digital wallet identifier can also be selected by the merchant on the payment terminal from a list of payment service providers available via the payment terminal (this list is for example transmitted by an intermediary server periodically).
• the service identification code is specific to the payment service provider whose digital wallet is used. This code is not standardized.
• the mobile terminal comprises means for searching for this code among the data transmitted by the payment application.
• the identifier of the user, for its part, is not standardized either. However, it is transmitted during the initiation of the payment transaction.
• these two data are transmitted by the payment terminal to an intermediate server, which is located within a communication network, and which processes the transmitted data.
• the processing carried out by the intermediate server is mainly as follows: identification of the type of digital wallet used, construction, from the identified digital wallet type, of a treatment request including the user's identifier.
• the user's identifier is formatted according to the expectations of a transactional server of the payment service provider.
• the processing request is then transmitted to the transactional server, by the intermediate server, using a dedicated application.
• the transactional server upon receipt of the processing request, processes the transaction (ie whether or not it accepts payment for the user) in conjunction with the dedicated application of the intermediary server.
• the intermediate server can either request additional data from the payment terminal (such as the amount of the transaction), or require additional information from the user device (when it has the capabilities to do so). This additional information passes through the payment terminal, which then acts as a bridge between the user device and the intermediate server.
• the process for managing a purchase transaction of one or more goods or services in a shop of a physical merchant using a user terminal (TU) is described.
• the terminal in question (TU) is a smart phone, called a smartphone.
• An initial process, which takes place at the payment terminal level, includes:
• This initialization is intended to allow the user terminal to transmit the data required for payment. It can be done automatically or by an action of the merchant on the terminal, in a complementary manner, to facilitate the handling by the payment terminal of the data transmitted by the user terminal, the merchant can advantageously select, among a list of payment service providers, the payment service provider that the user wishes to use. In this case, advantageously, the terminal has a list of payment service providers, which is updated centrally and is transmitted regularly by an intermediate server to the various payment terminals.
• IPN digital wallet identifier
• PN UI digital wallet user (or user account) identifier
• an optional step of verifying (50) a match between a value representative of a security code (such as a PIN code) entered by the user on said payment terminal (TP) and a value representative of a payment code security present within the terminal of the user (TU) (this makes it possible to verify that the user is indeed the owner of the terminal which he wishes to use to make the payment).
• This representative value may be a hash of the PIN code or a signature of it.
• a password or a fingerprint can act as a security code.
• an encapsulation step (60), within a processing request, said digital portfolio identifier, said user identifier and at least one data representative of a transaction amount.
• the representative value of the PIN can also be encapsulated in the processing request.
• the processing request is encrypted by a public key / private key mechanism: a public key of the intermediate server (IS) is used to encrypt the processing request before it is transmitted. This has the advantage of reducing the risks of interception and modification of the contents of the processing requests.
• These key public / private key pairs are temporary key pairs. A temporary public key of the intermediate server is transmitted regularly or as needed to the payment terminal to reduce the risk of compromise.
• an analysis step (200) of said processing request delivering the previously inserted data: identifier of the digital wallet, user identifier and optionally transaction amount and signature of the security code.
• ST transactional server
• the optional nature of this specific data varies depending on the requirements of the transactional server (ST).
• This finalization step may consist in the display, on said terminal, of the finalization data and the transmission of this finalization data for example to a cash register for accounting of the transaction.
• the transaction is conducted from the intermediate server (SI).
• This is somehow perceived as the payment terminal (TP) by the transactional server (ST).
• the intermediate server (SI) can:
• This choice can be considered as a design choice. In fact, it answers a specific problem: depending on the number of types of transactional servers to address, the management of a general code to address all types of transactional servers can be complex. On the other hand, it is also conceivable that payment service providers provide their own application (AppT) s. Thus, the solution of loading and executing an application (AppT) adapted to the transactional server may be a more durable solution.
• AppT application
• additional data is provided either by the payment terminal (TP) (in this case, these data are integrated into the request (qT) transmitted by the payment terminal (TP)), either directly by the intermediate server (SI).
• these additional data there is notably a location of the payment terminal (TP).
• the transactional server (ST) may want to ensure that the payment terminal (TP) and the terminal of the user (TU) are in identical geographical areas.
• the transactional server (ST) can use the IP address of the payment terminal (TP) to obtain a location (or other data allowing a location, such as GPS data or data connection to a relay antenna type GSM). Therefore, in at least one embodiment of the proposed technique, a data representative of the IP address is used as the location data of the payment terminal (TP).
• the intermediate server emulates the payment terminal (TP) behavior.
• TP payment terminal
• the intermediate server (SI) can obtain these parameters (PrS) directly from the identified payment service provider.
• the database comprises at least one network address (for example a URI) making it possible to access these parameters.
• TP payment terminal
• data necessary for the transaction to proceed address, payment method, payment card used - when the digital wallet includes several payment cards, or the number account to use.
• the transaction is managed in two stages. This embodiment is described in relation with FIG. 3. The steps are common with the first embodiment and are therefore not repeated in this description. Their order is changed. These steps carry the same numbers as in FIG. 1.
• the intermediate server (SI) performs the transaction directly (it takes the place of the transactional server (ST) - step 300X).
• the intermediate server (SI) validates the transaction (the merchant is credited with the amount corresponding to the purchase of goods and the user of the terminal is debited the same amount). This validation is performed using a database that is used to count the transactions supported by the intermediate server. For the merchant and for the customer, the payment transaction is complete.
• This embodiment has the advantage of not requiring a too long processing time and is suitable for environments in which the data transmission rates per network (whether a wired network or a wireless network) are limited.
• the intermediate server (SI) performs the transaction (steps 300 and 400) with the transactional server (ST) of the payment service provider. To do this, he uses the application (AppT) adapted to this provider to make the payment. The same data and the same messages are exchanged as in the case of the first embodiment. Thus the intermediate server (SI) recovers the amount credited to the merchant. 5.5. Other features and benefits
• a simplified architecture of an intermediate server (SI) capable of implementing the described technique is presented.
• a server comprises a memory 41, a processing unit 42 equipped for example with a microprocessor, and driven by the computer program 43, implementing at least part of the method as described.
• the technique described is implemented in the form of a software application.
• the described technique is implemented in a purely hardware form, using processors and interfaces specially created for this purpose.
• Such a server includes:
• means for analyzing said processing request delivering the previously inserted data digital wallet identifier, user identifier and optionally transaction amount and security code signature.
• ST transactional server
• the technique described can be implemented via a communication network to which the server is connected.
• the described technique is implemented in a plurality of intermediate servers, for example distributed within a grid area.
• the server is associated with a database.
• This database includes, in addition to the information needed to identify and execute transactions with the transactional servers, merchant data.
• Such data stored securely in the database, allow, for example from payment terminal identifier, to obtain the data necessary for the completion of the transaction for the benefit of the merchant.
• This "merchant" data is for example the following: the merchant's name, physical address, bank domiciliation, etc.
• a simplified architecture of a payment terminal capable of implementing the described technique is presented.
• a terminal comprises a memory 51, a processing unit 52 equipped for example with a microprocessor, and driven by the computer program 53, implementing at least a part of the method as described.
• the technique described is implemented in the form of a software application.
• the described technique is implemented in a purely hardware form, using processors and interfaces specially created for this purpose.
• Such a terminal comprises:
• means for receiving data from a user terminal may for example consist of a processor in a contactless antenna.
• means for obtaining a service identification code and a user identifier may be implemented by a terminal processor which, from the data received by the user's terminal, structuring these data according to several possible structuring schemes; these means can also be implemented based on an entry made by the merchant after questioning the client on the type of digital wallet he wants to use.
• the terminal also comprises other means for exchanging with the intermediate server and for receiving from it temporary encryption keys to perform data exchange confidentially.

Applications Claiming Priority (2)

Publications (1)

Family

ID=50069020

Family Applications (1)

Country Status (5)

Families Citing this family (8)

Citations (3)

Family Cites Families (8)

• 2013
  • 2013-08-29 FR FR1358276A patent/FR3010215B1/fr active Active
• 2014
  • 2014-08-26 EP EP14761809.4A patent/EP3039628A2/de not_active Ceased
  • 2014-08-26 WO PCT/EP2014/068017 patent/WO2015028435A2/fr active Application Filing
  • 2014-08-26 CA CA2921193A patent/CA2921193A1/en not_active Abandoned
  • 2014-08-26 US US14/915,539 patent/US20160210617A1/en not_active Abandoned

Patent Citations (3)

Also Published As

Similar Documents

Legal Events