WO2002048974A1 - A method for communicating a transaction between a payment terminal and at least one acquirer - Google Patents

A method for communicating a transaction between a payment terminal and at least one acquirer Download PDF

Info

Publication number
WO2002048974A1
WO2002048974A1 PCT/DK2001/000832 DK0100832W WO0248974A1 WO 2002048974 A1 WO2002048974 A1 WO 2002048974A1 DK 0100832 W DK0100832 W DK 0100832W WO 0248974 A1 WO0248974 A1 WO 0248974A1
Authority
WO
WIPO (PCT)
Prior art keywords
credit
transaction
acquirer
payment terminal
payment
Prior art date
Application number
PCT/DK2001/000832
Other languages
French (fr)
Inventor
Jan Johannes KYHNÆB
Michael SCHMÜCKER
Original Assignee
Bording Data A/S
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 Bording Data A/S filed Critical Bording Data A/S
Priority to AU2002221574A priority Critical patent/AU2002221574A1/en
Publication of WO2002048974A1 publication Critical patent/WO2002048974A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/403Solvency checks
    • G06Q20/4037Remote solvency checks
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873Details of the card reader
    • G07F7/088Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself
    • G07F7/0886Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself the card reader being portable for interacting with a POS or ECR in realizing a payment transaction

Definitions

  • a method for communicating a transaction between a payment terminal and at least one acquirer is a method for communicating a transaction between a payment terminal and at least one acquirer.
  • the invention relates to a method for communicating a transaction between a payment terminal and at least one acquirer, said acquirer representing at least one credit central.
  • the invention further relates to a system and a storage medium with a software application for performing the method.
  • the invention also relates to payment terminal for transmitting transaction requests to at least one acquirer and receiving transaction responds from said acquirer, said acquirer representing at least one credit central.
  • an acquirer representing a number of credit card providers handles it.
  • the acquirer can e.g. be a credit card provider handling a number of different credit cards.
  • This terminal communicates with an acquirer, selected by the service or good provider.
  • the communication is made through a closed line, assuring the safety of the data communicated between the acquirer and the terminal.
  • the acquirer has to certify both the terminal and the communication line according to some predefined specific certification rules defined by the acquirer.
  • the terminal is typically hardware based and most of the logic has been built into the hardware of the terminal in order to fulfill the certification rules specified by the acquirer.
  • the certification rules could e.g. be communication rules defining in what format the data must be communicated and how the data must be communicated.
  • a further problem is that the existing solutions focus entirely on the payment transaction and the terminals have therefore been built for this purpose only. Therefore the existing solution does not allow easy integration with other applications, which could be necessary if the client wants integration of the entire business system.
  • EP 0484198-A1 and US patent 5,387,784 a payment system that can handle credit card payments on a mobile device is disclosed. This system is not for performing credit card transactions but only for performing an online check up on the validity of the credit card.
  • a method for communicating a transaction between a payment terminal and at least one acquirer, said acquirer representing at least one credit central comprising the steps of: - receiving a transaction request from a payment terminal, said transaction being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, selecting a second communication rule between a predefined set of communication rules, each of said communication rules being specific for at least one acquirer, said selected communication rule belonging to the acquirer representing the credit central identified by said credit media data, transmitting the transaction request to said acquirer, said transaction request being communicated according to said selected second communication rule.
  • the method further comprises the steps of: receiving transaction response from the acquirer, said transaction response being communicated according to the selected second communication rule, transmitting at least part of said transaction response to said payment terminal.
  • a Payment Server could e.g. perform the method using the Internet (Internet Payment Server, IPS) and the credit central could e.g. be a credit card central.
  • Internet Payment Server Internet Payment Server, IPS
  • the credit central could e.g. be a credit card central.
  • the invention separates communication between the payment terminal and acquirer in two parts.
  • the first part is the communication between a payment server and the payment terminals using first communication rules and the second part is the communication between the payment server and the acquirers using different communication rules according to the demands of the acquirers.
  • This payment server separately handles the specific communication rules w th the acquirers and the payment terminals. When specifications change due to e.g. a new acquirer it is only necessary to adjust the payment server communicating with the acquirer instead of all the payment terminals .
  • An advantage of the invention is that the communication rules used between the payment server and the payment terminals do not have to be so advanced as the communication rules defined by the acquirers used between the payment server and the acquirers. It is only the payment server that has to be able to fulfill these advanced communication rules, which can be very hardware demanding. It is thereby obtained that a simpler communication rule can be used, which e.g. could be adapted on different pieces of existing hardware, which then could be used as payment terminals. Examples of existing hardware are described below. It is thereby also possible with a total integration of the payment terminals with the rest of the system in e.g. a service or good provider.
  • the invention further comprises the step of storing said received transaction request and said received transaction response.
  • the payment server can handle and log the large amount of highly sensitive information and the user can if necessary review backup of all payment transactions.
  • this accessed part is in the following also denoted as a local payment server LPS.
  • LPS local payment server
  • the transaction request and transaction response is communicated to the payment terminal over a public communication network.
  • the credit media is a credit card.
  • a credit card is very common, when paying for a service or good.
  • the invention further comprises a system comprising a payment terminal, at least one acquirer, said acquirer representing at least one credit central and a payment server for performing the method described above.
  • the payment terminal is adapted for: - receiving credit media information from a credit media
  • the invention comprises a payment terminal for transmitting transaction requests to at least one acquirer and receiving transaction responds from said acquirer, said acquirer representing at least one credit central, said payment terminal being adapted for: transmitting a transaction request to a payment server, said transaction being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, the server being adapted for communicating with the acquirer identified by the credit media data using a second communication rule selected from a set of specific communication rules, receiving a transaction response from said payment server, said transaction response being communicated according to said first communication rule.
  • the payment terminal is adapted for storing said transmitted transaction request and said received transaction response.
  • the credit media is a credit card and the credit card data is entered using a credit card reader being connected to the payment terminal.
  • the payment terminal could e.g. be a mobile payment terminal.
  • the hardware could e.g. be adapted by installing an application (Mobile Payment Application) into the hardware, enabling the hardware to function as a payment terminal.
  • the MPA could be installed in PDA's already taking care of table reservations, meal and drinks ordering and maybe taxi and ticket booking. This could be a Symbol Palm Pilot 1740 with a Spectrum 24 wireless communication to the LAN and from there through the company router to the Internet.
  • the built-in scanner would give easy access to reading meals directly from the menu using barcodes. Companies developing these applications would integrate the MPA to be called whenever the payment situation occurred between customer and waiter.
  • PC's serving as tills in shops either on a fixed basis but not necessarily - PC's could also be mobile in the sense that their connection to the LAN could be through wireless communication such as Spectrum 24 from Symbol.
  • the till would of course serve as the POS-terminal solving pricing issues, stock issues, receipts and in case of credit payments the POS-application would call the MPA application to generate and handle the appropriate transactions to and from the acquirer.
  • the system can support mobile and fixed terminals and handle transactions to be charged to credit accounts using existing and future credit media such as credit cards, chip cards, "'Blue Tooth” -based credit media etc.
  • a future solution may be a new terminal with Blue-Tooth (micro LAN) technology, which can communicate with a Blue-Tooth based credit media (i.e. a mobile phone) and negotiate authenticity and a PIN-code entered on the customers credit media (i.e. mobile phone) .
  • Blue-Tooth micro LAN
  • the integration possibilities with other applications within the payment terminal can be ensured, by using open development standards and open integration standards. This allows other applications to call the MPA- application whenever a payment situation occurs.
  • the real value add becomes visible when service application ends up in a business transaction giving the customer a service/goods for which a payment becomes due and this can be handled as a part of the total process - just as we know it from retailers in shops using fixed terminals
  • Connection to a payment server or payment server supplier can be done by various means.
  • Local in-house fixed terminals i.e. PC's, tills etc.
  • the in-house wireless terminals can communicate via the wireless network (wireless LAN, GSM in all its forms around the world, GRPS, UTMS) .
  • the transmission of classified data from the payment terminal to the payment server supplier through open networks as the Internet could be secured by encrypting the data according to open standards such as SSL.
  • the transmission between the payment server and the acquirer must follow certain specifications drawn up by the individual acquirers.
  • the payment server is a system with a unique structure, this structure can e.g. be obtained using AGETOR ® as a building block which is an application that is specially designed to handle and convert large amounts of information.
  • AGETOR ® makes it possible for the payment server to separate the payment terminal and the acquirer. Therefore an additional application to meet the specifications for communication with a new acquirer is easily allowed by the systems structure.
  • fig. 1 shows a data flow diagram of an embodiment of the payment transaction system according to the invention
  • fig. 2 shows a block diagram of an embodiment of the payment transaction from the payment device with the MPA to the ISP with the IPS-application;
  • fig. 3 shows a data flow diagram of the payment transaction process according to an embodiment of the invention
  • fig. 4 shows a data flow diagram of an embodiment of the software components of the mobile payment application according to the invention.
  • fig. 5 shows a data flow diagram of an embodiment of the software components of the Internet payment server.
  • Fig. 1 shows the principle of two embodiments of the invention using a restaurant as an example. The invention is however, not restricted to restaurants. Fig. 1 may be explained as follows:
  • a restaurant 10 has three waiters that move among the tables. Two of the waiters have a PDA (Personal Digital Assistant) 11 and 12 and work among the tables and one waiter uses a fixed terminal 13 in the bar. All payment terminals have applications installed for reviewing orders and sending the orders to the kitchen by wireless communication or other. When a table is ready to pay any of the three waiters can by using their payment terminal easily receive payment by credit media either at the table (waiter 11 or 12) or by the bar (waiter 13) . The applications in the terminal are interfaced so the payment system already has the necessary data regarding the amount payable.
  • the credit media data is entered into the payment terminal in a preferred embodiment by sliding a credit card through a magnetic card reader.
  • the payment terminal connects to the restaurants communication platform 14, which has connection to the IPS 40 over the Internet 30 in a preferred embodiment of the payment system.
  • the data is transmitted to the IPS (Internet Payment Server) , which in this embodiment is supplied by the ISP (Internet Service Provider) .
  • the IPS establishes the connection 60 to the relevant acquirer 50 consistent with the specifications or communication rules required by the acquirer.
  • the acquirer authorizes the transaction and sends back the necessary data to confirm or reject the transaction by the connection 60 to the IPS.
  • the IPS transmits the data back to the payment terminal, which displays the result of the transaction.
  • connection to the payment server 40 could bee direct through GSM or any other network.
  • a first embodiment of a payment system comprising an MPA (Mobile Payment Application) -device 204 such as a PDA, a connection 205 to a network 206 such as the Internet and a payment server supplier 208 such as an Internet service provider.
  • the MPA-device is an open hardware device, which can contain other applications 203 besides the MPA.
  • the MPA can interface 201 with other applications by the means of advanced programming interface.
  • the payment server can support the secured line to the acquirer in concordance with the specifications of the acquirer. Thus if the payment server supplier wants to be able to connect with other acquirers an additional application that can support a secured line in concordance with other specifications and new acquirers can be installed.
  • Part of the payment server can deliver a local payment server which allows e.g. the restaurant to monitor the transaction and install applications in accordance with specific needs e.g. currency.
  • Embodiments of the MPA 202 according to the invention are further described in connection with fig. 4 and embodiments of the IPS 209 are further described in connection with fig. 5.
  • Fig. 3 illustrates a flow diagram of the payment clearance process.
  • Fig. 3 also illustrates whether the individual process steps are performed by, or under control of, the MPA-device user 401, the IPS provider 402 or the acquirer 403.
  • the payment transactions begin with the payable amount being entered to the MPA-device 410.
  • the credit media data is then entered to the MPA-device 411. This could be a credit card swiped through an MSR.
  • the MPA prepares the data to be sent by a secure line 412 in a preferred embodiment by the means of cryptographic tools.
  • the data is then sent to the IPS provider by the means of a network such as the Internet.
  • the IPS receives the data according to the secured line 414.
  • the transaction is logged 415 and statistical data is filled in order to be able to provide the MPA user additional services such as scripts of transactions completed.
  • the IPS identifies the credit media and selects connection and the specifications corresponding to the acquirer matching the credit media and sends the data by secured line defined by the acquirer 416.
  • the acquirer receives the data 417 and performs the authorization that is necessary to validate the credit media and complete the transaction 418.
  • the data verifying or denying the transaction is sent by the secured line 419 back to the IPS 420.
  • the IPS logs the transaction 421 and sends the data by a secured line 422 to the MPA 423 were the transaction is acknowledged or denied 424.
  • Fig 4 shows the flowchart of an embodiment of the MPA.
  • the application initiates the process by checking the hardware and software to see if the hardware is in good status and the software is a legal copy 502. The user is also checked in a preferred embodiment by the means of an access code. If there is an error in this configuration check the program is ended 520. If the configuration check follows through the amount payable is entered 502 by the means of the MPA-device and the credit media data is entered 503 also by the means of the MPA-device which might be by an MSR. The MPA now ensures the process of receiving credit data 504. If there has been an error in this process the program starts again 530. The process is logged 505.
  • the MPA secures the connection to the server 506 in a preferred embodiment by the means of cryptographic tools. If somebody is attempting to interfere with this transaction the MPA will alert the user 550 and cancel the transaction 551, and record all the information of this login 552. When the secured connection to the server is established the data is send 507. The transaction is then approved 508 and the MPA will finish the transaction 509 and write a log file 510. If the transaction is denied 540 the MPA will stop the transaction and write a log file 541.
  • Fig. 5 shows a flowchart of an embodiment of the IPS. To initiate this part of the payment transaction the IPS accepts the connection 601 and checks if the secured line is ok 602. If the secured line is not ok a security alert 630 will close the connection.
  • the MPA ID and user ID is checked 603 against a database 620. In this step it ensures that if an MPA-device is lost it is possible to close the connection. If this step is not successful a security alert 630 will close the connection. If the verification is successful the IPS will receive the data from the MPA 604 and the transaction is logged 605. This step allows the IPS provider to offer the MPA user additional services such as transcript of transactions. The IPS identifies the credit media and matches it with the corresponding acquirer. The IPS establishes connection to the acquirer 606 by using a secured communication defined by the individual acquirer. If this connection fails a security alert 640 will close the connection and send an error message to the MPA and close connection with MPA.
  • connection is in order the data is transmitted 607 to the acquirer and data is received back. This process is logged within the IPS and an approval or disapproval of the transaction is sent to the MPA 609. The acquirer is then sent data to ensure that the transaction is finished 610.
  • At least part of the invention may be embodied as a computer program or a part of a computer program, which may be loaded into the memory of a computer and executed there from.
  • the computer program may be distributed by means of any data storage or data transmission medium.
  • the storage media can be magnetic tape, optical disc, compact disc (CD or CD-ROM) , mini-disc, hard disk, floppy disk, ferro-electric memory, electrically erasable programmable read only memory (EEPROM) , flash memory, EPROM, read only memory (ROM) , static random access memory (SRAM) , dynamic random access memory (DRAM) , ferromagnetic memory, optical storage, charge coupled devices, smart cards, etc.
  • the transmission medium can be a network, e.g.
  • the network may comprise wire and wire-less communication links .
  • a software embodiment i.e. a program of the invention, or a part thereof, may be distributed by transferring a program via the network.
  • IPS Internet Payment server
  • GSM Global System for Mobile communications

