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.