WO2007144708A1

WO2007144708A1 - Method of secure payment over a network

Info

Publication number: WO2007144708A1
Application number: PCT/IB2007/001230
Authority: WO
Inventors: Kean Hoe Au
Original assignee: Kean Hoe Au
Priority date: 2006-06-09
Filing date: 2007-05-07
Publication date: 2007-12-21

Abstract

A secure transaction is carried out by a merchant application which provides details of the customer bank and the transaction amount to a host system (104) and receives a transaction identifier. The merchant provides the customer with the identifier. The customer uses the bank's online banking and enters the transaction identifier. The specified bank (106) verifies the transaction identifier and the transaction amount with the host system, and then approves the transaction. The bank then advises the host system which advises the merchant to release the purchased goods or services.

Description

METHOD OF SECURE PAYMENT OVER A NETWORK

Field of the Invention

The invention generally relates to the secure payment of transactions. More particularly the invention relates to the secure payment of transactions at a remote merchant vendor.

Background of the Invention

It is known to carry out transactions with a remote merchant over the internet by an online transaction with a credit card. Typically with such transactions some 6% of the purchase price is seconded to the credit card authority rather than the merchant, and there is a risk that the site which the user interacts with is not a real site but a phisbing site imitating a real site, in which case the payment may be lost. This may result in the owner having to cancel his/her credit card that is used to make the payment to avoid further credit card frauds.

Published international patent application WO 01/54038 Al outlines a secure system for online purchase in which the buyer's browser session is routed to a secure host server through which the buyer views merchant sites, and the buyer makes online purchases where the transaction is captured by the host server, an identification number passed to the buyer, and buyer identification data and the identification number transmitted to a buyer bank by the host server. Following this the buyer browses to the bank site and authorises a transaction with the merchant using the identification number. Once the transaction is approved the host server is advised of the success and carries out the required purchase. Such a system requires downloaded software at the buyer's computer to divert the browser to the host server site, which is a major disadvantage. Furthermore, the buyer's computer has to communicate with the host server to initiate the payment process. The present invention provides a solution to this and other problems which offers advantages over the prior art. It is acknowledged that the term 'comprise' may, under varying jurisdictions, be attributed with either an exclusive or an inclusive meaning. For the purpose of this specification, and unless otherwise noted, the term 'comprise' shall have an inclusive meaning - i.e. that it will be taken to mean an inclusion of not only the listed components it directly references, but also other non-specified components or elements. This rationale will also be used when the term 'comprised', 'comprising' or the like is used in relation to one or more steps in a method or process.

Summary of the Invention

In one exemplification the invention consists in a transaction system comprising: a host server including: a communicator for communicating with a merchant computer system and a transaction authority, and a transaction identifier generator generating a unique transaction identification code for any proposed transaction; a merchant computer system communicator communicating with the host server and transferring to it at least information relating to a proposed transaction, and receiving from it at least a transaction identification code, and confirmation of any transaction with a transaction authority involving the transaction identification code; a buyer computer receiving from a merchant computer system the transaction identification code and communicating with a communication device to the transaction authority at least the transaction identification code to authorise the transaction; a transaction authority communicator communicating with the host server after receiving the transaction authorisation information from said buyer computer; and a transaction verifier comparing and verifying at least the transaction identification code received by the transaction authority communicator with that stored by the host server, and generating authorisation of a transaction involving the transaction identification code when the two sets of data match. Preferably the information communicated by the buyer computer to the transaction authority includes the transaction amount or another identifier relating to the transaction. A suitable other identifier is the merchant's purchase order number or reference.

Preferably the transaction authority carries out a transaction for the specified amount on receipt and verification of the information provided by the buyer computer. Preferably the transaction amount is divided into two portions, the merchant account being credited with one portion and the host server owner with the other portion.

Preferably the buyer communication device is an internet browser. Preferably the merchant computer system is an internet purchase site and all communications are via the internet and/or virtual private network.

Preferably the transaction authority is a bank or a card-issuing company or any banking company.

Preferably the identification code is formatted to include an identification for the merchant. Alternatively the invention lies in a method of carrying out an internet transaction comprising: providing a merchant computer system including a merchant transaction initiating process; providing a host server under control of a hosting authority and capable of interacting with a merchant transaction initiating process; on intended purchase of goods or services by a buyer from the merchant: requiring the buyer to choose a transaction authority; initiating a transaction process with the host server comprising: transferring from merchant computer system to host server information sufficient to identify at least the merchant, the buyer's chosen transaction authority and the amount; generating and transferring from the host server to the merchant computer system an identification code identifying the transaction; requiring the buyer to initiate a transaction process with the chosen transaction authority comprising: identifying the host authority; specifying at least the transaction identification code; comparing and verifying the transaction identification code provided by the buyer with that stored by the host server; the transaction authority then: carrying out the transaction by crediting at least the merchant if the verification is successful; refusing the transaction if the verification is unsuccessful after a certain number of tries; communicating to the host server the completion of the transaction; on receipt of the communication, the host server then communicates to the merchant computer system of the success of the transaction. Preferably the information transferred from the merchant computer system to the host server includes the merchant's purchase order number or other reference for the transaction, which is then stored in the host server database for use in the event of any subsequent query.

