KR20060135726A - Systems and Methods for Security of Telephone Transactions and Computer Transactions - Google Patents

Abstract

A secure electronic payment system and method are provided for conducting secure transaction 120 using authentication. The merchant's computer 104 sends an authentication request to the access control server 112. The access control server 112 verifies the identity of the purchaser 102 by, for example, acquiring an authentication 13 via an electronic form or an interactive voice response system. The access control server 112 then sends a response to the merchant's computer. Once the buyer 102 is granted access to the account, the payment by the merchant 104 is processed and the transaction 102 is completed.

Description

SYSTEM AND METHOD FOR SECURING TELEPHONE AND COMPUTER TRANSACTIONS {SYSTEM AND METHOD FOR SECURE TELEPHONE AND COMPUTER TRANSACTIONS}

Cross Reference of Related Applications

This application is filed on Jan. 23, 2004, entitled "System and Method for Secure Telephone And Computer Transactions Using Voice Authentication," US Patent Application No. 10 / 764,099 (US, filed Jan. 23, 2003). Provisional Patent Application No. 60 / 442,143, which is part of an earlier application, is hereby incorporated by reference in its entirety.

The present invention relates to systems and methods for the security of telephone and computer transactions.

Credit cards and other forms of payment card were originally designed for use in in-person transactions, in which the card is a means for payment and for cardholder authentication. It can provide all of them. In addition to the actual possession of the card, the buyer must also provide a signature that can be compared with the signature on the back of the card.

The main disadvantage of the telephone order transaction is that the majority cannot be authenticated in the manner mentioned above. Thus, the number of fraudulent transactions and chargebacks associated with credit / payment cards is increasing as a result. In addition, consumers may be concerned about the potential risk of their payment information being provided by phone to an unidentifiable individual.

On-line shopping, or e-commerce, suffers from many of the same problems. Online shopping offers consumers unprecedented convenience, while at the same time saving merchants and gaining new customers. Many consumers, however, have been reluctant to use these benefits because of fear of theft of sensitive information, such as credit card numbers. Efforts have been made to improve the security of this information transmitted throughout the Internet. For example, Secure Socket Layer (SSL) technology encrypts messages sent between consumers and merchants, making it more difficult for third parties to intercept and use the information. However, this method does not provide the merchant with any verification of the consumer's identity. Thus, if a third party obtained the credit card number by another negative method such as stealing the physical credit card, the SSL method would not prevent the third party from using the stolen information illegally.

SET ^TM (Secure Electronic Transaction) Technology attempts to solve the aforementioned problem by using digital certificates for authentication of consumer / account holders, merchants and credit card issuers. Although SET ^TM is currently the safest way to handle payments over the Internet, it requires digital certificates and cryptographic software to be installed and operated on the account holder's computer.

In fact, most prior art secure e-commerce systems require consumers to install special software on their computers. Yet many consumers are reluctant to install such software, and anyway, specialized account holder applications are incompatible with a wide variety of account holders' access devices (e.g. mobile devices such as personal computers, personal digital assistants, and mobile phones). It may not be. As a result, some e-commerce systems have been difficult to accept widely among consumers.

Thus, to facilitate safer transactions, there is a need in the art for methods and systems for verifying the identity of consumers in connection with telephone purchases or online purchases.

It is therefore an object of the present invention to provide a method for conducting secure telephone and online transactions.

This and other objects may include providing a database that includes first authentication information, preferably associated with ownership of a payment account; Providing payment account information associated with the payment account to be used in performing the transaction; Sending an authentication request including the payment account information to an access control server; Receiving information including an authentication instruction by a merchant; Receiving second authentication information from the customer; And comparing the first authentication information with the second authentication information to determine whether the transaction is a transaction authorized by the owner of the payment account (authorized). Achieved by the system.

It is also an object of the present invention to receive payment account information, preferably associated with the payment account, to be used to perform the transaction; Sending an authentication request including the payment account information to an access control server, receiving authentication information in an electronic form from the owner; Authenticating the owner for authorization of the transaction; And a method and system for performing a secure transaction, comprising authorizing the transaction, wherein the authentication request automatically triggers the transmission of data used for presentation in electronic form by the server. do.

