JP2007523405A - System and method for secure telephone and computer transactions - Google Patents

Abstract

A secure electronic payment system and a method for performing secure transactions (112) using authentication are provided. The merchant computer (104) sends a permission (approval) request to the access control server (112). The access control server (112) obtains the authentication (130) by, for example, an electronic form or an interactive voice response system in order to confirm the identity of the purchaser. Thereafter, the access control server sends a response to the merchant's computer. If the purchaser is authorized to access the account, the settlement is processed by the merchant computer (104) and the transaction is terminated.

Description

Cross-reference to related applications. This application is a US patent application Ser. No. 10 / 764,099, “System and Method for Secure Phone and Computer Transactions Using Voice Authentication” (filed January 23, 2004) This is a continuation-in-part application of US Provisional Patent Application No. 60 / 442,143 (filed January 23, 2003), all of which are incorporated herein by reference. This application also requests priority from US Provisional Patent Application 60 / 538,761 (filed January 23, 2004), which is incorporated herein by reference in its entirety.

  Other forms of credit cards and payment (payment) cards were originally designed for use in face-to-face transactions (transactions), during which the card is the means of payment, and An authentication means for the cardholder (name holder) can be provided. In addition to actually holding the card, the purchaser must also provide a signature that can be compared to the signature on the back of the card.

  A major drawback with telephone order transactions is that most people are not authenticated in the manner described above. Accordingly, the number of fraudulent transactions and refunds associated with credit / settlement cards has resulted in an increase. In addition, consumers may be interested in the potential danger of giving personal payment (payment) information to individuals who are probably unknown and unidentified on the phone.

  Online shopping, i.e. electronic commerce, suffers from many of the same problems. Online shopping provides consumers with unprecedented ease and convenience while allowing merchants (retailers) to reduce costs and obtain new customers. However, many consumers are hesitant to take advantage of these benefits because of the risk of stealing sensitive information such as credit card numbers. Efforts have been made to increase the security of such information transmitted over the Internet. For example, with secure socket layer (SSL) technology, messages sent between consumers and merchants are encrypted, which makes it more difficult for a third party to intercept and use the information. I have to. However, this method does not provide the merchant with any verification of consumer identity (identity). Therefore, if a third party obtains a credit card number by other fraudulent activities such as physical credit card theft, SSL techniques will prevent unauthorized use of information stolen by the third party. Could not prevent.

  Secure Electronic Transaction (SETTM) technology attempts to solve the aforementioned problems by using digital certificates to authenticate consumers / account holders (holders), merchants and card issuers ing. Each certificate is issued by a trusted certificate authority. While SETTM is currently the safest way to handle payments on the Internet, it requires cryptographic software and digital certificates that are installed and operated on the account holder's computer.

  In fact, most prior art secure electronic commerce systems require that special software be installed on the consumer's computer. However, many consumers are reluctant to install such software. Also, in some cases, special account holder applications may not be compatible with a variety of different account holder access devices (eg, mobile communication devices such as personal computers, personal digital assistants, mobile phones). possible. As a result, it has been difficult for these secure electronic commerce systems to be widely accepted by consumers.

  Therefore, there is a need in the art for a method to verify customer identity along with telephone, ie online purchases, in order to process transactions more securely.

  Accordingly, it is an object of the present invention to provide a method for performing secure telephone and online transactions.

  This and further objects are achieved by the following systems and methods. That is, the system and method for performing a secure transaction preferably includes providing a database including first authentication information associated with a payment account owner (nominee), and a payment associated with the payment account. Providing the account information; sending the authentication request including the payment account information to the access control server, wherein the payment account information is used to execute the transaction; and the information including the authentication command is received by the merchant. Receiving second authentication information from the customer; comparing the first authentication information with the second authentication information to determine whether the transaction is approved by the settlement account owner; Is included.

  This and further objects are further achieved by the following systems and methods. That is, the system and method for performing a secure transaction preferably includes receiving payment account information associated with a payment account, such as used for performing a transaction, and an access control server. Sending an authentication request including the payment account information to the authentication request, causing the server to automatically operate transmission of data used to display the electronic form; Receiving the authentication information from the owner by the electronic form, authenticating the owner for the purpose of approving the transaction, and approving the transaction.

  This object and further objects are further achieved by the following method. That is, a method for conducting a secure transaction preferably includes providing a database including at least a first set of authentication information associated with an owner of the payment account; and payment account information associated with the payment account. Receiving payment account information used to perform the transaction, receiving an authentication request including at least the payment account information in connection with performing the transaction, and displaying an electronic form. Automatically actuating; receiving a second set of authentication information from the owner of the payment account; inputting the second set of authentication information in the electronic form; and Comparing the first set with the second set of authentication information, the transaction But it is intended to include determining whether or not approved by the owner of the payment account.

  This object and further objects are further achieved by the following system. That is, the system for conducting secure transactions preferably includes a server computer subsystem that includes information related to at least one payment account, including at least a first set of authentication information related to the account owner of the payment account. An automated voice response subsystem and an authentication subsystem, wherein the automated voice response subsystem connects a telephone 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 approved by the account owner. It is characterized by that.

  This object and further objects are further achieved by the following system. That is, the system for conducting secure transactions preferably includes a server computer subsystem that includes information related to at least one payment account, including at least a first set of authentication information related to the account owner of the payment account. A virtual electronic form subsystem, wherein the virtual electronic form subsystem provides the merchant with an electronic form for receiving a second set of authentication information from the merchant, the server computer subsystem , Comparing the first set of authentication information with the second set of authentication information to determine whether the transaction is approved by the account owner.

  Further objects, features and advantages of the present invention will become apparent from the detailed description, taken in conjunction with the drawings illustrating illustrative embodiments of the invention. Throughout the figures, unless otherwise noted, the same reference numerals (numbers and letters) are used to indicate similar features, components and parts of the illustrated embodiment.

  FIG. 1 illustrates an exemplary method for performing a secure payment transaction according to the present invention. The system includes a consumer 102, a merchant 104 selling goods and / or services, an acquirer 106 (typically a merchant acquiring bank), and an issuer 108 (typically Is a bank or other financial institution that has issued a settlement account for use by merchants to execute transactions). The system may also include a cardholder directory / database 110 that further stores information regarding the cardholder's account. The database 110 is preferably a server computer operated by a payment organization such as a MasterCard (registered trademark) payment institution and connected to a network such as the Internet. According to an embodiment of the present invention, the system advantageously includes an issuer access control server 112 coupled with the issuer virtual authentication service 114 as part of the issuer system 108.

  A consumer 102 may be conducting a transaction 120 with a merchant 104 by telephone. The system and method of the present invention can be implemented regardless of the means by which the transaction between the user and the merchant takes place, and thus the present invention is not limited to telephone transactions (transactions). The payment account used to pay for goods or services provided by merchant 104 is typically a credit card account, a debit card account, and / or some other type of payment card account (account). . An account is not required, but is associated with a physical card. For example, a payment account can be associated with a virtual card that can be stored electronically on a computing device used by the consumer 102. A consumer may be, but is not required, an account holder (nominee) and, as used herein, the term “owner (nominee)” is a payment account or payment card. Including one or more individuals who are authorized to use and associated.

  In one exemplary embodiment of the method according to the present invention, transaction 120 is performed between consumer 102 and merchant 104 using a payment card, such as a master card credit card. The consumer 102 selects the goods / services to purchase and places an order with the merchant 104, thereby making payment including master card / credit card information such as the cardholder's account number, expiration date, and name Provide account information to merchant 104. To determine the cardholder's participation in an authentication service, a merchant 104 using a networked computer system can send a query 122 to a directory 110, such as a master card directory. .

  The directory 110 then communicates with the issuer 108 to verify (124) the cardholder's participation (registration). This verification 124 can be performed by issuer access control server 112, which is preferably part of issuer system 108. Assuming that the cardholder is verified (approved) to use an authentication service such as that described in accordance with the present invention, the directory 110 registers the merchant 104 for the cardholder's authentication service. A registration verification message 126 to confirm can be sent out. After the merchant 104 receives a registration verification message from the directory 110, the merchant 104 notifies the consumer 102 that authentication will be performed and that the transaction will end with receipt of an approval. Can do. Thereafter, merchant 104 sends a request for authentication 130 via issuer authentication service 114.

  Authentication can be done at this time by one of several methods depending on the specific embodiment of the invention. For example, in the context of a telephone order verification system, the merchant 104 can also prompt the cardholder to enter data on the telephone line (or the internet in the case of online transactions), which data is used for authentication Can be used for However, several other procedures for authentication can also be performed within the scope of the present invention.

  For example, in one exemplary implementation, an extension to the core protocol of the transaction (eg, a 3D secure protocol, which will be described in detail later, hereinafter referred to as a related application referred to) can be realized. Also, the data required for authentication can be carried in message extension tags (VEReq, VERes, PAReq messages, etc.) exchanged during non-standard 3D secure transactions.

  In another exemplary embodiment according to the system and method of the present invention, the core protocol can be implemented without modification. In one such embodiment, all data and tags according to the 3D secure protocol can be used as is. However, to perform the authentication step, the merchant can issue a query to a second directory that independently determines whether the issuer participates in authentication. If the issuer participates in authentication, the merchant may also instruct the cardholder to call an interactive voice response (“IVR”) system to complete the authentication.

  In yet another exemplary embodiment, as discussed above, according to the system and method of the present invention, the core protocol allows the merchant to enter data into the authentication system on behalf of the cardholder. With minor modifications that allow for the most, but most can be left alone. A phone that may not want to end the call with the merchant (to provide the issuer with the required authentication data) until the transaction is over, or the cardholder may not have access to the computer Such a system is useful for transactions. In one embodiment of such, modifications can be made to the 3D secure protocol, for example to modify the access control server URL field in the VERes message to enter authentication data on behalf of the cardholder. Encourage merchants to In particular, the cardholder is preferably a consumer 102, or the consumer may be a purchaser authorized by the cardholder to pay for a transaction with a merchant. The latter may be the case, for example, when the cardholder's agent is instructed to purchase goods or services on behalf of the cardholder. As used herein, the term “owner” includes any of these individuals.