Preferably the identification code identifying the transaction is tagged with the merchant's purchase order number or reference.

Preferably the transaction identification code includes a merchant identification and a unique identifier.

Preferably the transaction is partially credited to both merchant and host authority.

Preferably at least some of the method steps of data transfer and communication occur via an internet connection and/or virtual private network. Alternatively the invention relates to a computer system when providing: a communicator implemented to receive a communication from a merchant system over a communication medium and receiving therefrom details of a proposed transaction; an identification code generator generating a code identifying the proposed transaction; the communicator communicating the identification code to the merchant system; and a transaction verifier transmitting a payment authorisation to a transaction authority after verifying that at least a transaction code provided to the transaction authority by a buyer matches the code generated by said generator. Preferably the transaction details include a merchant identification, a transaction authority identification and a transaction amount.

Alternatively, the invention provides a secure payment transaction server, comprising: communicating means for communicating with a merchant server and a bank server; a code generator for generating a unique transaction code for a proposed transaction, upon receiving the details of the proposed transaction from said merchant server, said details including the amount to be paid; storage means for storing the unique transaction code and amount of the proposed transaction; said communicating means being adapted to transmit the generated transaction code for the proposed transaction to a buyer via said merchant server; comparing means for comparing a transaction code and amount that are received from said buyer via said bank server with the corresponding code and amount stored in said storage means; and said communicating means being adapted to transmit a transaction authorization to said bank server when the comparing means determines that the two sets of code and amount match. These and other features of as well as advantages which characterise the present invention will be apparent upon reading of the following detailed description and reviews of the associated drawings, which illustrate although do not limit the invention.

Brief Description of the Drawings

FIG. 1 is a diagrammatic view of a transaction system of an embodiment of the invention.

FIG. 2 is a flow diagram of a sample transaction.

Detailed Description of the Invention

A system for carrying out a transaction securely is described with reference to FIG.l which shows a buyer computer 101 connecting through the internet 102 to an online or similar merchant computer system 103. Via the computer 101, user selects goods or services for purchase from the merchant site but both merchant and user require a secure method for payment of the purchase which preferably does not involve the user giving credit/debit/charge card or bank account details, such as bank account number or bank account name, to the merchant web site. This secure service is provided by a host server 104 with a database 105 containing details of the merchant and a list of banking companies which support the inventive transaction method and providing software to the merchant to connect securely with the host server. The merchants' bank account details are also stored in the host server's database 105, while the host server's account is stored in the bank's database 107. The database 105 will be updated as and when a new merchant, a merchant's new bank account or a new banking company is added or removed from the host server 104. With regard to the updated list of banking companies, it will appear on the merchant web site at the payment stage, allowing the user to choose a banking authority, at which the user has an account or a banking card with, or opt out and use a standard credit/debit/charge card payment method instead. Once the user has chosen a bank supporting the secure method, the merchant site transfers details of the purchase to the host server. An identification code generator 108 then returns a unique transaction identification code while the details of the proposed transaction are stored in database 105. The merchant web site displays this code to the user on his computer 101.

After the user successfully logs in to his bank web site 106, the bank recognises the user's bank account, or credit card, debit card or charge card that the user may have with the bank which is stored in the bank's database 107. User enters a special transaction activity in which the user selects the host server authority from a menu of online payment recipients (such as for utility bills) and enters the unique code and preferably also another identifier such as the payment amount. The bank 106 logs in to the host server 104, preferably via a virtual private network 109 and communicates the information received from the user to the host server 104. The host server 104 compares and verifies, using a transaction verifier, this data with that in the database 105 and, if the data match, sends a payment instruction to the bank 106. The payment instruction may specify paying the whole amount to the host server's account or to divide the payment amount in a predefined way between the host's and the merchant's accounts. Upon receipt of the instruction, the bank will run its payment utility program, makes the necessary payment(s) and generates its own payment reference that is forwarded to the host server. The bank's website confirms the successful instruction to the buyer. Server 104 passes the confirmation on to the merchant server 103 and the merchant releases the goods or services to the customer. If the system requires only that the user provide his identification code, the verification process confirms that code exists and has not been cancelled (for example, due to delay by the user in confirming his transaction).