It is also an object of the present invention to provide a database that preferably includes at least a first set of authentication information associated with an owner of the payment account; Receiving payment account information associated with the payment account to be used in performing the transaction; Receiving an authentication request including at least the payment account information associated with performing the transaction; Automatically triggering the display of the electronic form; Receiving a second set of authentication information from a payer of the payment account; Inputting the second set of authentication information into an electronic form; And comparing the first set of authentication information with the second set of authentication information to determine whether the transaction is a transaction authorized by the owner of the payment information. .

The object of the invention is also achieved by a system for conducting secure transactions, preferably comprising a server computer subsystem. The server computer subsystem includes information about at least one payment account, an automated voice response subsystem, and an authentication subsystem that includes at least a first set of authentication information about an account holder of a payment account. The established voice response subsystem connects a call to the account holder to obtain a second set of authentication information, and wherein the authentication subsystem connects the first set of authentication information and the second set of authentication information. In comparison, it is determined whether the transaction is a transaction authorized by the account holder.

The object of the invention is also achieved by a system for performing a secure transaction, preferably comprising a server computer subsystem, said server computer subsystem comprising at least a first set of authentication information relating to the account holder of said payment account. Information about at least one payment account, and a virtual electronic form subsystem, wherein the virtual electronic form subsystem provides the merchant with an electronic form, the electronic form being submitted from the merchant. Receiving two sets of authentication information, the server computer subsystem also compares the first set of authentication information with the second set of authentication information to determine whether the transaction is a transaction authorized by the account holder.

1 is a block diagram illustrating an exemplary system for performing a payment transaction in accordance with an embodiment of the present invention.

2A is a flowchart illustrating an exemplary procedure for performing a payment transaction in accordance with the present invention.

2B is a flowchart illustrating an exemplary procedure for performing a payment transaction in accordance with the present invention.

3A is a flowchart illustrating an exemplary procedure for performing a payment transaction in accordance with the present invention.

3B is a flowchart illustrating an exemplary procedure for performing a payment transaction in accordance with the present invention.

4 is a block diagram illustrating an exemplary system for performing a payment transaction in accordance with the present invention.

5 is a block diagram illustrating an exemplary system for performing a payment transaction in accordance with the present invention.

Other objects, features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate embodiments of the invention.

Throughout the drawings, the same reference numerals and letters are used to indicate the same features, elements, components or parts of the described embodiments unless otherwise specified.

1 is a block diagram illustrating an exemplary system for performing a secure payment transaction in accordance with an embodiment of the present invention. The system is a payment account used to conduct a transaction with a consumer 102, a merchant 104 selling goods and / or services, an acquirer 106 (typically an acquiring bank of the merchant) and the merchant. Issuer 108 (typically a financial institution such as a bank). The system may also include a cardholder's directory / database 110 (hereinafter referred to as directory 110) that stores information about the cardholder's account. Directory 110 is operated by the paying agency (payment organization) such as MasterCard ^® (MasterCard), preferably a server computer connected to a network such as the Internet. According to a representative embodiment of the present invention, the system preferably further includes a publisher access control server 112 paired with a publisher virtual authentication service 114 as part of the publisher system 108.

The consumer 102 may conduct a transaction with the merchant 104 over the telephone. The method and system of the present invention may be implemented irrespective of the means used to conduct a transaction between a consumer and a merchant, and therefore the present invention is not limited to telephone transactions. Payment accounts used to pay for goods or services provided by merchant 104 are generally credit card accounts, debit card accounts, and / or any other type of payment card. Account. This account is not necessarily, but is associated with a physical card. For example, it may be associated with a virtual card that may be electronically stored on a computing device used by the consumer 102. A consumer may be a cardholder, although not necessarily, where the term "holder" includes one or more individuals associated with and authorized to use a payment account or payment card.

In an exemplary embodiment of the method according to the invention, the transaction 120 is performed between the consumer 102 and the merchant 104 using a payment card such as MasterCard ^® . Select a product / service to buy and offers to dealers (104) Traders (104) a payment account information, including MasterCard ^® credit card information to your orders, and the name of the account number, expiration date, and card holder accordingly. Merchant 104 using a computer system that is connected to the network, it sends a query (query) (122) to determine the participation of the cardholder at the time of authentication to the directory service 110, such as MasterCard ^® directory.

