A METHOD FOR THE SECURE TRANSFER OF PAYMENTS

Abstract: A method for the secure transfer of payments over a network sales system. The system includes a plurality of card holder computers (4), a card issuer computer (6), merchant computers (3) and at least one merchant payment acquirer computer (11). Card holder account details are stored in a secure database (7) by the card issuer computer (6). When a card holder (4a) wishes to make a transaction with a merchant computer (3) the card holder computer establishes communication with the card issuer computer (6) and the card holder (4a) must enter a password or PIN number to his or her account. The transaction is authorised by the card issuer computer (5) which authorisation is transmitted either directly to the merchant computer (3) or indirectly through the merchant payment acquirer company (11). Important aspects of the invention are that (a) a card holder's payment account number is permanent and is used repeatedly for many successive transactions; and (b) for each transaction there is a dedicated communications channel between the card holder computer (4) and the merchant computer (3) into which the card issuer computer (5) can write account information.

Description: "A Method for the Secure Transfer of Payments" Introduction The present invention relates to a method and sales system for the secure transfer of payment and related purchase information over a network sales system for a payment card-not-present transaction, including a plurality of card holder computers, a card issuer computer, merchant computers and a merchant payment acquirer computer, all interconnected by a communications network. In this specification the term "payment card" is used to encompass not alone what is considered generally as being a credit card, but also debit cards and any other issued cards and payment accounts which comprise a standard payment account number, but without the provision of a conventional physical plastics imprint card which can be used by consumers, or corporate purchasers, for the payment for goods and services. _A "payment card transaction" as used in this specification refers to the use of any such payment card in a transaction. Electronic commerce is growing at a phenomenal rate. Because payment cards are recognised as the one globally accepted means of payment, they are the ideal payment method for the purchase of goods and services over open networks like the Internet. However, the use of payment cards over open networks raises fears and anxiety as payment card information has to be transferred to a third party while the payment card is not present. Thus, a third party, generally the merchant, gets all the payment card details of the card holder including the payment card number and expiry date. This is perceived, whether correct or not, to be a considerable security risk for the payment card holder, not alone due to the misuse of the payment card in the third party's hands, but more importantly the possible lack of security in the transfer of the information over the Internet. It is therefore essential, if electronic commerce is to continue to grow, that the purchaser be able to use their payment card in an absolutely secure manner. Further it is essential for the payment card holder be able to use the payment card for electronic commerce in substantially the same way as the payment card holder uses a payment card for card-present transactions, in card present transactions the card holder proffers a payment card in an establishment, the payment card slip is printed for the payment card holder, who then signs the payment card slip, obtains a receipt, and is secure in the knowledge that the receipt corresponds to what they have paid. One of the interesting facts in relation to electronic commerce is that a report by a research organisation namely Forrester Research states that something on the order of two thirds of on-line shopping carts are abandoned prior to completing a purchase. It is suggested that the primary reason for this is the complex nature of the payment systems compared to those of a card present transaction. Many vendors have developed comprehensive Internet payment applications which store card holder information and automatically fill out complex and detailed merchant forms when the shopper wants to buy. These applications, typified as electronic wallets, simplify and secure the process of on-line buying. While traditional electronic wallets are the more common approach they have proven to be spectacularly unsuccessful in market acceptance. They are something that those who are technologically skilled immediately appreciate and understand, however, the general consumer is reluctant to use them. Indeed it has been suggested that virtually none of the $13 billion in on-line purchases by consumers in 1998 was made with electronic wallets. Various methods have been proposed to facilitate the security of electronic commerce such as, for example, the network sales system disclosed in U.S. Patent Specification No. 5,715,314 (Open Market, Inc.) which is based on the relatively simple proposition that the card holder does not at any stage transmit his or her credit card number to the merchant. This is achieved by having what is effectively a payment computer which, for example, could be the credit card provider computer programmed to receive payment messages from the merchant and to effectively handle the payments system with the merchant. Thus, the card holder sends a payment message to the payment computer which message includes sufficient information to identify the product and then the payment computer is programmed to receive this payment message, to authenticate it in the usual way and then to send an access message to the merchant computer which is programmed to receive and authenticate the message and then to cause the product to be sent to the user. Unfortunately, this changes the whole manner in which payment is now made and would be very difficult to institute in practice. Various proposals have been made in relation to digital advertising, but most of these systems are directed to methods which allow the advertising to be active, as it were, such that it will allow users to preview products and will make available to consumers a large number of advertisements relating to products available for purchase. Usually these advertising systems are in some way linked to a shopping system that will allow the user to purchase the desired product using some payment method. Based somewhat on the previously described payment system, U.S. Patent Specification No. 5,724,424 (Open Market, Inc.) allows for the transmission to a consumer of a large number of advertisements with a network payment system similar to that previously described. Again these advertisements are chosen by the user and are not to any great extent under the control of any third party in the sense that they are not focussed by the third party on a specific consumer. They may be focussed on a class of consumer, but they still require a consumer in that set of consumers to visit the site. Another method proposed for overcoming the problems of security in ecommerce is that described in U.S. Patent Specification No. 5,883,810 (Microsoft Corporation) which is addressed to the security of such an on-line system over a public network. This patent specification describes a credit card which does not exist in a physical form, it only exists in digital form and when the card holder wishes to conduct an on-line transaction, the card holder asks the card issuer to issue a transaction number for a single transaction. This is a temporary transaction number and is associated directly with a permanent account number of the card holder. This transaction number is then used with the merchant instead of the card holder's actual credit card number. This invention addresses some security concerns but its reliance on temporary transaction numbers substantially modifies the cardholder experience and it may not be compatible with existing merchant behavior. In particular, it is not compatible with merchants who offer rewards to repeat card holder customers by recording the number or value of multiple purchases made with a specific payment card number. This invention may generate confusion when cardholders communicate with merchants to resolve problems or disputes, as there will be two payment numbers associated with the transaction, namely the permanent account number and the temporary transaction number. Finally, this invention does not work seamlessly with merchants who offer 'one-click' buying by maintaining their own database of cardholder payment-card numbers. Thus, while this invention may substantially reduce fraud, it does not satisfy the market need for a payment system that requires minimal change to cardholder and merchant behavior. What the card holder wants is to use his or her payment card as if it had been handed to the merchant in a card present transaction i.e. it must be used in a clear and seamless fashion without the card holder having to make any decisions other than the normal purchase decisions. Consumers will be much more likely to engage in electronic commerce if on-line card payments can be accomplished as simply and conveniently as a traditional card- present payment. Once card holders can conveniently and securely buy on-line, it is suggested that the purchase volume taking place on-line will greatly increase. Even so, electronic commerce has grown without the active involvement of the card issuers with their customers. While the financial institutions including the card issuers have made significant investments to support on-line commerce, particularly in establishing the Secure Electronic Transaction (SET) standard, they have not yet recognised any tangible marketing advantage. It would appear that the financial institutions' investment in payment technology has simply kept them up to date with developments in electronic commerce. The financial institutions are well aware of the need to maintain brand awareness with their customers. There is a recognised need for the card issuer to transmit advertisements to the card holders when purchase transactions are taking place, especially ideally when the card issuer's payment card is being used. The card issuer has a strong need to reinforce the card issuer's corporate and brand identity, and Trade Marks. In summary electronic commerce is growing rapidly and payment cards are the Internet payment option of choice. Financial institutions have an opportunity to capitalize on this growth. Card holders must feel secure about sending their card details over the Internet and they need the necessary tools to facilitate simple yet secure Internet payments. Card issuers need an effective tool to maintain strong customer relations and reinforce the value proposition they offer their card holders. The present invention is directed towards overcoming these problems. In particular it is directed towards allowing a payment card to have all the attributes of an electronic wallet such as allowing the payment card to be used securely for electronic commerce, and further to providing a system and method so that the consumer can use the same process he or she is familiar with when using a payment card in a card-present transaction. Finally, the invention is directed towards providing a method and system allowing the card issuer to maintain close client contact with the card holder, providing a marketing channel of communication and other opportunities for the card issuer. Additionally the invention is directed towards removing the need to have a physical payment card particularly for card not present transactions but not exclusively so. Statements of Invention According to the invention there is provided a method for the secure transfer of payment and related purchase information over a network sales system for a payment card transaction, the system including a communications network and at least a card holder computer operated by a card holder, a card issuer computer, a merchant computer and a merchant payment acquirer computer comprising: the initial act of downloading initiation data from a card issuer computer to the card holder computer and then there is subsequently performed the acts not necessarily sequentially of: a payment request is sent from the merchant computer to the card holder computer; the card holder computer contacts the card issuer computer and opens a direct communications link with the card issuer computer; the identity of the card holder is authenticated to the card issuer computer; the card holder computer sends merchant and purchase information to the card issuer computer; the card issuer computer sends card payment information to the card holder computer; the card holder reviews the card payment information displayed on the card holder computer; the card holder computer causes the card payment information to be sent to the merchant computer thereby authorising the payment; and the merchant computer confirms the transaction to the card holder computer. The advantage of this is two-fold: the issuer carries out the payment tasks usually performed by the card holder, and a direct and unobstructed channel of communication is established between the card holder at the time of the payment transaction. An additional advantage is that all of the information for payment and purchase is displayed on the screen and the user can alter this prior to final transmission or submission to the merchant computer to complete the payment authorisation request. Ideally the identity of the card holder is authenticated by a password, a digital certificate, a shared secret key or by a separate party authentication computer connected to the communications network. All of these will lead to increased security. When an authentication computer is used and connected to the communications network, the method comprises the steps of: the card holder computer transmits authentication information to the party authentication computer and requests the party authentication computer to provide authentication; the party authentication computer transmits an authenticatior file to the card holder computer; and the card holder computer transmits the authentication file to the card issuer computer. Ideally, the authentication file is deactivated after a pre-set time. It is envisaged in the method on review of the card payment information displayed on the card holder computer the card holder changes the card payment information before causing it to be sent to the merchant computer. This allows the user or card holder a final review before actually making the purchase. Further it is envisaged that: on review of the card payment information displayed the card holder computer instructs the card issuer computer to send the card payment information to the merchant computer; and the card issuer computer sends the card payment information to the merchant computer. Ideally prior to the merchant computer confirming the transaction the merchant computer obtains confirmation that the payment will be made from the merchant payment acquirer computer and this may be obtained in real time rather than in batches from the merchant computer as is usually the situation. The advantage is that in the event of errors or omissions in the information they can be rectified in real time and not at a subsequent date which can be difficult, particularly when batch payment requests are sent by the merchant computer to the merchant payment acquirer computer. In one method according to the invention on the merchant computer confirming the transaction to the card holder computer, the card holder computer confirms the transaction will take place to the card issuer computer. Further it is envisaged that on the card issuer computer sending card payment information through the card holder computer to the merchant computer the steps are performed of: the merchant computer places a payment card authorisation request with the merchant payment acquirer computer; the merchant payment acquirer computer contacts the card issuer computer; the card issuer computer causes payment authorisation to be established; the card issuer computer confirms the payment authorisation to the merchant payment acquirer computer; and the merchant payment acquirer computer confirms the payment authorisation to the merchant computer. Further it is envisaged that the card issuer computer may additionally open a direct communications link with the merchant computer and on the card holder computer causing the card payment information to be sent to merchant computer thereby authorising the payment, the card issuer computer confirms payment authorisation to the merchant computer. It is envisaged that authorisation may be established: on pre-existing credit risk data; on receiving authorisation from the card holder; it may be deemed established based on the identity of the card holder being authenticated to the satisfaction of the card issuer computer; it may be established based on authorisation protocols previously agreed between one or more of the merchant payment acquirer computer, the card issuer computer, and the merchant computer, which protocols have been previously agreed between one or more of these parties. It is envisaged that: on the authorisation being established the card issuer computer stores sufficient transaction identification information to identify the transaction; on subsequently receiving a payment request from the merchant payment acquirer computer the card issuer computer consults the transaction identification information to confirm that the payment may be made; and the card issuer computer causes appropriate payment to be made to the merchant payment acquirer computer. It is envisaged that the card issuer computer stores all the payment card information and the card holder computer may store communications and other protocols which other protocols can include an authentication protocol for initiating the use of the method. It is also envisaged that the card issuer computer stores necessary merchant information to complete the transactions with the merchant computer. In one way of carrying out the invention, the payment request is sent by the merchant computer in the form of a merchant payment form and the card issuer computer downloads all relevant payment card and card holder information onto the merchant payment form to provide the card payment information for subsequent transmission to the merchant computer as a completed merchant payment form. Ideally, in this latter method the card issuer computer causes the complete merchant payment form to be displayed on the card holder computer as a completed card issuer payment slip, or causes the completed merchant payment form and the card issuer payment slip to be displayed side by side on the card holder computer. It is also envisaged that on completion of the transaction the card issuer computer downloads to the card holder computer the card issuer payment slip which card issuer payment slip ideally conforms to the format of a card payment slip conventionally used for a card present transaction. It is also envisaged that all data transmitted may be encrypted. Ideally, the card holders payment card number is not transmitted to the merchant computer and a purchase payment authorisation number is used when transmitting payment authorisation to the merchant computer, the payment card number being only issued to the payment acquirer computer Ideally, the sensitive card holder information is stored on the card holder computer in encrypted form, a key transmitted from the card issuer being necessary to decrypt the information by the card holder computer and ideally the commands are inputted by using a command icon on the screen of the card holder computer . In one way of carrying out the invention, the card holder computer displays messages from the card issuer computer during the transaction said messages being additional to those required for the operation of the transaction. ideally such messages are displayed during time intervals when the display of transaction information is not required which messages may be linked to merchant information stored in the card issuer computer, or to card holder information on the card issuer computer, or indeed to purchase information sent to the card issuer computer in the current or previous payment card transactions. Further the invention provides a method for a card issuer to control the flow of information to a card holder during a sales transactions in a network sales system for a payment card transaction, the system including a communications network and at least a card holder computer, a card issuer computer, a merchant computer and a merchant payment acquirer computer using a payment card comprising: storing all payment card information on the card issuer computer; initially downloading communications and authentication protocols for initiating the payment card transaction by the card holder computer and on the card holder computer contacting the card issuer computer to conduct a card payment transaction for the card holder the steps, not necessary sequentially, are performed of: the card issuer (6) opens a direct communications link with the card holder computer; the card issuer computer receives from the card holder computer merchant and purchase information; the card issuer computer downloads card information for display on the card holder computer with the merchant and purchase information; and the card issuer computer downloads additional messages for display on the card holder computer. The additional messages may be displayed on the card holder computer simultaneously with the payment card, merchant and purchase information, such messages being additional to those required for the operation of the transaction. They may also be displayed during time intervals when the display of transaction information is not required. Such messages may be linked to merchant information stored in the card issuer computer, or to card holder information on the card issuer computer, or to purchase information sent to the card issuer computer in the current or previous payment card transactions. This provides the card issuer with a marketing opportunity. When the card issuer is aware that somebody is, for example, purchasing automobile parts, it is relatively easy for the card issuer to target that person with advertisements on automobile finance. Similarly, the level of purchase and the type of purchase will also alert the card issuer to advertisements that the card holder might be interested in. The advertisements do not necessarily have to be services provided by the card issuer. The card issuer could, for example, agree to take advertisements for others knowing that a card holder is purchasing goods, for example, from a book supplier such as AMAZON. It would then be possible for the card issuer to download advertisements for book clubs or other literary matters with the issuer being compensated for performing the advertising service. Further, the invention provides a method based sales system for payment cards comprising: at least one card holder computer; at least one card issuer computer; at least one merchant computer; at least one merchant acquirer computer; and a communications network interconnecting the computers (3, 4, 6 and 11); said card holder computer being programmed to receive and store initiation data from the card issuer computer including an authentication protocol for initiation of the sales system; said card issuer computer being programmed to store card payment information and to receive merchant and purchase information from the card holder computer and to transmit card payment information to the card holder computer to enable a payment card transaction to be completed by the card holder computer with the merchant computer; said card issuer computer being further programmed to deliver messages to the card holder computer during the transaction; said merchant computer being programmed to deliver a payment request to the card holder computer and to carry out the transaction with the card holder computer. Ideally in such a sales system there is a separate party authentication computer connected to the communications network and in which: said party authentication computer is programmed to prepare an authentication file and to transmit it to the card holder computer; and said card holder computer is programmed to transmit authentication information to the party authentication computer for authentication and to transmit authentication files to the party authentication computer. Ideally the party authentication computer is programmed to de-activate the authentication file after a pre-set time. The card holder computer can be a mobile phone and in this case then a card present transaction without physically proffering a credit card to a merchant computer can be carried out comprising using the method based sales system described above in which the mobile phone is used instead of a credit card. In this way, the card holder maintains his or her credit card number secret, in effect, keeping a credit card in a wallet. Further the invention provides a computerised method for secure transfer of payment and related purchase information for a payment card transaction in which there is at least one card holder computer operated by a card holder, at least one card issuer computer operated by a card issuer, at least one merchant computer and at least one merchant acquirer computer and a communications network interconnecting the computers (3, 4, 6 and 11) comprising: receiving purchase information related to at least one purchase from a card holder processor at the card issuer computer; authenticating a payment request from the card holder computer; and transmitting card holder information including payment card information to the card holder computer. In this latter method the step of transmitting the card holder information including the card holder payment card information to the merchant computer is performed. It is also envisaged that with this computerised method for secure payments and related purchase information that there is also included sending targeted advertising messages from the card issuer computer to the card holder computer based on at least one of the card holder data, the merchant data and purchase data based on the current or previous payment card transaction. Ideally, with this computerised method, the authentication of payment further includes receiving authentication information from a third party which is transmitted to the card issuer computer and also may further includes receiving a request for payment settlement from the merchant computer. It may further include transmitting payment card information and sending the card payment information to the card holder computer which is subsequently forwarded to the merchant computer. In this computerised method, authenticating the payment includes receiving authorization of payment to the merchant computer from the card holder computer and ideally the purchase information includes at least one of purchase data, payment request data, merchant URL, card holder data, merchant data, or merchant acquirer data and the method may also include transmitting pre- authorization to the merchant computer, and receiving confirmation from the acquirer computer at the card issuer computer. It is also envisaged that the method may further include sending a payment authorization message to the merchant computer. Further the invention provides a computerized method for secure transfer of payment and related purchase information for a payment card transaction in a system having at least one card holder computer operated by a card holder and a card issuer computer comprising: receiving payment and merchant information related to at least one purchase from a card holder computer at a card issuer computer; authenticating a payment request from the card holder through the card holder computer; sending merchant profiling information to the card holder computer which enables the population of a merchant payment page; and sending card holder data including payment card information to the card holder computer. In the latter method populating the payment page includes transmitting a drag and drop metaphor for use by the card holder to automatically fill out the merchant payment page and may preferably include displaying the merchant payment page to the card holder for review and editing. This computerised method may also include storing a merchant profile at the card issuer computer for use in populating the merchant page and additionally for further updating the merchant profile by the card issuer computer based upon editing activity of the card holder or indeed generating a merchant profile. It is further envisaged to include generating a merchant page on the card holder computer in the form of a merchant payment page. According to the invention there is further provides a method for the secure transfer of payment and related purchase information of a payment card transaction, comprising: receiving merchant and purchase information from a card holder computer; authenticating the identity of the card holder; searching a merchant profile database; and sending card holder data including payment card information to the card holder computer. In this latter method there is the step of further recognizing the identity of the merchant and subsequently preferably propagating a merchant payment page. For this method, ideally the card holder computer is a mobile phone. Further the invention provides a computerized method for secure transfer of payment and related purchase information for a payment card transaction, comprising: (A) initializing a card holder account and card holder software, comprising: activating a card holder payment card account for use on the internet based on at least one of pre-existing card holder data, payment card information, or a payment card application; populating a card holder payment card account database record with information from at least one of pre-existing card holder data, payment card information, or the payment card application; generating card holder identification data for use in subsequent communications to authenticate the card holder; recording the card holder identification data; downloading initiation data and client software from a card issuer computer to a card holder computer; (B) receiving purchase and merchant information from at least one card holder computer at a card issuer computer, comprising: opening a communication link between the card holder computer and the card issuer computer; receiving at least one of purchase data, payment request data, merchant URL, card holder data, merchant data, or merchant acquirer data; (C) authenticating a payment request from the card holder, comprising: receiving card holder provided authentication information including at least one of a username, password, a digital certificate, a shared secret key, a separate party authentication computer, or a card holder profile; searching a card holder profile database; maintaining a card holder profile database: comparing the card holder provided information to authentication data extracted from the cardholder profile database; maintaining the card holder transaction database; evaluating recent transactions obtained from the card holder transaction database for patterns to detect possible fraud; maintaining a merchant fraud risk database including information relating to fraud rates by card holders at the merchant; (D) transmitting card payment information of the card holder to the card holder computer, comprising: sending card holder data including payment card information to the card holder computer by a communication link; searching a merchant profile database to obtain a profile for the merchant in question; recognizing the identity of the merchant; maintaining the merchant profile database; sending the merchant profile information to the card holder computer enabling the population of a merchant payment form with appropriate card payment information; updating the merchant profile database if the merchant is not listed in the card issuer computer or if the merchant profile has been changed; (E) transmitting marketing information and advertisements, comprising transmitting marketing messages to the card holder computer based on the purchase and merchant information received; maintaining a message database; (F) authorizing a payment authorization request, comprising: receiving an authorization request; authorizing the payment request based on a predetermined protocol; and completing payment settlement for the purchase of the card holder. Further the invention provides a system for providing secure transfer of payment and related purchase information for a payment card transaction, comprising: a memory device having embodied therein data relating to a card holder profile and a merchant profile; a processor in communication with the memory device and configured to receive information related to at least one purchase from a card holder computer at a card issuer computer, authenticate a payment request from the card holder, and transmit card payment information of the card holder to the card holder computer ; and a communications link (2) connecting the memory device to the card holder computer. Further the invention comprises a system for providing secure transfer of payment and related purchase information for a payment card transaction, comprising: a memory device having embodied therein data relating to a card holder profile and a merchant profile; a processor in communication with the memory device and configured to receive information related to at least one purchase from a card holder computer at a card issuer computer, authenticate a payment request from the card holder, and transmit card payment information of the card holder to a merchant computer; and a communications link (2) connecting the memory device to the merchant computer. In this latter system the communications link (2) also connects the memory device to the card holder computer. Ideally the authentication of the request is by authenticating the identify of the card holder. Further the invention provides a system for secure transfer of payment and related purchase information of a payment card transaction, comprising: means for receiving merchant and purchase information from a card holder computer; means for authenticating the identity of the card holder; means for searching a merchant profile database; and means for sending card holder and payment card information to the card holder computer. The invention also provides another system for secure transfer of payment and related purchase information of a payment card transaction, comprising: means for receiving merchant and purchase information from a card holder computer; means for authenticating the identity of the card holder; means for searching a merchant profile database; and means for sending card holder and payment card information to a merchant computer. In this latter system it may comprise means for populating a merchant payment page. Further the invention provides a computer readable medium for use in secure transfer of payment and related purchase information for a payment card transaction, comprising: an instruction code for receiving information related to at least one purchase from a card holder computer at a card issuer computer; an instruction code for authenticating a payment request from the card holder; and an instruction code for transmitting card holder and payment card information to the card holder computer. Additionally the invention provides a computer readable medium for use in secure transfer of payment and related purchase information for a payment card transaction, comprising: an instruction code for receiving information related to at least one purchase from a card holder computer at a card issuer computer; an instruction code for authenticating a payment request from the card holder; and an instruction code for transmitting card holder and payment card information to a merchant computer. Ideally the computer readable medium comprises an instruction code for populating a merchant payment page. Detailed Description of the Invention The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only described with reference to the accompanying drawings in which: Fig. 1 is a broad outline of the eCommerce Network; Figs. 2 to 4 are flow diagrams of a typical purchase of goods or services using the present invention; Fig. 5 is a functional diagram of how the invention operates in practice for the parties; Fig. 6 is a view similar to Fig. 1 of an alternative arrangement of the Network; and Figs. 7 and 8 are flow diagrams of an alternative method according to the present invention. Since effectively the present invention produces an electronic version of a card holder's existing card or payment card, it has been for convenience in this specification referred to sometimes as an eCard or an ezCard, which are proprietary names we have chosen for them. In this specification it is represented in the distinctive form ezCard. The reason for this is that ezCards are simply virtual versions of an existing payment or debit card, which enables card holders to conveniently and securely buy on-line. The distribution and activation of the ezCard mirror the established process for physical cards since both are issued by the same source, namely the card issuer. The ezCard is never embodied physically. It is envisaged that these ezCards will be issued for established debit or payment card accounts and therefore billing address, card holder name, payment card number and expiration date are not configurable by card holders. However, this information will correspond directly to the card issuer's account information on which the ezCard is issued. One important purpose of the present invention, as will be described hereinafter, is that the ezCard mirrors the familiar and well understood distribution, and activation process of a physical payment card, often hereinafter referred to simply as a payment card, thus the ezCard mirrors the existing physical payment cards for virtual use on the Internet. A credit or payment card as understood by most consumers consists of two separate features, firstly the payment account with the issuing financial institution and secondly a physically present plastics card with optional magnetic stripe which can be used to provide an imprint of the card information or provide an electronically-readable version of the same. Alternately, the card can be used simply as a permanent means to store the number of the account for card-not- present transactions. It is envisaged that some card issuers may. prefer to issue what are effectively virtual payment cards and never produce a physical embodiment of the card. This could have several advantages for the financial institution. Firstly, it obviates the need to manufacture and distribute such physical cards. Secondly since virtual cards have no physical presence they cannot be used to make fraudulent purchases in card-present transaction situations. Similarly, it makes it more difficult to use in mail order transactions as well, because the authorization request that is sent to the issuing bank by the merchant acquirer bank can indicate whether or not the purchase is eCommerce or mail order. Further if there is fraud against a virtual payment card, the card holder knows that the fraud must have taken place on the Internet because it obviously wasn't stolen in for example a restaurant or a store and secondly the card holder can cancel the virtual card without affecting his or her ability to continue card-present transactions, which presumably could be tied to other non-virtual cards, i.e. to conventional credit or payment cards. The present invention allows maximum flexibility for both the card holder, card issuer and the card issuer bank. It is also envisioned that the organization operating the invention, whether a card issuer or not, may provide service to holders of pre-existing credit cards who do not have any prior relationship with it. In this case, prior to any payment transactions being performed, a registration process would occur through which the card holder would provide all necessary information to the organization including the credit card number, said information being subsequently stored in the organization's database. Such card holders would not be authenticated to the same degree as users who were known to the organization prior to their registration, but they would still benefit from the seamless merchant form-filling capabilities of the invention, and the operators of the invention would still benefit from the valuable commercial information which they derive from participating in the card holder's purchase transactions. It is also envisioned that optionally the organization operating the invention, whether a card issuer or not, may provide service to persons wishing to establish a new credit card account by opening a communications link to a card issuer or a credit-rating institution during the registration process. While reference in this specification has been made to the card issuer computer operating the invention, it will be appreciated that instead of the card issuer computer actually being the place where the invention is operated that it could be a separate server computer, which in turn would download or handle the service for the card issuer computer. However, the card holder would not know this and it is thus irrelevant. Sometimes in this specification, the organisation operating the invention is referred to as the Net Issuer. In this specification information and data is described as being continuously transmitted between the parties. Rather than make the description complex and unwieldy and thus difficult to understand it is taken as read that the type and nature of the information being transmitted is that appropriate for the task in hand. Thus, for example, merchant information transmitted to the card issuer by the card holding computer might be the minimum to allow the merchant to be identified, the information sent to the same merchant's payment acquirer would of necessity contain more details such as account number etc. Thus, many types of information will be required at various stages in any transaction and indeed the type and amount of such information may vary or indeed its treatment may be changed because of the nature of the actual transaction itself, or indeed may be different for different transactions between the same parties. For example, a transaction having a monetary value above a certain amount may require the merchant and its acquirer bank to initiate a more rigorous authorisation protocol. Similarly the reference to information or data by a general term such as "merchant payment information" or "merchant payment data" may not always mean that the information transmitted or obtained is identical at least in detail, such a definition, description or label on the definition must be qualified by the phrase "as is appropriate for the requirements of the recipient". For example, as mentioned already, all a card holder may require as "merchant payment information" is a completed merchant form - while the card issuer computer may require more information to complete its part of the transaction. For simplicity and to avoid unnecessary confusion such qualification to a description of the information is not made each time. The term "profiling" is used to qualify information such as for example "merchant profiling information" to describe information about the merchant as described in more detail below. Further the term 'computer' is used in the broadest way and in many instances more appropriate wordings would be organisation; database; etc. However, as in most instances a computer, mobile phone, or some other instrument, device, or machine will be the contact device used. Equally the term processor could be used. The term computer encompasses such an information processor which may include databases, wireless devices, image storage and retrieval systems, or could be part of a network of even a website. Thus, the term computer when used for a card holders use can be quite different to the same term when used for a merchant for the former it could be a PC and for the latter a website. The term computer is used as it appeared to be the one most likely to be used and thus the most appropriate term. Also in some instances parties to the transaction have been identified as "computers" where more properly the reference should be the party operating the computer. However, it makes for easier reading and understanding of the invention not to do so. This is particularly so in the claims. The only distinction made sometimes in the claims is between card holder and card holder computer as a card holder can use different devices or similar geographically separate devices or computers to carry out the invention. 01/22374 - 26 - As will be seen from the following description the present invention conveniently and automatically fills out merchant payment pages using a "drag and drop" metaphor. A further feature of the present invention as will be apparent from the following description is that it allows a wide variety of messages, including marketing information and advertising, to be transmitted by the card issuer to the card holder every time a purchase is made. A key capability of the invention is that when the ezCard is invoked; and the issuer's computer is contacted, a clear and unobstructed channel of communication is established between the issuer and the card holder. This channel of communication enables the issuer to reinforce its corporate and brand identity at every such instance. Even more importantly, any involved intermediaries such as Internet portals, Internet service providers (ISP's) and other advertisers are automatically subordinated. This is a key consideration for issuers who otherwise are at the mercy of such intermediaries. In summary, the invention provides protection from brand disintermediation from any such intermediaries. Referring now to Fig. 1 there is illustrated an Internet service provider (ISP) 1 connected by communication links or network 2 to a plurality of merchant computers 3 and card holder computers 4, which card holder computers 4 will be used by the card holder to make necessary purchases ot goods and services from the merchant computers 3. The card holder is identified in Fig. 1 separately by the reference numeral 4a since, strictly speaking, a card holder is not limited to using one, let alone the same card holder computer 4, each time to carry out the invention. All the other parties in the transaction do not need to be separately identified and can be referred to as being, for example, the merchant computer 3. Connected to the Internet service provider 1 is a card issuer 5, which card issuer will include and have or have the services of a card issuer computer 6, a payment card information database 7, a message database 8 and a merchant database 9. The merchant database 9 is linked to a merchant profile server 10 which stores relevant merchant information for a number of Internet service providers and card issuers. All of these may in fact be contained in the one card issuer computer, however, for convenience it is easier to separate them. Alternatively they may be contained on a separate Net Issuer computer as explained above. The merchant computers 3 are in turn linked to merchant payment acquirer computers 11. The communications link between merchant computer and its payment acquirer computer could be as shown by direct link, but could be via the ISP. All other communications links which could be or are established are not shown. It will be appreciated that for the particular Internet service provider that there could be a number of card issuers connected directly to the Internet service provider and similarly the one card issuer could be connected to a number of Internet service providers, however, to illustrate them in the drawings would merely confuse the issue. Essentially there are four organisation involved in the purchase and payment transaction. The first is the customer, namely the card holder having access to a card holder computer downloaded onto which is sufficient data from the card issuer to allow the card holder to contact the card issuer and display information as required. The one card holder computer could service a number of card holders. The card issuer computer is the second element in the transaction. The card issuer computer carries all the payment card details, together with merchant information sufficient to allow a full transaction to be carried out. The merchant then carries out the necessary payment request and purchase confirmation while the fourth party namely the merchant payment acquirer receives any funds that the merchant should receive for the delivery of the goods from the card issuer. Very often with such remote trade, despite approval of a purchase transaction by a card holder, actual payment cannot be made until the goods have been shipped by the merchant. In some cases not all the goods included in a particular order will be dispatched at the same time, thus there can be payments made on a phased or staged basis. As explained already all of these principals or organisations are connected over the Internet or through conventional credit-card association communication networks. While in the following various related methods of carrying out the invention are described, it will be appreciated that, depending on the circumstances, many variations may be made in what is essential the one method. Referring now to Figs. 2 to 4 inclusive, it is presumed that the system has already been set up and that the card holder computer has sufficient information to allow the card holder to contact the card issuer and the card issuer already has merchant information and also merchant payment acquirer information sufficient to contact the merchant payment acquirer computer i.e. the ezCard is operative. The term OPT has been used in the flowcharts in some of the boxes to indicate that an optional operation, step or procedure could be carried out. In certain cases the fact that they are optional will be immediately understood. For example, the card holder could immediately consider authorization of a particular request from a merchant, or alternative could wish to alter the request received from the merchant, before giving payment authorization, for example, changing shipping address and so on. To avoid unnecessary complications the term OPT has been used to indicate this. In step 20 the card holder computer has been in contact with the merchant computer and the card holder has filled out a shopping cart and transmits this to the merchant in step 21. The merchant then downloads a payment form as a payment request in step 22 to the card holder computer for payment. In step 23 the card holder activates the ezCard usually by simply clicking an icon on the computer screen. This initiates a direct Internet-based communications session in step 24 between the card holder computer and the card issuer computer, so disintermediation is prevented. The card holder's identity is authenticated to the card issuer by means of a username-password protocol or other conventional cryptographic authentication protocol, or by presentation of a digital "cookie" obtained from a third party as is described later. In step 25 the card holder sends purchase and merchant URL to the card issuer which now has available to it certain information. Simultaneously the card issuer starts to send messages to the card holder in step 26 and these messages continue to be sent to the card holder computer. These messages, as explained below, can be various advertisements, dependent on the information already downloaded in relation to the merchant, they can be linked in some way to information already contained in the card issuer's computer about the card holder, they can be linked to the specific purchase of goods and services being initiated and so on. In step 27 the card issuer consults the merchant and cardholder databases and in step 28 the card issuer downloads the card holder data and merchant profiling information that is needed by ezCard to write the card holder data onto the appropriate data fields in the merchant form. The data will now be displayed on the card holder's computer as a merchant form including such information as shipping address and credit card number in step 29. Prior to payment authorization by the card holder, any of the information downloaded from the card issuer can be altered by the card holder simply by typing new data into the appropriate data field on the merchant form, for example a different shipping address. In step 30 the card holder who now has the total data displayed considers authorisation of purchase to the merchant and may immediately proceed in step 31 to authorise payment with the merchant. Alternatively, in step 32 the card holder changes the purchase by altering the payment data that has previously been displayed in step 29, or, may alternatively decline the purchase in step 33. The cardholder's decision to proceed with the transaction that it is to say carrying out step 31 is again communicated to the Merchant after step 32. The merchant now wishes to obtain a payment authorization from the Card Issuer. The conventional method for obtaining such payment authorization requires that the Merchant contact the Merchant acquirer computer in step 34 which computer contacts the Card issuer computer in step 35, usually by means of payment-card-association networks. The Card issuer computer evaluates the authorization request using standard credit-risk data. The card issuer in step 36 contacts the merchant payment acquirer to confirm the order and agrees to the payment terms and the acquirer bank confirms payment to the merchant. Optionally, the card issuer computer additionally issues a direct authorization confirmation message to the Merchant in step 37. Optionally, the card holder's decision to proceed with the purchase transaction in step 34 is also communicated to the Card Issuer in step 37. In this case, the Card Issuer has all the information it requires to evaluate the authorization of the transaction including the payment card number and the purchase amount. In addition the Card Issuer knows the internet address (URL) of the merchant. The card issuer computer can therefore generate and transmit an authorization decision to the Merchant directly in step 39, using a message protocol previously agreed upon, without the involvement of payment card-association computer networks. Payment card associations typically assess a per-transaction fee for use of their networks in processing the authorization request and response corresponding to steps 34 and 35. The optional method comprising steps 38 and 39 thereby provides a means for merchants to avoid such fees. The invention envisions that in this optional method the card issuer software would typically proceed from step 38 to step 40, thereby skipping the costly steps 34, 35 and 36. Step 40 is when the merchant confirms to the card holder that the transaction is accepted, see below. However, in some circumstances the merchant may wish to receive an authorization both from the card issuer directly, in step 37, and in addition an authorization indirectly, by proceeding to step 34 following step 39. It will be appreciated that the card holder can optionally confirm the purchase to the card issuer in step 37 even if the merchant intends to utilize the conventional method of obtaining payment authorization, namely by submitting a payment request to its merchant acquirer computer in step 34. Thus the card issuer will be able to confirm that the card holder has indeed confirmed a purchase before the card issuer will confirm to the acquirer bank that the payment will be made. Irrespective of whether the merchant receives a payment authorisation directly from the card issuer (steps 38 and 39) or indirectly through its acquirer bank (steps 34, 35 and 36) in step 40 the merchant confirms to the card holder that the necessary transaction has been accepted. In step 41 , the card holder receives a final card payment form. This final card payment form can be in any suitable format but will generally mirror the standard credit card payment slip and ideally one appropriate to the particular credit card. This step completes the communication between the card holder and card issuer, and so at this time in step 44 the messages end to the card holder computer. In step 43 the card issuer completes the payment to the merchant payment acquirer following dispatch of the goods in step 42 by the merchant. It should be noted that the relative timing of steps 41 to 44 is affected by the type of product being delivered. If the purchase involves immediate delivery of goods such as electronic download of software or music then step 42 may precede steps 41 and 44, but if the purchase involves physical delivery of a product, then the usual warehouse, packing and shipping cycles typically dictate that step 42 follows step 41 by as much as several days. The above is a general description of how the invention can be carried out, but it will be appreciated that there are many variations of it only some of which have been given. For example, the payment slip or document that is displayed by the card holder can be stored, can be delivered afterwards as a payment receipt and so on. The above description did not describe the operation of one feature of the invention already described with reference to Fig. 1 , namely, the merchant profile service and the merchant database. Typical merchant forms used in eCommerce comprise a set of field names (e.g. Street Address; PaymentCardNumber) and their corresponding values (e.g. 123 Park Street; 4650345626445678). Although an industry-standard set of field names has been proposed, namely the Electronic Commerce Markup Language (ECML), the present situation is that every internet merchant uses different field names. To correctly populate the merchant form, the invention requires a list specific to each merchant, known as a merchant 'profile', which list defines the association between the merchant field names and their corresponding entries in the card holder database. The merchant profile contains in addition all other merchant-specific data that is required to populate the merchant form and to extract particular data values such as the total purchase amount from merchant-supplied web pages. The merchant profile database comprises the set of all merchant profiles which are known to the card issuer computer. Rather than read a unique merchant profile from a merchant profile database, the card issuer computer can instead attempt to guess the meaning of various field names on the merchant form based on a set of rules derived from previous experience. For example, the logic could search for character strings "St", "Street" or "Addr" on the merchant form and tentatively associate them with the Street Address. These approaches can be combined to provide 100%-accurate profiles for some merchants and a reasonably accurate profile for all merchants. Individual merchant profiles in the merchant profile database can be obtained manually, by visiting each merchant individually and recording the field names which appear on their merchant form. Alternately, the system can 'learn' the profile for a previously-unknown merchant by observing the cardholder type data inputted into the merchant fields and comparing said data to entries in the card holder database. In addition, the system can continuously update its merchant profiles and look for changes to them by recording how often card holders alter the data on the merchant form that is automatically populated by the ezCard. Thus, the merchant profile database may be started with a reasonably small number of merchants which is extended over time. The separate merchant profile service (10 in Fig. 1) retains a master database of known merchant profiles, which are continuously updated and this will ensure that the merchant database (9 in Fig. 1) will be continuously updated. This means that when, for example, there is any change in a merchant profile this is sent to all card issuers connected in the particular network to that Internet service provider, or indeed connected to other Internet service providers. Referring now to Fig. 5 there is illustrated the functional operation of the invention insofar as the parties to the transaction view it and in this drawing the electronic element of the card issuers' operations are separated from the normal card issuer's operations which are identified as the card issuer's back office and the former is identified by the term net issuer. The circled numerals in Fig. 5 identify the operations listed below. 1. Card issuer installs the system on a secure server at their site, or the site of an outside service provider. 2. A target group of cardholders is identified who would be active users of electronic cards, based on purchases previously charged to card accounts (such as recurring ISP charges, computer and software purchases, or purchases at Internet merchants such as amazon.com or peapod.com). A cardholder extract file is built of card account details and is exported to the system. 3 The system is customized for appearance, ezCard security features, and the advertising server to deliver targeted messages to cardholders when they use their ezCards. A promotional mailer is made to card-holders in the target market group announcing ezCard to cardholders including instructions, initial password, and Issuer's unique resource locator (URL). 4. Cardholder goes to Issuer's URL and enters the password given in the mailer. 5. The system accesses the associated account and asks for personal information such as "Mother's Maiden Name" or PIN to confirm her identity. Cardholder selects a button "Click to Activate your Electronic Card". The system then downloads, installs, and launches ezCard. The minimal information to subsequently initiate ezCard is all that is stored on the card holder computer. Cardholder chooses a personal password, or has one assigned depending on the policies imposed by the issuer bank and enters shipping address, e-mail address, and phone number. ezCard is then ready for use. 6. The system issues tracking certs, or other tracking mechanisms, for license control and audit trails. 7. Alternatively, a Certificate Authorisation (CA) service could be used for authentication or SET certs as is described below. 8. A cardholder could also apply on-line for a card 9. If approved, ezCard could be issued in real-time and a physical card mailed. This is optional. 10. Cardholder goes shopping at an Internet merchant, finds what he wants, and places it in his shopping cart. When he is ready to buy, the merchant web site asks for address and payment information. 11. Cardholder launches his ezCard by simply clicking a desktop icon or dragging and dropping the icon onto the merchant page. ezCard launches in another window, which displays card issuer logo and advertising, shows the name and graphical representation of associated physical details of the card (not the number or expiry), and requests a password. 12. Cardholder enters a personal password for verification. The password may be checked by the Netlssuer, or it may be checked by a third party as described below, which upon successful authentication, transmits a digital file to the card holder computer that is subsequently presented to Netlssuer to validate the cardholder's identity. Following authentication, the Cardholder then drags ezCard to merchant's payment page to auto-fill the form. 13. EzCard sends merchant's URL to the system to see if it is in the merchant profile database 14. At the same time, ezCard sends cookie (if available for use) to the system, and receives targeted advertising message from a database 15. If merchant's profile is in the system database, then payment page is auto- populated, with ezCard automatically filling out the necessary information on the merchant site (cardholder name, address, e-mail, card details, etc) 16. If not, notification is sent to merchant Profile Service, which maintains a master database of known merchant profiles 17. The Profile Service profiles the site in question and updates the master database 18. New profiles are then distributed to all the system merchant profile databases on a recurring basis, resulting in all the system customers benefiting from the sum total of all cardholder purchase activity. 19. Alternatively, payment information manually entered by a cardholder can serve as the basis for preliminary profiling on a previously unknown merchant page. 20. The system can also connect to a fraud detection service for fraud screening. Fraud screening could extend to authenticating the merchant in question, or identifying fraudulent use (e.g. theft) of the physical card associated with an ezCard that is valid. 21. Cardholder reviews the completed merchant form and submits it. When payment is submitted, ezCard directs the system to capture transaction details. 22. After payment is authorized, the cardholder receives a graphical representation of a charge slip that psychologically reinforces the fact that a payment transaction was completed - a key factor to cardholder comfort level and ease of mind 23. This sales receipt can be sent via e-mail, stored within the system, or on the card-holder's PC and can be used as any payment slip in a card-present transaction. Referring to Fig. 6, there is illustrated in broad outline another arrangement of an eCommerce network for carrying out the invention which is substantially similar to the eCommerce network illustrated in Fig. 1 and thus the same reference numerals are used to identify similar parties and parts. Connected to the internet service provider 1 is a party authenticator, namely, party authentication computer 15, which facilitates an alternative method of authentication whereby the card holder authenticates himself or herself not to the card issuer computer 6 directly, but to the separate party authentication computer 15 operated by a party authentication server. This could also be described as a separate web server. The authentication will be done in the usual way using a user name and password combination entered by the card holder and verified against a database maintained by the authentication server. While the details of how the authentication is performed are unimportant, what is important to note is that a web server other than the card issuer computer authenticates the card holder computer. Once the card holder is authenticated the party authentication computer 15 downloads back to the card holder computer a small standard file known as a "cookie" which contains the information that will authenticate the card holder to the card issuer computer and in one embodiment the cookie contains the payment card account number in encrypted form and an expiration date for the cookie. Figs. 7 and 8 illustrate in flowchart form, in a slightly simpler way, the principal features of the invention. This flowchart illustrates the principal steps in a method of carrying out the invention as laid out in Fig. 6. However, it illustrates very clearly the operation of the present invention eliminating many of the optional and extraneous steps. In step 120, the card holder fills out a shopping cart and in step 121 , a purchase request is sent to a merchant. The merchant will then download a payment form to the card holder computer in step 122. The card holder then activates ezCard on the card holder computer in step 123. In step 124 the card holder computer opens direct communication with the card issuer computer and thus there is now direct communication between the card holder and the card issuer. This allows the card issuer to send messages to the card holder computer and hence to the card holder in step 125. As explained above, these messages will only be sent at appropriate times. The card holder computer will immediately send merchant URL to the card issuer in step 126. In step 127, the card holder authenticates his or her identity to the card issuer with a password. This is absolutely essential because it is not sufficient for the card issuer to identify the message coming from what would appear to be an appropriate card holder computer but the card issuer must identify the particular card holder as more than one card holder could use the same computer or indeed a card holder could, for example, at certain times, use a mobile phone and at other times, a computer. This authentication is described below. In step 128, the card issuer reads card holder and merchant profile information from the database. Optionally, in step 129, the card issuer may record the successful authentication of the card holder in the database. In many instances, this would be desirable. Then, in step 130, the card issuer downloads card holder data and merchant profile data to the card holder computer. In step 131 , the card holder data is entered automatically onto the merchant payment form in the sense that the card holder does not have to do anything as it is done simply following step 130. Then, in step 132, there is the optional step of the card holder modifying some information on the card merchant payment form. This would often happen at the last moment. In step 133, the card holder considers payment authorization and can then either abort the transaction in step 134 or effectively accept the transaction by sending the completed payment form to the merchant computer in step 135. This illustrates the invention relatively simply without additional complications. The authentication steps are now described. At some point in the purchase transaction it could indeed be before the shopping starts, or it could be after the card holder decides to make the purchase (e.g. following step 121), the card holder activates the method according to the present invention by opening the direct communication with the card issuer computer 6, namely step 124. Also at some point in the purchase transaction the card holder computer in step 140 contacts the separate party authentication computer 15 which is operated by a separate web server. Step 140 is shown in Fig. 7 as typically following step 124, but it is not necessary that step 140 be initiated by the ezCard in step 124 indeed some card issuers would like their card holders to establish a web connection to an authentication party computer independently. Logically, step 140 can be carried out anytime before steps 125 and 126. In step 141 the party authentication computer 15 requests authentication information from the card holder computer such as, for example, user name and password. In step 142 the server checks this information against a user database and if this information matches a valid record in its user database, the server looks up the corresponding payment card number. The web server generates in step 143 a cookie with this number plus the cookie's expiration date which is determined from the local time, plus a defined validity period. These would normally be transmitted in encrypted form. In step 144 the cookie is downloaded automatically to the card holder computer. Then in step 145 at some suitable time the card holder computer uploads to the card issuer computer 6 the cookie. The validity of this cookie is checked by the card issuer computer in step 146, and if the cookie is deemed valid then the card holder's identity has been authenticated and the logic proceeds to steps 128 and 129 just as if the card holder ' s identity had been verified directly by the card issuer. Authentication could also be by a digital certificate, a shared secret key, or some other means. The cryptographic details of how this authentication is performed are unimportant for purposes of this invention; what is important is that there are two alternate paths to the authentication: either directly with the card issuer computer or indirectly, with a party authentication computer that communicates with the card issuer computer with a cookie. In the above, reference has been made to the fact that the presence of a merchant payment acquirer computer is necessary for the operation of the invention. While at the present moment, merchant payment acquirer computers are used in most payment systems, it is appreciated that in the future, payment systems may evolve such that the merchant computer, or merchant could itself carry out the functionality now provided by the merchant payment acquirer computer. Essentially, these are simply functions in the payment system in that the merchant payment acquirer computer translates the format of the merchant's authorization request into an "Internet format", i.e. the format used for messages between the merchant and its acquirer bank on the Internet to "back-end format" i.e. to translate into the format used to convey the authorization request from the acquirer bank to the issuing bank. Then it transmits the authorization requesting the back-end format to the issuing bank typically using as an intermediary a card association network such as VISANet. There is, strictly speaking, no reason in principle that this functionality of the acquiring bank, namely the use of a merchant payment acquirer computer couldn't be carried out by the merchant computer itself. It would thus be possible to combine the functionality of the merchant computer and the merchant payment acquirer computer into the one computer. It will be appreciated that the same applies to any other functionality described above. Many of the functionalities have been described as being carried out by separate computers because this makes the understanding of the invention easier. In the above, while discussing confirmation of payment authorization, it will be appreciated that in most situations, merchants confirm to a card holder or customer before they get any response from the acquirer bank. Thus, the merchant computer confirms the transaction to the card holder computer before obtaining confirmation that the payment will be made from the merchant payment acquirer computer. Essentially, all this confirmation means is that the merchant has accepted the card holder's order and will attempt to process it. What happens in practice at the present moment is that the merchant waits for an authorization from the acquirer bank i.e. from the merchant payment acquirer computer using the terminology above before dispatching goods or supplying the particular service. The way in which the card holder computer authorizes a transaction or payment to the card issuer computer can be carried out in many ways and will be based on the authorization procedures or protocols previously established between the card holder computer and the card issuer computer. For example, these could be credit risk data previously established. It could mean that before the card issuer computer would authorize a payment, the card holder computer would have to positively confirm that payment was to be made by authorizing it. Alternatively, these rules could be based on values of transactions. Thus, for example, once a transaction was below a certain monetary sum, then the card issuer computer on being satisfied in accordance with whatever rules it has established in regard to the identity of the card holder computer, then the authorization could be made. Accordingly, at the very beginning of the transaction, once the card issuer was satisfied of the identity of the card holder, then the card issuer would not require any further authorization from the card holder to authenticate the payment. Again, this could be controlled by various rules which would obviate the possibility of fraud. Again authorisation could be established based on authorisation protocols previously agreed between the merchant payment acquirer and both the card issuer and the merchant, or between the card issuer and the acquirer. There is strictly speaking no limit to such protocols and any desired protocol may be accommodated by the invention. Again it may be obtained if desired in real time. It will be appreciated that since the information and data is downloaded directly onto the card users computer all the card user requires, presuming that the computer has the normal mouse control, is to simply point at various command icons, click once and the information is downloaded. The advantage of this is that all the information is entered onto the merchant payment page as if it was entered manually by the card holder it is envisaged that the information will be transmitted by encryption and, for example, it is envisaged that various suitable encryption systems may be used, such as Secure Sockets Layer (SSL), this encryption system which is widely used over the Internet provides up to 128 bit data encryption support. It is envisaged that the encryption can also be by secure electronic transmission (SET), Cert-Less Set, Merchant-Originated set (MOSET), or indeed any other encryption system. As explained already, the invention provides a method for a card issuer to control the flow of information to a card holder sales transaction. Further it provides a method based sales system for payment cards and as already mentioned, this is essentially a computerised method. The invention particularly provides a method for the secure transfer of payment and related purchase information and in particular computer messages for the secure transfer of payment. It is also envisaged that in accordance with the invention, there may be provided a computer readable medium for use in the secure transfer of payment and related purchase payment information for a credit card transaction, which will comprise various instruction codes, such as an instruction code for receiving information relating to a purchase form a card holder computer at a card issuer computer, some instruction code for authenticating a payment required, instruction code for transmitting card holder and payment card information to the card holder computer and in general instruction code for carrying out the method according to the invention. It will be appreciated that for the card issuer there are considerable advantages in that the card issuer now has an opportunity to deliver messages throughout the purchase transaction to the card holder and further to display prominently the card issuer's logo, Trade Marks, etc. on forms and information downloaded to the cardholder. Further, it will be possible for the card issuer to sell advertising and promotional space to other companies and thus could realise a significant revenue stream for the card issuer. A further advantage of the present invention is that it will allow card issuers to target their card holders with very specifically designed advertising. They already have a considerable amount of information on their card holders by virtue of an analysis of previous purchases from which they always build up card holder profiles. Using these card holder profiles and in particular the specific information given to them at each purchase, whether it be information in relation to the merchant being purchased from, or the actual items being purchased, the card issuer has a unique opportunity to very clearly target the advertising messages to the card holder. Further, in many situations during a purchase operation there will be time lags, indeed in the actual operation itself which can be utilised and further the card issuer can determine the length of these time lags. Another major advantage of the present invention is that minimal card holder information needs to be stored on the card holders computer, while the bulk of the card holder information can be stored on the card issuers computer, or secure server. It will also be appreciated that with the present invention that these electronic payments assist the financial institution by lowering the amount of data entry required and thus the likelihood of error and it generally reduces transaction costs. The completed merchant payment form can be supplemented by a new format identical to that of a completed card issuer payment slip which the card holder will be familiar with. It is envisaged that instead of the use, for example, of a computer by the card holder that a mobile phone could be easily configured to carry out the functions described above. Using a mobile phone as the communication device for a card holder offers several advantages including more reliable authentication of the card holder's identity, since a mobile phone is typically supplied with built-in electronic hardware that identifies itself to the phone network. In addition, there is a market advantage owing to the fact that there are currently four times as many mobile phones in service compared to personal computers. The use of mobile phones could have a considerable advantage for not just simply card-remote transactions, but also what would effectively be the same as card-present transactions in that on arriving at an outlet the mobile phone could be used to produce the necessary trade with the merchant through the merchant's own computer in front of the customer, without the need for the customer to carry a credit card with him or her. It in turn makes the theft of the payment card with consequent disclosure of the payment card number which is a continual problem for most payment card holders less damaging because the mobile phone payment system would be inoperative without user authentication by means of a password. In the specification the terms "comprise, comprises, comprised and. comprising" or any variation thereof and the terms "include, includes, included and including" or any variation thereof are considered to be totally interchangeable and they should all be afforded the widest possible interpretation and vice versa. The invention is not limited to the embodiment hereinbefore described, but may be varied in both construction and detail within the scope of the claims.

Claims: CLAIMS 1. A method for the secure transfer of payment and related purchase information over a network sales system for a payment card transaction, the system including a communications network (2) and at least a card holder computer (4) operated by a card holder (4a), a card issuer computer (6), a merchant computer (3) and a merchant payment acquirer computer (11) comprising: the initial act of downloading initiation data from a card issuer computer (5) to the card holder computer (4) and then there is subsequently performed the acts not necessarily sequentially of: a payment request is sent from the merchant computer (3) to the card holder computer (4); the card holder computer (4) contacts the card issuer computer (6) and opens a direct communications link with the card issuer computer (6); the identity of the card holder (4a) is authenticated to the card issuer computer (6); the card holder computer (4) sends merchant and purchase information to the card issuer computer (6); the card issuer computer (6) sends card payment information to the card holder computer (4); the card holder (4a) reviews the card payment information displayed on the card holder computer (4); the card holder computer causes the card payment information to be sent to the merchant computer (3) thereby authorising the payment; and the merchant computer (3) confirms the transaction to the card holder computer (4). 2. A method as claimed in claim 1 in which the identity of the card holder (4a) is authenticated by a password. 3. A method as claimed in claim 1 in which the identity of the card holder (4a) is authenticated by a digital certificate. 4. A method as claimed in claim 2 in which the identity of the card holder (4a) is authenticated by a shared secret key. 5. A method as claimed in claim 1 in which the identity of the card holder is authenticated by a separate party authentication computer (15) connected to the communications network (2). 6. A method as claimed in claim 5 comprising the steps of: the card holder computer (4) transmits authentication information to the party authentication computer (15) and requests the party authentication computer (15) to provide authentication; the party authentication computer (15) transmits an authentication file to the card holder computer (4); and the card holder computer (4) transmits the authentication file to the card issuer computer (6). 7. A method as claimed in claim 6 in which the authentication file is deactivated after a pre-set time. 8. A method as claimed in any preceding claim in which on review of the card payment information displayed on the card holder computer (4) the card holder (4a) changes the card payment information before causing it to be sent to the merchant computer (3). 9. A method as claimed in any preceding claim in which: on review of the card payment information displayed the card holder computer (4) instructs the card issuer computer (6) to send the card payment information to the merchant computer (3); and the card issuer computer (6) sends the card payment information to the merchant computer (3). 10. A method as claimed in any preceding claim in which prior to the merchant computer (3) confirming the transaction the merchant computer (3) obtains confirmation that the payment will be made from the merchant payment acquirer computer (11). 11. A method as claimed in claim 10 in which the confirmation is obtained in real time. 12. A method as claimed in any preceding claim in which on the merchant computer (3) confirming the transaction to the card holder computer (4), the card holder computer (4) confirms the transaction will take place to the card issuer computer (6). 13. A method as claimed in any preceding claim in which on the card issuer computer (6) sending card payment information through the card holder computer (4) to the merchant computer (3) the steps are performed of: the merchant computer (3) places a payment card authorisation request with the merchant payment acquirer computer ^11); the merchant payment acquirer computer (11) contacts the card issuer computer (6); the card issuer computer (6) causes payment authorisation to be established; the card issuer computer (6) confirms the payment authorisation to the merchant payment acquirer computer (11); and the merchant payment acquirer computer (11 ) confirms the payment authorisation to the merchant computer (3). 14. A method as claimed in any of claims 1 to 12 in which the card issuer computer (6) additionally opens a direct communications link with the merchant computer (3) and on the card holder computer (4) causing the card payment information to be sent to merchant computer (3) thereby authorising the payment, the card issuer computer (6) confirms payment authorisation to the merchant computer (3). 15. A method as claimed in claim 13 or 14 in which the authorisation is established based on pre-existing credit risk data. 16. A method as claimed in any of claims 13 to 15 in which the authorisation is established based on receiving an authorisation from the card holder (4a). 17. A method as claimed in any of claims 13 to 15 in which the authorisation is deemed established based on the identity of the card holder (4a) being authenticated to the satisfaction of the card issuer computer (6). 18. A method as claimed in claim 13 or 14 in which the authorisation is established based on authorisation protocols previously agreed between the merchant payment acquirer computer (11) and both the card issuer computer (6) and the merchant computer (3). 19. A method as claimed in claim 13 or 14 in which the authorisation is established based on authorisation protocols previously agreed between the card issuer computer (6) and the merchant computer (3). 20. A method as claimed in claim 13 or 14 in which the authorisation is established based on authorisation protocols previously agreed between the card issuer computer (6) and the merchant payment acquirer computer (11). 21. A method as claimed in any of claims 13 to 20 in which: on the authorisation being established the card issuer computer (6) stores sufficient transaction identification information to identify the transaction; on subsequently receiving a payment request from the merchant payment acquirer computer (11) the card issuer computer (6) consults the transaction identification information to confirm that the payment may be made; and the card issuer computer (6) causes appropriate payment to be made to the merchant payment acquirer computer (11). 22. A method as claimed in any preceding claim in which the card issuer computer (6) stores all the payment card information. 23. A method as claimed in any preceding claim in which the card holder computer (4) stores communications and other protocols. 24. A method as claimed in claim 22, in which the other protocols include an authentication protocol for initiating the use of the method. 25. A method as claimed in any preceding claim in which the card issuer computer (6) stores necessary merchant information to complete the transaction with the merchant computer (3). 26. A method as claimed in any preceding claim in which a payment request is sent by the merchant computer (3) in the form of a merchant payment form and the card issuer computer (6) downloads all relevant payment card and card holder information onto the merchant payment form to provide the card payment information for subsequent transmission to the merchant computer > (3) as a completed merchant payment form. 27. A method as claimed in claim 26 in which the card issuer computer (6) causes the completed merchant payment form to be displayed on the card holder computer (4) as a completed card issuer payment slip. 28. A method as claimed in claim 26 in which the card issuer computer (6) causes the completed merchant payment form and the card issuer payment slip to be displayed side by side on the card holder computer (4). 29. A method as claimed in any preceding claim in which on completion of the transaction the card issuer computer (6) downloads to the card holder computer (4) the card issuer payment slip. 30. A method as claimed in any of claims 27 to 29 in which the card issuer payment slip conforms to the format of a card payment slip conventionally used for a card present transaction. 31. A method as claimed in any preceding claim in which the data transmitted is encrypted. 32. A method as claimed in any preceding claim in which the card holders payment card number is not transmitted to the merchant computer (3), a purchase payment authorisation number being used when transmitting payment authorisation to the merchant computer (3) the payment card number being only issued to the payment acquirer computer (11). 33. A method as claimed in any previous claim in which the sensitive card holder information is stored on the card holder computer (4) in encrypted form, a key transmitted from the card issuer being necessary to decrypt the information by the card holder computer (4). 34. A method as claimed in any preceding claim in which the commands are inputted by using a command icon on the screen of the card holder computer (4). 35. A method as claimed in any preceding claim in which the card holder computer (4) displays messages from the card issuer computer (6) during the transaction said messages being additional to those required for the operation of the transaction. 36. A method as claimed in claim 35 in which the messages are displayed during time intervals when the display of transaction information is not required. 37. A method as claimed in claim 35 or 36 in which the messages are linked to merchant information stored in the card issuer computer (6). 38. A method as claimed in claim 35 to 37 in which the messages are linked to card holder information on the card issuer computer (6). 39. A method as claimed in claim 35 to 38 in which the messages are linked to purchase information sent to the card issuer computer in the current or previous payment card transactions. 40. A method for a card issuer to control the flow of information to a card holder (4a) during a sales transactions in a network sales system for a payment card transaction, the system including a communications network (2) and at least a card holder computer (4), a card issuer computer (6), a merchant computer (3) and a merchant payment acquirer computer (11) using a payment card comprising: storing all payment card information on the card issuer computer (6); initially downloading communications and authentication protocols for initiating the payment card transaction by the card holder computer (4) and on the card holder computer (4) contacting the card issuer computer (6) to conduct a card payment transaction for the card holder (4a) the steps, not necessary sequentially, are performed of: the card issuer (6) opens a direct communications link with the card holder computer (4); the card issuer computer (6) receives from the card holder computer (4) merchant and purchase information; the card issuer computer (6) downloads card information for display on the card holder computer (4) with the merchant and purchase information; and the card issuer computer (6) downloads additional messages for display on the card holder computer (4). 41. A method as claimed in claim 40 in which the additional messages are displayed on the card holder computer (4) simultaneously with the payment card, merchant and purchase information. 42. A method as claimed in claim 41 in which the card holder computer (4) displays messages from the card issuer computer (6) during the transaction said messages being additional to those required for the operation of the transaction. 43. A method as claimed in any of claims 41 to 42 in which the messages are displayed during time intervals when the display of transaction information is not required. 44. A method as claimed in claim 40 to 43 in which the messages are linked to merchant information stored in the card issuer computer (6). 45. A method as claimed in any of claims 40 to 44 in which the ^ messages are linked to card holder information on the card issuer computer (6). 46. A method as claimed in any of claims 40 to 45 in which the messages are linked to purchase information sent to the card issuer computer (6) in the current or previous payment card transactions. 47. A method based sales system for payment cards comprising: at least one card holder computer (4); at least one card issuer computer (6); at least one merchant computer (3); at least one merchant acquirer computer (11); and a communications network (2) interconnecting the computers (3, 4, 6 and 1 1); said card holder computer (4) being programmed to receive and store initiation data from the card issuer computer (6) including an authentication protocol for initiation of the sales system; said card issuer computer (6) being programmed to store card payment information and to receive merchant and purchase information from the card holder computer (4) and to transmit card payment information to the card holder computer (4) to enable a payment card transaction to be completed by the card holder computer (4) with the merchant computer (3); said card issuer computer (6) being further programmed to deliver messages to the card holder computer (4) during the transaction; and said merchant computer (3) being programmed to deliver a payment request to the card holder computer (4) and to carry out the transaction with the card holder computer (4). 48. A sales system as claimed in claim 47 in which there is a separate party authentication computer connected to the communications network and in which: said party authentication computer (15) is programmed to prepare an authentication file and to transmit it to the card holder computer (4); and said card holder computer (4) is programmed to transmit authentication information to the party authentication computer (15) for authentication and to transmit authentication files to the party authentication computer (15). 49. A sales system as claimed in claim 48 in which the party authentication computer (15) is programmed to de-activate the authentication file after a pre-set time. 50. A sales system as claimed in any of claims 47 to 49 in which the card holder computer (4) is a mobile phone. 51. A method of conducting a card present transaction without physically proffering a credit card to a merchant comprising using a method based sales system as claimed in claim 50 in which the mobile phone is used instead of a credit card. 52. A computerised method for secure transfer of payment and related purchase information for a payment card transaction in which there is at least one card holder computer (4) operated by a card holder (4a), at least one card issuer computer (6) operated by a card issuer, at least one merchant computer (3) and at least one merchant acquirer computer (11) and a communications network (2) interconnecting the computers (3, 4, 6 and 11) comprising: receiving purchase information related to at least one purchase from a card holder processor at the card issuer computer (6); authenticating a payment request from the card holder computer (4); and transmitting card holder information including payment card information to the card holder computer (4). 53. A method as claimed in claim 52 and in which the step of transmitting the card holder information including the card holder payment card information to the merchant computer (3) is performed. 54. A method as claimed in claim 52 or 53 including sending targeted advertising messages from the card issuer computer (6) to the card holder computer (4) based on at least one of the card holder data, the merchant data and purchase data based on the current or a previous payment card transaction. 55. A method as claimed in any of claims 52 to 54 wherein the authenticating of the payment further includes receiving authentication information from a third party which is transmitted to the card issuer computer (6). 56. A method as claimed in any of claims 52 to 55 further including receiving a request for payment settlement from the merchant computer (3). 57. A method as claimed in any of claims 52 to 56, wherein transmitting payment card information further includes sending the card payment information to the card holder computer (4) which is subsequently forwarded to the merchant computer (3). 58. A method as claimed in any of claims 52 to 57 in which authenticating the payment includes receiving authorization of payment to the merchant computer (3) from the card holder computer (4). 59. A method as claimed in any of claims 52 to 58 wherein the purchase information includes at least one of purchase data, payment request data, merchant URL, card holder data, merchant data, or merchant acquirer data. 60. A method as claimed in any of claims 52 to 59 further including transmitting pre-authorization to the merchant computer (6), and receiving confirmation from the acquirer computer at the card issuer computer (6). 61. A method as claimed in any of claims 52 to 59 further including sending a payment authorization message to the merchant computer (3). 62. A computerized method for secure transfer of payment and related purchase information for a payment card transaction in a system having at least one card holder computer (4) operated by a card holder (4a) and a card issuer computer (6) comprising: receiving payment and merchant information related to at least one purchase from a card holder computer at a card issuer computer; authenticating a payment request from the card holder through the card holder computer (4); sending merchant profiling information to the card holder computer (4) which enables the population of a merchant payment page; and sending card holder data including payment card information to the card holder computer (4). 63. A method as claimed in claims 61 wherein populating the payment page includes transmitting a drag and drop metaphor for use by the card holder computer (4) to automatically fill out the merchant payment page. 64. A method as claimed in claim 62 or 63 further including ^ displaying the merchant payment page to the card holder (4a) for review and editing. 65. A method as claimed in any of claims 62 to 64 further including storing a merchant profile at the card issuer computer (6) for use in populating the merchant page. 66. A method as claimed in any of claims 62 to 65 further including updating the merchant profile by the card issuer computer (6) based upon editing activity of the card holder computer (4). 67. A method as claimed in any of claims 62 to 66 further including generating a merchant profile by the card issuer computer (4). 68. A method as claimed in any of claims 62 to 67 further including generating a merchant page on the card holder computer (4) in the form of a merchant payment page. 69. A method for the secure transfer of payment and related purchase information of a payment card transaction, comprising: receiving merchant and purchase information from a card holder computer (4); authenticating the identity of the card holder (4a); searching a merchant profile database (9); and sending card holder data including payment card information to the card holder computer (4). 70. A method as claimed in claim 69 further comprising recognizing the identity of the merchant. 71. A method as claimed in claim 70 further comprising propagating a merchant payment page. 72. A method as claimed in any of claims 69 to 71 wherein the card holder computer is a mobile phone. 73. A computerized method for secure transfer of payment and related purchase information for a payment card transaction, comprising: (A) initializing a card holder account and card holder software, comprising: activating a card holder payment card account for use on the internet based on at least one of pre-existing card holder data, payment card information, or a payment card application; populating a card holder payment card account database record with information from at least one of pre-existing card holder data, payment card information, or the payment card application; generating card holder identification data for use in subsequent communications to authenticate the card holder; recording the card holder identification data; downloading initiation data and client software from a card issuer computer (6) to a card holder computer (4); (B) receiving purchase and merchant information from at least one card holder computer (4) at a card issuer computer (6), comprising: opening a communication link between the card holder computer (4) and the card issuer computer (6); receiving at least one of purchase data, payment request data, merchant URL, card holder data, merchant data, or merchant acquirer data; (C) authenticating a payment request from the card holder, comprising: receiving card holder provided authentication information including at least one of a username, password, a digital certificate, a shared secret key, a separate party authentication computer, or a card holder profile; searching a card holder profile database; maintaining a card holder profile database: comparing the card holder provided information to authentication data extracted from the cardholder profile database; maintaining the card holder transaction database; evaluating recent transactions obtained from the card holder transaction database for patterns to detect possible fraud; maintaining a merchant fraud risk database including information relating to fraud rates by card holders at the merchant; (D) transmitting card payment information of the card holder (4a) to the card holder computer, comprising: sending card holder data including payment card information to the card holder computer (4) by a communication link; searching a merchant profile database (9) to obtain a profile for the merchant in question; recognizing the identity of the merchant; maintaining the merchant profile database (9); sending the merchant profile information to the card holder computer (4) enabling the population of a merchant payment form with appropriate card payment information; updating the merchant profile database (9) if the merchant is not listed in the card issuer computer (6) or if the merchant profile has been changed; (E) transmitting marketing information and advertisements, comprising transmitting marketing messages to the card holder computer (4) based on the purchase and merchant information received; maintaining a message database (8); (F) authorizing a payment authorization request, comprising: receiving an authorization request; authorizing the payment request based on a predetermined protocol; and completing payment settlement for the purchase of the card holder (4a). 74. A system for providing secure transfer of payment and related purchase information for a payment card transaction, comprising: a memory device having embodied therein data relating to a card holder profile and a merchant profile; a processor in communication with the memory device and configured to receive information related to at least one purchase from a card holder computer (4) at a card issuer computer (6), authenticate a payment request from the card holder (4a), and transmit card payment information of the card holder (4a)to the card holder computer (4); and a communications link (2) connecting the memory device to the card holder computer (4). 75. A system for providing secure transfer of payment and related purchase information for a payment card transaction, comprising: a memory device having embodied therein data relating to a card holder profile and a merchant profile; a processor in communication with the memory device and configured to receive information related to at least one purchase from a card holder computer (4) at a card issuer computer (6), authenticate a payment request from the card holder (4a), and transmit card payment information of the card holder (4a) to a merchant computer (3); and a communications link (2) connecting the memory device to the merchant computer (3). 76. A system as claimed in claim 75 in which the communications link (2) also connects the memory device to the card holder computer (3). 77. A system as claimed in any of claims 74 to 76 in which the authentication of the request is by authenticating the identify of the card holder (4a). 78. A system for secure transfer of payment and related purchase information of a payment card transaction, comprising: means for receiving merchant and purchase information from a card holder computer (4); means for authenticating the identity of the card holder (4a); means for searching a merchant profile database (9); and means for sending card holder and payment card information to the card holder computer (4). 79. A system for secure transfer of payment and related purchase information of a payment card transaction, comprising; means for receiving merchant and purchase information from a card holder computer (4); means for authenticating the identity of the card holder (4a); means for searching a merchant profile database; and means for sending card holder and payment card information to a merchant computer (3). 80. A system as claimed in claim 78 or 79 comprising means for populating a merchant payment page. 81. A computer readable medium for use in secure transfer of payment and related purchase information for a payment card transaction, comprising: an instruction code for receiving information related to at least one purchase from a card holder computer (4) at a card issuer computer (6); an instruction code for authenticating a payment request from the card holder (4a); and an instruction code for transmitting card holder and payment card information to the card holder computer (4). 82. A computer readable medium for use in secure transfer of payment and related purchase information for a payment card transaction as claimed in claim 81 comprising an instruction code for transmitting card holder and payment card information to a merchant computer (3). 83. A computer readable medium as claimed in claim 81 or 82 comprising an instruction code for populating a merchant payment page.

Inventors: BRAHMBHATT BHAGWAT, HAMILTON CHRISTOPHER JOHN, WELLS LISA KAY, BRAHMBHATT, BHAGWAT, HAMILTON, CHRISTOPHER, JOHN, WELLS, LISA, KAY
Applicants: BRAHMBHATT BHAGWAT, HAMILTON CHRISTOPHER JOHN, TRINTECH LTD, WELLS LISA KAY, BRAHMBHATT, BHAGWAT, HAMILTON, CHRISTOPHER, JOHN, TRINTECH LIMITED, WELLS, LISA, KAY
Application year: 2000
Main classification: G07F19
IPC codes: G06Q20, G07F7