FIG. 2 shows the steps in more detail, where customer browses 201 goods displayed in merchant web site 202 and selects items or services which are transferred to a shopping cart. The customer then checks out the shopping kart at 203, and the web site then requests customer information at 204, typically the name of a bank from which the purchase is to be debited, but no account information or other secure data.

The customer enters this information at 205, and the merchant receives and accumulates it at 206, 207 together with the total amount owed. The merchant then invokes a program loaded on his accounting system by the download from host server 104.

This program takes the data entered, namely the customer's bank and the amount concerned and transfers this together with the merchant name or identification and the merchant's purchase order number or reference at 208 to the host server. At the host server, this is identified as a transaction at 209 and an identification code created by identification code generator 108 at 210. The identification code is then stored in the host server at 213. Potentially, as an additional security measure for the buyer, the buyer's name or buyer's bank account name is not included in the data transferred to host server, or a pseudonym can be specified by the buyer instead. In the case where the goods or services have to be physically delivered to the customer or to another person, perhaps as gifts, the recipient's name and address need to be entered at the merchant's web site for delivery purposes only. This identification code preferably contains a part which identifies the merchant, for instance the first four digits, but the remainder of the number is preferably unique and may be generated in various ways such as by a random number generator or by hashing a variable such as the time. The identification code created is transferred back to the merchant at 211 and displayed on the customer browser session for the customer to note down at 212. Alternatively, the merchant can generate its own identification code which consists of the merchant code and purchase reference number, sends it to the host server 104 to be stored in database 105, and at the same time, displays the identification code on the customer browser session for the customer to note down. However, this method is less preferable, since there is a possibility that the merchant may generate identical identification codes for different transactions and it is difficult for the host server 104 to detect the error should this happen.

The customer now browses at 214 to the online banking interface and selects at 215 the transaction type and specifies the transaction itself by entering the identification code supplied and the amount of the transaction, and then authorises the transaction at 216.

The bank 106 logs in to the host server 104, preferably via a virtual private network 109 and communicates the information received from the user to the host server 104. The host server 104 will compare and verify the information with that stored in the host server at 217 '. If upon comparing the information at 217 with the identification code recorded in the host server 104, any item differs, the transaction is refused. Preferably, the customer is allowed to enter the identification number and the amount of the transaction for no more than a few times, say three times, before the transaction is ultimately refused, after which, the customer will then have to repeat the whole process starting with step 201.

If upon comparing at 217, the information matches with that recorded in the host server 104, the host server 104 issues a payment instruction to the bank, which informs the customer his payment is proceeding. In this embodiment, the payment instruction specifies paying the whole amount to the host server's account, and the host server will then divide the payment amount in a predefined way between the host's and the merchant's accounts. Upon receipt of the instruction, the bank will run its payment utility program, makes the necessary payment and generates its own payment reference that is forwarded to the host server.

The customer can choose to complete the transaction by either debiting his bank account or by authorizing a charge to his debit card or charge card or credit card that he may have with the bank. The transaction is refused if the customer's account has insufficient funds to complete the transaction. If this happens, the customer can proceed to charge his bank's debit card or charge card or credit card instead. Otherwise, the customer will have to repeat the whole process starting with step 201. Therefore, it is important for the customer to know the balance of his account or the remaining limit for his charge card or credit card, before selecting his bank at step 204.

If the transaction is considered satisfactory, the merchant's account is credited and the customer debited at 218. The host server 104 is then advised by the bank's server of the success of the transaction at 219, 220 and the host server 104 advises the merchant at 221. The merchant then checks, using the bank reference provided to the merchant through the host server, whether its record tallies with the payments received. In an embodiment in which the payment instruction specifies paying the merchant directly, the merchant's bank account information may be transmitted as part of the instruction. Alternatively, this information may be derived from the merchant identifier element of the transaction code.

The merchant can either confirm with the customer that the transaction has proceeded or merely supply the required goods or services at 222. It may be desirable to limit the transactions per customer to a specific number to avoid any possibility of excessive fraud taking place if the system is compromised in some way. For this purpose, there may be a limit on the number of transactions of any customer with a particular merchant. A figure of two transactions within 20 minutes may be sufficient to trigger such a limit. Similarly, any transaction which has not been completed by a buyer with his bank within a specified maximum time may be cancelled or invalidated. Such time could be 2 hours. The terms and conditions in completing the transaction can be relayed to the customer at the same time as the identification number is sent to the customer at 212.

The host server itself may negate a transaction if the transaction authority has not returned notice of a transaction by a buyer within a specified time period, such as one hour. This requires that the host server send to the merchant an advice that the transaction has been negated. On the other hand, the transaction authority only needs to be informed that the transaction has been negated if an out of time attempt to complete the transaction is made by the buyer. In this case, the verification process will fail and the host server will advise the bank server accordingly. The buyer will then be informed through his online banking session that the transaction is void.

There is no requirement for the customer to download any special software. However the merchant must have embedded software which queries the host server at the point when a purchase is made. Normally, this will be a simple matter of diverting to the host server communication software rather than diverting to a payment routine. Because there are a limited number of merchant web site processing sites, as compared to providing downloaded software for each customer, it is relatively simple to implement the process of the invention. For merchants who do not maintain, or wish to maintain their own server, they will use a hosting service provider instead. In this case, the embedded software will reside in the hosting service provider server.

The customer transaction with the bank may be by way of credit card, direct debit, or funds transfer but this is essentially transparent to the merchant since the methods on offer are those provided by the host server after agreement with the various banks as to the services on offer from each. Each bank using the system may need to vary the standard customer interaction to allow for the use of the inventive system.

While the system is described as using the internet as the transmission medium, especially between the customer and the merchant, the merchant and the host server and the customer and the bank, these interactions could equally well take place over a direct connection, a dial-up direct connection, a virtual private network or a wireless connection. However, based on current practice and for security measures, the interactions between the bank and the host server take place preferably via a virtual private network, so that the bank's server is not easily accessed by unscrupulous parties. It should be noted that the entire transaction is secure in that the customer interaction with the merchant requires minimal security and the merchant interaction with the host server requires only that the identification code be held reasonably secure. The host server interaction with the bank and the customer transaction with the bank are done only within the bank's own terms and conditions.

In one embodiment, the identity of the buyer is not transmitted to the host server. Thus, identity theft becomes impossible. While the description above describes the unique identifier as an identification number it may equally well be a code of any type and preferably includes a merchant identifying system. Thus for instance an identification code may be such as MAX49120fd5 where MAX identifies the merchant Maximum Auxiliary Services, 49120 is a random number and fd5 the result of an encrypted redundancy check of the code digits. Such a code ensures that the merchant can be identified and the internal validity of the code checked. The generation of such a code requires only the application of techniques standard within the industry.

The description above assumes that the whole of the amount of the transaction is forwarded to the host server's account before the host server forwarding the payment to the merchant's account. It may be desired that a commission is provided to the owner or operator of the host server. To do this, the host server authority may have a commission rate, either one rate for all merchants, or a different rate for a different merchant. The host server authority can then split the transaction destination of the amount based on the agreed commission rates, so that the specified proportion is transferred to the merchant, either on a per- transaction basis or cumulatively at some agreed interval. The merchant's account will need to be already stored in the host server's database or the merchant can provide information on the merchant's account number when providing transaction details to the host server. In the case that the amount of the transaction is forwarded to the merchant's account at some agreed interval, the merchant can open a separate account with the host server and this account will be maintained by the host server. The transaction amount can be stored accumulatively in this separate account up to a certain period, say one week or one month, at the end of which, the accumulated amount from different transactions is credited to the merchant. This method may be more preferable for small to medium sized merchant companies, since bank charges are charged on the accumulated amount one time only, instead of them accruing many bank charges for each separate transaction within that same period of time.

Although payment is credited once a week or once a month, the merchant is still notified immediately, every time a transaction is successful, or he is given the option of being able to login to his account in the host server, to view his latest balance and transaction history. It is to be understood that even though numerous characteristics and advantages of the various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and functioning of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail so long as the functioning of the invention is not adversely affected. For example the particular elements involved in the transfer of information may vary dependent on the particular application for which it is used without variation in the scope of the present invention. In addition, although the preferred embodiments described herein are directed to transactions in an internet banking system, it will be appreciated by those skilled in the art that the teachings of the present invention can be applied to other systems such as transfer over dedicated lines such as telephone lines, without departing from the scope of the present invention.

Industrial Applicability The invention relates to the generation of an identifier for use in securely processing a transaction by the transmission of that identifier to a purchaser and the use of that identifier by a transaction authority in the verification of a proposed transaction. As such, a technical process of generation, transmission and comparison takes place.

Claims

1. A transaction system comprising: a host server including: a communicator for communicating with a merchant computer system