Preferably, directory 110 then communicates 124 with issuer system 108 to verify cardholder participation. This verification 124 may be performed in conjunction with the issuer access control server 112, which is preferably part of the issuer system 108. Assuming the cardholder uses an authentication service as described in accordance with the present invention, directory 110 may send a registration verification message 126 to merchant 104 verifying that the cardholder has registered with the authentication service. . After the merchant 104 receives the registration verification message from the directory 110, the merchant 104 may inform the consumer 102 that authentication will be performed and that the transaction will be completed upon receipt of the authentication. The merchant 104 then preferably sends a request 130 for authentication to the issuer access control server 112 via the issuer authentication service 114.

Authentication can now be performed using one of several methods in accordance with certain embodiments of the present invention. For example, in a telephone order authentication system environment, the merchant 104 urges the cardholder to provide data that can be used to perform authentication over a telephone line (or online transaction, the Internet). However, some other procedures for authentication may also be implemented within the scope of the present invention.

For example, in a representative embodiment, an extension of the core protocol of a transaction (e.g., a 3-D security protocol described in more detail below and related to the applications referenced herein) may be implemented and The necessary data can be carried in an extension "tag" of messages (such as VEReq, VERes, and PAReq messages) that are exchanged during other standard 3-D security transactions.

In another exemplary embodiment according to the systems and methods of the present invention, the core protocol may be executed without modification. In one such embodiment, all data and tags according to the 3-D security protocol remain unchanged. However, to perform the authentication step, the merchant can query the second directory to independently determine whether the issuer participates in authentication. If the issuer participates in the authentication, the merchant may instruct the cardholder to call the IVR (Interactive Voice Response) system to complete the authentication.

In another exemplary embodiment according to the system and method of the present invention, as described above, there are local changes but no major changes to the core protocol that allows merchants to enter data into the authentication system for cardholders. Such a system may be particularly beneficial for telephone transactions where the cardholder has no access to the computer and does not want to close the telephone call with the merchant until the transaction is complete (to provide the issuer with the necessary authentication data). In one such embodiment, the 3-D security protocol may be changed so that the access control server URL field in the VERes message may be changed to prompt the merchant to enter authentication data for the cardholder. Clearly, it is desirable for the cardholder to be a consumer; alternatively, the consumer may be a buyer authorized by the cardholder to pay for a transaction with the merchant. The latter case may apply, for example, if the agent of the cardholder is instructed to purchase goods or services for the cardholder. As used herein, the term "owner" includes all such individuals.

Regardless of the procedure used to obtain the necessary information from the cardholder, the information requested by the cardholder for authentication purposes may include any information held by the issuer 108, which is the identity of the sender / buyer. Can be used to verify that the sender / buyer is the cardholder. One such example would be the use of an EMV Chip Card and card reader to provide a cardholder's SecureCode ^™ (security code) to a merchant, issuer or automated call center. Other procedures for verification known to those skilled in the art include dynamic security questions, dual tone multiple-frequency (DTMF) user input by sender / buyer, voice biometrics analysis, Or any other method for verifying that the sender / buyer is the cardholder.

In accordance with the present invention, following the description of a representative embodiment of the system, if the issuer access control server 112 determines that the transaction is correctly acknowledged, the issuer authentication service 114 generates an authentication response message 132 indicating that the transaction has been authenticated. It is desirable to send to the merchant 104 via. Thereafter, the transaction, for example, is known in the art, for example, the communication 134 between the merchant 104 and the acquirer 106 and the communication between the acquirer 106 and the issuer 108 (for example). 136). One exemplary embodiment of the invention may be implemented with a security protocol such as a 3-D (or three domain) security authentication protocol. 3-D security authentication protocols are known in the art and are generally adopted and implemented in the payment industry. The present invention is filed, and the title of the invention on June 10, 2003, "Algorithm for use in a Secure Payment Application" in the United States is of the MasterCard ^® as described in the Patent Application No. 60/477 187 and No. 3 RELATED APPLICATIONS D may be practiced with a security implementation, the entire contents of which are incorporated herein by reference. It should be noted, however, that the scope of the present invention is not limited to this implementation of methods and systems for secure transactions using 3-D security protocols, and the concepts described herein will be apparent to those skilled in the art. Likewise, it can be widely applied in many ways.