Regardless of the procedure used to obtain the necessary information from the cardholder, the information required by the cardholder for authentication purposes can include information on a file held by the issuer 108. To verify the identity of the person who made the call (caller) / buyer (that is, the person), that is, the person who made the call (caller) / buyer is the cardholder be able to. One such example is using an EMV chip card and card reader to provide the cardholder's secure code to a merchant, issuer or automated call center.
Other procedures for verification as known to those skilled in the art include dynamic security questions, telephone calls / dual tone multi-frequency (DTMF) user input by the purchaser, voice biometric analysis, or telephone calls / Including some other method of confirming the purchaser card holder.

  Continuing with the description of the exemplary embodiment of the system according to the present invention, if the issuer access control server 112 determines that the transaction has been properly verified (approved), the access control server 112 will verify that the transaction has been verified. It is preferable to send an authentication response message 132 to the merchant 104 through the issuer authentication service 114. Thereafter, as known in the art, the transaction can be completed, for example, through communication 134 between merchant 104 and acquirer 106 and communication 136 between acquirer 106 and issuer 108. Exemplary embodiments of the present invention can be implemented with a security protocol such as a 3D (ie, three-dimensional) secure authentication protocol. 3D secure authentication protocols are known in the art and are commonly adopted and implemented throughout the payment industry. The present invention can be implemented in conjunction with a '3D secure master card' implementation, which is described in US Provisional Patent Application No. 60 / 477,187, “Algorithms Used in Secure Payment Applications” (June 10, 2003). Application), the entirety of which and related applications are incorporated herein by reference. It should be noted, however, that the scope of the present invention is not limited to this implementation of the system and method for secure transactions using the 3D secure protocol. Also, the concepts described herein can be widely applied in a number of ways, as will be apparent to those skilled in the art.

  Further details regarding the completion of a transaction using a master card implementation of the 3D secure protocol can be found in the following application. All of which are incorporated herein by reference in their entirety. US patent application Ser. No. 09 / 963,274, “Universal and Interoperable System and Method Utilizing Universal Cardholder Authentication Field (UCAF) for Authentication Data Collection and Verification” (filed September 26, 2001), US Provisional Patent Application 60 / 280,776, “Systems and Methods for Secure Payment Applications (SPA) and Universal Cardholder Authentication” (filed April 2, 2001), US Provisional Patent Application 60 / 295,630 , "System and Method for Secure Payment Application Using Universal Cardholder Authentication Field" (filed June 4, 2001), US Provisional Patent Application No. 60 / 307,575, "Communication Network Using Secure Payment Application System and Method for Performing Transactions Beyond ”(filed July 24, 2001), US patent application Ser. No. 09 / 886,486,“ pseudo or proxy ” -System and method for performing transactions across a communication network using a secure payment application without using an account number "(filed June 22, 2001), US patent application 09 / 886,485," Communications System and Method for Performing Secure Payments Across Networks "(filed June 22, 2001), US Patent Application No. 10 / 096,271," System and Method for Performing Secure Payments "( Such as US Provisional Patent Application No. 60 / 352,968, “MasterCard UCAF ™ and SPA ™ Clientless Solution” (filed January 30, 2002).

  2A and 2B illustrate an exemplary method for operating the payment transaction system shown in FIG. 1 using authentication with a 3D secure authentication protocol. First, the consumer selects an item and / or service that is the subject of the transaction (step 202). Next, the merchant (retail store) computer system issues a query to the master card directory (query) to verify that the cardholder is participating in the voice authentication system (step 204). Preferably, this query can be in the form of a 3D Secure Verification Registration Registration Request (VEReq) message, the details of which are described in the above application specification incorporated herein. In particular, merchant systems are software plug-ins that are compatible with, for example, issuers (via issuer-side plug-ins such as issuer virtual pop-up services) and directory systems to provide efficient interoperability. Can be configured together. This plug-in can be used to convert data from merchants into a format suitable for use by publishers and vice versa. Such plug-ins are convenient for upgrading current merchant systems for use with the systems and methods according to the present invention, but such upgrades are not necessary within the scope of the present invention. Furthermore, the plug-in can be composed of software, hardware, or a combination thereof.

  The master card directory then communicates with the issuer access control server to verify cardholder participation (step 206). Assuming the cardholder's participation has been verified (successfully), then the master card directory sends a registration verification message to the merchant computer system (step 208) indicating that authentication will be performed. (Step 214). The registration verification message is preferably in the form of a verification registration response (VERes) message that conforms to the 3D secure master card implementation as referenced above. Also, as described above, this message can be received by a merchant system software plug-in, which provides interoperability to the merchant's current system.

  After the merchant receives VERes from the master card directory that confirms the cardholder's participation, the merchant can send an authentication request message (step 210) to the issuer system. This request message may preferably be a 3D secure payer authorization (approval) request message (PAReq) and may be received by the issuer access control server. The PAReq message preferably includes a plurality of data fields, eg, data fields that contain information that allows the issuer to perform authorization (approval), and includes an “expiration request” field. This can also be used to allow the merchant plug-in to time out a transaction if no payer authentication response (PARes) is received from the issuer access control server by the merchant plug-in. Point to date.

  After the merchant access control server receives the PAReq message, authentication can begin. In one exemplary embodiment of the present invention, the issuer authentication service prepares an electronic form for the cardholder (step 212) and sends the form for entry of the cardholder data to the merchant. It can be a “virtual pop-up” service. The merchant then calls the appropriate person / buyer data over the phone, enters the information into the form, and the cardholder (step 214) (this exemplary embodiment is the merchant representative, That is, although referred to as the “MOBO” approach, the details of which are described in more detail below with respect to FIG. 3A), data can be sent to the issuer for authentication. Based on the completion of the authentication procedure (detailed below with reference to FIGS. 3A and 3B below), an authentication response is generated by the issuer access control server and sent to the merchant (step 222) for authentication procedure The results are shown. The authentication response can be, for example, in the form of a payer authentication response (PARes) according to the 3D secure protocol.

  If authentication fails or times out, the transaction can still begin depending on the configuration of the particular implementation of the system according to the invention and the reason for the failure. However, if authentication fails for reasons such as obvious authentication problems or indications of potential fraudulent transactions, the authentication can be rejected (step 218) and the transaction can be cancelled. In contrast, if authentication is successfully completed (step 220), the access control server can send an authentication response to the merchant (step 222). The transaction can also be terminated in a conventional manner according to the 3D secure protocol (step 224).

A typical procedure for performing authentication (step 214 of FIG. 2A) is illustrated in FIG. 3A. In this exemplary embodiment, a merchant agent ("MOBO") approach is implemented, i.e., the merchant requests authentication information from the cardholder (e.g., making a call during a telephone transaction), and the electronic form Alternatively, authentication information is input to the system by other means. Upon purchase of the cardholder, the merchant can communicate via a merchant plug-in with an issuer access control server to determine whether the cardholder is registered with the authentication service (step 302). . In response, the issuer can send a VERes message containing the query string parameter “IVRNO” in the ACS (Access Control Server) URL element (step 304). For example, the following sample URL may be included in the VERes message:
https: //securecode,issuer.com/authenticate.asp? IVRNO = MOBO

  This additional question (querier) string parameter added to the ACS URL is detected by the merchant plug-in, the cardholder is registered for phone authentication, and the merchant authenticates (securely) Indicate to the merchant that MOBO authentication must be performed using the means specified for the Code).

  The merchant plug-in can then generate a PAReq message and add name / value pairs in the merchant data ("## authentication type = MOBO ##"). The merchant can then send merchant data to the issuer access control server (step 306). This name / value pair indicates to the access control server that the PAReq sent by the merchant is for phone authentication as opposed to electronic commerce / online transaction authentication. The merchant can then collect the necessary authentication information from the cardholder according to the instructions provided on the authentication web page provided by the issuer access control server (step 308). The merchant can then enter authentication credentials into the access control server electronic form (step 310). The electronic form (or “virtual pop-up”) is preferably provided by an issuer authentication service. The electronic form can be provided over the Internet using a web interface, or it can be provided using any software application that facilitates secure data transfer between the merchant and the issuer.

  Next, preferably, the issuer access control server generates PARes (step 312), and sends PARes to the URL defined in the TermURL element of PAReq. The merchant plug-in can receive the encrypted PARes, extract the digital signature, and verify that it is valid (step 314). Following the 3D secure protocol, the merchant can then obtain an application authentication value (AAV) from PARes and pass the AAV in the authentication message (step 316). Finally, the merchant can end the transaction according to a 3D secure protocol or other known transaction protocol (step 318).

  Another exemplary procedure for performing authentication (step 214 in FIG. 2A) is shown in FIG. 3B. In this exemplary embodiment, an interactive voice response (“IVR”) approach is implemented, in which the merchant conducts a telephone transaction with the caller / buyer and for authentication purposes. The person who made the call / buyer is transferred to the IVR system that prompts the purchaser to enter the authentication information in and the necessary authentication steps are performed.