Abstract

This invention relates to a method for communicating a transaction between a payment terminal and at least one acquirer. The acquirer represents one or more credit centrals, such as VISA, Euro Card and Diners. A payment service communicates with payment terminals using a first predefined communication rule and a second communication rule is used for communication between the acquirer and the payment server. The payment server selects the second communication rule according to the acquirer. A more flexible payment system is thereby obtained.

Description

A method for communicating a transaction between a payment terminal and at least one acquirer.
FIELD OF THE INVENTION The invention relates to a method for communicating a transaction between a payment terminal and at least one acquirer, said acquirer representing at least one credit central. The invention further relates to a system and a storage medium with a software application for performing the method. The invention also relates to payment terminal for transmitting transaction requests to at least one acquirer and receiving transaction responds from said acquirer, said acquirer representing at least one credit central.
BACKGROUND OF THE INVENTION
Today it has become more and more common to use credit cards when paying for goods or services. Today a credit card can be provided from a number of different providers such as (VISA, Euro Card, American Express, etc.) and the number of providers will probably increase in the coming years.
Because of the popularity of using credit cards more and more people often only have one or more credit cards and is only able to buy from a service- or good provider if the service- or good provider accepts the specific credit card. Whether the credit card is accepted can therefore be crucial when the costumer decides where to buy the service or good. Hence it is very important for a service or good provider that a number of specific credit cards can be accepted.
Normally when performing transactions with a credit card the transaction is not communicated directly to the credit card provider, instead an acquirer representing a number of credit card providers handles it. The acquirer can e.g. be a credit card provider handling a number of different credit cards.
In order for a service or good provider to be able to accept credit cards it is necessary to install a specific terminal adapted for reading a credit card. This terminal communicates with an acquirer, selected by the service or good provider. The communication is made through a closed line, assuring the safety of the data communicated between the acquirer and the terminal. Typically the acquirer has to certify both the terminal and the communication line according to some predefined specific certification rules defined by the acquirer. The terminal is typically hardware based and most of the logic has been built into the hardware of the terminal in order to fulfill the certification rules specified by the acquirer. The certification rules could e.g. be communication rules defining in what format the data must be communicated and how the data must be communicated.
Often the certification rules vary from one acquirer to another acquirer. Therefore if a service or good provider is interested in being able to accept credit cards from different acquirers it could be necessary to upgrade the already installed terminal or the new acquirer would have to make some agreement with the acquirer already connected.
It can therefore be both a very cumbersome and expensive process for both the acquirer and the service or good provider to install a terminal for transferring transaction data to the acquirer. Further because of the hardware based logic in the terminal. It is necessary to have a specific piece of hardware for accepting the credit card and the terminal function can therefore not be added in existing devices, such as PDA's already used by the service or good provider.
A further problem is that the existing solutions focus entirely on the payment transaction and the terminals have therefore been built for this purpose only. Therefore the existing solution does not allow easy integration with other applications, which could be necessary if the client wants integration of the entire business system.
In general the problems with the prior art therefore mainly consist of closed and inflexible payment systems.,
In EP 0484198-A1 and US patent 5,387,784 a payment system that can handle credit card payments on a mobile device is disclosed. This system is not for performing credit card transactions but only for performing an online check up on the validity of the credit card.
OBJECT AND SUMMARY OF THE INVENTION
It is an object of the invention to provide a method solving the above-mentioned problems .
This is obtained by a method for communicating a transaction between a payment terminal and at least one acquirer, said acquirer representing at least one credit central, said method comprising the steps of: - receiving a transaction request from a payment terminal, said transaction being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, selecting a second communication rule between a predefined set of communication rules, each of said communication rules being specific for at least one acquirer, said selected communication rule belonging to the acquirer representing the credit central identified by said credit media data, transmitting the transaction request to said acquirer, said transaction request being communicated according to said selected second communication rule.
In a further embodiment of the invention the method further comprises the steps of: receiving transaction response from the acquirer, said transaction response being communicated according to the selected second communication rule, transmitting at least part of said transaction response to said payment terminal.
A Payment Server could e.g. perform the method using the Internet (Internet Payment Server, IPS) and the credit central could e.g. be a credit card central.
The invention separates communication between the payment terminal and acquirer in two parts. The first part is the communication between a payment server and the payment terminals using first communication rules and the second part is the communication between the payment server and the acquirers using different communication rules according to the demands of the acquirers. This payment server separately handles the specific communication rules w th the acquirers and the payment terminals. When specifications change due to e.g. a new acquirer it is only necessary to adjust the payment server communicating with the acquirer instead of all the payment terminals .
An advantage of the invention is that the communication rules used between the payment server and the payment terminals do not have to be so advanced as the communication rules defined by the acquirers used between the payment server and the acquirers. It is only the payment server that has to be able to fulfill these advanced communication rules, which can be very hardware demanding. It is thereby obtained that a simpler communication rule can be used, which e.g. could be adapted on different pieces of existing hardware, which then could be used as payment terminals. Examples of existing hardware are described below. It is thereby also possible with a total integration of the payment terminals with the rest of the system in e.g. a service or good provider.
In an embodiment the invention further comprises the step of storing said received transaction request and said received transaction response. Thereby the payment server can handle and log the large amount of highly sensitive information and the user can if necessary review backup of all payment transactions.
It makes it possible to give the service or good provider e.g. a restaurant access to monitor the transactions by giving access to a part of the payment server, this accessed part is in the following also denoted as a local payment server LPS. By letting the service or good provider access a part of the payment server the LPS it could e.g. be possible to easily install applications in accordance with specific needs e.g. currency without giving the user access to the highly sensitive information that only should be received by the acquirer.
In another embodiment the invention further comprises the step of:
- verifying that the payment terminal communicating the transaction request is accepted, and only . transmitting the transaction request to the acquirer if said payment terminal is accepted.
Thereby security is obtained, if the transaction is not accepted, then it will never be transmitted to the acquirer.
In a specific embodiment the transaction request and transaction response is communicated to the payment terminal over a public communication network. Thereby flexibility is obtained and it is easy for a new service or good provider to get connected to the system.
In a specific embodiment the credit media is a credit card. Using a credit card is very common, when paying for a service or good.
The invention further comprises a system comprising a payment terminal, at least one acquirer, said acquirer representing at least one credit central and a payment server for performing the method described above.
In a specific embodiment the payment terminal is adapted for: - receiving credit media information from a credit media,
- transmitting a transaction request according to a first communication rule, said transaction request comprising said credit media data identifying a link between the credit media and a specific credit central,
- receiving transaction response, said transaction response being communicated according to said first communication rule. The invention comprises a payment terminal for transmitting transaction requests to at least one acquirer and receiving transaction responds from said acquirer, said acquirer representing at least one credit central, said payment terminal being adapted for: transmitting a transaction request to a payment server, said transaction being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, the server being adapted for communicating with the acquirer identified by the credit media data using a second communication rule selected from a set of specific communication rules, receiving a transaction response from said payment server, said transaction response being communicated according to said first communication rule.
In yet another embodiment the payment terminal is adapted for storing said transmitted transaction request and said received transaction response.
In a specific embodiment the credit media is a credit card and the credit card data is entered using a credit card reader being connected to the payment terminal.
Because of the defined communication between the payment terminal and the payment server, it is possible to adapt a wide range of hardware to be used as a payment terminal. The payment terminal could e.g. be a mobile payment terminal. The hardware could e.g. be adapted by installing an application (Mobile Payment Application) into the hardware, enabling the hardware to function as a payment terminal. The MPA could be installed in PDA's already taking care of table reservations, meal and drinks ordering and maybe taxi and ticket booking. This could be a Symbol Palm Pilot 1740 with a Spectrum 24 wireless communication to the LAN and from there through the company router to the Internet. The built-in scanner would give easy access to reading meals directly from the menu using barcodes. Companies developing these applications would integrate the MPA to be called whenever the payment situation occurred between customer and waiter.
In PC's serving as tills in shops either on a fixed basis but not necessarily - PC's could also be mobile in the sense that their connection to the LAN could be through wireless communication such as Spectrum 24 from Symbol. The till would of course serve as the POS-terminal solving pricing issues, stock issues, receipts and in case of credit payments the POS-application would call the MPA application to generate and handle the appropriate transactions to and from the acquirer.
In future PDA's and tills being developed to serve the physical trading situations around the world from companies like Compaq, HP, Sony, and Psion etc.
The system can support mobile and fixed terminals and handle transactions to be charged to credit accounts using existing and future credit media such as credit cards, chip cards, "'Blue Tooth" -based credit media etc.
This is ensured by the openness of the system where the payment server creates the secure communication between the retailer and the acquirer, leaving options as to how a credit media is produced, read and authenticated at the retailer. Therefore a future solution may be a new terminal with Blue-Tooth (micro LAN) technology, which can communicate with a Blue-Tooth based credit media (i.e. a mobile phone) and negotiate authenticity and a PIN-code entered on the customers credit media (i.e. mobile phone) .
The integration possibilities with other applications within the payment terminal can be ensured, by using open development standards and open integration standards. This allows other applications to call the MPA- application whenever a payment situation occurs. The real value add becomes visible when service application ends up in a business transaction giving the customer a service/goods for which a payment becomes due and this can be handled as a part of the total process - just as we know it from retailers in shops using fixed terminals
Connection to a payment server or payment server supplier can be done by various means. Local in-house fixed terminals (i.e. PC's, tills etc.) can be communicating via the existing network and the in-house wireless terminals can communicate via the wireless network (wireless LAN, GSM in all its forms around the world, GRPS, UTMS) .
The transmission of classified data from the payment terminal to the payment server supplier through open networks as the Internet could be secured by encrypting the data according to open standards such as SSL.
The transmission between the payment server and the acquirer must follow certain specifications drawn up by the individual acquirers. The payment server is a system with a unique structure, this structure can e.g. be obtained using AGETOR ® as a building block which is an application that is specially designed to handle and convert large amounts of information. AGETOR ® makes it possible for the payment server to separate the payment terminal and the acquirer. Therefore an additional application to meet the specifications for communication with a new acquirer is easily allowed by the systems structure.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be explained more fully below in connection with preferred embodiments and with reference to the drawings, in which:
fig. 1 shows a data flow diagram of an embodiment of the payment transaction system according to the invention;
fig. 2 shows a block diagram of an embodiment of the payment transaction from the payment device with the MPA to the ISP with the IPS-application;
fig. 3 shows a data flow diagram of the payment transaction process according to an embodiment of the invention;
fig. 4 shows a data flow diagram of an embodiment of the software components of the mobile payment application according to the invention; and
fig. 5 shows a data flow diagram of an embodiment of the software components of the Internet payment server.
DESCRIPTION OF PREFERRED EMBODIMENTS
Fig. 1 shows the principle of two embodiments of the invention using a restaurant as an example. The invention is however, not restricted to restaurants. Fig. 1 may be explained as follows:
A restaurant 10 has three waiters that move among the tables. Two of the waiters have a PDA (Personal Digital Assistant) 11 and 12 and work among the tables and one waiter uses a fixed terminal 13 in the bar. All payment terminals have applications installed for reviewing orders and sending the orders to the kitchen by wireless communication or other. When a table is ready to pay any of the three waiters can by using their payment terminal easily receive payment by credit media either at the table (waiter 11 or 12) or by the bar (waiter 13) . The applications in the terminal are interfaced so the payment system already has the necessary data regarding the amount payable. The credit media data is entered into the payment terminal in a preferred embodiment by sliding a credit card through a magnetic card reader. The payment terminal connects to the restaurants communication platform 14, which has connection to the IPS 40 over the Internet 30 in a preferred embodiment of the payment system. The data is transmitted to the IPS (Internet Payment Server) , which in this embodiment is supplied by the ISP (Internet Service Provider) . The IPS establishes the connection 60 to the relevant acquirer 50 consistent with the specifications or communication rules required by the acquirer. The acquirer authorizes the transaction and sends back the necessary data to confirm or reject the transaction by the connection 60 to the IPS. The IPS transmits the data back to the payment terminal, which displays the result of the transaction.
Had it been a restaurant 20 with only one payment terminal 21 the connection to the payment server 40 could bee direct through GSM or any other network.
Now referring to Fig. 2, a first embodiment of a payment system according to the invention comprising an MPA (Mobile Payment Application) -device 204 such as a PDA, a connection 205 to a network 206 such as the Internet and a payment server supplier 208 such as an Internet service provider. The MPA-device is an open hardware device, which can contain other applications 203 besides the MPA. The MPA can interface 201 with other applications by the means of advanced programming interface. The payment server can support the secured line to the acquirer in concordance with the specifications of the acquirer. Thus if the payment server supplier wants to be able to connect with other acquirers an additional application that can support a secured line in concordance with other specifications and new acquirers can be installed. Part of the payment server can deliver a local payment server which allows e.g. the restaurant to monitor the transaction and install applications in accordance with specific needs e.g. currency. Embodiments of the MPA 202 according to the invention are further described in connection with fig. 4 and embodiments of the IPS 209 are further described in connection with fig. 5.
Fig. 3 illustrates a flow diagram of the payment clearance process. Fig. 3 also illustrates whether the individual process steps are performed by, or under control of, the MPA-device user 401, the IPS provider 402 or the acquirer 403. The payment transactions begin with the payable amount being entered to the MPA-device 410. The credit media data is then entered to the MPA-device 411. This could be a credit card swiped through an MSR. The MPA prepares the data to be sent by a secure line 412 in a preferred embodiment by the means of cryptographic tools. The data is then sent to the IPS provider by the means of a network such as the Internet. The IPS receives the data according to the secured line 414. The transaction is logged 415 and statistical data is filled in order to be able to provide the MPA user additional services such as scripts of transactions completed. The IPS identifies the credit media and selects connection and the specifications corresponding to the acquirer matching the credit media and sends the data by secured line defined by the acquirer 416. The acquirer receives the data 417 and performs the authorization that is necessary to validate the credit media and complete the transaction 418. The data verifying or denying the transaction is sent by the secured line 419 back to the IPS 420. The IPS logs the transaction 421 and sends the data by a secured line 422 to the MPA 423 were the transaction is acknowledged or denied 424.
Fig 4 shows the flowchart of an embodiment of the MPA. The application initiates the process by checking the hardware and software to see if the hardware is in good status and the software is a legal copy 502. The user is also checked in a preferred embodiment by the means of an access code. If there is an error in this configuration check the program is ended 520. If the configuration check follows through the amount payable is entered 502 by the means of the MPA-device and the credit media data is entered 503 also by the means of the MPA-device which might be by an MSR. The MPA now ensures the process of receiving credit data 504. If there has been an error in this process the program starts again 530. The process is logged 505. The MPA secures the connection to the server 506 in a preferred embodiment by the means of cryptographic tools. If somebody is attempting to interfere with this transaction the MPA will alert the user 550 and cancel the transaction 551, and record all the information of this login 552. When the secured connection to the server is established the data is send 507. The transaction is then approved 508 and the MPA will finish the transaction 509 and write a log file 510. If the transaction is denied 540 the MPA will stop the transaction and write a log file 541. Fig. 5 shows a flowchart of an embodiment of the IPS. To initiate this part of the payment transaction the IPS accepts the connection 601 and checks if the secured line is ok 602. If the secured line is not ok a security alert 630 will close the connection. The MPA ID and user ID is checked 603 against a database 620. In this step it ensures that if an MPA-device is lost it is possible to close the connection. If this step is not successful a security alert 630 will close the connection. If the verification is successful the IPS will receive the data from the MPA 604 and the transaction is logged 605. This step allows the IPS provider to offer the MPA user additional services such as transcript of transactions. The IPS identifies the credit media and matches it with the corresponding acquirer. The IPS establishes connection to the acquirer 606 by using a secured communication defined by the individual acquirer. If this connection fails a security alert 640 will close the connection and send an error message to the MPA and close connection with MPA. If connection is in order the data is transmitted 607 to the acquirer and data is received back. This process is logged within the IPS and an approval or disapproval of the transaction is sent to the MPA 609. The acquirer is then sent data to ensure that the transaction is finished 610.
At least part of the invention may be embodied as a computer program or a part of a computer program, which may be loaded into the memory of a computer and executed there from. The computer program may be distributed by means of any data storage or data transmission medium. The storage media can be magnetic tape, optical disc, compact disc (CD or CD-ROM) , mini-disc, hard disk, floppy disk, ferro-electric memory, electrically erasable programmable read only memory (EEPROM) , flash memory, EPROM, read only memory (ROM) , static random access memory (SRAM) , dynamic random access memory (DRAM) , ferromagnetic memory, optical storage, charge coupled devices, smart cards, etc. The transmission medium can be a network, e.g. a local area network (LAM), a wide area network (WAN), or any combination thereof, e.g. the Internet. The network may comprise wire and wire-less communication links . Via the network a software embodiment (i.e. a program) of the invention, or a part thereof, may be distributed by transferring a program via the network.
In the above description an IPS (Internet Payment server) is mentioned, the Payment server will of cause also be able to communicate with both the payment terminal and the acquirer user other public communication networks, such as GSM.

Claims

1. A method for communicating a transaction between a payment terminal and at least one acquirer, said acquirer representing at least one credit central, said method comprising the steps of: receiving a transaction request from a payment terminal, said transaction request being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, selecting a second communication rule between a predefined set of communication rules, each of said communication rules being specific for at least one acquirer, said selected communication rule belonging to the acquirer representing the credit central identified by said credit media data, transmitting the transaction request to said acquirer, said transaction request being communicated according to said selected second communication rule.
2. A method according to claim 1, wherein the method further comprises the steps of: - receiving transaction response from the acquirer, said transaction response being communicated according to the selected second communication rule, transmitting at least part of said transaction response to said payment terminal using said first communication rules.
3. A method according to claim 1-2, further comprising the step of: storing said received transaction request and said received transaction response.
4. A method according to claim 1-3, further comprising the step of:
- verifying that the payment terminal communicating the transaction request is accepted, and only transmitting the transaction request to the acquirer if said payment terminal is accepted.
5. A method according to claim 1-4, wherein the transaction request and transaction response is communicated to the payment terminal over a public communication network.
6. A method according to claim 1-5, wherein the credit media is a credit card.
7. A program storage device readable by a machine and encoding a program of instructions for executing the method defined in claim 1-6.
8. A system comprising a payment terminal, at least one acquirer, said acquirer representing at least one credit central and a payment server for performing the method defined in any of the claims 1-6.
9. A system according to claim 8, wherein the payment terminal is adapted for: receiving credit media information from a credit media, transmitting a transaction request according to a first communication rule, said transaction request comprising said credit media data identifying a link between the credit media and a specific credit central,
- receiving transaction response, said transaction response being communicated according to said first communication rule.
10. A system according to claim 8-9, wherein said transaction request and said received transaction response stored on said payment server can be accessed by said payment terminal.
11. A system according to claim 8-10, wherein the payment terminal is a mobile payment terminal.
12. A payment terminal for transmitting transaction requests to at least one acquirer and receiving transaction responds from said acquirer, said acquirer representing at least one credit central, said payment terminal being adapted for: transmitting a transaction request to a payment server, said transaction request being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, the server being adapted for communicating with the acquirer identified by the credit media data using a second communication rule selected from a set of specific communication rules,
- receiving a transaction response from said payment server, said transaction response being communicated according to said first communication rule.
13. A payment terminal according to claim 12, wherein the payment terminal is adapted for storing said transmitted transaction request and said received transaction response.
14. A payment terminal according to claim 12 or 13, wherein the payment server is adapted to store the received transaction request and transmitted transaction response and wherein the payment terminal can access said stored transaction request and transaction response.
15. A payment terminal according to claim 12-14, wherein the credit media is a credit card and wherein the credit card data is entered using a credit card reader being connected to said payment terminal.
16. A method for communicating transaction requests with at least one acquirer, said acquirer representing at least one credit central, said method comprising the steps of: transmitting a transaction request to a payment server, said transaction request being communicated according to a first communication rule, said transaction request comprising credit media data identifying a link between the credit media and a specific credit central, the payment server being adapted for communicating with the acquirer identified by the credit media data using a second communication rule selected from a set of specific communication rules, receiving a transaction response from said payment server, said transaction response being communicated according to said first communication rule.
17. A method according to claim 16, further comprising the step of storing said transmitted transaction request and said received transaction response.
18. A program storage device readable by a machine and encoding a program of instructions for executing the method defined in claim 16 or 17.
PCT/DK2001/000832 2000-12-15 2001-12-17 A method for communicating a transaction between a payment terminal and at least one acquirer WO2002048974A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002221574A AU2002221574A1 (en) 2000-12-15 2001-12-17 A method for communicating a transaction between a payment terminal and at leastone acquirer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DKPA200001883 2000-12-15
DKPA200001883 2000-12-15

Publications (1)

Publication Number Publication Date
WO2002048974A1 true WO2002048974A1 (en) 2002-06-20

Family

ID=8159909

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DK2001/000832 WO2002048974A1 (en) 2000-12-15 2001-12-17 A method for communicating a transaction between a payment terminal and at least one acquirer

Country Status (2)

Country Link
AU (1) AU2002221574A1 (en)
WO (1) WO2002048974A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120095905A1 (en) * 2010-10-14 2012-04-19 Syniverse Technologies, Inc. Payment gateway for processing payment requests associated with a wireless users account

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997049069A2 (en) * 1996-06-17 1997-12-24 Verifone, Inc. A system, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture
WO1998052151A1 (en) * 1997-05-15 1998-11-19 Access Security Sweden Ab Electronic transaction
WO1999046881A1 (en) * 1998-03-11 1999-09-16 Guardtech Technologies Ltd. Transaction card security system
US6012144A (en) * 1996-10-08 2000-01-04 Pickett; Thomas E. Transaction security method and apparatus
US6016476A (en) * 1997-08-11 2000-01-18 International Business Machines Corporation Portable information and transaction processing system and method utilizing biometric authorization and digital certificate security
WO2000011624A1 (en) * 1998-08-25 2000-03-02 Telefonaktiebolaget Lm Ericsson (Publ) Smart card wallet

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997049069A2 (en) * 1996-06-17 1997-12-24 Verifone, Inc. A system, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture
US6012144A (en) * 1996-10-08 2000-01-04 Pickett; Thomas E. Transaction security method and apparatus
WO1998052151A1 (en) * 1997-05-15 1998-11-19 Access Security Sweden Ab Electronic transaction
US6016476A (en) * 1997-08-11 2000-01-18 International Business Machines Corporation Portable information and transaction processing system and method utilizing biometric authorization and digital certificate security
WO1999046881A1 (en) * 1998-03-11 1999-09-16 Guardtech Technologies Ltd. Transaction card security system
WO2000011624A1 (en) * 1998-08-25 2000-03-02 Telefonaktiebolaget Lm Ericsson (Publ) Smart card wallet

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120095905A1 (en) * 2010-10-14 2012-04-19 Syniverse Technologies, Inc. Payment gateway for processing payment requests associated with a wireless users account
US9911103B2 (en) * 2010-10-14 2018-03-06 Syniverse Technologies, Llc Payment gateway for processing payment requests associated with a wireless users account

Also Published As

Publication number Publication date
AU2002221574A1 (en) 2002-06-24

Similar Documents

Publication Publication Date Title
US10643180B2 (en) Fraud detection system automatic rule population engine
US11379818B2 (en) Systems and methods for payment management for supporting mobile payments
KR101015341B1 (en) Online payer authentication service
US9530125B2 (en) Method and system for secure mobile payment transactions
US20190259020A1 (en) Enrollment server
US6980970B2 (en) Secure networked transaction system
US20170039563A1 (en) Secure authentication and payment system
US10956899B2 (en) Mechanism to allow the use of disposable cards on a system designed to accept cards conforming to the standards of the global payments industry
US20080048025A1 (en) Method for Electronic Payment
US20090063312A1 (en) Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions
US20130212006A1 (en) Fraud detection system automatic rule manipulator
US20070094113A1 (en) Transactional mobile system
CN102844776A (en) Payment channel returning limited use proxy dynamic value
KR20040035849A (en) Mobile digital receipts
KR20140037213A (en) System and method of multi-factor balance inquiry and electronic funds transfer
WO2015051074A1 (en) Enabling synchronization between disparate payment account systems
WO2007121316A2 (en) Payment processing support device and method
US20030120590A1 (en) Electronic settlement method and system
KR100897498B1 (en) Total finance service system in ubiquitous environment
WO2002048974A1 (en) A method for communicating a transaction between a payment terminal and at least one acquirer
WO2007029123A2 (en) System and method for processing transactions
KR20090018761A (en) System and method for check card payment by using virtual account and program recording medium
KR20090097839A (en) System for check card payment by using virtual account
WO2006044213A2 (en) A method for electronic payment
KR20090018760A (en) System and method for issuing check card and program recording medium

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP