A computerized method and system for a secure on-line transaction using cardholder authentication

0001A COMPUTERIZED METHOD AND SYSTEM FOR A SECURE ON-LINE TRANSACTION USING CARDHOLDER AUTHENTICATION

BACKGROUND OF THE INVENTION

0003Field of the Invention The present invention relates to a computerized method and system for providing a secure on-line transaction. More particularly, the present invention relates to a method and system for authenticating a cardholder for providing a secure on-line purchase and payment.

0004Description of Related Art A typical online commerce transaction includes a consumer paying for goods or services ordered over the Internet with a credit card or some other type of payment card. During the online transaction, the merchant usually sends an order form and requests the consumer to fill-in personal data and credit card information such as an account number, expiration date, and shipping address. The consumer then returns the completed form to the merchant over the Internet. The merchant typically requests verification that the credit card account number or other payment card account number is valid and receives some authorization for the payment amount.

0005One problem with this traditional approach to online purchasing is that the security of credit card data as it is transmitted over the Internet is at risk. The credit card information can be intercepted and used to make unauthorized purchases. One frequently used approach to address this problem involves encryption of the credit card data before it travels over the Internet and the use digital certificates to identify the consumer. However, encryption algorithms may be broken. Digital certificates often require a large certificate hierarchy and add complexity to the transaction. An additional risk is that, even if the Internet communication is cryptograph ically secure, the credit card numbers can be stolen from a merchant computer terminal, from an electronic merchant database, or from a backup copy of a merchant database stored on magnetic tape or other media. Hence, the credit card information may be stolen by a variety of means and lead to unauthorized use of the credit card.

0006Another approach involves generating a temporary credit card number, which is used as a proxy for the permanent credit card account number. One disadvantage to this approach includes having a different account number for each transaction. Thus, the consumer cannot make purchases on a merchant Internet website using automated purchase technologies based on storing the consumer's credit card information in the merchant's database. Additionally, if the merchant uses the credit card number to keep track of loyalty reward points, for example frequent flier miles, this approach does not allow such tracking because of the use of a different account number for each transaction. Lastly, this approach may cause confusion to the issuing bank or merchant's bank since there is no mechanism in place to keep track of whether the different account numbers are for an Internet or point of service purchase.

0007Another approach involves a payment protocol built for payment transactions especially on the Internet. An example of this approach is the Secure Electronic Transaction (SET ^tm) protocol developed by credit card associations like Visa and MasterCard. This protocol provides encryption of credit card numbers between a cardholder and a merchant. Encryption of credit card numbers also is provided between merchant and the bank. However, this approach requires that each party: the cardholder, the merchant, and the bank installs special software on their computers to support the protocol and communication changes to the cardholder, and to the merchant and its bank.

0008Thus, there still remains a need in the art for a method and system for providing a secure on-line transaction, particularly one which requires minimal or no changes to the software used by the merchant and the merchant's bank. In addition, there remains a need to allow consumer loyalty reward programs to continue with use of on-line purchasing. The method and system should be compatible with merchant websites using technology which stores the consumer's credit card account number in its database. Finally, the method should reduce confusion to the issuing bank or merchant's bank by indicating whether the purchase is an internet or point of service purchase.

SUMMARY OF THE INVENTION

0010The present invention avoids the aforementioned disadvantages. One aspect of the invention involves a method and system for providing a secure on-line transaction by authenticating the cardholder identity. In one variant, the method includes receiving a secure communication from a cardholder computer at an issuing bank computer prior to a purchase. Thus, a cardholder having a permanent account number from a payment card contacts the issuing bank before the purchase transaction is completed.

0011A request for authentication information is transmitted to the cardholder computer from the issuing bank computer. The cardholder may enter authentication information, for example, an account number or, usemame plus a personal identification number or a password. The issuing bank computer responds to correct cardholder authentication by recording the cardholder authentication event in a cardholder authentication database or record for use in payment authorization to a merchant. The issuing bank computer stores this cardholder authentication record in a database. Periodically, the issuing bank computer provides a "skimming" process that periodically erases records from the Cardholder database that are too old. These aspects and other objects, features, and advantages of the present invention are described in the following Detailed Description which is to be read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0013FIG. 1 shows a schematic block diagram of the typical environment in which the method and system of the present invention may be practiced; FIG. 2 shows the schematic block diagram of FIG. 1 with the addition of a Third Party Authentication Service;

0014FIG. 3 shows a schematic flow diagram of one embodiment of a method and system for using cardholder authentication in authenticating a cardholder and recording this authentication event in a database;

0015FIG. 4 shows a schematic flow diagram of one embodiment of a method and system for using cardholder authentication in authenticating a cardholder and recording this authentication event in a database; FIG. 5 shows a schematic flow diagram of one embodiment of the cardholder authentication method to match authentication events recorded in the database to payment requests by a merchant;

0016FIG. 6 illustrates a schematic flow diagram depicting one embodiment for using cardholder authentication in authorizing merchant payment; FIG. 7 shows a schematic flow diagram illustrating one embodiment for the cardholder authentication method to match authentication events recorded in the database to payment requests by a merchant in which the method and system of the present invention may be practiced; and

0017FIG. 8 shows a schematic flow diagram illustrating one embodiment for the cardholder authentication method to match authentication events recorded in the database to payment requests by a merchant in which the method and system of the present invention may be practiced. DETAILED DESCRIPTION

0018The present invention relates to a computerized method and system for a secure on-line transaction using cardholder authentication. One typical example of a business relationship utilizing this invention is that relationship existing between a cardholder having a payment card seeking to purchase an item on-line at a merchant's website, and the bank that issued the payment card. For purposes of this description, the term "payment card" is used interchangeably with any type of payment card such as a debit card, credit card, checking card, and any combination thereof. This "payment card" can be a real physical card like a "plastic card" or a "virtual payment" card as discussed herein or a combination of both types of payment cards. The term "cardholder" refers to the consumer that is authorized by the issuing bank to use the payment card in transactions. Additionally, several terms shall be used throughout the description that shall encompass a wider scope of terms. For example, "unique cardholder identifier", "cardholder identity authentication information", and "cardholder identifier" shall mean at least one of including at least one of a usemame, a password, a pass phrase, a personal identification number; a digitally signed message, digital certificates, a cryptogram, smart card-originated authentication information, an electronic address of the cardholder's processor, a serial number of the cardholder computer's processor, a serial number of software resident on the cardholder computer, a digital secret key shared between the cardholder processor and the issuing bank computer, the permanent account number, an expiration date, the cardholder's social security number, the cardholder's mother's maiden name, the cardholder's birth date, an alphanumeric code, or character; the permanent account number, an expiration date, or an alpha numeric code. In addition, "purchase transaction identifier" purchase transaction information and "purchase transaction authentication information" shall mean at least one of merchant-URL; purchase amount; shipping charges; tax amount; currency; merchant name; language used by merchant web page; character set used by merchant web page; merchant-originated purchase transaction identifier; account verification numbers; logical flag indicating whether order can be split into multiple deliveries in the case of back-ordered goods; cardholder-originated purchase transaction identifier; time-date stamp; information about recurring payments: number of such payments, amount of each payment, frequency of such payments, last allowable date of such payments, maximum accumulated value of all recurring payments; information about ongoing payments (e.g., utility bills), frequency of such payments, last allowable date of such payments, maximum amount of each payment; an account number, expiration date, merchant originated information, purchase amount, a merchant originated unique transaction identifier, a merchant category code, merchant country code, acquirer originated information, acquirer identifier, or acquirer assigned merchant identifier. This purchase transaction information can originate at the cardholder or merchant. Purchase transaction information is received by the issuing bank and used with purchase record information to match information from an authorization or settlement request to approve payment to the merchant.