(103) and a transaction authority, and a transaction identifier generator (108) generating a unique transaction identification code for any proposed transaction; a merchant computer system communicator communicating with the host server (104) and transferring to it at least information relating to a proposed transaction, and receiving from it at least a transaction identification code, and confirmation of any transaction with a transaction authority involving the transaction identification code; a buyer computer (101) receiving from a merchant computer system (103) the transaction identification code and communicating with a communication device to the transaction authority (106) at least the transaction identification code to authorise the transaction; a transaction authority communicator communicating with the host server

(104) after receiving the transaction authorisation information from said buyer computer (101); and a transaction verifier comparing and verifying at least the transaction identification code received by the transaction authority communicator with that stored by the host server, and generating authorisation of a transaction involving the transaction identification code when the two sets of data match.

2. The transaction system of claim 1 wherein the information communicated by the buyer to the transaction authority (106) includes the transaction amount or another identifier relating to the transaction.

3. The transaction system of claim 2 wherein the information communicated by the buyer to the transaction authority (106) also includes an identification of the merchant.

4. The transaction system of claim 1 wherein the transaction authority (106) carries out a transaction for the specified amount on receipt and verification of the information provided by the buyer computer.

5. The transaction system of claim 4 wherein the transaction amount is divided into two portions, the merchant account being credited with one portion and the host server owner with the other portion.

6. The transaction system of claim 1 wherein the buyer communication device is an internet browser.

7. The transaction system of claim 1 wherein the merchant computer system (103) is an internet purchase site and all communications are via the internet (102).

8. The transaction system of claim 1 wherein the transaction authority (106) is a bank or a card-issuing company.

9. The transaction system of claim 1 wherein the identification code is formatted to include an identification for the merchant.

10. A method of carrying out an internet transaction comprising: providing a merchant computer system (103) including a merchant transaction initiating process; providing a host server (104) under control of a hosting authority and capable of interacting with a merchant transaction initiating process; on intended purchase of goods or services by a buyer from the merchant: requiring the buyer to choose a transaction authority (106); initiating a transaction process with the host server (104) comprising: transferring from merchant computer system (103) to host server (104) information sufficient to identify at least the merchant, the buyer's chosen transaction authority and the amount; generating and transferring from the host server (104) to the merchant computer system (103) an identification code identifying the transaction; requiring the buyer to initiate a transaction process with the chosen transaction authority comprising: identifying the host authority; specifying at least the transaction identification code; comparing and verifying the transaction identification code with the host server (104); the transaction authority (106) then: carrying out the transaction by crediting at least the merchant if the verification is successful; refusing the transaction if the verification is unsuccessful after a certain number of tries; communicating to the host server (104) the completion of the transaction; on receipt of the communication, the host server (104) then communicates to the merchant computer system (103) of the success of the transaction.

11. A method as claimed in claim 10 wherein the transaction identification code is supplied to the transaction authority (106).

12. A method as claimed in claim 10 wherein the transaction is partially credited to both merchant and hosting server owner.

13. A method as claimed in claim 10 wherein the transaction identification code includes a merchant identification and a unique identifier.

14. A method as claimed in claim 10 wherein at least some of the method steps of data transfer and communication occur via an internet connection (102).

15. A computer system when providing: a communicator implemented to receive a communication from a merchant system (103) over a communication medium and receiving therefrom details of a proposed transaction; an identification code generator generating a code identifying the proposed transaction; the communicator communicating the identification code to the merchant system; and a transaction verifier transmitting a payment authorisation to a transaction authority after verifying that at least a transaction code provided to the transaction authority by a buyer matches the code generated by said generator.

16. A computer system as claimed in claim 15 wherein the transaction details include a merchant identification and a transaction amount.

17. A secure payment transaction server (104), comprising: communicating means for communicating with a merchant server (103) and a bank server (106); a code generator (108) for generating a unique transaction code for a proposed transaction, upon receiving the details of the proposed transaction from said merchant server, said details including the amount to be paid; storage means (105) for storing the unique transaction code and amount of the proposed transaction; said communicating means being adapted to transmit the generated transaction code for the proposed transaction to a buyer via said merchant server; comparing means for comparing a transaction code and amount that are received from said buyer via said bank server (106) with the corresponding code and amount stored in said storage means (105); and said communicating means being adapted to transmit a transaction authorization to said bank server (106) when the comparing means determines that the two sets of code and amount match.

18. A secure payment transaction server as claimed in claim 17, wherein the transaction server (104) allows receipt from the merchant server (103), only a certain number of transactions from the same user within a certain period of time.

19. A secure payment transaction server as claimed in claim 17, wherein the transaction server (104) negates a transaction if no successful verification has been made by the comparing means after a certain period of time.

20. A secure payment transaction server as claimed in claim 17, wherein the transaction code includes an element that identifies the merchant, and a random element that is unique to the particular transaction.