WO2012141588A1 - Ensemble et procédé de gestion de transactions - Google Patents

Ensemble et procédé de gestion de transactions Download PDF

Info

Publication number
WO2012141588A1
WO2012141588A1 PCT/NL2012/050248 NL2012050248W WO2012141588A1 WO 2012141588 A1 WO2012141588 A1 WO 2012141588A1 NL 2012050248 W NL2012050248 W NL 2012050248W WO 2012141588 A1 WO2012141588 A1 WO 2012141588A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
transaction
transaction order
merchant
pms
Prior art date
Application number
PCT/NL2012/050248
Other languages
English (en)
Inventor
Eugène Raymond TEN CATE
Original Assignee
Sepasoft B.V.
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 Sepasoft B.V. filed Critical Sepasoft B.V.
Publication of WO2012141588A1 publication Critical patent/WO2012141588A1/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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • 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/04—Billing or invoicing

Definitions

  • the present invention relates to an assembly for handling transactions between at least one merchant and at least one consumer.
  • the invention also relates to the payment management system of said assembly and to a method for handling such transactions.
  • POS Point of Sale
  • POS Point of Sale
  • POS Point of Sale
  • a transaction order processor which controls the electronic clearing and settlement of the transaction amount with the relevant banks.
  • these systems are regionally oriented; each country has for instance its own transaction order processor and many of the banks involved are only
  • FIG. 1 Shown schematically in figure 1 is a typical setup of such a system.
  • the system is set up per region.
  • the example shows only three regions (Rl, R2 and R3) , but this number can of course vary.
  • the payment terminal disposed in the shop allows payments to be made according to one or more specific card schemes or card protocols.
  • the terminal can optionally be coupled
  • the payment terminal 4 When the consumer 1 authorizes a payment, for instance by allowing his/her payment card to be read and entering a personal identification number (PIN) via a keyboard on the payment terminal, the payment terminal 4 generates an electronic transaction order.
  • the payment terminal forwards the transaction order via a secure connection 9 to a so-called transaction order processor 5, also referred to here as the processor.
  • This processor is in turn connected via secure connections 10 and 11 to a payment system.
  • the payment system comprises an issuer bank 6 and an acquirer bank 7.
  • the transaction order now ensures that the transaction amount is debited from the account of the consumer at the issuer bank 6 and is credited
  • the transaction order processor 5 more specifically the server handling the electronic transactions with the affiliated banks, and the payment system (i.e. the banks) normally operate in a limited geographical area.
  • transaction order processor 5 and the merchants in this limited geographical area are obliged to work with payment terminals which have a one on one relation with said
  • the processor 5 of the one area makes contact via a communication connection 39 with a processor 5' in the other area and the handling of the transaction is provided by two (of more) processors 5 and 5' .
  • the merchant therefore have any freedom of choice in respect of the processor of the second area (R2) . This lack of freedom of choice is often not advantageous for the merchant for competitive reasons.
  • an assembly for handling transactions between at least one merchant and at least one consumer comprising:
  • a transaction order processor connected to the payment system for electronic clearing and settlement of the transaction amount associated with the transaction order, wherein the transaction order processor is adapted to receive and process an electronic transaction order and to control the payment system for transfer of the transaction amount associated with the transaction order generated by the payment terminal;
  • the assembly comprises a group of transaction order processors, wherein each of the transaction order processors is connected to a payment system and wherein a payment management system (PMS) is arranged between the payment terminal and the transaction order processors which is adapted to select one transaction order processor from the group of transaction order processors and to control the associated payment system with the selected transaction order processor.
  • PMS payment management system
  • the system is flexible such that the payment terminals are no longer required to communicate with a single prescribed transaction order processor (usually operating in only a limited geographical area) . It has now become possible, from the viewpoint of the payment terminal, to choose and select a desired transaction order processor from a number of transaction order processors. This makes it possible for instance for the merchant to negotiate with a number of transaction order processors in order to opt for the commercially most advantageous processor.
  • Transaction order processors often only operate regionally, for instance per country. For interregional payment transfers the transaction order processor which has received a transaction order for interregional payment has heretofore made contact with another transaction order processor. Together they control the payment system or systems. According to embodiments of the invention, it is however possible for the merchant (or the consumer)
  • transactions continues to be performed by a transaction order processor itself.
  • the usually secret identification data and identification protocols can thus remain within the domain of the transaction order processor (for instance a card issuer) .
  • the transaction order processor is adapted to perform
  • the payment management system can for instance be linked as virtual payment terminal to a
  • the usual authentication steps for instance checking identification data such as the PAN and PIN data of a card, are performed by the transaction order processor itself, optionally supplemented by an authentication by the payment terminal. In determined embodiments the payment management system does not perform authentication of these identification data (e.g. PIN and PAN data) .
  • the transaction order processor subsequently sends an authentication signal to the payment management system which is representative of the approval or rejection of the transaction .
  • a further drawback of the existing systems in which the payment terminals are linked per region to a regional transaction order processor is that the payment terminals of different regions, in any case payment
  • the payment management system can however ensure that the different types of payment terminal are
  • the payment management system can form a virtual payment terminal.
  • a transaction order processor can be connected via the communication connection to a virtual payment terminal in the form of the payment management system.
  • the transaction order processor thinks there is a connection to the physical payment terminal and does not in principle need to notice that there is in reality only a connection to the payment management system. This means that in determined embodiments there is no hardware and/or software modification of the transaction order processors required at all, or at least hardly any.
  • a payment system can be made up of at least one issuer bank subsystem which manages the bank account of the consumer and an acquirer bank subsystem which manages the bank account of the merchant.
  • the transaction order can be made up of at least one issuer bank subsystem which manages the bank account of the consumer and an acquirer bank subsystem which manages the bank account of the merchant.
  • the processor is adapted here to control both subsystems for the purpose of transferring an amount of money from the issuer bank subsystem to the acquirer bank subsystem.
  • the payment management system can be adapted to select one of the payment systems. This can for instance be realized by selecting one of the transaction order processors which are linked to the
  • a free bank choice can in principle hereby be realized.
  • the payment terminal is adapted to generate and send information concerning the transaction order processor to be selected and/or concerning the payment system to be selected.
  • This information can for instance be formed by an application identifier (ApID) .
  • An application identifier is
  • the application identifier also determines the acquirer identifier (AID) of the acquiring bank which is going to perform the transaction.
  • AID acquirer identifier
  • the payment management system can further be adapted to receive this information and, on the basis of the received information, to select the transaction order processor which must control the payment system and/or the payment system which must perform the transaction.
  • PMS payment management system
  • information can be generated on the payment terminal which influences or even determines the selection of the transaction order processor.
  • the one or more payment terminals are each provided with a read unit for reading first identification data, which are stored on an electronic input carrier and which are representative of the bank account of the consumer.
  • identification data can for instance be formed by the primary account number (PAN) of the relevant input carrier (e.g. a payment card).
  • PAN primary account number
  • the one or more payment terminals are each provided with an input unit for entry by the consumer of second identification data representative of the identity of the consumer.
  • the second identification data can for instance be formed by the "personal identif cation number" (PIN) of the consumer.
  • the input carrier can be a payment card, more particularly a debit card or a credit card.
  • a payment card more particularly a debit card or a credit card.
  • the input carrier is a loyalty card or a smart card of a mobile telephone. This latter example can relate to a SIM card with EMV functionality.
  • EMV is an acronym for EuroPay MasterCard and Visa which refers to the
  • EMV relates particularly to the data and the protocol (standard) employed which provides for a relatively high level of data security.
  • the electronic transaction order comprises:
  • the payment terminal is preferably adapted to encrypt at least one (but still more preferably all) of the first, second, third and fourth transaction data.
  • the encryption is performed before sending to the payment management system (PMS) and/or before storing thereof on the payment terminal or on the PMS.
  • the payment management system (PMS) comprises a storage medium, on which is stored at least:
  • TID unique master terminal identifiers
  • MID unique master merchant identifiers
  • the payment management system comprises a storage medium on which is stored at least:
  • each of the slave terminal identifiers being associated with a different transaction order
  • identifiers have a different configuration, for instance according to a differing protocol.
  • the slave identifiers are configured (according to a suitable
  • slave MIDs unique slave merchant identifiers
  • master MID unique master merchant identifier
  • the payment management system is adapted to select a slave TID from the list of slave TIDs and/or to select a slave MID from the list of slave MIDs.
  • the payment terminal can be an automated teller machine (ATM) or a Point of Sale (POS) terminal which is optionally connected to a cash register, in particular an Electronic Cash Register (ECR) .
  • ATM automated teller machine
  • POS Point of Sale
  • ECR Electronic Cash Register
  • PMS payment management system
  • a menu can thus be presented on the cash register of the desired payment methods from which the merchant and consumer may choose.
  • the information stored on an input carrier can be read in different ways depending on the type of input carrier.
  • an input carrier such as (but not limited to) the PAN
  • the information can be read using a reader (i.e. a magnetic strip reader MSR) specially embodied for this purpose.
  • a reader i.e. a magnetic strip reader MSR
  • EMV in accordance with ISO/IEC 7816 standard
  • EMV in accordance with ISO/IEC 7816 standard
  • the examples relate to readers for which a lesser or greater extent of contact is required between the card and the reader.
  • the reading can take place in wholly contactless manner.
  • the input carrier is for instance provided with optical marks such as a bar code
  • the information can be read via an optical reader, in particular a bar code reader.
  • the system comprises a wireless receiver for reading a smart card via a wireless connection.
  • a standard for contactless cards is formed for instance by ISO/IEC 14443. Use can for instance be made of a mobile telephone smart card, more particularly an EMV SIM card.
  • the system comprises:
  • a first payment terminal adapted to generate an electronic transaction order according to a first protocol which can only be handled by a first transaction order processor;
  • a second payment terminal adapted to generate an electronic transaction order according to a second protocol which can only be handled by a second transaction order processor, wherein the second protocol differs from the first protocol;
  • the payment management system is adapted to receive a transaction order according to the first protocol and to have the second transaction order processor (or the first) handle the transaction and/or to receive the
  • the transaction orders can in principle be processed by a random processor.
  • the payment management system comprises a storage medium and the system is adapted to store a transaction certificate (TC) for each of the performed transactions, wherein the
  • transaction certificate comprises merchant-specific
  • This merchant-specific information can for instance comprise an invoice reference (number) , a specification (text) , an order number, an official report and the like.
  • the merchant- specific information can now be linked directly to actually performed past transactions.
  • the merchant for instance via a so-called merchant portal
  • the payment management system PMS
  • the stored data can at least comprise one of the following data:
  • the financial management of the merchant and the monitoring thereof can hereby be greatly simplified.
  • the TID is stored in combination with a
  • a method for handling transactions between at least one merchant and at least one consumer comprising of:
  • Figure 2 shows a schematic overview of a first embodiment of a system according to the invention
  • FIG. 3 shows a more detailed overview of the embodiment of figure 2;
  • Figure 4 shows schematically the information stored on the storage medium of the payment management system
  • Figure 5 shows a schematic overview of a second embodiment of a system according to the invention.
  • Figure 6 shows a schematic overview of a third embodiment of a system according to the invention.
  • Figure 7 shows a more detailed diagram of the payment management system according to an embodiment of the invention .
  • FIG. 2 and 3 show two payment systems.
  • the first payment system 40 is located in the first region or the first area (Rl)
  • the second payment system 40' is located in the second area (R2) .
  • Each of the payment systems comprises a number of servers with which the banks connected to the payment system can perform their mutual payments.
  • the first payment system 40 comprises a server 6 of an issuer bank, i.e. the bank at which the consumer holds an account, and a server 7 of an acquirer bank, i.e. the bank where the merchant holds his/her account.
  • the servers are mutually linked via one or more communication networks.
  • the payment systems are connected via respective secure connections 10,11 to a first transaction order processor, also referred to in the field as the processor 18.
  • This processor is adapted to control servers 6,7 of the payment system 11, i.e. to perform the required transactions.
  • processor 18 is connected via a secure connection 17 to a payment management system 16.
  • the payment management system is also referred to here as the P S system, PMS server or simply PMS.
  • the payment management system is embodied such that it can control the above mentioned payment systems to perform a determined transaction. It is noted here that the payment in the payment management system stands for a transaction representing a determined value, of a financial or non-financial nature.
  • Payment management system 16 is further connected with a secure connection 15 to one or more payment terminals 12.
  • a transaction order processor or processor 21 is provided in usual manner for the purpose of handling
  • payment management server 16 is also connected via a secure connection 20 to one or more further transaction order processors, such as the second transaction order processor or processor 21 shown in the figure.
  • Second processor 21 is connected in similar manner using secure connections 25, 26 to respective servers of second payment system 40' .
  • Second payment system 40' consists in the shown embodiments of a server of an issuer bank 12 and a corresponding server of an acquirer bank 13, mutually connected via one or more electronic communication networks. It is noted that in other embodiments many more banks are linked to the second processor 21. It will further be apparent that the role played by a determined bank can change. On one occasion a bank forms the issuer bank, since the bank account of the consumer is registered at this bank, on another occasion it forms the acquirer bank because in this case the bank account of the merchant is registered at this bank. It is also possible for both the merchant and the consumer to have their bank account at the same bank.
  • second processor 21 can be connected not only to second payment system 40' of the second area (R2) but can also be linked, for instance via a secure connection 27, to one or more banks of first payment system 40 located in the first area (Rl) -
  • Payment terminal 12 is provided in usual manner with a slot 29 into which a bank card (B) can be inserted such that the magnetic strip or EMV chip ⁇ present on the bank card (B) can be read by a reader 30 arranged in
  • Payment terminal 12 is also provided with, among other components, a keyboard 28 with which the user can enter his/her PIN code and a display 23 on which texts, such as the transaction amount, can be displayed.
  • payment terminal 12 is also linked via a connection 14 to a cash register 13, for instance an electronic cash register (ECR) .
  • ECR electronic cash register
  • This cash register can for instance send a signal to payment terminal 12 from which the payment terminal 12 can derive the amount to be paid.
  • payment terminal 12 is however embodied as stand-alone device and the amount has to be entered via the keyboard 28 of the terminal 12 itself.
  • a connected payment terminal is assigned a unique code from PMS system 16.
  • This code also referred to as the terminal identifier (TID)
  • TID terminal identifier
  • a unique code or identifier can be assigned in similar manner to the merchant associated with payment terminal 12, i.e. for instance the retailer in whose shop the payment terminal is disposed. The assignment of this code is carried out by the acquirer bank with which the merchant has a contract.
  • This identifier also referred to as the master merchant identifier MID 51, is likewise stored on storage medium 31 of PMS system 16 in the above stated configuration phase.
  • the payment terminal 12 is further linked to one or more corresponding codes (derived or slave TIDs 52,53) with which the payment terminal is designated by the different processors 18,21.
  • the payment terminal 12 identified using a master TID 50 has for instance a determined unique first terminal identifier T1D A 52,53 (figure 4) for first processor 18 and a determined unique second terminal identifier TTD B 54,55 for second processor 21.
  • the merchant designated with the master MID 51 can be designated in similar manner with different slave MIDs.
  • the merchant does after all have different contracts at the different banks for the handling of the payment transfers.
  • the merchant can be assigned different MIDs at the banks.
  • Stored on storage medium 31 of PMS server 16 are the master MID 51, the slave MIDs 56-59 and the relations existing between them.
  • the acquiring bank 7 has for instance a contract with the merchant of payment terminal 12 and this merchant has obtained the unique merchant
  • identifier (MID) 56 The same merchant has been given another unique identifier from another bank 13, for instance merchant identifier MID 57. Both identifiers MID 56,57 therefore designate the same merchant, but can relate to different handling protocols. In similar manner the bank 13, which is also connected to second processor 21, can have designated the same merchant with a third merchant
  • processor 18 can communicate with PMS 16 as if it were the payment terminal 12 itself.
  • second processor 21 can also communicate with PMS 16 as if it were the payment terminal 12 itself.
  • PMS 16 therefore functions here as a kind of virtual payment terminal arranged between the physical payment terminal 12 and processor 18, 21. Modifications to the hardware and/or software of the processors are in principle therefore not necessary to enable control of the transaction .
  • a part of the data read by the payment terminal is formed by the so-called application identifier (AID) .
  • Described in the above mentioned ISO/IEC standard 7816 is the process for the selection of the different applications supported by the card.
  • Applications can refer here to wholly differing applications such as GSM and EMV, although an application can also be a product type supported by a determined product issuer (e.g. banks issuing a Visa,
  • the product issuer of a Visa card may support different applications, such as Visa credit /debit , Visa Electron, V PAY, etc.
  • the product issuer of a MasterCard card may support the applications credit/debit , Maestro, Cirrus, etc.
  • Each product issuer has in general one or more of its own product types or applications.
  • AID application identifier
  • AID registered application provider identifier
  • PIX application identifier extension
  • the Client software running on the payment terminal controls the reader such that the card is read.
  • the reader reads from the card the possible card payment applications (Application ID of the card) .
  • This card application ID list is subsequently compared by the payment terminal to a prestored list on the payment terminal (consisting of one or more IDs) of
  • a message is sent back via the display of the payment terminal that payment has to be made in another way.
  • the consumer is provided with the option of selecting one of the possible card application IDs (i.e. one of the card ApIDs for which a match has been found) .
  • the selected ApID is subsequently incorporated in an electronic payment order, for instance in the form of transaction data, as described in more detail below .
  • PAN stands for
  • PIN PIN code
  • Payment terminal 12 collects the PAN and PIN codes, encrypts them and sends them, together with
  • PMS 16 determines on the basis of the received ApID data designating the desired application (for instance the Visa VPAY application) (and optionally the master TID 50 and master MID 51 already stored in the configuration phase) which of the processors 18,21 should be selected to handle the transaction.
  • a determined processor is for instance adapted to process VISA VPAY transactions, while yet another processor is adapted to process Mastercard credit/debit transactions.
  • the choice of the processor can likewise depend on the area in which the payment terminal is situated (which area can be derived from the TID of the payment terminal stored in the configuration phase, since the area in which the payment terminal is situated is known
  • tables are stored on PMS 16, at least in the electronic storage medium connected thereto, on the basis of which a number of
  • the possible methods of payment can be selected in accordance with the ApID data for each payment terminal (i.e. for each master TID 50) .
  • the received ApID data correspond to AIDi
  • the transaction will be handled by first processor 18 together with issuing bank 6 of payment system 40.
  • the payment terminal has a TID 52 in first processor 38 and the merchant has a MID 56.
  • the AID data correspond to AID 2
  • the transaction wil] be performed by the same processor 18, but the transfer of amounts takes place via one or more other banks, for which the merchant is
  • AID data corresponds to AID3
  • second processor 21 wherein the payment terminal is designated in unique manner with TID B
  • a further acquirer bank 13 in which the merchant is designated with MID 3
  • second processor 21 will be used while a bank from the first payment system 11 will perform the actual transaction.
  • the merchant is again characterized here by MID a 59.
  • a transaction order is generated in a so-called protocol adapter 35 of PMS 16 in accordance with the relevant protocol for the associated processor 18, 21 and the associated acquirers.
  • a transaction signal is then sent to the relevant processor 18,21 in accordance with the generated transaction order, which further handles the transaction in the usual manner.
  • the application ID (ApID, sometimes also abbreviated to
  • the AID) received from the payment terminal is more particularly associated with a specific acquiring zone.
  • the acquiring zone is related to a determined processor and to the
  • Each processor has its own application ApID and several
  • AID acquirer identifier
  • the processor sends the transaction data over the communication network here to the issuing and acquiring banks relevant for authorization of the PIN associated with a specific PAN and transaction amount, including all
  • the processor receives a response from the issuer that the authorization of both is accepted and the transaction amount is reserved at the acquirer bank.
  • An authorization code is sent back to the payment terminal and linked to a
  • transaction certificate which is associated with the relevant payment and is stored as such.
  • This communication between processor 18,21 on the one hand and the issuer and acquirer banks on the other is known in the field under the terms clearing and settlement.
  • the communication can take place online and/or offline.
  • PMS server 16 is as it were placed as virtual payment terminal between the physical payment terminal 12 and processors 18, 21, there is also a greater freedom of choice for the merchant in the selection of the desired type of payment terminal.
  • the types of payment terminal to be used were determined by the requirements set by the relevant processor 18, according to embodiments of the invention the PMS 16 can be adapted such that different types of payment terminal (not the type of payment terminal prescribed by the relevant processor) can be used as long as PMS 16 is capable of making the correct translation so as to enable processor 18, 21 to be controlled in the desired manner (as if it were being controlled by a prescribed payment terminal).
  • FIG. 5 Shown for instance in figure 5 is a further embodiment of the invention which largely corresponds to the embodiment shown in fig. 2, but wherein more than one payment terminal is linked to PMS 16.
  • a second payment terminal 12' is linked of another type differing from the above mentioned type.
  • PMS 16 is adapted to make a correct translation of the signals coming from the different types of payment terminal to the format suitable for the relevant processor 18, 21, according to the embodiment of the invention the merchant him/herself can choose the type of payment terminal (12, 12') he/she will use to perform the transactions.
  • PMS 16 is adapted to handle not only financial transactions but also non- financial transactions, for instance transactions related to loyalty cards, bonus cards, etc. In these embodiments contact is made with PMS 16 by payment terminal 12. On the basis of the provided PAN codes, after a possible
  • PMS 16 can store information about the relevant consumer on storage medium 31 of PMS 16. This information can for instance comprise loyalty information, for instance data received from the cash register system which are representative of the articles purchased by the T NL2012/050248
  • This loyalty information can for instance be used to give discount on possible further financial transactions.
  • PAN data can be stored on the magnetic strip of the
  • the card On the basis of the PAN data (and so without requiring a PIN code) the card can be recognized via BIN from the CST (Card System Table) as being a loyalty card. In consultation with an acquirer bank a determined card range can even be reserved for loyalty purposes.
  • the card data can subsequently be sent directly to the loyalty host and processed and, if desired or supported, linked to the financial transaction and the associated transaction amount. Value points can in this way be saved or redeemed with the loyalty card.
  • the loyalty host keeps track of the conversion rate and the balance total. Using this solution the retailer is able to influence the behaviour of the consumer. For instance 200 points if the consumer opts to pay with a first application (for instance Maestro) and only 50 points for paying with a second application (for instance with Visa or MasterCard credit cards) .
  • a first application for instance Maestro
  • a second application for instance with Visa or MasterCard credit cards
  • Communication connection 15 between payment terminal 12 and PMS server 16 forms a secure connection according to a predetermined protocol, for instance the transport layer security (TLS) or the secure socket layer (SSL)
  • a predetermined protocol for instance the transport layer security (TLS) or the secure socket layer (SSL)
  • the input carrier is a payment card, loyalty card or the like, wherein the data representative of the client, such as the PAN code, are stored on a magnetic strip or on a microchip (for instance an EMV chip).
  • the input carrier can be read, for instance by detecting a bar code provided on the card by means of an optical bar code reader or by making use of an electromagnetic sensor for reading a resonance circuit (for instance an RFID tag or the like).
  • NFC technology which is provided for instance on a mobile platform, such as a mobile phone, PDA or the like.
  • An EMV functionality can for instance be arranged in the SIM card of the mobile phone so that reading the SIM card, or at least a part thereof, can be seen as a reading of the EMV chip used which is provided on a payment card.
  • Figure 6 shows an example of performing a financial transaction remotely using a mobile platform.
  • PMS server 60 Shown in the figure is a PMS server 60 which is connected in known manner via a secure data connection 61 to a payment terminal 62. PMS server 60 is further linked in the above described manner to one or more processors 65, 66 which in turn control one or more transaction systems (acquirers) 67- 70. Further shown is a mobile phone 71 which establishes a wireless connection 73 to payment terminal 62 using an NFC transmitter/receiver. Because the smart card (SIM card) provided in the mobile phone is provided with EMV
  • the mobile phone 71 function as a payment terminal.
  • payment terminal 62 reads the mobile phone (payment card) and here collects inter alia the PIN code unique to the consumer and the PAN code representati e of the bank account of the user.
  • mobile phone 71 makes contact via a wireless network transmitter/receiver 75 with the mobile network (for instance a GSM network, 3G network, etc.) and establishes an internet connection 77 with PMS server 60.
  • PMS server 60 can determine the mobile phone number (M) of the phone 71 (with a standard number recognition technique) .
  • This mobile telephone number (M) can subsequently be compared to a list 80 of prestored mobile phone numbers ( ⁇ - ⁇ ⁇ ) .
  • Mobile phone numbers can be stored on PMS server 60 or, as in the shown embodiment, on a separate storage medium 82.
  • the list of telephone numbers 80 originates from the mobile network operator (MNO) managing the network with which the internet connection has been made.
  • PMS 60 can for this purpose be directly connected to a server 85 of the mobile network operator (MNO) .
  • MNO mobile network operator
  • an additional check can thus be performed by comparing the telephone number of the consumer with a list of
  • the PMS can conclude that the
  • the PMS 60 will however decide that a transaction is allowed to take place, but that this transaction has a higher risk profile. Depending on the size of the amount and possible other parameters, it is then possible for instance to decide to allow the transaction to continue, but at relatively high costs. A more detailed description of the specific embodiment for handling transactions is given hereinbelow.
  • Table 1 gives an explanation of different components of the transaction system according to an
  • PMS the central software core on the central host system which has control over the payment logic and controls the hardware
  • PCI PTS Payments Card Industry
  • ECR Electronic Cash Register
  • Acquirer hosts the host systems of the processors.
  • the processor controls the processing of clearing and settlement files between the acquiring banks and the issuing banks. In other words they provide for the mechanism in which the transaction amount to be paid by the consumer at the POS in the shop of the merchant is transferred in electronic manner from the bank account of the consumer to the bank account of the merchant.
  • Consumer the person starting the electronic transaction at the POS (including e.g. a physical payment terminal or a webshop or the like) in order to obtain goods or services in exchange for money or for a value transfer accepted in similar manner.
  • Merchant is for instance the retailer (organization or person) accepting electronic payments in the virtual and/or physical shop(s)
  • Terminal Management System the TMS (terminal management system) subsystem provides for the remote configurations and secure software and firmware downloads of the input hardware.
  • the Client profiles (behaviour of the input hardware on the input products: how for instance does the payment terminal deal with the EMV payment cards that are used, risk management) are exported from the PMS to the TMS system and subsequently configured for the specific type of input hardware.
  • the Key Management System controls all keys in the PMS.
  • the KMS is used to create, store, import, export, store and use as back-up the keys of the POS terminals, OMS, TMS, third-party systems and the like in secure manner.
  • the ( De) Multiplexer has the task of routing messages as follows:
  • the keys in the HSM are used.
  • HSM The Keys are always located in a secure
  • HSM Hardware Secure Module
  • COTS Common Off The Shelf
  • the HSM is able to wrap/encrypt keys using a Loading Key. This mechanism is used to back up all the wrapped keys in the database. ⁇ group of key custodians will be used to create a paper backup of the Loading Key for the HSM. In the case the HSM of the key manager breaks down, the key custodians are able to fill a new HSM with the loading key. The new HSM is then able to load all the wrapped keys from the database.
  • the architecture aims at offloading complexity from the LW-POS or input hardware device to the PMS.
  • the LW-POS communicates with a counterpart in the PMS referred to as the POS
  • Every connected LW- POS has its own POS instance.
  • the POS instance contains most of the payment flow and generates the content of host messages that are sent to the acquirer host via the protocol adaptor during a transaction.
  • Protocol adaptor formats the host message in the correct format for the intended acquirer and adds the security to these messages (MAC, MAC,
  • I POS manager the POS Manager manages all the POS
  • I System log the System Log module stores all the log information produced by other modules in the PMS, in the database. This information can be used for analysis and debugging of the PMS system.
  • I Database all LW-POS or input hardware Client and POS profiles with configuration and trusted relation
  • 028 Merchant reporting the configuration can be seen by the merchant. It also provides usage data per device and location. See 008.
  • 029 Service Provider reporting this is the location where a service provider can configure the input hardware and ECR devices. It can also provide usage statistics for preventive maintenance. See 009.
  • the acquirer can generate usage
  • the Service console can be used to communicate
  • a method and system for realizing freedom of choice in a flexible manner in the secure relations an electronic transaction system maintains with third parties.
  • electronic transactions processed via the system comprise data representing a specific value of a financial or non- financial nature. In the operational environment this value is accepted by all users as a valid electronic means of payment. Value is transferred in electronic manner from the one user to the other.
  • the identity of the user is determined on the basis of a unique physical carrier and a unique code linked to this carrier. Linked to these two entities is a transaction amount which is exchanged with a third party which validates and approves the transfer of the value.
  • the electronic transaction is handled wholly within a secure environment.
  • the physical data of the carrier and the associated unique code are basically secured immediately at input, including the associated electronic value.
  • Some of the described embodiments make it possible to enter simultaneously into a plurality of secure relations with third parties, thus enabling the end user to make a choice from the diverse parties.
  • the input hardware determines with the security software with whom it maintains a secure relation by realizing the secure
  • the system enabling the freedom of choice comprises in determined embodiments a central secure software bus which has a number of specific branches for handling specific tasks.
  • the front end software operating on the input hardware provides for the secure input, storage, output and communication.
  • the central software likewise provides for the secure input, storage, output and
  • the central part fully controls and checks the front end.
  • the principle of the Client-Server technology is applied for this purpose.
  • a card payment card, credit card, etc.
  • PIN and PAN data the relevant data is encrypted via the Client software running on the payment terminal and thereby made inaccessible to the outside world.
  • the encrypted data are then sent in tunnelled manner (via a secure connection) to the secure memory part of the payment management system (PMS) .
  • the PMS forwards these data (in a protocol selected from a list of possible protocols) in an authentication request via a secure connection to the selected transaction order processor.
  • This processor subsequently performs a check (authentication) , for instance on the authenticity of the card and on the PIN code.
  • the payment terminal can also perform a first check.
  • the authenticity of a card is checked in the first instance by the Client on the payment terminal.
  • a PIN code can for instance be checked in an offline mode with the encrypted PIN on the card itself, and be directly validated and checked in an online mode by the card issuer (i.e. the transaction order processor) which has issued the relevant card.
  • the PMS In both modes the PMS always submits an authentication request (also referred to as authorization request) to the card issuer (s).
  • the identification data such as the PAN and PIN data are not saved or stored by the payment management system. The secrets of the card and associated PIN
  • Web service ensures that, from a management viewpoint, all users gain access to the controlled subsystems and data. For each type of user a separate application is started so that a physical separation is realized between the different domains. Each type of user assigns his/her own user management and access rights at application level and data level.
  • the Administrator of the Payment Management System the central software is at the top of the hierarchy and, via the local system on a local network, has access to all
  • this A I subsystem creates the virtual payment terminals
  • a profile can consist of several Acquirer Zones.
  • An Acquirer zone virtualizes a single secure relation comprising a specific route for the processing and the supported electronic payment products valid for this route.
  • An Acquirer Zone has its own unique identifiers: TID terminal identifier, uniquely linked to a payment terminal and MID merchant identifier representing a payment product which is supported.
  • a TID can have several MIDs.
  • Subsystem KMS + HSM security manager this subsystem B I provides for the security of the overall PMS system.
  • the keys and certificates ensure that secure relations can be entered into and implemented between the physical input hardware and virtual payment terminal on the one hand and between the virtual payment terminal and the relevant third parties on the other.
  • Two core security systems can be distinguished, the one, a security module, is particularly concerned with the securing and encryption of the data of the unique identifier of the user, the so-called PIN (personal identification number) , and in combination with the associated unique carrier in the form of a PAN (personal account number) and of course the associated electronic transaction amount.
  • This encrypted data in the form of a PIN Block is formed on the input hardware via the specific security software of the hardware, and subsequently undergoes in the PMS security module a translation for the purpose of establishing a secure relation with a third party.
  • the second module provides for the certificates and keys for the secure connections between the systems mutually and all external
  • the combined security modules also ensure that the PAN is already stored at application level in masked form within the relevant transaction data (and/or in combination with other sensitive transaction data). In the case of theft of the
  • Subsystem Configuration and Client profiles manager this subsystem provides a behaviour profile for the input hardware of how to deal with the diverse input means and how to handle these via the security
  • the payment terminal is for instance how the PIN is presented in the dialogue between user and input hardware, as well as that for security reasons an on-line PIN and authorization is always enforced. Also envisage here however a selection list of payment products with a preferred selection of a payment product from which the user can choose.
  • this data is prepared for input via the TMS (terminal management system) into the input hardware.
  • the profile also comprises the software versions which are realized the first time via personalisation of the input hardware and, once operational, can be maintained securely and remotely via the TMS.
  • Subsystem Payment or Transaction device manager this subsystem ensures that a physical input hardware is linked to a Client, POS instance and POS profile.
  • Subsequently generated from the PMS via the KMS+HSM subsystem is a unique master TID linked to a master MID, both of which are linked to a Master key with which the Slave keys are generated for the associated relations with the third parties which have been created from the POS profile.
  • operationally active payment terminal in the field which can process secure transactions via the diverse established secure relations with third parties for the purpose of processing the electronic transactions.
  • User management service ensures that on the basis of USN and PW a user profile is activated for access to the PMS system, with access to the diverse data structures of the different subsystems.
  • Important here in addition to the date time stamp is the service per user which serves the purpose of logging which data have been accessed and subsequently which data
  • Login process result keeps track of whether the login has been successful and keeps track of the number of login attempts and whether the date procedure must start to run and provides for interim data storage of and for the log file.
  • a timer function ensures that the procedure may be repeated, starting from 108, only after an x number of minutes.
  • TIDs activate and/or deactivate, change and delete them. Only TIDs which have been created on the system and come from the creation list can be set up and used for deployment.
  • TID seeding process ensures that Master TIDs are created on the PMS system. Master TID is later linked uniquely to an input hardware device. In this specific case the physical payment terminal at the Merchant location .
  • TID seeding process result produces a list with Master TIDs which can be set up and activated via the PMS. This list is stored within the relevant subsystem of the PMS. Master TIDs always remain saved, even if they have been deleted.
  • Master TIDs are then known, and the Administrator can then begin to prepare a new Master TID for activation on the PMS system.
  • a black and white list system On a subsystem an overview of all Master TIDs is maintained via a black and white list system. Via the Master TID list it is possible to check whether a physical payment terminal at the Merchant location is allowed to start or perform electronic transactions.
  • a physical payment terminal in the case of a malfunction which cannot be remedied remotely, is replaced on site by a new physical payment terminal. The new physical payment terminal may then be activated only after the old terminal has been returned.
  • Another example is when a physical payment terminal which cannot maintain an online connection with the PMS is temporarily
  • determined preferences in behaviour are prepared in the form of configuration parameters for use by the TMS. That the specific Client Profile is then stored properly on the relevant subsystem. Administrator can make use of created standard profiles and configurations .
  • Client profile must also be linked to the physical input hardware and stored.
  • Start Client Profile process wherein a profile for a Master Merchant can be started. Note that a profile for the physical payment terminal at shop level can be determined per region and per country. A single Client profile can be used for several Master TIDs.
  • Client and configuration process involves a form completion task wherein a table is compiled and made ready for further processing via the TMS system to the hardware input device.
  • Client profile process result is a list which can be stored on the relevant subsystem and produces a file which can be read by TMS and linked to unique hardware ID of the input hardware.
  • Timer indicates that, if repeat steps are not
  • Start Payment / Transaction device process within this process a choice is made for the input hardware linked to the created Client Profile.
  • the hardware service ensures that a relation is established between the unique ID of the hardware and the Client profile. All hardware of the different suppliers has a unique hardware ID. During manufacture and transport lists are provided and the hardware provided with transport keys. The manufacturing process must comply with TQM process wherein assembly P T/NL2012/050248
  • Measures include: opening the payment terminal, drilling holes in the payment terminal etc. In all cases the secure memory must be immediately deleted and this must be shown in the display when power is supplied to the hardware .
  • a list of available hardware IDs will be available from the TMS for the PMS, and vice versa.
  • Hardware selection result is that a physical hardware ID can be linked to a specific Client profile with associated Master Merchant ID. Result is then stored for further use.
  • Hardware selection is not successful, a new process will be started. If it is not possible to select hardware ID the procedure will be discontinued after an x number of attempts, and restarted with a
  • Master Key management process result is that, on the basis of a Master key structure, the Administrator can create, assign, activate, change and store different Acquirer zones.
  • Master key successful has two results. Firstly, if Administrator is unable to make a Master Key profile, an x number of attempts to make a profile are in this case allowed. If this is not realized within the x attempts, the current process will be discontinued and restarted with a different profile. If making of a Master key profile has been successful, the following process step can be started.
  • Start POS instances and profiles process.
  • the virtual payment terminals are set up (POS instances) and the associated POS profiles comprising the derived Slave relations with the third parties said Acquirer zones are determined and set up.
  • AID Processor list
  • Acquirer zones a list of third processing parties will have to be set up. These are, in the example of the payment terminal, the parties which ultimately handle the transactions via a clearing and settlement mechanism with the issuing and accepting banks / financial institutions of the relevant payment product.
  • the PMS system supports both an online and file-oriented mechanism. This list must then be maintained: it must be possible to add, modify or remove Acquirer zones.
  • the processing parties each have their own specific ID on the basis of an AID characteristic .
  • Acquirer list a list of acquirers, banks will have to be set up which are fixed behind a determined secure processing relation and transaction route. The end user, in the case of the payment terminal the
  • Retailer will enter into the Merchant contract with an Acquirer / Bank for acceptance of electronic payment in the cash register environment for a specific payment product.
  • This list must then be maintained: it must be possible to add, modify or remove Acquirers / Banks. It must similarly be possible to track / modify the list of payment products associated with a specific acquirer / bank. Each acquirer has their own specific ID on the basis of slave TIDs and MIDs.
  • TID list a list of Master TIDs will be set up which are associated with specific input hardware. It must then be possible to link these Master TIDs to the POS instances and associated POS profiles. The result of linking different profiles will be stored.
  • Merchant list an associated Merchant list will also be set up from the Master TID list. For the payment terminal this is the list of the retailers or retail merchants. The result of linking different profiles will be stored.
  • Client profiles list a Client profile list will be set up from a previous process. From this list a profile can specifically be made for a Master Merchant with associated POS instance and POS profile. The result of linking different profiles will be stored.
  • Start POS profile process within this process the third or derived relations with the third parties are determined: the processing parties and acquirers / banks with the associated payment products.
  • the POS profiles can then be linked to the list of virtual payment terminals and the POS instances.
  • the outcome is a list of Acquirer zones with the payment products linked here per Acquirer / bank.
  • the separate derived TIDs and MIDs are known per Acquirer zone.
  • I POS profile service the service ensures that the POS profiles can be created and are maintained.
  • POS profile result is a POS profile which can be linked to virtual payment terminals, the POS instances, and this profile can be drawn up,
  • I POS profile successful if not successful and no profile can be made, the session is repeated x times. The service is then discontinued and restarted. If successful, the following process can then be started.
  • I Start Slave Key management process within this process the derived keys are determined on the basis of the BDK, the Master key determined per Acquirer zone.
  • I Derived key management service service (automated process) runs via KMS + HMS subsystem which provides for generation of derived keys on the basis of the BDK for a Acquirer zone.
  • Key loading device subsystem this system (hardware + software) ensures that the Master and Slave keys are made ready in a controlled secure manner for loading of the keys into the input hardware. These keys ensure that a hardware input device in combination with the associated POS instance (the virtual payment terminal) on the PMS can together (operating as central software bus from the PMS with the different subsystems) maintain a secure relation with determined Acquirer zones .
  • Master TID list this is the list of Master TIDs and Master Merchant IDs set up/compiled in an earlier process (114) .
  • the process tree is now assembled in combination with the derived relations: keys and profiles. Specific lists are now placed within the tree for further processing within the operational environment. Tree structures are stored.
  • Master + Slave key lists this is the list of Master Keys and Slave Keys set up/compiled in an earlier process (133+147). Specific keys are now placed within the tree for further processing within the operational environment. Tree structures are stored.
  • Client profile lists this the list of Client profiles set up/compiled in an earlier process (125). Specific lists are now placed within the tree for further processing within the operational environment. Tree structures are stored.
  • POS profile + POS instances lists this is the list of POS profiles and POS instances set up/compiled in an earlier process (137). Specific lists are now placed within the tree for further processing within the operational environment. Tree structures are stored.
  • the process is repeated x times. At the last attempt the process is discontinued after x minutes and restarted. If successful, the payment terminal (physical + virtual) is then made specific for an end customer as unit within the PMS system and prepared for
  • Administrator can start the following process .
  • POS profile and POS instance profile are
  • 163 TID list this is the Master TID and Merchant list which are made specific for the end customer per shop location and per country.
  • TMS list list of Client profiles sent as
  • PMS list list of POS instances and profiles linked to the correct Client profiles.
  • Software + keyload+testing service automated service which makes it possible under software control to load the software and keys to the input hardware devices via a loading facility. A test procedure then also takes place which checks whether the correct software versions have been loaded, and the hardware can start up.
  • Start device deployment proces within this process the customer-specific aspects for delivery process are activated in terms of issue and receipt procedures.
  • TMS + PMS systems within the operational systems the customer domain is provided with the necessary Master TIDs and Merchant IDs.
  • Deployment service service which shows that a batch of input hardware devices has been sent to the
  • result of the service is a batch delivery of the payment terminals accepted by the customer .
  • Deployment process successful if not successful during transport, then direct blocking of payment terminals on PMS system. If not successful during acceptance process customer, return physical payment terminals and replace with new payment terminals or, worst case, completely new batch. If successful, the Administrator can then start with the installation procedure .
  • I Start device installation process in this process the payment terminals are installed within the shop environment. The two pairs of eyes rule is applied for this process.
  • An FSE field service engineer
  • the help-desk observes remotely and can activate the physical payment terminal and associated POS instance on the PMS system.
  • I Install service the service makes it possible to install and link the physical payment terminal to the virtual payment terminal and subsequently activate the whole via the help-desk.
  • I Install process successful if not successful, the FSE can look at whether this is due to the physical payment terminal, and remedy the malfunction via configuration and software updates or modification. If not successful on the virtual payment terminal side, the help-desk can look at whether this is due to the POS profile and or the POS instance. The help-desk can look at whether these malfunctions can be remedied remotely. Install process is discontinued if PMS cannot reach the physical payment terminal. If
  • the payment terminal is then wholly ready for operational use.
  • Start device transaction process in this process the whole payment terminal is active in the operational mode. Different transaction types are performed and handled daily via the payment terminal.
  • a transaction results are now processed and stored with the diverse Acquirer zones.
  • a specific clearing and settlement procedure can be employed per Acquirer zone. It is important that from the PMS system forced online PIN verification, and authorization are in the first instance always used. After approval of the PIN and authorization, the transaction data can then be sent batchwise/filewise or directly to the Acquirer zone .
  • Selection can be repeated until a payment product can complete a transaction. If not the case, the customer can abort the transaction.
  • the customer receives a copy receipt of the payment transaction.
  • the PAN will be shown in masked form on copy receipt of both the customer and the merchant.
  • the receipt shows which payment product has been used and which acquirer zone has been used.
  • TMS+PMS system systems are adapted such that each A logical user has their own portal has for access to the system. Customer is starting point and indicates who the Service provider is and which contracts are associated with which Aquirer zones. Each portal has its own specific function geared to the role assigned in respect of the payment terminal via the portal.
  • B service can be provided at the physical payment
  • Service provider can hereby act more quickly and more efficiently on behalf of the customer in the field of service. Service provider, provided it is trained, can itself manage and maintain the profiles and configurations of the customer domain on behalf of the end customer.
  • the merchant via this portal the merchant can keep C track per book entry period of his/her turnover per shop, region, country, countries. He/she can also update his/her own MSC (merchant service charge) table, wherein he/she can display transaction costs. On the other side the Merchant administrator portal makes it possible to make electronic repayments for transactions performed previously within the shop environment with the physical payment terminal.
  • MSC product service charge
  • the payment terminal If successful, the payment terminal returns to its operational mode.
  • End Freedom or Choice (FOC) process result of this process is that the end customer has obtained the
  • the solution provides both at the front and back end a freedom of choice in which a secure solution is
  • transaction data remains guaranteed from the moment of data input, processing and storage.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

La présente invention concerne un ensemble destiné à traiter des transactions entre un commerçant et un client, comprenant : - un terminal de paiement destiné à générer et envoyer un ordre de transaction électronique ; un système de paiement destiné au transfert électronique d'un montant de transaction du compte bancaire du client au compte bancaire du commerçant ; - un processeur d'ordre de transaction destiné à la compensation et au règlement électronique du montant de la transaction, le processeur d'ordre de transaction étant adapté pour commander le système de paiement en vue du transfert du montant de la transaction. L'ensemble comprend un groupe de processeurs d'ordre de transaction dont chaque dit processeur est connecté à un système de paiement et un système de gestion de paiement (PMS), disposé entre le terminal de paiement et les processeurs d'ordre de transaction, est adapté pour sélectionner un processeur d'ordre de transaction parmi le groupe de processeurs d'ordre de transaction et pour commander le système de paiement associé avec le processeur d'ordre de transaction sélectionné.
PCT/NL2012/050248 2011-04-14 2012-04-16 Ensemble et procédé de gestion de transactions WO2012141588A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NL2006608 2011-04-14
NL2006608A NL2006608C2 (nl) 2011-04-14 2011-04-14 Samenstel en werkwijze voor het afhandelen van transacties.

Publications (1)

Publication Number Publication Date
WO2012141588A1 true WO2012141588A1 (fr) 2012-10-18

Family

ID=46022611

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NL2012/050248 WO2012141588A1 (fr) 2011-04-14 2012-04-16 Ensemble et procédé de gestion de transactions

Country Status (2)

Country Link
NL (1) NL2006608C2 (fr)
WO (1) WO2012141588A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106296174A (zh) * 2016-08-08 2017-01-04 东信和平科技股份有限公司 一种基于hce技术的小额支付卡装置及其实现方法
US20190114607A1 (en) * 2017-10-18 2019-04-18 Mastercard International Incorporated System for executing a computer process for processing a transaction, and related computer process
CN112308555A (zh) * 2014-03-25 2021-02-02 艾柯西派特有限公司 远程交易系统、方法和销售点终端

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110111170A (zh) * 2019-03-28 2019-08-09 北京三快在线科技有限公司 候选商家匹配方法、装置、电子设备及可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002079939A2 (fr) * 2001-03-31 2002-10-10 First Data Corporation Systeme et procede de paiement electronique avec identificateur
WO2002101512A2 (fr) * 2001-06-12 2002-12-19 Paytronix Systems, Inc. Systeme de passerelle de paiement de commerçant, de fidelite et d'identification de client
US20040030647A1 (en) * 2001-03-31 2004-02-12 First Data Corporation Staged transactions systems and methods
US20050015336A1 (en) * 2003-07-15 2005-01-20 Microsoft Corporation Electronic draft capture
WO2008117212A1 (fr) * 2007-03-23 2008-10-02 Iveri Payment Technologies (Proprietary) Limited Commerce électronique

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002079939A2 (fr) * 2001-03-31 2002-10-10 First Data Corporation Systeme et procede de paiement electronique avec identificateur
US20040030647A1 (en) * 2001-03-31 2004-02-12 First Data Corporation Staged transactions systems and methods
WO2002101512A2 (fr) * 2001-06-12 2002-12-19 Paytronix Systems, Inc. Systeme de passerelle de paiement de commerçant, de fidelite et d'identification de client
US20050015336A1 (en) * 2003-07-15 2005-01-20 Microsoft Corporation Electronic draft capture
WO2008117212A1 (fr) * 2007-03-23 2008-10-02 Iveri Payment Technologies (Proprietary) Limited Commerce électronique

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112308555A (zh) * 2014-03-25 2021-02-02 艾柯西派特有限公司 远程交易系统、方法和销售点终端
CN106296174A (zh) * 2016-08-08 2017-01-04 东信和平科技股份有限公司 一种基于hce技术的小额支付卡装置及其实现方法
US20190114607A1 (en) * 2017-10-18 2019-04-18 Mastercard International Incorporated System for executing a computer process for processing a transaction, and related computer process
WO2019078957A1 (fr) * 2017-10-18 2019-04-25 Mastercard International Incorporated Système d'exécution d'un processus informatique permettant de traiter une transaction, et processus informatique associé
US10896415B2 (en) 2017-10-18 2021-01-19 Mastercard International Incorporated System for executing a computer process for processing a transaction, and related computer process

Also Published As

Publication number Publication date
NL2006608C2 (nl) 2012-10-16

Similar Documents

Publication Publication Date Title
US11216803B2 (en) Authentication token for wallet based transactions
US11282337B2 (en) Enabling financial transactions for electronic gaming machines
JP4810613B2 (ja) 承認システム
KR100731905B1 (ko) 지불 장치와 방법
CN109313764A (zh) 对在支付卡接受点处使用的存款账号进行令牌化的系统和方法
CN105590214A (zh) 一种虚拟卡的支付方法以及支付系统
US20140172596A1 (en) Assembly and Method of Handling Transactions
CN106462849A (zh) 用于令牌域控制的系统和方法
EP2815361A1 (fr) Cartes de paiement jetables
GB2546740A (en) Electronic payment system and method
US20170178121A1 (en) System and method for providing instructions to a payment device
KR20000024588A (ko) 전자상거래 금융정보 처리시스템과 그 방법
WO2012141588A1 (fr) Ensemble et procédé de gestion de transactions
US20170178111A1 (en) System and method for using multiple balances with a single payment device
CN111047325B (zh) 一种收款系统及方法
US20230230449A1 (en) Enabling financial transactions for electronic gaming machines
WO2020152656A1 (fr) Procédé de paiement et système de paiement
US11508213B2 (en) Enabling financial transactions for electronic gaming machines
KR101506023B1 (ko) 기록형 계좌를 이용한 출금 관리 방법
US20210090200A1 (en) System and method for utilizing prepaid cards to facilitate purchases in association with a gaming establishment retail account
JP2022037919A (ja) 金融自動化機器を用いた入出金サービスシステムと方法及びそのためのコンピュータプログラム
CN116739589A (zh) 支付校验方法、装置及计算机设备

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: 12717904

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION NOT DELIVERED. NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 11.02.2014)

122 Ep: pct application non-entry in european phase

Ref document number: 12717904

Country of ref document: EP

Kind code of ref document: A1