Additional details on completing a transaction using MasterCard ^® 's implementation of the 3-D security protocol can be found in the following application, all of which is hereby incorporated by reference in its entirety: September 2001 US patent application Ser. No. 09 / 963,274, filed on June 26, entitled "A Universal and Interoperable System and Method Utilizing a Universal Cardholder Authentication Field (UCAF) For Authentication Data Collection and Validation"; United States Provisional Patent Application 60 / 280,776, filed April 2, 2001, entitled "System and Method for Secure Payment Application (SPA) and Universal Cardholder Authentication"; United States Provisional Patent Application 60 / 295,630, filed June 4, 2001, entitled "Method and Process for a Secure Payment Application Using a Universal Cardholder Authentication Field"; United States Provisional Application No. 60 / 307,575, filed Jul. 24, 2001, entitled "Method and System for Conducting Transactions Over a Communication Network Using a Secure Payment Application"; US patent application Ser. No. 09 / 886,486, filed June 22, 2001, entitled "Method and System for Conducting Secure Payment Over a Computer Network Without a Pseudo or Proxy Account Number"; US patent application Ser. No. 09 / 886,485, filed Jun. 22, 2001, entitled "Method and System for Conducting Secure Payments Over a Computer Network"; US Patent Application No. 10 / 096,271, filed March 11, 2002, entitled " System and Method for Conducting Secure Payment Transactions "; United States Provisional Patent Application 60 / 352,968, filed January 30, 2002, entitled "MasterCard UCAF ™ and SPA ™ Client-less Solutions."

2A and 2B illustrate an exemplary method of operating the payment transaction system shown in FIG. 1 using authentication in conjunction with a 3-D secure authentication protocol. First, the consumer selects the goods and / or services that are the subject of the transaction (step 202). Next, the merchant computer system queries the MasterCard ^® directory to verify the cardholder's participation in the voice recognition system (step 204). Preferably, this query may be in the form of a 3-D Secure Veren Enrollment Request (VEReq) message, as described in detail in the aforementioned references incorporated herein. Obviously, the merchant's system is a software plug-in, for example, to facilitate compatibility and interoperability with the publisher (eg through a plug-in to the publisher's side, such as the publisher's virtual pop-up service) and the directory system. (plug-in) can be configured. This plug-in is used to translate data from the merchant's system into a form suitable for use in the publisher's system and vice versa. Such a plug-in may be useful to facilitate upgrading a merchant's current system to use the systems and methods according to the present invention, but such an upgrade is not necessary within the scope of the present invention. In addition, the plug-in may be software, hardware, or some combination thereof.

The next, MasterCard ^® directory publishers to communicate with the access control server to verify the cardholder involved (step 206). Assuming that the participation of cardholder verification, MasterCard ^® directory sends a message indicating that registration verification After authentication is performed on the merchant's computer system (step 208). Preferably, the registration verification message may be in the form of a VERes message according to 3-D security executed by MasterCard ^® as mentioned above. As also described above, this message may be received by the software plug-in of the merchant system, which provides interoperability with the merchant's current system.

The merchant may receive a VERes message from the MasterCard ^® directory confirming the validity of the cardholder participation and then send an authentication request message to the issuer system (step 210). Preferably, the authentication request message may be a 3-D secure Payer Authorization Request (PAReq) message and may be received by the issuer access control server. The PAReq message preferably includes a plurality of data fields containing information that will allow the issuer to perform authentication, for example, and if the PAReq has not been received from the issuer access control server by the merchant's plug-in, the merchant May include a "Request Expiration" field that can be used to indicate the date that allows the plug-in to time out the transaction.