0019Purchase record information is information generated locally at the issuing bank or other similar acting site operating cardholder authentication software or else obtained purchase record information is in contrast to purchase transaction information which "receives" the information. Purchase record information includes, but is not limited to, at least one of: time-stamp; issuing-bank generated purchase transaction identifier; permanent account number; account verification numbers such as the industry-standard CW2, CVC2 or CID number (these are numbers which are printed, but not embossed, on plastic cards so they don't appear on paper copies of card imprints); merchant-ID; merchant name; merchant nation; merchant state/province; merchant city; merchant telephone number; merchant category code; acquirer-ID; acquirer nation; logical flag indicating whether order can be split into multiple deliveries in the case of back- ordered goods; maximum number of deliveries per purchase for split orders; typical shipping charges; tax rate; typical/maximum delay between time of purchase and time of submitted authorization request; typical/maximum delay between time of purchase and time of submitted settlement request; information indicating whether merchant tracks cardholder account numbers; typical/maximum difference between purchase amount reported to cardholder and authorization amount; typical/maximum difference between purchase amount reported to cardholder and settlement amount. Information in a payment authorization or settlement request received by the issuing bank is meant to include, but not limited to, the following information: payment account number, card expiration date, account verification numbers such as the industry-standard "CVV2", "CVC2", or "CID" number, purchase price amount, purchase currency, billing amount, billing currency, time- date stamp, acquiring bank country, acquiring bank identifier, merchant identifiers, merchant name, merchant country, merchant state/province, merchant city, merchant telephone number, merchant category code, and an alphanumeric code that indicates whether the transaction was point-of-sale, mail order/telephone order, or e-commerce. Historical transaction data is a subset of purchase transaction information and includes, but is not limited to, a shipping tracking number; shipping address; transaction details including a listing of the items ordered, the price of each item, the number of each item ordered; applied discounts, customer- loyalty points awarded; gift certificates used; estimated delivery dates, merchant customer service contact information. Depending on the implementation, historical transaction data may or may not be used to assist in the matching process. In one variant, historical data is used to assist in resolving disputes between the cardholder and merchant or to improve the issuing bank's and cardholder's overall knowledge of a transaction. For example, historical transaction data may assist the issuing bank in challenging a repudiated transaction, or "reminding" the cardholder what was purchased.

0020Broader meanings for these terms may be developed as technology develops as further discussed herein. For the convenience of the reader, an overview of the present invention is discussed below, with a more detailed explanation which follows. For purposes of this overview, the following scenario is illustrated with the intent to describe principles of the present invention. In no way is this summary intended to limit the scope of the invention to only the example given. Thus, in one implementation, a registered payment cardholder visits a merchant's website and plans to make a purchase on the website. The cardholder activates a previously downloaded software payment module, which automatically establishes a communication connection with the issuing bank. The cardholder supplies cardholder identity authentication information, which could include a unique cardholder identifier. The issuing bank of the payment card records this cardholder identity authentication event in a cardholder authentication record located in a cardholder database. Purchase transaction authentication information is also received by the issuing bank and stored in the cardholder authentication record for use in authorizing and settling payment with the merchant. Purchase record information may be locally generated by the issuing bank and also used in the matching process. The issuing bank sends cardholder information necessary to complete the purchase transaction which includes at least the permanent account number of the payment card and may include a purchase transaction identifier for the cardholder. The identifier, along with other purchase transaction authentication information, and purchase record information is used in the payment authorization and settlement of the transaction with the merchant. As later described herein, the identifier may be any type of number, letter, character, or the like that can fit in the expiration field of the payment card. However, as further described in detail below, as more fields are developed in relationship to the payment card and merchant web pages, those fields may be used as the purchase transaction identifier. A payment authorization request is sent to the issuing bank when the merchant seeks final payment from the credited transaction. The issuing bank matches information in the authorization request with purchase transaction authentication information in the cardholder authentication record. Based on an acceptable matching level, the issuing bank authorizes payment and authenticates the cardholder's identity based on the previous cardholder identity authentication. Similarly, when a settlement request is sent, based on an acceptable matching level, the issuing bank settles payment with the merchant and authenticates the cardholder's identity based on the previous cardholder identity authentication.

0021In further detail, the principles of the invention can be understood with reference to a method and system that allows the identity of the cardholder to be authenticated prior to the authorization of payment to the merchant. A record of this authentication event, along with other information, is recorded in a cardholder authentication record located in a computer or processor at the payment card-issuing bank. The cardholder authentication record is also used in releasing payment authorization for the purchase. For example, information that is available to the issuing bank when the cardholder authenticates at the start of the purchase transaction is matched to information that is available to the issuing bank in the merchant payment authorization request. Thus, the cardholder authentication can be linked to subsequent payment authorization requests submitted to the issuing bank on behalf of the merchant. The system of the present invention also provides payment authorization without cardholder authentication for circumstances where a cardholder authentication is undesired.

0022Typically, the payment authorization request is submitted by a merchant to its merchant-acquiring bank, which forwards the request through a payment network that ultimately delivers it to the issuing bank. Alternately, the merchant could submit the request directly to the payment network, thereby bypassing an acquiring bank, or the merchant could transmit the request directly to the issuing bank, thereby bypassing both the acquiring bank and the payment network. It is an objective of the present method and system to require no changes to the merchant and bank software, nor to require any changes to the communications between merchant and its acquiring bank, nor to require any changes to the communications between the acquiring bank and the issuing bank, because such changes are time-consuming and costly to the merchants and Banks. In addition, because the present method and system is essentially independent of the back-end merchant and bank software and communications, that back-end system could be upgraded or changed at a later date without requiring any corresponding changes to the software that implements the present method and system. Depending upon the implementation, the present method and system may involve merchants and Banks implementing changes to their software and communications. For example, if the merchant generated a unique transaction identifier number which it shared with both the cardholder and the Banks, or if the merchant allowed the cardholder to generate a unique identifier, which the merchant then passed on to the Banks, the logic to match the cardholder authentication event to the payment authorization request could be simplified. However, a large degree of fraud protection can be obtained with the present method and system without requiring any changes whatsoever to the existing merchant and bank software and communications. Essentially, all implementations of this method and system do not require any major changes to the communications.

0023Customer tracking and transaction tracking mechanisms used by the parties involved in a typical payment card transaction are unaffected. Thus, the present invention provides a secure on-line transaction with minimal complexity to the parties involved in the transaction. Stated differently, the present invention involves the recognition that if the cardholder has a convenient mechanism to communicate with the issuing bank during a payment transaction, then there is enough information present in the existing communications among all parties involved in the transaction to correlate, with a high degree of certainty, the authentication of the cardholder to the payment request made by a merchant that is ultimately transmitted to the issuing bank. A comparison can be made between the information communicated between the cardholder and the issuing bank to the information present in communications between the merchant and issuing bank to make a correlation between the two events with a high degree of certainty.

0024The method and system of the present invention can use a variety of payment account numbers to identify the cardholder account. For purposes of this description, the terms "payment account number", "permanent account number", or "account number" shall generally refer to one or more account numbers from a group of different types of account numbers unless otherwise stated. For example, a "billing account number" represents the number that typically appears at the top of a monthly statement. This account number may also be imprinted on a physical or plastic payment card (the "plastic" number). However, the billing account number may be distinctly different from the plastic charge card. A virtual payment card (VPC) account number may also exist distinct from the previous noted account numbers. This account number may be a number used exclusively for e-commerce purchases and have no physical card form. However, depending on the implementation, the billing account number, the plastic number, and the VPC may all be the same number.

0025In one implementation of the present invention, the use of account numbers may be only valid for purchases over the Internet. In another variant, account numbers are valid for both Internet purchases and point-of-sale (POS) purchases . In both cases, these account numbers may use "permanent" account numbers, in the sense that the same number may be used for multiple purchases over an extended period. Because of the use of permanent account numbers, the method and system offers many advantages including for example, maintenance of customer loyalty reward programs, ability to use on-line purchasing sites that require use of one credit card number, and providing a secure on-line transaction with minimal complexity to the merchant and consumer. In addition, the present invention does not require issuance of digital certificates to cardholders, thereby eliminating the need for a large certificate hierarchy. However, if such digital certificates or other cardholder authentication mechanisms such as "smart cards" are desired by the issuing bank, they could be used within the context of this invention.

0026Two major benefits involving security issues for payment transactions through the Internet are also provided by the present invention. One advantage is the reduction of fraud due to disclosure or theft of the confidential payment card information, which includes the card number and expiration date. The second advantage addresses the inherent lack of authentication of the cardholder's identity during an Internet transaction. For example, in one implementation, a type of payment account number called a virtual payment card (VPC) is used for only transactions conducted through the Internet. All payment authorizations associated with the VPC, which do not originate through the Internet, are rejected. Therefore, disclosure or theft of the VPC account number does not provide an adversary with the capability to generate false physical payment cards with the VPC number written onto the magnetic stripe.

0027In addition, the present invention provides a system and method to authenticate the identity of the cardholder during an e-commerce transaction and tag that particular transaction as having been authenticated by the issuing bank. For example, the authentication event, in one implementation, is stored in a database. Variants of where this record is stored typically include at the issuing bank, and/or a third party Web server. If stored at a third party Web server, the record can also be recorded in a database at the issuing bank. Transactions that are tagged are authorized for payment by the issuing bank. The issuing bank may authorize payment if the transaction is tagged and if it passes the existing, conventional checks. These checks may include for example the following queries: is the cardholder's account is within its credit limit and is the card number hot listed. Identity of the cardholder of the VPC can be determined by the use of personal identification numbers (PIN) with the payment card. Thus, the VPC account number could be used for e-commerce transactions only if the possessor of the VPC also knows the corresponding PIN.

0028Depending on the implementation, the account number is routed through an existing e-commerce payment system, including the electronic merchant, with the same security against disclosure as present payment card numbers. This level of security is presently considered inadequate because the security consciousness of the web based merchants varies widely. In addition, attack on any one merchant can potentially disclose large numbers of payment card accounts. In contrast, the PIN as used in the present invention is verified only through communication between the cardholder and the issuing bank or a third party acting on behalf of the issuing bank. The PIN is never transmitted to the merchant or any other entity in the e-commerce payment transaction system. Therefore, the overall level of fraud is substantially reduced.

0029In another implementation, a search may be conducted by the issuing bank during the authentication process to determine the cardholder credit history. Depending on the implementation, the issuing bank may also transmit credit information to the cardholder. In addition, the issuing bank generates and sends to the cardholder computer an expiration date. In one variant the generation of expiration dates is unique to each transaction. In another variant where the merchant keeps track of the account number for processing subsequent purchases, the expiration date is the same for all transactions between a particular cardholder and merchant combination. In addition, the issuing bank sends to the cardholder computer other information relevant to the purchase transaction, such as the cardholder's shipping address.

0030The issuing bank may receive the total purchase price of the transaction from the cardholder computer. This purchase price may be obtained automatically by the software resident on the cardholder computer that listens to the Internet communication between merchant and cardholder during the course of the purchase transaction, or it may be entered manually by the cardholder. This purchase price may be obtained during the course of the purchase transaction, or after the cardholder has completed the purchase with the merchant. This purchase information is stored at the issuing bank computer, with the cardholder authentication record, for use in payment authorization.

0031The present method and system is built largely on the realization that enough information can be extracted by a software component running on a cardholder computer, which listens to the Internet communication between cardholder and merchant and which transmits information to the issuing bank computer. The software component uniquely links a purchase transaction to a merchants authorization request subsequently received by the issuing bank by using information that is presently available in industry-standard message formats for such requests. Significantly, the linkage can be established with reasonably high assurance without any modification whatsoever to the information provided to the merchant, including the payment card number or the card's expiration date, or to the information contained in the merchant's payment authorization request. Therefore, the proposed method and system can be implemented in the present- day payment infrastructure with complete transparency to the linkage between cardholder authentication and payment request can be established with sufficient reliability to deter most fraud. In addition, the reliability of the linkage is improved by the present invention with only minimal changes to the information supplied to the merchant, such as modified expiration date. Under no circumstances does the proposed method and system for fraud reduction require any changes to the message format of payment authorization requests received at the issuing bank.

0032The information in the cardholder authentication record may not match exactly the information present in the merchant's payment authorization request. For example, due to taxes, shipping charges, or back-ordered merchandise, the purchase amount in the cardholder authentication record may differ from that in the authorization request. In addition, there may occasionally be some ambiguity about the identity of the merchant if the merchant changes its Internet address (URL) or if the merchant starts doing business with a different bank. Although fraud reduction is obviously an important objective of issuing Banks, the issuing Banks must also seldom reject valid transactions. Variants of this method and system provide flexibility to the issuing bank to establish permissible tolerances between data in the cardholder authentication record and payment authorization request that result in approved payment authorization even if the data items do not match exactly. These tolerances can be changed by the bank over time, and they can be applied in different combinations and permutations, so that based upon its business experience accumulated over many transactions, the bank can flexibly adjust its logic to catch the most fraud but reject the fewest legitimate transactions.

0033For purposes of this description, examples are given to describe the interaction between authentication and an authorization request. Similar interaction between authentication and a settlement request using the principles described herein are also within the scope of the present invention. For the convenience of the reader, only examples of authorization are given with respect to authentication of the cardholder with the understanding that a settlement request can similarly be used with the principles applied to the payment authorization request. Payment settlement to the merchant is begun when the merchant submits a request for payment to its acquiring bank or processor, namely the merchant payment acquirer computer. The process flow and information content for settlement request is substantially the same as for the authorization, except that if the settlement request is approved additional processes are instigated leading to the actual transfer of monetary funds between the cardholder's issuer bank and the merchant's acquired bank. With reference to the drawings, shown in FIG. 1 is an issuing bank computer 100 which schematically represents a network, server, mainframe computer, website, processor, in communication with or including an image storage/retrieval system, or a database of information as described herein. For purposes of this description, the term "computer" shall refer to any type of processor, network, server, mainframe computer, and electronic device, regardless if it is wireless or wire connected. Issuing bank computer 100 responds to authentication and payment authorization requests made by a cardholder or merchant related entity such as a merchant-acquiring bank. Similarly, issuing bank computer 100 receives information related to purchase transactions over the Internet from the cardholder, merchant, and acquiring bank. For convenience of illustration, the issuing bank computer 100 is represented as a single entity in FIG. 1 , but it could comprise multiple computers operating on the same local area network (LAN) or it could comprise multiple computers located at different sites which communicate over a public or private network. In particular, the software which authenticates the cardholder may reside on a different computer from the one used by the issuing bank to authorize payment. In some implementations where a third party is used in the cardholder authentication process, the issuing bank receives information concerning the Internet transaction from the third party. The issuing bank computer 100 further includes databases for storing information regarding the transaction between a cardholder and a merchant. In FIG. 1 , software is also shown resident at the issuing bank computer 100. Depending on the implementation, events of authentication, authorization, and settlement of payment can have software, illustrated as "S/W" in the Figs., to perform these functions at the issuing bank computer 100. A cardholder computer 110 is connected to the issuing bank computer by a communication link 101. In one implementation, the cardholder computer is used by a cardholder that has been issued by the issuing bank a payment card. The payment card contains an account number. This account number may or may not be permanent depending on the implementation. As described above, the payment card can be any type of payment card such as a credit card, checking card, debit card, or automatic teller machine (ATM) card. In addition, the payment card can be either virtual, or physical. The term virtual payment card is meant to describe a payment card that does not exist in physical format, and only exists by its account number. Physical payment card is meant to describe a payment card in a physical format such as a plastic card with the account number embossed thereon or inscribed on a magnetic tape on the back of the physical payment card. The card-holder computer 110 also contains software. Typically, the cardholder would "drag & drop" an icon onto the merchant page to initiate the communication with the issuing bank. The cardholder may or may not realize that this communication is taking place depending on the implementation. The cardholder may directly contact the issuing bank or the cardholder prompted for cardholder authentication information, and therefore be aware of the communication. On the other hand, the software may automatically make contact with the issuing bank and supply saved cardholder authentication information stored in the cardholder's computer. The software resident at the cardholder computer 110 allows the cardholder to easily initiate communication with the issuing bank during a transaction with a merchant. Depending on the implementation, the software that resides on the cardholder computer typically does not contain any information about the cardholder. Such transactional information is downloaded from the issuing bank computer on each transaction. One purpose of the cardholder software is to copy this information (such as the payment card number) onto the appropriate merchant field such as a hypertext markup language (HTML) field. The software accepts cardholder information transmitted from the bank computer and copies it into the appropriate fields on the merchant payment page thereby relieving the cardholder from this burdensome task.

0034Communication link 101 is in one embodiment a data link. Such data link can alternatively be, but is not limited to, an electronic data link, optical fiber connection, wireless data connection or any other known connection used for data transfer, for example, over the Internet. Depending upon the implementation, communication link 101 can operate in one or more modes of transmission. For example, such modes include radio frequency transmission, optical transmission, microwave transmission, digital or analog transmission, or other known data transmission. Communication link 101 may comprise multiple communication mediums and intermediate information processors, for example in the case of a cardholder operating a mobile phone, the initial communication medium would be the wireless connection to telecommunications service, which would convert the communication into a standard electronic Internet link. Because communications link 101 conveys confidential information such as credit card numbers and Personal Identification Numbers, it is assumed to be secured by standard cryptographic means, for example Secure Sockets Layer (SSL) encryption protocol. SSL is a protocol for transmitting private documents via the Internet. SSL works by using a private or secret key to encrypt data that is transferred over the SSL connection. Thus, e-commerce and mobile commerce are available in using the system of the present invention. E-commerce is defined as commerce occurring either in part or fully by electronic communication media. Such electronic media includes Internet communications, telephone communications, satellite communications, cable communications, and other related communication methods. Mobile commerce is that commerce transacted on a mobile electronic device. Such devices include mobile phones, hand held computers, pagers, and other wireless communication devices. Mobile commerce may or may not utilize e-commerce communication media. Depending on the implementation, the payment card that is issued from the issuing bank can be in many formats. For example, the issuing bank can issue a physical card that can be used for conventional point-of -sale purchases, mail order, and telephone order purchases. In addition, in one variant of the present invention, it can also be used for Internet based e-commerce purchases, mobile-commerce purchases, and secure electronic transaction purchases. Again, this payment card would have a single, permanent account number associated with it at the issuing bank computer 100.

0035In another implementation, the bank may issue a virtual payment card that is only authorized by the issuing bank for transactions on the Internet. Another variant would allow the issuing bank to create a single master payment account, which typically would have associated with it a physical payment card. The master payment account would have associated with it sub-accounts with different permanent account numbers than the parent master account. All charges against these sub-accounts would appear on the master account billing statement. In one embodiment, individual transactions would be identified by which of the several account numbers, the master account or sub-accounts, was used to make the purchase. Depending on the implementation, the master and sub-accounts could have several combinations of whether the account number is authorized for Internet purchases only or point-of-sale or both types of purchases.

0036When the cardholder opens an account with the issuing bank, the initial registration and credit-rating processing can be done through conventional means such as "walk-in" personal contact with the issuing bank, through a telephone application, or electronically via the cardholder computer over the Internet. This registration feature is typically not used for the authentication or cardholder identity verification phase. However, it is within the scope of this invention to include such a variant. Another variant includes taking an existing account number and assigning a new, associated account number for use in the above-described system. For example, a cardholder may have an existing credit card account. That account number would be assigned a virtual payment card to allow the cardholder to purchase over the Internet using the secure on-line system and method of the present invention.

0037For all the examples outlined herein, the issuing bank could use a permanent substitute account number, which issued in place of the true account number without revealing the true account number. The substitute account number can be any type of fabricated number, character, symbol or the like that the issuing bank can link to the true account number. In addition, the account number may be permanent for advantages previously described. In this manner, if the account number is stolen, the true account number need not be replaced with another account number. An advantage of maintaining both a physical card number that represents the true account in addition to an associated virtual card number which is usable only on the Internet is that, in the unlikely event that the virtual card number is comprised, it would not be necessary to cancel the physical card number. Cardholder computer 110 contacts issuing bank computer 100 via link 101 when the cardholder activates the cardholder software, typically by mouse-clicking on its icon. This contact is done transparently without the cardholder entering commands other than the simple mouse-click. Initially, the cardholder registers with the issuing bank to set up an account. During this initial phase and depending on the implementation, the issuing bank computer could issue a permanent account number or receive a permanent account number already in existence for the cardholder. Again, depending upon the implementation, the issuing bank computer assigns to the cardholder or allows the cardholder to choose a username password, and/or PIN associated with the permanent account number. In addition, the issuing bank can optionally download to the cardholder computer a secret key, or the cardholder computer could upload a secret key to the issuing bank, or the issuing bank and cardholder jointly construct a secret key. The secret key would be used to authenticate the cardholder or to supplement the authentication of the cardholder. Such a secret key would typically be stored permanently on the cardholder's computer, encrypted for protection against unauthorized disclosure. During communications between the cardholder and the issuing bank, software resident on the cardholder computer would transmit the key to the issuing bank for authentication, or more precisely the software would typically transmit information to the issuing bank which information would convince the bank that the cardholder computer possesses knowledge of the secret key. There are a variety of cryptographic methods known by those skilled in the art by which the cardholder can convince the issuing bank that it possesses the secret key without actually revealing the key itself in a communication. The advantage of sharing a secret key between the cardholder computer and the issuing bank is that in order to gain unauthorized use of the payment account, a potential thief would have to obtain both the secret key and the cardholder's PIN or password. Because the secret key never leaves the cardholder's computer, a thief would have to access the cardholder's computer in order to carry out fraudulent transactions.

0038This invention could employ standard cryptographic methods to authenticate the cardholder to the issuing bank during the purchase transaction. One method involves the use of public key cryptography, digital signatures, and digital certificates. For example, during the registration process, software on the cardholder computer would generate a pair of mathematically-related keys known as public and private keys. The public key is transmitted along with one-time authentication information to a third party, which could be issuing bank or a party acting on behalf of the issuing bank. The party digitally signs the key and sends it to the cardholder software in the form of a digital certificate.

0039Typically, the password comprises a series of alphanumeric characters optionally supplemented by non-alphanumeric characters (such as an underscore, question mark, slash, at sign, any symbol and the like), characters only, or numeric characters only, with a minimum and maximum length specified by the bank. The password comprised of only numeric characteristics often called secret personal identification number (PIN). The password and username are different concepts. The username identifies the user and is not considered a secret. The password confirms the identity of the user and is considered a secret. In one embodiment, it is through this password that the issuing bank computer authenticates the identity of the cardholder prior to or during the purchase transaction. Even if a vandal steals the account number, the cardholder's password remains a secret to the cardholder and the issuing bank. The issuing bank computer can also use additional information in authenticating the identity of the cardholder.

0040Depending on the implementation, such information that would authenticate the identity of the cardholder or cardholder identification information includes the previous listed items as well as at least one of the password, the username of the cardholder, the secret PIN, a digitally signed message with digital certificates, a serial number of the cardholder's CPU processor, a serial number associated with the cardholder's browser software or computer operating system, a shared secret key, or a cryptogram derived from a shared secret key and other information. Such information may be entered manually by the cardholder, for example by typing it into the cardholder computer, or it may be read from a permanent storage device associated with the cardholder computer, or it may be read from a "smart card", which is a plastic card with an embedded microchip that can be loaded with data, or other such hardware device. This information is particularly useful in determining or authenticating the identity of the cardholder when the issuing bank computer is presented with a payment authorization request to authorize payment to the merchant.

0041Depending on the implementation, the cardholder can be asked during the initial registration process whether the cardholder would like to restrict use of the permanent account number to a specific computer address. Thus, cardholders that desire additional security would limit access to one computer. Those cardholders, which desire access from several computers, would skip this feature. In one variant, after this initial phase is successfully completed, issuing bank computer 100 sends via link 101 to cardholder computer 110 the software application previously mentioned. This software generally has three functions. First, at the start of the transaction, it provides a convenient means for the cardholder to enter the information demanded by the bank to verify the cardholder's identity. Second, it automatically copies all payment-card and address information that is transmitted from the bank onto the appropriate fields on the merchant payment page. Third, it automatically transmits information pertinent to the transaction, such as the Merchant's URL address and the purchase amount, to the bank computer. The software also allows ease of use of the authentication process. For example, the fraud reduction feature of the present invention is transparent to the user.

0042Also in FIG. 1 is depicted a merchant computer 120. Merchant computer 120 is connected to the cardholder computer by a communication link 102. Similarly, as with communication link 101 , communication link 102 can have various configurations depending upon the implementation. However, communication link 102 need not be the same, or bear any relation in type or mode, to a particular communication link 101 employed between the cardholder computer and issuing bank computer. In one embodiment, communication link 102 is a data link such as an Internet connection. However, as with communication link 101 , it is within the scope of the invention to include all other types of communication links known.

0043Merchant computer 120 depicts a network, mainframe computer, processor, server, or website in communication with the cardholder computer. The cardholder through the cardholder computer shops at the merchant computer or for example, the merchant's website. Once the cardholder has identified the type and quantity of goods to be purchased, the cardholder is typically presented with one or more merchant "payment pages" which display blank fields into which the cardholder is expected to enter pertinent information such as the payment card number, the expiration date, and shipping and/or billing address. This information is stored permanently at the bank computer. Once the cardholder's identity has been established to the satisfaction of the bank computer, this information is transmitted to the cardholder software along with information that specifies which data item should be written onto which field on the merchant page.

0044In an alternate implementation, the cardholder data is stored on the cardholder's computer using a key known only to the bank. In this implementation, after the cardholder's identity has been established to the satisfaction of the bank, the bank computer downloads the key to the cardholder computer and software resident on the cardholder computer decrypts the encrypted cardholder data and said data is then copied to the appropriate fields on the merchant web page as previously described.

0045The automatic merchant form-filling capability is mostly intended as a convenience to the cardholder. The cardholder does not have to type in anything onto the merchant page. It doesn't make much difference whether the cardholder types in his payment account number, whether cardholder software reads that payment account number from memory on the cardholder computer, or whether the payment account number is downloaded from the issuing bank to the cardholder computer. The cardholder must establish the communication with the issuing bank, provide authentication, and provide sufficient information to the issuing bank to uniquely identify the purchase transaction. This way, the issuing bank has a clear record that the cardholder intended to carry out this particular transaction. Depending on the implementation, the payment card number and expiration date that is provided to the merchant, and which the merchant subsequently uses in a payment authorization request, may be the same as that which the bank computer logs in its database for the transaction previously described.

0046In one implementation there is nothing to stop the cardholder from manually typing in his payment account number and expiration date directly onto the merchant form, thereby bypassing the entire issuing bank computer system. However, if the cardholder does this, when the issuing bank receives a payment authorization request from the merchant, the issuing bank will not be able to locate a record in the cardholder authentication database corresponding to that transaction, and the issuing bank may then reject the payment authorization. Depending on the implementation, the cardholder can contact the issuing bank prior to completion of the transaction or prior to visiting the merchant's website to obtain the payment card number, expiration date, and other information from the issuing bank computer. The cardholder may authenticate its identity before the issuing bank computer will transmit this information.

0047In another variant, the cardholder may authenticate its identity without any information whatsoever being transmitted from the issuing bank to the cardholder computer during a purchase transaction. In this situation, information is transmitted from the cardholder computer to the issuing bank computer including data to authenticate the cardholder's identity and some of the merchant URL, and the payment amount, and the payment currency. It is the information that the issuing bank needs to correlate the cardholder authentication record to the payment authorization request.

0048The expiration date is an exception to this information flow. By assigning a expiration date that is unique to the transaction, the issuing bank can more easily match the cardholder authentication records to a payment authorization request. However, the issuing bank can perform this matching operation even if a fixed expiration date is consistently used.

0049Because the issuing bank needs some information from the merchant in order to create a complete cardholder authentication record, including typically the merchant URL and the total payment amount, the cardholder software continues its communication with the issuing bank throughout the purchase transaction with the merchant. For example, the total purchase amount is typically revealed by the merchant at the very end of several Web pages, because first the merchant needs to figure in additional charges such as shipping and taxes, some of which are influenced by choices made by the cardholder (for example, overnight delivery vs. standard mail). Authentication of a cardholder's identity is accomplished with. one of several cryptographic techniques. Typically this requires at least one of a username, and a password, or PIN. In one embodiment, the bank computer maintains a database that contains a list of cardholder usernames and associated PIN values, plus other data such as the billing account number, VPC number, Expiry Dates that have been used recently for this cardholder, and other information. The cardholder computer transmits the username and PIN entered by the cardholder to the bank computer, which computer compares the PIN it has recorded in its database for that username to the one submitted by the cardholder. Issuing bank computer 100 responds to a successful authentication event by recording the authentication in a cardholder authentication database. This cardholder authentication record is later used in the payment authorization phase when the merchant seeks payment authorization for the cardholder's purchase. In one variant, the issuing bank computer also responds to a correct cardholder authentication by issuing an expiration date explained herein.

0050Depending on the implementation, the issuing bank computer can also record other information in the card holder authentication record. Such authentication information includes, but is not limited to, a time date stamp, the purchase amount, the merchant's URL, the billing account number, the VPC, plastic card number, the issued expiration date, the merchant's name, the currency of the transaction, a transaction identifier generated by the merchant, cardholder, or bank computer, payment details such as whether splits orders are allowed or expected, payment details that characterize recurring charges such as the frequency in magnitude of those charges, a shipping tracking number, as well as transaction details such as individual item description, number of items of each type, taxes, and shipping charges.

0051In addition to sending cardholder payment information including the account number, an expiration date, and shipping address to the cardholder computer for automatic insertion onto the HTML merchant page in response to a correct authentication, the issuing bank computer can also send the cardholder information about the cardholder's account balance and maximum credit available. Additionally, the issuing bank can offer to the cardholder an opportunity to increase the cardholder credit limit and/or take out a loan to conduct the purchase with the merchant. This feature provides to the cardholder the avoidance of embarrassment at having the transaction rejected due to an exceeded credit limit. In addition, the issuing bank gets an opportunity to effectively make a loan offer to a highly motivated buyer. In addition, the bank has an opportunity at this point to look up data related to the merchant and transmit such data to the cardholder, for example a warning about a merchant with a poor record of customer service.

0052Alternately, prior to downloading the cardholder information and prior to generating the authentication record in its database, the bank has an opportunity to compare the merchant URL and payment amount against a predefined list of merchants which have been approved for shopping. In this implementation, the approved list would be defined by the cardholder or the person responsible for the cardholder account, rather than by the bank. This provides an organization, for example a corporation, with the .capability to issue virtual credit cards to its buying agents for e-commerce purchases, but to restrict such purchasing power to a defined list of merchants and/or to a limited dollar ceiling.

0053In another variant of authentication, the cardholder can be authenticated by a third party computer denoted in a block 112 instead of the issuing bank computer. The third party authenticator computer is linked to the card holder computer through a communication link 105. Similar to link 101, communication link 105 is In one embodiment a data link. Communication link 105 can have various configurations depending upon the implementation. However, communication link 105 need not be the same, or bear any relation in type or mode, to a particular communication link employed in this system.

0054The third party authenticator computer would receive authentication information from the cardholder similar to the procedure followed for the issuing bank computer. The third party would then transmit a special digital file, for example , a "cookie" to the cardholder computer which provides evidence of the cardholder's identity. A digital secret shared between the third party computer and the issuing bank computer allows the issuing bank to verify the validity of a cookie and the cardholder's identity. This file is then automatically retransmitted to the issuing bank computer by the cardholder computer. Alternately, the third party could transmit its decision regarding the authentication including for example a digital file directly to the bank, thereby bypassing the cardholder computer.

0055Depending on the implementation, the issuing bank generates a unique expiration date. This date may be generated randomly or non-randomly. The date is unique in the sense that it is unique to that particular transaction. However, it is within the scope of the invention to provide an expiration date that is the same for advantages discussed herein. This date may be presented in the format expected by the merchant (typically month and year) and may be a valid expiration date as defined by the merchant. Typically this means that it cannot be a date that has already past and not be a date too far into the future, as most merchant web sites only accept expiration dates 2-10 years into the future. In practice, the issued unique expiration date will typically be a date 6 - 36 months from the current date. The issuing bank computer will attempt to avoid using expiration dates previously assigned to a particular cardholder within the recent past, so that the expiration date is a numerical tag that uniquely identifies a given transaction. Since the number of possible expiration dates is fairly limited, this may not always be possible, and under such conditions a transaction will be uniquely identified only by the combination of the expiration date plus other information such as the merchant URL and a purchase amount. Issuing bank computer 100 has the ability to determine whether the merchant tracks account number for subsequent purchasing reasons, customer loyalty programs or other related reasons. If the merchant does track the account number, the issuing bank computer has the ability to generate the same expiration date for that particular cardholder and merchant combination. In this manner, such merchant tracking is preserved as well as the merchant's reasons for tracking the account number. The issuing bank software may or may not know whether the merchant tracks the expiration date for subsequent purchasing reasons. It depends whether the merchant has been "Profiled" which is further explained herein. The bank computer has the option to treat merchants which have not been Profiled either as merchants which track the account number, or as merchants which do not track the account number.

0056Some merchants generate a unique transaction identifier number called an order number in some implementations and pass this number to the cardholder computer. This issuing bank can store the number in the cardholder authentication record. Storing data in this way would provide some assistance in resolving later disputes between the cardholder and the merchant, because both parties would have an easy way to uniquely identify the transaction. However, because there is no industry system at present which allow a merchant to transmit such a number to its bank as part of its payment authorization request, such a number would not assist in matching the cardholder authentication events to the merchant's payment authorization requests. If the merchant forwarded the transaction identifier number to its bank, and the bank forwarded the number through the payment network to the issuing bank, then the number would assist in matching the cardholder authentication events to the merchant's payment authorization requests. As described below, this implementation provides further reductions in fraud, but it would require changes to the communication protocol between the merchant and its bank, between the bank and payment network, and between the payment network and the issuing bank. In other implementations which do not involve a merchant- generated transaction identifier, fraud is nevertheless reduced significantly because a thief who illicitly obtains the confidential cardholder information including VPC and expiration date that is transmitted to the merchant must carry out a fraudulent purchase within a short time window of the original legitimate purchase, at the same merchant as the original purchase, and for a purchase value less than or comparable to the original purchase amount. If the merchant generates a transaction identifier which is transmitted both to the cardholder and to the back-end banking system, the potential for fraud is reduced still further, because in addition to the constraints above, the thief would have to somehow coerce the merchant software to issue the same transaction identifier to the fraudulent transaction that was issued previously to the legitimate transaction.

0057Further depicted in FIG. 1 is an acquiring bank computer 130. The acquiring bank computer is connected to the merchant computer by a communication link 103. A payment card network 104 connects the acquiring bank to the issuing bank computer. Similarly to link 101 , communication links 103 and 104 are data links. However, communication links 103 and 104 need not be the same, or bear any relation in type or mode, to a particular communication link employed in the present invention. The payment card network 104 may involve several other parties such as major credit card providers, for example, that would provide the communication link between the acquiring bank computer 130 and the issuing bank computer 100.

0058In some implementations, the merchant computer may communicate directly to the issuing bank computer to forward the authorization request. An acquiring bank computer 130 depicts the current network or system used by merchants to receive payment authorizations from the card issuing bank. The acquiring bank computer typically sends a request to the issuing bank for authorization of payment. Depending on the implementation, this authorization process can occur before, during, or after the transaction. For example, in one implementation, the authorization process occurs before or after the cardholder completes the Internet-based communication with the merchant. If the authorization occurs before the transaction, the cardholder knows before entering a transaction whether the credit limit is exceeded and/or whether the card has been identified as stolen for fraud purposes. The issuing bank 100 can optionally provide this information to the cardholder when the cardholder authenticates to the issuing bank 100.

0059Acquiring bank computer 130 transmits information to the issuing bank computer as part of the authorization request. This authorization information includes at least one of the VPC, the issued expiration date, purchase price, currency, the account number, time-date stamp, acquiring bank identifier, merchant identifiers, merchant category code, or an alphanumeric code that indicates whether the transaction was point-of-sale, mail order/telephone order, or e-commerce. In one implementation, the issuing bank compares the authorization information with the earlier authentication information it recorded in the cardholder authentication record. If the information matches, the issuing bank computer sends payment authorization to the acquiring bank computer. The acquiring bank computer then transmits the authorization to the merchant computer. In the matching process where the comparison of the authorization information with the earlier authentication information is accomplished, a transaction identifier field may be used. The transaction identifier field illustrates at least one field in the payment card that may be generated as unique to each transaction, recorded at the cardholder authentication stage, and carried through the transactional process to the authorization and/or settlement requests stage for match up with the recorded or stored transaction identifier field at the previous authentication stage, One example of a transaction identifier field on the payment card is the expiration date field. For convenience of the reader, generation of expiration dates will be discussed as a vehicle to provide minimization of fraud in payment cards. This in no way is meant to limit or disclaim any other field of the payment card presently available or to be created in the future. Depending on the implementation, other fields of the payment card or other fields on the merchant web site, either currently available or later developed may utilize the principles of this invention. The ability to provide a permanent account number with fraud minimization features, such as the generation of an expiration date, is still furthered if other fields on the payment card are used. This other payment card field may be used in conjunction with or instead of the expiration date field.

0060In another variant of the authorization sequence, the issuing bank computer can send payment authorization to the merchant through the cardholder computer. For this variant, the cardholder contacts the issuing bank computer as previously described. When the issuing bank has authenticated the cardholder, the issuing bank can send both authentication and payment authorization confirmations to the cardholder computer. The cardholder computer can then transmit to the merchant computer the authentication and payment authorization confirmations. This variant requires a mechanism by which the merchant can authenticate the validity of the issuing Bank's authorization response. This requirement can be met by a variety of cryptographic methods, such as a secret key shared between the merchant and the issuing bank, or digitally signed messages supported by digital certificates that are signed by a third party. Presently, there is no mechanism in the standard card-association message formats that allow the merchant URL to be included in the authorization request messages. An advantage to the present invention is that it works entirely within the existing infrastructure that has been created over the years to handle credit card payment transactions. This infrastructure includes very well defined and hard to change formats of messages that are exchanged between the merchant and its acquiring bank, and between the acquiring bank and the issuing bank. There are over 20,000 issuing and merchant acquiring banks throughout the world. Essentially, major credit card companies like Visa and MasterCard act like clearing houses to connect all the issuing banks to all the acquiring banks. In this way, each bank needs only to connect to one or two card association networks such as VisaNet and BankNet, for example. Having a well defined message format is needed to keep the information exchange among the parties simple and accurate. Changing the message format for example in adding new fields is a very time consuming and expensive task. It may take up to one year or more to get all parties to agree on a change to the message format and may cost multi-millions of dollars to implement the change.

0061FIG. 2 illustrates another implementation of the invention. Essentially, this implementation differs from the one illustrated in FIG. 1 by separating the authentication and authorization functions shown as comprising a single block 100 of FIG. 1 into two separate services. The principal advantage of this implementation is that it would allow the issuing bank to contract out the responsibility for authenticating the cardholder to an independent third party, thereby relieving the bank of the need to install the cardholder authentication software on its own computers. Shown in FIG. 2 is issuing bank computer 100 which schematically represents the same as previously described for FIG 1. In this implementation, however, the issuing bank computer contains software for just authorization of payment and settlement to a merchant. The issuing bank also contains databases. A third party authentication service denoted by a block 240 contains software and databases for generating and storing cardholder authentication records that contain information pertinent to the transaction and for issuing and downloading cardholder data to the software application that resides on the cardholder's computer. Essentially, the third party authentication service carries out some or all of the functions illustrated in FIG. 1. The actual authentication of the cardholder's identity could optionally be carried out by a different entity represented in block 112 and communicated to the third party authentication service in block 240. Depending on the implementation, the third party authentication service is in communication with both the cardholder and the issuing bank computer. When the acquiring bank seeks payment for the merchant, the issuing bank computer authorizes payment and may use information from the third party authentication service.

0062Functions of block 112 and 240 can be further distinguished. In block 112, the identity of the cardholder is verified. In block 240, the fact of this successful authentication is recorded for later use. When the issuing bank receives a payment authorization request, it will ask block 240, not block 112 whether the cardholder has been authenticated for this transaction, even though the initial authentication was carried out in block 112. In another variant, the issuing bank may communicate directly with the cardholder computer during the purchase transaction and receive authentication information and information pertinent to the transaction. It then transmits this information on to the third party authentication service 240. This service retains responsibility for storing the authentication event and the pertinent purchase data in databases for later use. Thus, in this variant, in contrast to the one above, the third party authentication service 240 would not have any direct contact with the cardholder. It is not important whether the authentication information is originally received by the issuing bank or by the third party authentication service. The distinction is that the third party authentication service, rather than the issuing bank, stores a record of this data.

0063Further shown in FIG. 2, show similar blocks with similar numbers as in FIG. 1. For these similar blocks, functions are similar as previously described in FIG. 1. Again, the difference between Figs. 1 and 2 is that the functionality that previously resided only in the Issuing Bank has been split between two entities.

0064Communication link 202 is in one embodiment a data link. This link couples the third party authentication service to the issuing bank computer. This link encompasses the same description as link 101 , but need not be the same type of communication link as link 101.

0065With reference to FIG. 3, depicted is one implementation illustrating the phase or stage of authenticating the cardholder during the cardholder's on-line shopping experience and recordation of the cardholder authentication in a cardholder authentication record. Also, shown in this FIG. is the interface between the cardholder computer and the issuing bank computer. A block 300 depicts a cardholder computer opening a secure communication with an issuing bank computer using the software application that resides on the cardholder computer. The secure communication can be achieved by cryptographic means, but other security measure can be taken as well. For example, other security measures include, but are not limited to, secure line transmission, encryption, and other such security means. A block 310 denotes the issuing bank comparing the username and PIN to the account database to see if there is a match. In this implementation, a username and PIN are used. In other implementations, a password may be used or other information previously described. If there is no match, the issuing computer sends a rejection message to the cardholder computer as shown in a block 311. In this implementation, if a match is found, the issuing bank computer looks up in its database of cardholder accounts to obtain the VPC number which has been permanently assigned to the cardholder in block 315. As described earlier, the issuing bank could instead elect to maintain just a single billing account number on behalf of the cardholder rather than separate account numbers for Point-of-Sale (POS) versus Internet purchases, in which case it would look up the billing account number in block 315. The issuing bank computer may search for available credit limits of the cardholder's permanent account shown in a block 320. A block 321 depicts displaying this information to the cardholder over the cardholder computer. Searching for the available credit limit for the cardholder is optional, however, gives an added benefit for the cardholder. In addition, it takes advantage of the communication line already open between the cardholder and the issuing bank.

0066A block 331 illustrates the issuing bank computer 100 searching for the merchant in a merchant profile table. A "Profile" for purposes of this description is defined as information particular to the merchant and includes one or more classes of information: (1 ) a listing of field names on the merchant web page and which piece of cardholder data, for example the account number, they correspond with; (2) information that correlates the Merchant universal resource locator (URL) to data fields in the payment authorization request such as the Acquirer-identifier, the Merchant-identifier, and the Merchant category code; (3) information that is needed by the application to extract data such as the purchase amount from web pages downloaded to the cardholder computer from the merchant computer and (4) merchant behavior information: information indicating whether merchant ever splits orders into multiple deliveries; maximum number of deliveries per purchase for split orders; typical shipping charges; tax rate imposed by merchant; typical/maximum delay between time of purchase and time of submitted authorization request; typical/maximum delay between time of purchase and time of submitted settlement request; information indicating whether merchant tracks cardholder account numbers; typical/maximum difference between purchase amount reported to cardholder and authorization amount; typical/maximum difference between purchase amount reported to cardholder and settlement amount. A URL is defined as an address used to locate an entity on the Internet. If the merchant does not exist in the table, a new profile may be created for the merchant for use with this cardholder and other cardholders. Additionally, two possible flow paths may be taken, which depend upon the issuing bank's requirements. Essentially, these two paths correspond to whether the issuing bank assumes that merchants unknown to it track or do not track cardholder account data. One possible flow path if no merchant is found in the table is shown in a block 332 which depicts generating a unique transaction identifier field or in this implementation an expiration date in lieu of not finding the merchant in block 331. The expiration date for a given cardholder will be generated, if possible, to be unique to the merchant. Another option if no merchant is found in the merchant table is depicted in a block 330. The block 330 illustrates looking in a cardholder authentication records (CAR) for any match for the cardholder's account number and the merchant combination. In this implementation, the system of the present invention is searching for previous transactions done between the particular cardholder and merchant combination. If the merchant exists in the Merchant Profile Table, the cardholder computer may be offered a display of merchant related information as shown in a block 334. Such information may include for example, marketing information about the merchant's products, business ratings of the merchant from various agencies or other such related information. The next query in this implementation is deciding whether the merchant monitors the cardholder's account number as illustrated in a block 341. Various merchants may keep records of the cardholder for customer loyalty reasons such as frequent flier miles on a major airline. If the merchant does not monitor the cardholder account number, a unique expiration date is generated as shown in block 332. As previously described for block 330, if the merchant is determined to monitor the cardholder account number, then the logic, in this example at the issuing bank, searches for a previous purchase by the cardholder for that merchant. If no match is found, a unique expiration date is generated as previously described for block 332. If a match is found, the expiration date is read from the database or record particular to the cardholder and merchant. Regardless of the path taken, the issuing bank computer writes the authentication event in the cardholder authentication record with the VPC number, expiration date, and other information such as a time/date stamp, purchase amount and the like as shown in a block 350. This authentication information will later be used by the issuing bank computer to authorize payment to the merchant by matching the authentication information with information commonly placed on the authorization request.

0067A block 360 depicts returning the VPC number with the related expiration date back to the card holder computer from which the software application will then write it automatically onto the merchant's payment form.

0068FIG. 4 illustrates another implementation flow for the authentication event described in the previous figure. This implementation allows the issuing bank to decide whether it wants to issue proxy dates for individual transactions, or instead always use the permanent expiration date that is assigned to the payment card. In this implementation, the flow paths are similar to FIG. 3 up until the point where the system attempts to find the merchant in the merchant profile table as shown in the block 431. For clarity of Illustration in FIG. 4, it is assumed that the merchant is found in the profile table. If the merchant is not found in the profile table, the bank would have to decide whether to treat the merchant as one which tracks the cardholder account number, as described earlier in FIG. 3.

0069At this point, a determination is made to generate proxy expiration dates or not as illustrated in block 442. Although the use of substitute expiration dates provides benefit because it simplifies the logic to match Cardholder Authentication records to payment authorization requests, some banks may prefer to work with only the permanent card expiration date. This decision would be predefined by the issuing bank through a configurable logical variable. If the bank chooses to use only the permanent expiration date, it is read from the cardholder account database in block 443. If the bank chooses to use substitute expiration dates, the expiration date is assigned in blocks 441, 430, 432, and 440 in a similar way as illustrated in FIG. 3. Irrespective of whether a permanent or substitute expiration date is used, the authentication event is then recorded in the cardholder authentication record 450 and the account number and expiration date is transmitted back to the cardholder computer as shown in a block 460.

0070FIG. 5 illustrates one implementation of the system of the present invention matching the cardholder authentication record to the payment authorization request. A block 500 denotes payment authorization request data received from the merchant computer and/or acquiring bank computer. A block 510 illustrates the issuing bank computer searching its database for various information. A block 511 illustrates providing information to the issuing bank computer from a cardholder authentication database. For example, this database may provide all records in the cardholder authentication database which match the VPC number and optionally the expiration date in the payment authorization request. These records include also some of the time-stamp of the authentication event, the merchant URL, and the purchase amount and the currency reported to the cardholder during the e-commerce transaction. A block 512 depicts a merchant mapping database. The merchant mapping database includes information on merchants that allows the issuing bank to associate the merchant URL to data present in the authorization request. In particular, the merchant mapping table contains the values of several parameters typically present in authorization requests such as an Acquiring bank identification number, a merchant identification number, a merchant category code, a merchant name, and the like, through previous experience, to be associated with a given merchant URL. At this point, the issuing bank would also look up whether the merchant is known to track customer account numbers. A block 513 illustrates an account database. This database includes information on the cardholder's account. Such information includes credit limits, balance information, previous history of repudiated transactions or reports of fraud by the cardholder, and other related account information.

0071A block 520 represents a number of comparisons of individual items, which may or may not match. For example, a comparison of the following may be implemented: (a) the merchant identity, using the merchant URL, the acquirer ID, the merchant ID, merchant name, merchant nation, and a merchant category code; (b) the purchase amount; (c) the comparison of the time stamps of the cardholder authentication and payment authorization requests; (d) the expiration date. Some of these items may match well, but not necessarily all of them will match perfectly even for legitimate transactions. Due to the wide variety of business practices of e-commerce merchants and merchant acquiring banks across the world, there is not perfect uniformity in the content and reliability of data in payment authorization requests. Based on experience over time, the issuing bank needs flexibility to authorize payment for some transactions even if not all of the items match perfectly.

0072Block 530 takes as input the graded comparisons of the individual items. For example, it might be a perfect match on the merchant identity, a good match on the time stamp, and a bad match on the purchase amount. Block 530 has logic that decides whether to authorize payment depending on all of the graded comparisons. In one variant, there may be a "scoring" approach, which gives different weights to different items of information. This approach would fold in the quality of the match for each item. For example a 0 for a bad match, 1 for a reasonable match, 2 for a strong match, and three for a perfect match. The issuing bank would have to determine what constitutes "good" or "bad" matches and assigns tolerances accordingly.

0073Two features of this logic provided by the block 520 and 530 are of interest. First, the logic separates the bank's tolerances on what constitutes a good match on individual items such as the Merchant ID from the comprehensive evaluation of all the items taken together. This system provides the issuing bank with great flexibility to control what constitutes an acceptable match. Second, both the scoring of the individual items and the final comprehensive analysis is influenced by numbers that the issuing banks specify in blocks 521 and 531. In this way, the issuing bank can change the behavior of the logic quite easily and flexibly without requiring a rewrite of the underlying logic and software.

0074A user interface denoted by a block 525 is provided to the issuing bank computer to allow the issuing bank to configure the individual authentication evaluation and comprehensive authentication analysis to meet the needs of the issuing bank. Such configuration is typically done through the user interface and configuration files denoted in the block 521 and the block 531.

0075In some cases, for example during repeat purchases over a short period of time by a single cardholder at merchants who track cardholder accounts, more than one record in the cardholder authentication table will be approved by the logic describe in blocks 510-560. In this case, it is not possible to differentiate amongst the records in the cardholder authentication table which match the authorization request. In this case, comparisons of the dollar amount in the authorization request to purchase amounts stored in individual records in the cardholder authentication table are not meaningful, and instead it is necessary to compare the aggregated sum of all matched authorization requests against the aggregated sum of all matched records in the cardholder authentication database. The logic illustrated in FIG. 5 may be called twice by the issuing bank software during its processing of an authorization request, with two different sets of configurable tolerances that define an acceptable match. One of these calls defines what the bank itself regards as an acceptable match for approving the authorization, based on the bank's own fraud experience. The second call defines what card associations such as VISA and MasterCard may regard as an acceptable match in order to qualify the transaction for favorable processing charges. For example, if the transaction meets stringent card-association standards for authenticating the cardholder by requiring a high degree of matching on multiple data fields, the card associations may share a higher fraction of their fee charged to merchant with the issuing bank. The issuing bank would indicate that a particular transaction met these standards by setting a logical flag in the authorization response message to a pre-defined value.

0076When the authentication process illustrated in FIG. 5 is completed, the payment authorization request is judged to either have or not have a match in the cardholder authentication database. Typically, a transaction that has a match (Cardholder Authentication Status = Approved) as illustrated in block 540 -will be ultimately approved by the issuing bank for payment authorization. A transaction that does not have a match (Cardholder Authentication Status = Rejected) as illustrated in block 541- will be ultimately rejected for payment authorization. However, this is not necessarily always the case. For example, although the transaction has a match in the cardholder authentication table, the issuing bank may reject the transaction because the cardholder has exceeded his credit limit. Similarly, even if the transaction has no match in the cardholder authentication database, the issuing bank may elect to approve the payment authorization request for some high-value cardholders whose business they do not which to lose in the event that the transaction was legitimate. The cardholder authentication status is set to Approved or Rejected status in blocks 540 and block 541, respectively. If the cardholder is rejected in the authentication phase, the cardholder authentication record is updated as shown in a block 542. If the cardholder authentication status is set to rejected, additional records may be written in block 543 to various error and fraud-alert database tables to allow the bank to track down fraud attempts and to notify cardholders that particular transactions have been rejected. If the cardholder is approved, the cardholder authentication record is updated in block 550 and stored for later use in the purchase authorization phase. A block 560 denotes that the authentication status is sent back to the issuing bank. Depending on the implementation, this information of the outcome of the authorization decision may be stored in the original cardholder authentication record or a new database table.

0077FIG. 6 illustrates one implementation of the authorization phase between a merchant or its acquiring bank, and the issuing bank. The ordering of decisions in FIG. 6 illustrates one of many possible implementations, and a person skilled in the art could obtain essentially the same result with the logic tests in other orders. FIG. 6 represents an implementation that is especially simple to integrate into existing issuing-bank payment-authorization software. Generation of an expiration date as a unique identifier has been discussed as a vehicle to provide minimization of fraud in payment cards. Depending on the implementation, other fields of the payment card or other fields on the merchant web site, either currently available or later developed may utilize the principles of this invention. The ability to provide a permanent account number with fraud minimization features, such as the generation of a unique identifier, is still furthered if other fields on the payment card are used. This other payment card field may be used in conjunction with or instead of the expiration date field.

0078A block 600 denotes receiving the payment authorization request from the merchant or merchant-acquiring bank. In the implementation illustrated, cardholders are assigned permanent Virtual payment card (VPC) numbers for use in internet commerce which are different from the underlying account numbers imprinted on their plastic credit cards, however, the invention is not limited to such an embodiment. For example. VPC numbers may be the same as the underlying account numbers imprinted on the plastic cards. The issuing bank computer, in one implementation, determines if the account number in the authorization request represents a physical card or a virtual card as shown in block 604. The bank can use a variety of means to differentiate the VPC numbers from the underlying account numbers. A standard industry format for credit-card numbers comprises an initial set of six digits to identify the Issuing Bank (these digits are the Bank Identification Number, or BIN), followed by 9 digits to identify the account number, followed by a checksum digit. One approach to differentiating the VPC numbers from the underlying account numbers is to assign them to a different BIN.

0079If the account number is determined to correspond to a physical credit card, the logic proceeds to block 640, discussed below. If the account number is determined to be a virtual card number, the issuing bank computer proceeds to the logic comprised in blocks. The main purpose of blocks 608-648 is to determine whether or not a match for this transaction exists within the Cardholder Authentication records. The issuing bank computer first determines whether the purchase transaction is a Point of Sale (POS) purchase, a mail-order-telephone order purchase, or an e-commerce purchase in block 608. This decision is made based on a data field present in the authorization request. For purposes of fraud reduction in this cardholder authentication system, mail-order telephone-order purchases are treated synonymously with POS purchases. If the transaction is determined to be a POS purchase, the transaction is immediately flagged in block 608 as having Cardholder Authentication Status = Rejected in the Cardholder Authentication records, because records are not generated for POS purchases. If the transaction is determined to be an e-commerce transaction, the issuing bank computer proceeds to block 616 to determine whether there is a match for this transaction in the Cardholder Authentication record database illustrated as a block 624. The logic for this match-checking process was previously illustrated in FIG. 5. If no match is found, the transaction is flagged as having Cardholder Authentication Status Rejected in block 620.

0080If the outcome of block 616 is that Cardholder Authentication Status=Approved, the flow path proceeds block 628, where the data in the authorization request are compared optionally a second time to data in the cardholder authentication record, this time with a different set of configurable tolerances that define an acceptable match. The authentication information, which includes the previously described payment transaction information plus payment record information which may be used individually or in combination with each other, and previously described payment authorization information are matched. Depending on a comprehensive comparison of all of the authentication and authorization data, approval for authorization of payment to the merchant may be even if the authentication information does not identically match with the authorization information. The first comparison in block 616 determines whether the match met the standards of what the bank itself regards as an acceptable match for approving the authorization, based on the bank's own fraud experience. The second and optional call in block 628 defines what card associations such as VISA and MasterCard may regard as an acceptable match in order to qualify the transaction for favorable processing charges. For example, if the transaction meets stringent card-association standards for authenticating the cardholder by requiring a high degree of matching on multiple data fields, the card associations may share a higher fraction of their fee charged to merchant with the issuing bank. The issuing bank would indicate that a particular transaction met these standards by setting a logical flag in the authorization response message to a pre- defined value. The Cardholder Authentication Status is set to Approved in both blocks 632 and 636. However, the value of a flag indicating "match meets Card Association Standards" or "match fails Card Association Standards" is set differently depending on the outcome of the match comparison in block 628. Irrespective of whether the Cardholder Authentication Status flag is set to Rejected in block 612 or 620, or to Approved in block 632 or 636, the flow paths following these blocks all proceed to block 648. Here the issuing bank computer looks up in its cardholder account database to determine the billing account number which corresponds to the virtual account number. This number rather than the VPC number is forwarded to the existing issuing-bank authorization software, depicted in FIG. 6 by the composite block 652, which performs other standard checks on the account number as described below. The advantage of this system is that it requires minimal changes to the existing authorization software in the sense that said software deals with the billing account number as it did prior to the implementation of the Cardholder Authentication logic.

0081If the test in block 604 determines that the account number in the payment authorization request is a physical account number, the flow path proceeds to block 640 to evaluate whether the purchase transaction is a point-of- sale transaction or e-commerce transaction. This decision is based on a field in the authorization request which indicates the type of transaction. In the implementation illustrated, if the transaction is identified as an e-commerce transaction, the system returns an Authorization Code = Rejected status in its authorization response in block 644, because physical cards should not be used for e-commerce transactions. However, this decision rests with the issuing bank, which may elect to continue processing the authorization request by proceeding to block 652 even if the transaction is e-commerce, particularly during initial operation of this system. Depending on the implementation, if block 640 determines that the transaction type is e-commerce or Point of Sale (POS). If the transaction is POS, the flow path proceeds directly to block 652.

0082The issuing bank computer, in one implementation, determines if the account exists as shown in block 656. The issuing bank computer reads data from a cardholder accounts database or file depicted in block 660. If no account exists, the issuing bank computer sends a rejection message shown in block 664. If an account does exist in the cardholder account database, the issuing bank computer determines if the payment card account number has been "hot-listed" as demonstrated in a block 668. The term hot-listed refers to having the account on a list of account numbers, which are known or suspected to have been stolen. The issuing bank computer reads accounts numbers from a hit-list data bank depicted in a block 676. If the account number is on the hot list databank, the issuing bank sets its authorization code to Rejected in the authorization response in block 672. Finally, if the account number does not appear on the hot-list data bank, the issuing bank will determine whether the cardholder has enough credit or balance in the cardholder's account shown as a block 680. If the purchase price exceeds available credit limits, a rejection message is sent in the payment authorization response as depicted in block 684. If the credit limit or account balance is not exceeded, then the issuing bank approves the authorization request and transmits its approval in its authorization response in block 692. FIG. 7 demonstrates another implementation of the present invention. The flow path in FIG. 7 illustrates one embodiment of the logic involved at a high level for determining whether there is an acceptable match between the authorization request and data in the cardholder authentication database records: Again, acceptability of the match is determined by the issuing bank, and may or may not vary between different issuing banks. Also described in FIG. 7 is the determination of the type of purchase transaction, for example point-of-sale or e- commerce, and whether the purchase type is consistent with the type of payment card used (virtual or physical).

0083A block 700 in FIG. 7 illustrates a determination made by the system of the present invention of whether the payment card number in the authorization request is a virtual payment card (VPC) account number. There are various ways of making this determination as previously described. Depending on the implementation, a different Bank Identifier Number (BIN) for payment card numbers that are VPC may be utilized to assist in the determination. If the payment card number. is not a VPC, using this logic scheme a rejection of payment authorization is sent back to the acquiring bank or merchant as indicated by block 722. If the payment card number is a VPC, a determination is made by the system whether the transaction that is found in the cardholder authentication record is an e-commerce transaction. This logic is shown as a block 724. There are various ways of determining whether the transaction is an e-commerce method as previously illustrated. If the transaction is not an e-commerce transaction, a rejection is sent to the acquiring back or merchant as indicated by a block 726. If the transaction is an e-commerce transaction, a determination by the system is made whether the virtual payment card number and expiration date in the authorization request matches the virtual payment card number and expiration date in the cardholder authentication table. This determination is illustrated by block 728. In this implementation, if there is no match a rejection is sent indicated by block 729. If there is at least one match, the flow path proceeds to logic found in block 730.

0084In this implementation, block 730 represents logic used to make a determination of authentication by using information about the merchant's identity and the time difference between certain transactional events. Block 732 represents logic used to compare information concerning the merchant's identity. Depending on the implementation, information previously stored about the merchant is compared to information that is received with the payment authorization request. Several possible types of merchant information may be compared as previously described. Information is passed to logic that compare the time difference between certain transactional events as illustrated by a block 733. Depending on the implementation, the transactional events compared for time difference may or may not be selected by the issuing bank. Certain transactional events may include but are not limited to time authorization request was received, time card holder was authenticated, time of purchase by cardholder, and any combinations thereof. An allowed tolerance for the time difference may or may not be set to further the determination of authentication. Again, this tolerance may or may not vary from different issuing banks. The process described in block 730 is looped for each candidate record or transaction. For example, if a cardholder had multiple transactions, which used the same expiration date, information for each transaction would go through the process described in block 730.

0085Depending on the implementation, after this loop is completed, results from the information comparison in block 730 is passed to block 749. Block 749 illustrates a determination of a number of remaining good matches from all the information compared in each block of block 730. If the results indicate none or no matches, a rejection is sent as shown by block 752. If the results indicate exactly one match, a comparison may be made between the amount in the authorization request to the amount in the audit log record and the maximum number of authorizations associated with a single purchase allowed by the issuing bank. In another example, the bank may impose a maximum number of purchases or accumulated purchase amounts in a specified time period. These comparisons are illustrated in block 760. If the comparison from block 760 is deemed acceptable by the issuing bank, the transaction is authenticated as shown in block 764. If the bank determines that the comparison in block 760 is not acceptable based on the banks preset standards, a rejection is sent as shown in block 766 for a single purchase. A merchant may submit multiple authorization requests for a single purchase transaction, typically if the order is split into several parts due to lack of inventory at the merchant. The logic in block 760 in addition to the comparing the dollar value of the purchase against those in the associated authorization requests, compares the total number of authorizations that have been charged against a given record in the cardholder authentication table with an issuing bank-specified maximum number

0086More than one cardholder authentication record may pass the additional tests embodied in block 730. This situation would prevail, for example, if a cardholder makes multiple purchases over a short period of time with a merchant which tracks cardholder payment-card account numbers. In this case, the logic proceeds from block 749 to block 753. Block 753 compares the aggregated amounts in all matching audit records to the aggregated authorized amounts in all matching authorizations requests. For example, the total amount or purchase prices of all matching transactions the cardholder performed that were recorded at the issuing bank is compared to the total amount in all matching authorization requests. Similar to the determination in block 760, if the comparison in block 753 is deemed not acceptable by this issuing bank, a rejection is sent as illustrated by block 754. Conversely, if the comparison is deemed acceptable, the transaction is authenticated by the issuing bank as illustrated in block 764.

0087FIG. 8 demonstrates one implementation of the detailed logic represented by blocks 730 and 760 of FIG. 7 as block 830 and 860 in Figure 8. This example is only one implementation of such logic and is not intended to limit the invention to this embodiment. A block 800 in FIG. 8 illustrates a determination made by the system of the present invention of whether the payment card number in the authorization request is a virtual payment card account number. If it is not, a rejection of payment authorization is sent to the acquiring bank or merchant as indicated by block 822. If it is a virtual card, a determination shown in block 824 is made by the system of the present invention whether the transaction is an e- commerce transaction. If the transaction is not, a rejection is sent to the acquiring back or merchant as indicated by a block 826. If the transaction is an e- commerce transaction, a determination shown by a block 828 is made whether the virtual payment card number and expiration date in the authorization request matches the virtual payment card number and expiration date in the cardholder authentication table. In this implementation, if there is no match a rejection is sent indicated by blocks 829. If there is more than one match, the flow path proceeds to block 832 which is described more fully below. If there is exactly one match the flow path proceeds to examine other comparisons between the data in the cardholder authentication record and data in the authorization request as depicted in blocks 834 through 864 illustrated in block 830. In the event that more than one record in the cardholder authentication database matches the VPC number and expiration date in the authorization request, the flow path proceeds to block 832. Block 832 invokes a loop that will cause each of the candidate records which have a match on the VPC number and expiration date to undergo the further tests described in blocks 834-864. Under the control of the loop represented by block 832, blocks such as 839 which indicate "send rejection" are interpreted as rejection of a particular candidate record, in which case the loop proceeds to evaluate the next candidate record. Under control of block 832, each of the candidate records is examined in turn. If none survive the tests described in blocks 834-864, then the final outcome is a rejection. If only one candidate record survives the tests described in blocks 834-864, then the flow path proceeds to block 849. If multiple records survive the tests described in blocks 834-864, then it is not meaningful to carry out the final tests, depicted by blocks 849-876, that involve the number of authorizations and the total dollar amount of the authorizations versus the original value of the purchase, against a single audit log record. Instead, the system compares the total dollar value of all surviving records in the cardholder authentication database against the total dollar value of all associated authorization requests. Using logic identical to that depicted in blocks 870-876, if the total dollar value of the aggregated authorization requests is within a bank- defined tolerance of the aggregated purchase amounts, the present transaction is authenticated, otherwise it is rejected.

0088Block 834 illustrates the logic for determining whether the merchant identifier is present in the authorization request. If not, an acquirer identifier is searched for that corresponds to a merchant URL in the card authentication record by using the Merchant Mapping Table previously described. This lookup or search is denoted in block 856. If the merchant ID is present, a determination is made in block 836 whether the merchant URL that corresponds to this merchant ID is present in the Merchant mapping Table. If not, the system proceeds to the block 856 noted above. If the merchant URL is found in the Mapping Table, the system proceed to a block 838 where a comparison is made between the expected Merchant URL to the Merchant URL in the cardholder authentication record. If a comparison match is not made to the issuing bank's standards, a rejection of payment is sent shown by a block 839. Note that the logic and the merchant mapping table may allow more than one merchant ID to correspond to a single merchant URL. If a match is made between the URL's expected from the Mapping Table and received from the cardholder authentication table, then the system proceeds to a block 842. Block 842 illustrates searching for merchant specific profile data including allowable transaction age, and other related information that may be in the Merchant Profile. The system then computes the time difference between the time the authorization of payment was received by the issuing bank and the time the cardholder contacted the issuing bank for authentication of the cardholder's identity. This computation is indicated by a block 844. If the difference is less than zero a rejection is sent indicated by a block 848.

0089Depending on the implementation, block 844 may be connected to block 856 previously described. In block 856, if the search for the acquirer ID that corresponds to the Merchant URL is not found in the card authentication record, the computation in block 844 previously described is proceeds. If the acquirer ID is found in block 856, a comparison of the expected acquirer ID to the acquirer ID in the authorization request is done as shown in a block 858. If the comparison produces negative results per the issuing banks standards, a rejection is sent shown by block 859. If the comparison in block 858 is successful, the Merchant Category code expected for the merchant URL is searched for from the Merchant Mapping Table as indicated in block 862. If the Merchant Category code is not found the system proceeds to block 844 previously described. If the Code is found a comparison is done in block 863 to compare the expected Merchant Category code to the Code in the authorization request. If the comparison is not successful as determined by the issuing bank's standards, a rejection is sent shown in block 864. If the comparison of Merchant Category codes is successful, the system proceeds to block 844 previously described. In block 844, if the result is equal to or greater than zero, the system proceed to block 846 where a comparison is done to determine the difference in time between receiving the payment authorization request and time the card holder authenticated using an allowed tolerance determined by the issuing bank. If the difference exceeds the tolerance a rejection is sent shown by block 850. However, if the difference is within the tolerance allowed by the issuing bank, the system proceeds to block 849. Logic in block 849 determines the number of remaining good matches. If this determination from block 849 does not contain at least one match, a rejection is sent as shown in block 852. If the determination results in more than one good match, a comparison of aggregated amount is done by block 853, in which case a rejection may be sent if the comparison is not satisfactory as determined by the issuing bank.

0090If the determination in block 849 is exactly one match, the process proceeds to block 860 which defines one implementation of block 760 of Figure 7. In this implementation, block 849 proceeds to block 861. A merchant may submit multiple authorization requests for a single purchase transaction, typically if the order is split into several parts due to lack of inventory. The issuing bank retains a running sum of the total number of authorizations shown in a block 865 that have been charged to-date against a given cardholder authentication record by incrementing a counter as depicted in block 861. If the maximum number in block 865 is exceeded, a rejection is sent in response to the payment authorization request as shown in block 868.

0091If the maximum number of authorization are not exceeded, a determination in a block 870 is done to determine whether the purchase amount is available in the cardholder authentication record. If not, the transaction is authenticated as shown in block 874. If the purchase amount is available, block 872 determines whether the dollar value of the current authorization request, when added to all previous authorization requests charged to this cardholder authentication record, exceeds the original purchase price beyond a bank-defined tolerance factor for this merchant. Such tolerances are needed because the purchase price reported to the cardholder by some merchants does not include taxes and shipping charges.

0092If the comparison is not satisfactory, a rejection is sent shown as a block 876. If the comparison is successful, the transaction is authenticated in block 874 previously described.

0093It is understood that the tasks shown in the above-mentioned figures presented in this description can be sequenced in any order to achieve the desired result. Depending on the implementation, it is recognized that any of the events depicted can occur prior to or after its sequenced event. The order or sequence of tasks illustrated in the Figs, is merely intended to be exemplary of the concepts defined herein. In addition, the various comparisons of Merchant ID, Acquirer ID, merchant category code and the like can be extended directly to allow for the possibility that a merchant URL can be associated with multiple values of these parameters rather than just one. Furthermore, at the discretion of the bank individual tests may be activated or de-activated. For example, an issuing bank may elect to skip any comparison of the merchant category code in the authorization request against the value obtained from the merchant profile table for the merchant URL in the cardholder authentication record.

0094It is understood that the above description is only representative of illustrative examples of embodiments and implementations. For the reader's convenience, the above description has focused on a representative sample of all possible embodiments, a sample that teaches the principles of the invention.

0095Other embodiments may result from a different combination of portions of different embodiments. The description has not attempted to exhaustively enumerate all possible variations.

0096Alternate embodiments may not have been presented for a specific portion of the invention. Some alternate embodiments may result from a different combination of described portions, or other undescribed alternate embodiments may be available for a portion. This is not to be considered a disclaimer of those alternate embodiments. It is recognized that many of those undescribed embodiments are within the literal scope of the following claims, and others are equivalent.