Upon purchase of the cardholder, the merchant can 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 can then send a VERes message containing the query string parameter “IVRNO” in the ACS (Access Control Server) URL element (step 322). For example, the following sample URL may be included in the VERes message:
https: //securecode,issuer.com/authenticate.asp? IVRNO = IVR
This query string parameter added to the ACS URL is detected by the merchant plug-in to indicate to the merchant that the cardholder must be registered for phone authentication and the merchant must perform IVR authentication.

The merchant plug-in may then generate a PAReq message, for example adding a name / value pair in the merchant data element to indicate the parameters for authentication.
"## Authentication type = IVR; Telephone caller ID = 14403528444; Transfer back = Y; Transfer number = 18004681512 ##"

  The merchant can then send PAReq to the issuer access control server (step 324). For example, the above values indicate to the access control server that the PAReq sent by the merchant is for phone authentication as opposed to e-commerce / online authentication and that the authentication procedure is IVR. And preferably information such as caller identification information, instructions on the phone number of the IVR authentication that the customer will be transferred to, and after the IVR authentication is complete, the IVR system calls the merchant A transfer return flag is provided that indicates to the IVR system whether or not to transfer the user back. The merchant can then forward the person who called the caller (caller) to the phone number provided in the query string to initiate IVR authentication (step 326). The caller / buyer can then be forwarded to the issuer IVR for authentication (step 328). Authentication can be done using a number of different procedures within the scope of the present invention, for example, prompting the caller / buyer to confirm purchase information, and authentication such as a cardholder's secure code It may include prompting the caller / buyer to enter / speak information. The issuer access control server can then authenticate the caller / purchaser, generate PARes, and send the PARes to the URL defined in the TermURL element (step 330). If so indicated in the merchant data parameters, the cardholder can also be transferred back to the merchant. The merchant plug-in can then receive the encrypted (encoded) PARes and extract / verify the digital signature (step 332). Following the 3D secure protocol, the merchant can then obtain the AAV from the PARes and pass the AAV in an authentication message (step 334). Finally, the merchant can finish the transaction as normal according to the 3D secure protocol or other known protocols (step 336).

  It will be apparent to those skilled in the art that the methods and systems shown in FIGS. 1-3 can be implemented using a variety of 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 improve the efficiency of the above method.

  4 and 5 show typical computer hardware suitable for carrying out the present invention. Referring to FIG. 4, the computer system includes a processing section 410, a display 420, a keyboard 430, and a communication peripheral 440 such as a modem. The system can further include a printer 460. A computer system is one such as a magnetic medium (ie diskette) such as a computer readable or writable medium for storing data and application software, and / or an optical medium (eg CD-ROM or DVD). The above disk drive 470 is typically included. The system further typically includes an internal computer readable medium 480 such as a hard disk drive. Other input devices such as a digital pointer 490 (eg, a mouse) and a card reader 450 for reading the payment card 400 may also be included. The computer hardware illustrated in FIGS. 4 and 5 can be used to execute the software illustrated in FIGS. 1-3 and / or using these computer hardware, the consumer 102, merchant 104 ( It may also perform the functions of the computer processor utilized by the associated merchant plug-in described above, acquirer 106, issuer system 108, and directory system 110.

  FIG. 5 is a functional block diagram further illustrating the processing section 410. The processing section 410 generally includes a processing unit 510, control logic 520, and a storage device 550. Preferably, the processing section 410 can further include a timer 530 and an input / output port 540. The processing section 410 may further include a coprocessor 560, depending on the microprocessor used in the processing unit. The control logic 520, along with the processing unit 510, provides the control necessary to handle the communication between the storage device 530 and the input / output port 540. The timer 550 provides a timing reference signal to the arithmetic processing unit 510 and the control logic 520. Coprocessor 560 provides enhancements to perform complex real-time calculations such as those required by cryptographic algorithms.

  The storage device 530 can include different types of memory, such as volatile and non-volatile memory and read-only programmable memory. For example, as shown in FIG. 5, storage device 530 may include read only memory (ROM) 531, EEPROM 532, and random access storage device (RAM) 533. Different computer processors, memory configurations, data structures and the like can be used to implement the present invention. Also, the invention is not limited to a particular platform. For example, although processing section 410 is shown in FIGS. 4 and 5 as part of a computer system, the computer system, processing section 410, and / or some of its components can be incorporated into a PDA or mobile phone. .

  Although the invention has been described with reference to specific exemplary embodiments, it will be appreciated by those skilled in the art that the disclosed embodiments may be practiced in various ways without departing from the scope and spirit of the invention as set forth in the appended claims. It should be understood that changes, substitutions and substitutions can be made.

FIG. 6 is a block diagram illustrating an additional exemplary system for executing a payment transaction according to the present invention. 6 is a flowchart illustrating an exemplary procedure for executing a payment transaction according to the present invention. 6 is a flowchart illustrating an exemplary procedure for executing a payment transaction according to the present invention. 6 is a flowchart illustrating an exemplary procedure for executing a payment transaction according to the present invention. 2 is a flowchart illustrating an exemplary system for executing a settlement transaction according to the present invention. 1 is a block diagram illustrating an exemplary system for executing a settlement transaction according to the present invention. FIG. 1 is a block diagram illustrating an exemplary system for executing a settlement transaction according to the present invention. FIG.

Claims (26)

A method of processing payments from a payment account and performing a secure transaction between a merchant and a customer,
Providing a database including first authentication information associated with an owner of the payment account;
The payment account information associated with the payment account defining the payment account information used to perform the transaction;
Sending an authentication request including the settlement account information to an access control server;
Receiving information including an authentication order by the merchant;
Receiving second authentication information from the customer;
Comparing the first authentication information and the second authentication information to determine whether the transaction is approved by the owner of the payment account;
Including methods. The method of claim 1, wherein
Sending an authentication response in response to the authentication request;
The method of further comprising. The method of claim 2, wherein
Responsive to the authentication response, processing a payment from the payment account to complete the transaction;
The method of further comprising. The method of claim 1, wherein
The payment account information is provided via telephone;
A method characterized by that. The method of claim 1, wherein
The payment account information is provided via a computer network;
A method characterized by that. The method of claim 2, wherein
The authentication request and the authentication response are formatted by a 3D secure authentication protocol;
A method characterized by that. The method of claim 1, wherein
The authentication instructions include information related to IVR authentication;
A method characterized by that. The method of claim 1, wherein
The authentication instruction includes information related to MOBO authentication;
A method characterized by that. A method in which payment is processed from an owner's payment account and a secure transaction is performed using authentication,
Receiving payment account information associated with the payment account, such as used for conducting the transaction;
Sending an authentication request including the payment account information to an access control server, wherein the authentication request causes the server to automatically activate transmission of data used to display an electronic form. Steps,
Receiving the authentication information from the owner by the electronic form;
Authenticating the owner for the purpose of approving the transaction;
Approving the transaction;
Including methods. The method of claim 9, wherein
Receiving an authentication response in response to the authentication request;
The method of further comprising. The method of claim 10, wherein
Responsive to the authentication response, processing a payment from the payment account to complete the transaction;
The method of further comprising. The method of claim 9, wherein
The payment account information is provided by telephone;
A method characterized by that. The method of claim 9, wherein
The payment account information is provided via a computer network;
A method characterized by that. The method of claim 10, wherein
The authentication request and the authentication response are formatted by a 3D secure authentication protocol;
A method characterized by that. The method of claim 9, wherein
The authentication instructions include information related to IVR authentication;
A method characterized by that. The method of claim 9, wherein
The authentication instruction includes information related to MOBO authentication;
A method characterized by that. A method in which payment is processed from a payment account and a secure transaction is performed using authentication,
Providing a database including 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, the payment account information used to perform the transaction;
Receiving an authentication request including at least the payment account information in connection with performing the transaction;
Automatically activating electronic form display;
Receiving a second set of authentication information from the owner of the payment account;
Inputting the second set of authentication information into the electronic form;
Comparing the first set of authentication information with the second set of authentication information to determine whether the transaction is approved by the owner of the payment account;
Including methods. The method of claim 17, wherein
Providing an authentication response in response to the authentication request;
The method of further comprising. The method of claim 18, wherein
Responsive to the authentication response, processing a payment from the payment account to complete the transaction;
The method of further comprising. The method of claim 17, wherein
The payment account information is provided by phone;
A method characterized by that. The method of claim 17, wherein
The payment account information is provided via a computer network;
A method characterized by that. The method of claim 18, wherein
The authentication request and the authentication response are formatted by a 3D secure authentication protocol;
A method characterized by that. A system for safely performing transactions,
A server computer subsystem including information related to at least one payment account, including at least a first set of authentication information related to the account owner of the payment account;
An automated voice response subsystem;
An authentication subsystem, and
The automated voice response subsystem connects a phone to the account holder to obtain a second set of authentication information;
Further, the authentication subsystem compares the first set of authentication information with the second set of authentication information to determine whether the transaction is approved by the account owner;
A system characterized by that. 24. The system of claim 23.
The transaction is performed according to a 3D secure protocol;
A system characterized by that. A system for conducting secure transactions between merchants and account holders,
A server computer subsystem including information related to at least one payment account, including at least a first set of authentication information related to the account owner of the payment account;
A virtual electronic form subsystem,
Providing the electronic form to the merchant such that the virtual electronic form subsystem receives a second set of authentication information from the merchant;
The server computer subsystem compares the first set of authentication information with the second set of authentication information to determine whether the transaction is approved by the account owner;
A system characterized by that. The system of claim 25, wherein
The transaction is performed according to a 3D secure protocol;
A system characterized by that.

Images