The issuer access control server may initiate authentication after receiving the PAReq message. In a representative embodiment of the present invention, the issuer authentication service provides a "virtual pop-up" service that prepares an electronic form for the cardholder and sends the form to the merchant to enter the cardholder's data. Can be. The merchant may then request caller / buyer related data over the phone, enter the information into the form, and send the data to the issuer for cardholder authentication (step 214). On_Behalf_Of, or "MOBO" approach, which is described more fully below with respect to FIG. 3A). Upon completion of the authentication procedure described more fully below with respect to FIGS. 3A and 3B, an authentication response indicating the result of the authentication procedure is generated and sent to the merchant by the issuer access control server (step 222). This authentication response may be in the form of PARes, for example in accordance with a 3-D security protocol.

If the authentication fails or times out, the transaction may still be initiated depending on the cause of the failure and the configuration of the system of the particular embodiment according to the present invention. However, if the authentication failure is due to an apparent permission problem, the possibility of potential fraudulent transactions is notified and authentication is rejected (step 218), and the transaction is canceled. Conversely, if authentication is successfully completed (step 220), the access control server may send an authentication response to the merchant (step 222) and the transaction may be completed in a conventional manner according to the 3-D security protocol (step 224). ).

An exemplary procedure for performing authentication (step 214 of FIG. 2A) is shown in FIG. 3A. In this exemplary embodiment, the "MOBO" approach is implemented, i.e. the merchant requests authentication information from the cardholder (e.g., by phone during a telephone transaction) and authenticates the system via electronic form or other means. Enter the information. Upon purchase of the cardholder, the merchant communicates with the issuer access control server via the merchant plug-in to determine whether the cardholder is registered with the authentication service (step 302). In response, the issuer may send a VERes message containing a query string parameter "IVRNO" in an Access Control Server (ACS) URL element. For example, the following sample URL could be included in the VERes message:

https://securecode.issuer.om/authenticate.asp?IVRNO=MOBO

This additional query string parameter appended to the ACS URL is detected by the merchant's plug-in, which tells the merchant that the cardholder is registered for conversion authentication and that the merchant must perform MOBO authentication using a prescribed authentication scheme (e.g. SecureCode ^TM ). Indicates.

The merchant plug-in can then generate a PAReq message and add name / value pairs to the merchant data, such as "## authentication-type = MOBO ##". The merchant may then send the merchant data to the issuer access control server (step 306). This name / value pair indicates that the PAReq sent by the merchant to the access control server is for phone authentication as opposed to e-commerce / online transaction authentication. The merchant may then perform the instructions provided on the authentication webpage provided by the issuer access control server (step 308) and collect the required authentication information from the cardholder. The merchant may then enter the received authentication information into an electronic form of the access control server (step 310). The electronic form (or "virtual popup") is preferably provided by the issuer authentication service. This electronic form may be provided over the Internet using a web interface, or may be provided using any software application that will facilitate secure secure transmission of data between merchants and publishers.

Next, the issuer access control server preferably generates PARes (step 312), and sends the PARes to the URL specified in the TermURL of the PAReq. The merchant plug-in may receive the encoded PARes and extract the digital signature to verify validity (step 314). According to the 3-D security protocol, the merchant can then retrieve the Application Authentication Value (AAV) from the PARes and pass the AAV in an authentication message (step 316). Finally, the merchant may complete the transaction in accordance with the 3-D security protocol or other known trading protocol (step 318).

Another exemplary procedure for performing authentication (step 214 of FIG. 2A) is shown in FIG. 3B. In this exemplary embodiment, a two-way voice response ("IVR") approach is implemented, i.e. the merchant conducts a transaction with the sender / buyer over the telephone and prompts the buyer for authentication information for the purpose of authenticating the sender / buyer. Send to the IVR system and perform the required authentication steps.

Upon purchase of the cardholder, the merchant may communicate with the access control server via the merchant plug-in to determine whether the cardholder is registered with the authentication service (step 320). The issuer may then send a VERes message containing the query string parameter "IVRNO" in the Access Control Server (ACS) URL element (step 322). For example, the following sample URL could be included in the VERes message:

https://securecode.issuer.com/authenticate.asp?IVRNO=IVR

This additional query string parameter added to the ACS URL is detected at the merchant's plug-in, indicating to the merchant that the cardholder is registered for phone authentication and the merchant should perform IVR authentication.

Next, the merchant plug-in generates a PAReq message, name / value pairs to indicate that it is a parameter for authentication, for example:

"## authentication-type = IVR; caller-id = 14403528444; transfer-

back = Y; transfer-number = 18004681512 ## "

Can be added.

The merchant may then send the PAReq to the issuer access control server (step 324). For example, the above value means that the PAReq sent by the merchant to the access control server is for phone authentication as opposed to e-commerce / online transaction authentication, The authentication procedure is an IVR, preferably with caller identification information, an indication regarding the telephone number to which the customer must transfer (connect) for IVR authentication, and whether the caller should be forwarded back to the merchant upon completion of the IVR authentication. It also provides information, such as the TransBack flag indicating to the IVR system. The merchant may then forward (connect) the caller to the telephone number provided in the query string to initiate IVR authentication (step 326). The sender / buyer can then be forwarded to the issuer IVR for authentication (step 328). Authentication can be performed using many different procedures that fall within the scope of the present invention, for example, prompting the sender / buyer to confirm the purchase information, and asking the sender / buyer to obtain the cardholder's SecureCode. Prompting to enter / speak authentication information. The issuer access control server may then authenticate the sender / buyer, create PARes, and send the PARes to the URL specified in the TermURL element (step 330). The cardholder can be passed back to the merchant if the TransferBack parameter of the merchant data so instructs. The merchant plug-in may then receive the encoded PARes and extract / validate the digital signature (step 332). According to the 3-D security protocol, the merchant can then retrieve the AAV from the PARes and forward the AAV in an authentication message (step 334). Finally, the merchant can normally complete the transaction in accordance with the 3-D security protocol or other known protocol (step 336).

Those skilled in the art will appreciate that the methods and systems shown in FIGS. 1-3B may be practiced using various standard computer platforms that operate under the control of appropriate software. In some cases, dedicated computer hardware, such as a peripheral card, in a conventional personal computer may be used to enhance the operational efficiency of the methods described above.

4 and 5 illustrate general computer hardware suitable for practicing the present invention. Referring to FIG. 4, a computer system includes a processing section 410, a display 420, a keyboard 430, and a communications peripheral 440, such as a modem. The computer system also includes a printer 460. Computer systems generally read and write computer-readable media, such as magnetic media (ie, diskettes) and / or optical media (eg, CD-ROMs or DVDs) for storing data and application software. One or more disk drives 47. The system also generally includes an internal computer readable medium 48, such as a hard disk drive. Other input devices may also be included, such as digital pointer 490 (eg, a mouse) and card reader 450 for reading payment card 400. Computer hardware as shown in FIGS. 4 and 5 may be used to execute the software shown in FIGS. 1-3 and / or the consumer 102, merchant 104 (and related merchant plug-ins described above), purchasers 106, publisher 108, and directory 110 may be used to perform the functions of a computer processor.

5 is a functional block diagram illustrating the processing section 410 in more detail. Processing section 410 generally includes processing unit 510, control logic 520, and memory unit 550. Preferably, processing section 410 may also include a timer 530 and an input / output port 540. Processing section 410 may also include a co-processor 560 depending on the microprocessor used in the processing unit. The control logic 520, together with the processing unit 510, provides the control necessary to handle the communication between the memory unit 550 and the input / output port 540. The timer 530 provides timing reference signals for the processing unit 520 and the control logic 520. Coprocessor 560 provides enhanced capabilities for performing complex calculations in real time, as required by cryptographic algorithms.

The memory unit 550 may include different types of memory, such as volatile memory, nonvolatile memory, read-only memory, and programmable memory. For example, as shown in FIG. 5, the memory unit 550 may include a read-only M (ROM) 552, an electrically erasable programmable read-only memory (EEPROM) 554, and a random-access memory (RAM). 556 may be included. Different computer processors, memory configurations, data structures, etc. may be used in embodiments of the invention, and the invention is not limited to a particular platform. For example, although processing section 410 is shown as part of the computer system in FIGS. 4 and 5, processing section 410 and / or its components may be integrated into a PDA or mobile phone.

Although the present invention has been described in connection with specific exemplary embodiments, those skilled in the art will appreciate that various changes may be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims. Of course, changes, substitutions and changes can be made.

Claims (26)

A method of performing a secure transaction between a merchant and a customer, where payment is processed in a payment account, Providing a database containing first authentication information associated with an owner of the payment account; Providing payment account information associated with the payment account to be used in performing the transaction; Sending an authentication request including the payment account information to an access control server;  Receiving, by the merchant, information including an authentication instruction; Receiving second authentication information from the customer; And Comparing the first authentication information with the second authentication information to determine whether the transaction is a transaction authorized by the owner of the payment account; Method of performing a security transaction comprising a. The method of claim 1, And transmitting an authentication response in response to the authentication request. The method of claim 2, Processing the payment in the payment account to complete the transaction in accordance with the authentication response. The method of claim 1, The payment account information is provided via telephone. The method of claim 1, The payment account information is provided over a computer network. The method of claim 2, The authentication request and the authentication response are formatted according to a 3-D Secure authentication protocol. The method of claim 1, The authentication indication includes information on Interactive Voice Response (IVR) authentication. The method of claim 1, And the authentication indication includes information about Merchant-On_Behalf_Of (MOBO) authentication. A method of performing a secure transaction using authentication, where payment is processed in the owner's payment account.  Receiving payment account information associated with the payment account to be used in performing the transaction; Sending an authentication request to the access control server, the authentication request including the payment account information and causing the access control server to automatically trigger the transmission of the data used to display the electronic form; Receiving authentication information from the owner via the electronic form; Authenticating the owner for authorization of the transaction; And Authorizing the transaction Method of performing a security transaction comprising a. The method of claim 9, And transmitting an authentication response in response to the authentication request. The method of claim 10, Processing the payment in the payment account to complete the transaction in accordance with the authentication response. The method of claim 9, The payment account information is provided via telephone. The method of claim 9, The payment account information is provided over a computer network. The method of claim 10, The authentication request and the authentication response are formatted according to a 3-D secure authentication protocol. The method of claim 9, The authentication indication comprises information regarding IVR authentication. The method of claim 9, And the authentication indication comprises information regarding MOBO authentication. A method of using secure authentication and conducting secure transactions where payments are processed by a payment account. Providing a database comprising at least a first set of authentication information associated with an owner of the payment account; Receiving payment account information associated with the payment account to be used in performing the transaction; Receiving an authentication request including at least the payment account information associated with performing the transaction; Automatically triggering the display of the electronic form; Receiving a second set of authentication information from an owner of the payment account; Inputting the second set of authentication information into the electronic form; And Comparing the first set of authentication information with the second set of authentication information to determine whether the transaction is a transaction authorized by the owner of the payment information; How to perform a security transaction comprising a. The method of claim 17, And transmitting an authentication response in response to the authentication request. The method of claim 18, Processing the payment in the payment account to complete the transaction in accordance with the authentication response. The method of claim 17, The payment account information is provided via telephone. The method of claim 17, The payment account information is provided over a computer network. The method of claim 18, The authentication request and the authentication response are formatted according to a 3-D secure authentication protocol. A server computer subsystem including information relating to at least one payment account comprising at least a first set of authentication information about an account holder of the payment account; Automated voice response subsystem; And Authentication subsystem Including; The automated voice response subsystem connects a call to the account holder to obtain a second set of authentication information, And the authentication subsystem compares the first set of authentication information with the second set of authentication information to determine whether the transaction is a transaction authorized by the account holder. The method of claim 23, wherein The transaction is performed according to a 3-D security authentication protocol. A system for conducting secure transactions between merchants and account holders. A server computer subsystem comprising information relating to at least one payment account, the information including at least a first set of authentication information about an account holder of the payment account; And Virtual electronic form subsystem Including; The virtual electronic form subsystem provides the merchant with an electronic form, The electronic form receives a second set of authentication information from the merchant, And the server computer subsystem compares the first set of authentication information with the second set of authentication information to determine whether the transaction is a transaction authorized by the account holder. The method of claim 25, The transaction is performed according to a 3-D security authentication protocol.

Images