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

Abstract

A secure electronic payment system and method for conducting a secure transaction using authentication is provided. A merchant's computer transmits an authorization request to an access control server. The access control obtains authentication to confirm the identity of the purchaser, via e.g., an electronic form or interactive voice response system. The access control server then transmits a response to the merchant's computer. If the purchaser is authorized to access the account, payment is processed by the merchant and the transaction is completed.

Description

SYSTEM AND METHOD FOR SAFE TRANSACTIONS BY TELEPHONE AND COMPUTER FIELD AND BACKGROUND OF THE INVENTION Credit cards and other forms of payment were originally designed to be used during in-person transactions, during which the card can provide both a means of payment and a means of authenticating a cardholder. In addition to having the actual possession of the card, the buyer must also provide a signature which can be compared to the signature on the back of the card. The main disadvantage in transactions or telephone orders is that the vast majority are not authenticated in the manner described above. Accordingly, the number of fraudulent transactions and chargebacks associated with credit / payment cards increases as a consequence. Additionally, customers may be concerned about the potential dangers of providing personal payment information by telephone to an unidentifiable and possibly unknown individual. Online purchases, or e-commerce, suffer from many of the same problems. Online purchases offer unprecedented ease and convenience to customers, while allowing merchants to reduce costs and obtain new customers. However, many customers have been reluctant to take advantage of these benefits due to fear of theft of sensitive information such as credit card numbers. Efforts have been made to increase the security of such information transmitted through the internet. For example, in the technique of security level in connections (SSL), messages sent between the client and the merchant are coded, making it more difficult for other people to intercept and use the information. However, this method does not provide the merchant with any verification of the customer's identity. Accordingly, if other people obtained a credit card number by other fraudulent means such as theft of the physical credit card, the SSL method could not prevent other people from fraudulently using the stolen information.

Secure Electronic Transaction (SET ™) techniques attempt to solve the above problems using digital certificates to authenticate the customer / account holder, the merchant, and the credit card issuer. Each certificate is issued by a trusted certifier. Although SET ™ is currently the surest way to handle payments over the Internet, it requires that digital certificates and cryptographic software be installed and operated on the account holder's computer. In fact, most e-commerce systems, secure, of prior art, require customers to install a computer program on their computers. Even many customers are reluctant to install such software and, in any case, a specialized application of the account holder can not be compatible with a wide variety of access devices for account holders - for example, personal computers, digital assistants personal, and mobile communication devices such as mobile phones. As a result, it has been difficult for some secure e-commerce systems to gain general acceptance among customers. Accordingly, there is a need in the art for a system and method for confirming a customer's identity in conjunction with a telephone or online comparison in order to facilitate a safer transaction. BRIEF DESCRIPTION OF THE INVENTION Therefore, an objective of the present invention is to provide a method for conducting secure transactions, telephone and online. This and other objects are achieved by a system and method for performing a secure transaction, which preferably includes the steps of providing a database that includes a first authentication information associated with a payment account holder., provide information of the payment account associated with the payment account, the information of the payment account will be used to carry out the transaction, transmit an authentication request that includes the information of the payment account to an access control server , receiving by means of merchant information that includes the authentication instructions, receiving the second customer authentication information; and comparing the first and second authentication information to determine if the transaction is authorized by the account holder of the payment. The objects of the invention are furthermore achieved by a system and method for performing a secure transaction, which preferably includes the steps of receiving information from the payment account associated with the payment account, the information of the payment account will be used to perform the transaction, transmit an authentication request that includes the information of the payment account to an access control server, the authentication request that automatically activates by the server the transmission of data used to deploy an electronic form, receive through of the electronic form, the authentication information of the holder, authenticating the holder for the purpose of authorizing the transaction, and authorizing said transaction. The objects of the invention are still further achieved by a method for performing a secure transaction, which preferably includes the steps of providing a database that includes at least a first set of authentication information associated with a holder of said payment account. , receive information from the payment account associated with the payment account, the information from the payment account will be used to perform said transaction, receive an authentication request that includes at least the information of the payment account in connection with the realization of the transaction, automatically activate the deployment of an electronic form, receive a second set of authentication information from the holder of the payment account, enter the second set of authentication information in the electronic form; and comparing the first set of authentication information with the second set of authentication information to determine whether the transaction is authorized by said holder of the payment account. The objects of the invention are furthermore achieved by a system for performing a secure transaction, which preferably includes a file server subsystem, the file server subsystem includes information in relation to at least one payment account that includes at least one first set of authentication information in relation to an account holder of the payment account, an automated voice response subsystem, and an authentication subsystem, wherein the automated voice response subsystem connects a call to the owner of the account for obtaining a second set of authentication information, and wherein further said authentication subsystem compares the first set of authentication information with the second set of authentication information to determine whether the transaction is authorized by the account holder. The objects of the invention are furthermore achieved by a system for performing a secure transaction, which preferably includes a file server subsystem, the file server subsystem includes information in relation to at least one payment account that includes at least one first set of authentication information in relation to an account holder of the payment account, and a subsystem in electronic, virtual form, where the subsystem in electronic form, virtual, provides an electronic form to the merchant, the electronic form receives a second set of merchant authentication information, and wherein in addition the file server subsystem compares the first set of authentication information with the second set of authentication information to determine whether the transaction is authorized by the account holder. BRIEF DESCRIPTION OF THE DRAWINGS The objects, aspects, and additional advantages of the present invention will be apparent from the following detailed description taken in conjunction with the accompanying figures showing illustrative embodiments of the invention, in which: Fig. 1 is a block diagram illustrating an exemplary system for performing a payment transaction in accordance with the present invention; Fig. 2A is a flow diagram illustrating an exemplary method for performing a payment transaction in accordance with the present invention; Fig. 2B is a flow diagram illustrating an exemplary procedure for performing a payment transaction in accordance with the present invention; Fig. 3A is a flow diagram illustrating an exemplary method for performing a payment transaction in accordance with the present invention; Fig. 3B is a flow diagram illustrating an exemplary method for performing a payment transaction in accordance with the present invention; Fig. 4 is a schematic diagram illustrating an exemplary system for performing a payment transaction in accordance with the present invention; and Fig. 5 is a schematic diagram illustrating an exemplary system for performing a payment transaction in accordance with the present invention. In all the figures, unless stated otherwise, the same numbers and reference characters are used to denote similar aspects, elements, components or portions of the illustrated modalities. DETAILED DESCRIPTION OF THE INVENTION Fig. 1 illustrates an exemplary method for performing secure payment transactions in accordance with the present invention. The system includes a customer 102, a merchant 104 that sells goods and / or services, an acquirer 106 - typically the merchant's acquisition bank - and an issuer 108 - typically a financial institution such as a bank - that has issued a payment account that is used to make a transaction with the trader. The system may also include a directory / database 110 which stores information regarding the account holder's account. The database 110 is operated by a payment organization such as the payment organization MasterCard® and preferably is a server computer connected to a network such as the Internet. The system preferably further includes, as part of the sender system 108, an issuer access control server 112 which is linked to a virtual authentication service 114 of the sender, in accordance with an exemplary embodiment of the present invention. The client 102 can perform the transaction 120 with the merchant 104 via telephone. The system and method of the present invention can be implemented independently of the means by which the transaction between the user and the merchant is made, and in accordance with this the present invention will not be limited to telephone transactions. The payment account used to pay for the goods or services, provided by the merchant 104 is typically a credit card account, a debit card account, and / or any other type of payment card account. The account can, but not necessarily be, associated with a physical card. For example, the payment account can be associated with a virtual card which can be stored electronically in a computing device used by the client 102. The customer can, but not necessarily be, the account holder, and when it is used in the present the term "holder" includes one or more individuals associated with and authorized to use the payment or payment card account. In an exemplary embodiment of a method in accordance with the present invention, transaction 120 is performed between a client 102 and a merchant 104, using a payment card such as a MasterCard credit card. The client 102 selects the goods / services to be purchased, and places an order with the merchant 104, thereby providing the merchant 104 with the information of the payment account, including the information of the MasterCard credit card 'such as a credit card number. account, expiration date, and name of the account holder. The merchant 104, using a co-automated system, connects to a network, which can transmit a query 122 to a directory 110 such as a MasterCard directory to determine the participation of the account holder in the authentication services. The directory 110 then preferably communicates 124 with the sender 108 to verify the participation of the account holder. This check 124 can be performed with an issuer access control server 112, which preferably is part of a sender 108 system. Assuming that the account holder is verified using authentication services such as those described in accordance with the present invention, the directory 110 may transmit to the merchant 104 a registration or registration verification message 126 that verifies the registration of the account holder in the authentication services. After the merchant 104 receives the registration verification message from the directory 110, the merchant 104 can inform the client 102 that the authentication will be performed, and that the transaction will be completed upon receipt of the authorization. The merchant 104 preferably then transmits an authentication request 130 to the sender's access control server 112 through the sender authentication service 114. The authentication can now be performed by one of several methods depending on the specific implementation of the present invention. For example, in the context of a telephone order authentication system, the merchant 104 can indicate to the account holder by telephone line (or via the internet, in the case of an online transaction), what data can be used to perform authentication However, other methods for authentication may also be implemented within the scope of the present invention. For example, in an exemplary mode, extensions to the fundamental transaction protocol can be implemented (for example, the 3-D Secure protocol, described in greater detail hereinafter and in related applications mentioned below), and the data needed to Authentication can be carried within the extension "tags" of exchanged messages (such as VEReq, VERes, and PAReq messages) during the course of a 3-D Secure transaction, standard in some way. In another exemplary embodiment in accordance with a system and method of the present invention, the fundamental protocol can be implemented without modification. In one modality, all data and labels according to the 3-D Secure protocol can remain the same. However, in order to perform the authentication steps, a merchant may request a second directory to independently determine whether a sender participates in the authentication. If the issuer participates in the authentication, the merchant can instruct the account holder to call an Interactive Voice Response System ("IVR") in order to complete the authentication. In yet another exemplary embodiment in accordance with a system and method of the present invention, as described above, the fundamental protocol may remain for the most part the same, with minor modifications which could allow the merchant, on behalf of the account holder , enter the data in the authentication system. Such a system may be particularly beneficial for telephone transactions where the account holder may not have access to a computer and may not wish to terminate the telephone call with the merchant (to provide the necessary authentication data to the issuer) until it has been completed. the transaction. In such modality, modifications to the 3-D Secure protocol can be made in such a way that the URL field of the Access Control Server in the VERes message can be modified to request a merchant to enter the authentication data on behalf of the owner of the account. In particular, the account holder can preferably be the customer 102 or, alternatively, the customer can be a buyer who is authorized by the account holder to pay the transaction with the merchant. The latter case may apply when, for example, an agent of the account holder is sent to buy goods or services on behalf of the account holder. When used herein, the term "owner" includes any of these individuals. Regardless of the procedure used to obtain the required information from the account holder, the information requested from the account holder for authentication purposes, it can include any information in the file with the sender 108 and which can be used to verify the identity of the person who loves / buyer, that is, that of the person who loves / buyer is the account holder. Such an example could be used on an EMV Smart Card and the card reader to provide the merchant, issuer, or automated call center with the SecureCode ™ of the Account Holder. Other verification procedures may be known to those skilled in the art, may include the use of security issues, dynamics, user input to a Multi-Frequency Dual-Tone Telephone ("DTMF") by the person whom 11 loves / buyer, biometric voice analysis, or any other method to confirm that the person who loves / buyer is the owner of the account. Continuing with the description of the exemplary embodiment of a system in accordance with the present invention, if the sender access control server 112 determines that the transaction has been properly authenticated, the access control server 112 preferably transmits a message 132. of authentication response through the issuer authentication service 114 to the merchant 104, indicating that the transaction has been authenticated. Therefore, the transaction can be completed in a manner that is known in the art, for example, through communications 134 between the merchant 104 and an acquirer 106 and communications 136 between the acquirer 106 and the sender 108. A Exemplary embodiment of the present invention can be implemented in conjunction with security protocols such as the 3-D (or three-domain) Secure authentication protocol. The 3-D Secure authentication protocol is known in the art and has been adopted and implemented generally through the payment industry. The present invention can be implemented in conjunction with the MasterCard implementation of the 3-D Secure as described in US Provisional Patent Application No. 60 / 477,187, entitled "Algorithm for use in a Secure Payment Application", filed on 10 June 2003, which is incorporated herein by reference in its entirety, and related applications, however, it is noted that the scope of the present invention should not be limited to this implementation of a system and method for secure transactions using the 3-D Secure protocol; The concepts described herein can be broadly applied in numerous ways that could be apparent to one skilled in the related art. Additional details regarding the termination of the transaction can be found using the MasterCard implementation "of the 3-D Secure protocol, in the following applications, all of which are also incorporated herein by reference in their entirety: US Patent Application No. 09 / 963,274, entitled "A Universal and Interoperable System and Method Utilizing a Universal Cardholder Authentication Field (UCAF) for Authentication Data Collection and Validation", filed on September 26, 2001, US Provisional Patent Application No. 60 / 280,776, entitled "System and Method for Secure Payment Application (SPA) and Universal Cardholder Authentication", filed on April 2, 2001; US Provisional Patent Application No. 60 / 295,630, entitled "Method and Process for a Secure Payment Application Using a Universal Cardholder Authentication Field ", filed on June 4, 2001, the Provisi Patent Application United States No. 60 / 307,575, entitled "Method and System for Conducting Transactions Over a Communication Network Using a Secure Payment Application", filed on July 24, 2001; US Patent Application No. 09 / 886,486, entitled "Method and System for Conducting Secure Payments Over a Computer Network Without a Pseudo or Proxy Account Number", filed on June 22, 2001; US Patent Application No. 09 / 886,485, entitled "Method and System for Conducting Secure Payments Over a Computer Network", filed June 22, 2001; U.S. Patent Application No. 10 / 096,271 entitled "System and Method for Conducting Secure Payment Transactions", filed on March 11, 2002; and U.S. Provisional Patent Application No. 60 / 352,968, entitled "MasterCard UCAF TM and SPA TM Clientless Solution", filed January 30, 2002. FIGS. 2A and 2B illustrate an exemplary method for operating the payment transaction system, illustrated in Fig. 1, using an authentication, in conjunction with the 3-D Secure authentication protocol. First, a customer selects goods and / or services which are the purpose of the transaction (Step 202). The computerized merchant system then requests the MasterCard directory to "verify participation in the voice authentication system (Step 204)." This search may preferably be in the form of a 3-D Secure Registration Verification Request message. (VEReq), as described in detail in the references incorporated herein above In particular, the merchant system can be configured with an added computer program card to facilitate efficient compatibility and interoperability with, for example, the sender (e.g. , through the aggregate program card on the issuer side such as a virtual drop-down service) and directory systems.This added program card can be used to move the data from the merchant system to a format suitable for use by the system of the issuer, and vice versa. Such an aggregate program card would be useful to facilitate the updating in an updated merchant system for use with a system and method in accordance with the present invention, although such updating is not necessary within the scope of the present invention. Additionally, the extension component may be composed of computer programs, computer systems, or a combination thereof. Next, the MasterCard directory "communicates with an Issuer Access Control Server to verify the participation of the account holder (Step 206) Assuming that the account holder's participation is verified., the MasterCard Directory "then transmits a registration verification message to the computerized merchant system (Step 208), indicating that authentication will be performed (Step 214) .The registration verification message may preferably be in the form of a message. of Registry Verification Response (VERES) in accordance with the implementation of 3-D Secure MasterCard * as mentioned above.Also as described above, this message may be received by a computer program card added in the merchant's system , whose extension component provides interoperability with the current merchant system.After the merchant receives the VERes from the MasterCard directory, "which validated the participation of the account holder, the merchant can transmit an authentication request message (Step 210) to the issuer system. The request message may preferably be a 3-D Secure Payer Authorization Request (PAReq) message, and may be received by the Issuer Access Control Server. The message PAReq preferably includes a plurality of data fields, for example, which include information which will be provided to the sender for authentication, and may also contain a "Request Expiration" field, which may be used to indicate the date and time when the merchant extension component will allow the transaction to expire if the Payer Authentication Response (PAR) of the Issuer Access Control Server is not received by the merchant's extension component. After the Issuer Access Control Server receives the PAReq message, authentication can begin. In an exemplary embodiment of the present invention, the issuer authentication service may be a "Virtual Drop-down" Service which prepares an electronic form for the Account Holder (Step 212) and transmits the form to the Merchant for the receipt of the Account Holder data. The Merchant can then request the relevant data of the person who loves / buyer by phone and enter the information on the form and transmit the data to the issuer for authentication of the Account Holder (Step 214) (this exemplary mode can be called In Name of the Merchant, or "MOBO" method, described more fully hereinafter in relation to Fig. 3A). Upon completion of the authentication procedure, described more fully in conjunction with Figs. 3A and 3B subsequently, an authentication response is generated by the Issuer Access Control Server and transmitted to the merchant (Step 222), which indicates the result of the authentication procedure. The authentication response may be in the form of, for example, a Payer Authentication Response (PAR) in accordance with the 3-D Secure protocol. If the authentication fails or expires, the transaction can still be started depending on the reason for the failure and configuration of the particular mode of the system in accordance with the present invention. However, if the authentication fails due to an apparent authorization problem, which signals a fraudulent, potential transaction, the authentication can be declined (Step 218) and the transaction is canceled. On the contrary, if the authentication is successfully completed (Step 220), then the Access Control Server may transmit an authentication response to the Merchant (Step 222) and the transaction may be completed in a conventional manner according to protocol 3- D Secure (Step 224). An exemplary procedure for performing authentication (Step 214 of Fig. 2A) is illustrated in Fig. 3A. In this exemplary mode, a method is implemented In the Name of the Merchant ("MOBO"), that is, the Merchant requests the authentication information from an Account Holder (for example, by telephone during a telephone transaction) and enters the authentication information into the system through an electronic or other means. At the time of purchase of an Account Holder, the Merchant may communicate through an extension component of the Merchant with the Issuer's Access Control Server to determine if the Account Holder is registered in the authentication services ( Step 302). In response, the Issuer may transmit a VERes message which includes a query string parameter or "IVRNO" search characters within the URL element of the ACS (Access Control Server (Step 304).) For example, the following URL sample can be included in the VERes message: https: // securecode. issuer. com / authenticate. asp? IVRNO = MOBO This search string string character "IVRNO" included at the end of the ACS URL element is detected by the extension component of the Merchant and indicates to a Merchant that the Account Holder is registered for telephone authentication and that the Merchant must perform MOBO authentication using the prescribed means of authentication (eg SecureCode ™).

Merchant can generate a PAReq message and include a name / value pair within the merchant's data at the last (such as "## authentication-type = MOBO ##"). The Merchant may then transmit the merchant's data to the Issuer Access Control Server (Step 306). This name / value pair indicates to the Access Control Server that the PAReq transmitted by the Merchant is for telephone authentication in lieu of authentication for e-commerce / online transaction. The Merchant may then follow the instructions provided on the Web page or page of the authentication network provided by the Issuer Access Control Server (Step 308) and collect the necessary authentication information from the Account Owner. The Merchant can then enter the authentication information received in the electronic form of the Access Control Server (Step 310). The electronic form (or "Virtual Deployment") is preferably provided by the Issuer Authentication Service. The electronic form can be provided through the Internet using a Web interface or interconnection with the network, or it can be provided using any computer program application which can facilitate the secure transfer of data between the Merchant and the Issuer. Next, the Issuer Access Control Server preferably generates a PAR (Step 312) and transmits the PAR to the URL defined in the TermURL element of the PAReq. The Merchant's extension component can receive the Coded PAR and extract and validate the digital signature (Step 314): According to the 3-D Secure Protocol, the Merchant can then retrieve the Application Authentication Value (AAV) from the PAR. and pass the AAV in the authorization message (Step 316). Finally, the Merchant can complete the transaction in accordance with the 3-D Secure protocol or another known transaction protocol (Step 319). Another exemplary method for performing authentication (Step 214 of Fig. 2A) is illustrated in Fig. 3B. In this exemplary mode, an Interactive Voice Response ("IVR") method is implemented, that is, where the Merchant makes a transaction by telephone with a person who loves / buys and transfers the caller / buyer for purposes of authentication to an IVR system which asks the buyer for the authentication information and performs the necessary authentication steps. At the time of purchase of an Account Holder, the Merchant may communicate through an extension component of the Merchant with the Access Control Server to determine if the account holder is registered in the authentication services (Step 320). ). Next, the Issuer may transmit a VER message which includes a search string parameter "IVRNO" within the URL element of the ACS (Access Control Server) (Step 322). For example, the following sample URL can be included in the VERes message: https: // securecode. issuer. com / authenticate. asp? IVRNO = IVR This additional search string character, included at the end of the URL ACS is detected by the Merchant's extension component and tells the Merchant that the Account Holder is registered for telephone authentication and that the Merchant You must perform an IVR authentication.

Next, the Merchant's extension component can generate a PAReq message and include the last, name / value pairs within the merchant's data element to indicate authentication, for example: "## authentication-type = IVR; id = 14403528444; transfer-back = Y; transfer-number = 18004681512 ## "The Merchant can then transmit the PAReq to the Issuer Access Control Server (Step 324). For example, the above value may indicate to the Access Control Server that the PAReq transmitted by the Merchant is for telephone authentication instead of authentication for e-commerce / online, that the authentication procedure is IVR, and preferably also provides information such as caller identification information, instructions regarding the telephone number to which the customer must be transferred for IVR authentication, and a TransferBack mark or flag which indicates to the IVR system whether or not the caller should be transferred back to the Merchant upon completion of the IVR authentication. The Merchant can then transfer the caller to the telephone number provided within the search string to initiate IVR authentication (Step 326). The person who loves / buyer can then be transferred to the issuer's IVR for authentication (Step 328). The authentication can be performed using numerous different procedures within the scope of the present invention, and may include, for example, asking the person who loves / buying to confirm the purchase information and asking the caller / buyer to enter / pronounce the authentication information such as the SecureCode of the Account Holder. Next, the Issuer Access Control Server can authenticate the person who loves / buyer, generates a PAR and transmits the PAR to the URL defined in the TermURL element (Step 330). The Account Holder can be transferred back to the merchant if the TransferBack parameter in the merchant's data so dictates. The Merchant's extension component can then receive the encoded PAR and obtain / validate the digital signature (Step 332). In accordance with the 3-D Secure Protocol, the Merchant can then retrieve the AAV from the PAR and pass the AAV in the authorization message (Step 334). Finally, the Merchant can complete the transaction in a normal manner according to a 3-D Secure protocol or another known protocol (Step 336). It will be appreciated by those skilled in the art that the methods and systems illustrated in Figs. 1-3 can be implemented using several standard computer platforms that operate under the control of an appropriate computer program. In some cases, computer equipment of dedicated computers, such as a peripheral card in a conventional personal computer, may be used to improve the operational efficiency of the above methods. Figs. 4 and 5 illustrate a computer equipment suitable for practicing the present invention. Referring to Figure 4, the computerized system includes a processing section 410, a screen 420, a keyboard 430, and a peripheral communication device 440 such as a modem. The system may also include a printer 460. The computer system typically includes one or more disk drives 470 which can read and write on a computer-readable medium such as a magnetic medium (i.e., diskettes) and / or optical media ( for example, CD-ROMS or DVDs), to store data and computer applications. The system typically also includes an internal, computer readable medium 480, such as a hard disk drive. Other input devices may also be included, such as a digital pointer 490 (for example, a mouse) and a card reader 450 for reading a payment card 400. Computer equipment can be used as illustrated in Figs. 4 and 5 to execute the computer program illustrated in Figs. 1-3, and / or can be used to perform the functions of a computer processor used by the client 102, merchant 104 and the merchant extension component, described herein above), acquirer 106, the sender system 108, and the directory system 110. Figure 5 is a functional block diagram, which further illustrates the processing section 410. The processing section 410 generally includes a processing unit 510, a control logic 520 and a memory unit 550. Preferably, the processing section 410 may also include a timer 530 and input / output ports 540. The processing section 410 may also include a co-processor 560, depending on the microprocessor used in the processing unit. The control logic 520 provides, in conjunction with the unit 5210, the control necessary to handle communications between the memory unit 550 and the input / output ports 540. The timer 530 provides a timing reference signal for the processing unit 510 and the control logic 520. The co-processor 560 provides an improved ability to perform complex real-time computations, such as those required by the cryptographic algorithms.

The memory unit 550 may include different types of memory, such as volatile and non-volatile memory and programmable and read-only memory. For example, as shown in Fig. 5, the memory unit 550 may include read-only memory (ROM) 552, read-only, programmable, electrically erasable memory (EEPROM) 554, and random access memory 556 (RAM) ). Different computer processors, memory configurations, data structures and the like can be used to practice the present invention, and the invention is not limited to a specific platform. For example, although the processing section 410 is illustrated in Figs. 4 and 5 as part of a computerized system, the processing section 410 and / or its components may be incorporated into a PDA or a mobile telephone. Although the present invention has been described in relation to exemplary, specific embodiments, it should be understood that various changes, substitutions, and alterations can be made apparent to those skilled in the art, to the embodiments described without departing from the spirit and scope of the invention. invention as set forth in the appended claims.

Claims (26)

1. CLAIMS 1.- A method to per a secure transaction between a merchant and a customer, wherein the payment is processed from a payment account, characterized in that it comprises: providing a database comprising a first authentication ination associated with a holder of said payment account; provide ination of the payment account associated with said payment account, said ination of the payment account will be used to per said transaction; transmitting an authentication request that includes said payment account ination to an access control server; receipt by means of ination of the merchant comprising the authentication instructions; receive the second authentication ination from the client; comparing said first and said second authentication ination to determine if said transaction is authorized by said account holder of said payment account.
2. 2. The method of claim 1, characterized in that it further comprises the step of transmitting an authentication response that responds to said authentication request.
3. 3. - The method of claim 2, characterized in that it further comprises the step of processing said payment account to complete the transaction as a function of said authentication response.
4. 4. - The method of claim 1, characterized in that said ination of the payment account is provided via telephone.
5. 5. The method of claim 1, characterized in that said ination of the payment account is provided through a computer network.
6. 6. The method of claim 2, characterized in that said authentication request and said authentication response are atted in accordance with the 3-D Secure authentication protocol.
7. 7. - The method of claim 1, characterized in that said authentication instructions comprise ination in relation to the IVR authentication.
8. 8. The method of claim 1, characterized in that said authentication instructions comprise ination in relation to a MOBO authentication.
9. 9. A method to per a secure transaction using authentication, wherein the payment is processed from a payment account of the owner, characterized in that it comprises: receiving ination from the payment account associated with said payment account, said account ination payment will be used to per said transaction; transmitting an authentication request including said payment account ination to an access control server, said authentication request being automatically activated by said server the transmission of data used to display an electronic; receive through said electronic the authentication ination of said holder; authenticate said holder the purpose of authorizing said transaction; and authorize said transaction.
10. 10. The method of claim 9, characterized in that it further comprises the step of receiving an authentication response in response to said authentication request.
11. 11. - The method of claim 10, characterized in that further the steps of processing the payment of said payment account to complete the transaction as a function of said authentication response.
12. 12. - The method of claim 9, characterized in that said ination of the payment account is provided via telephone.
13. 13. - The method of claim 9, characterized in that said ination of the payment account is provided through a computer network.
14. 14. The method of claim 10, characterized in that said authentication request and said authentication response are atted in accordance with the 3-D Secure authentication protocol.
15. 15. The method of claim 9, characterized in that said authentication instructions comprise ination in relation to the IVR authentication.
16. 16. The method of claim 9, characterized in that said authentication instructions comprise ination in relation to a MOBO authentication.
17. 17. A method pering a secure transaction using authentication, wherein the payment is processed from a payment account, characterized in that it comprises: providing a database comprising at least a first set of authentication ination associated with a holder of said payment account; receive information from the payment account associated with said payment account, said information from the payment account will be used to perform said transaction; receiving an authentication request that includes at least said information from the payment account in connection with the completion of said transaction; automatically activate the deployment in an electronic way; receiving a second set of authentication information from said account holder of said payment account; entering said second set of authentication information in said electronic form; and comparing said first set of authentication information with said second set of authentication information to determine whether said transaction is authorized by said holder of said payment account.
18. 18. The method of claim 17, characterized in that it further comprises the step of providing an authentication response that responds to said authentication request.
19. 19. The method of claim 18, characterized in that it further comprises the steps of processing the payment from said payment account to complete the transaction as a function of said authentication response.
20. 20. The method of claim 17, characterized in that said information of the payment account is provided via telephone.
21. 21. - The method of claim 17, characterized in that said information of the payment account is provided through a computer network.
22. 22. The method of claim 18, characterized in that said authentication request and said authentication response are formatted in accordance with the 3-D Secure authentication protocol.
23. 23. A system for carrying out a secure transaction, characterized in that it comprises: a server computer subsystem, said server computer subsystem comprises information in relation to at least one payment account that includes at least a first set of authentication information in relation to with an account holder of said payment account; an automated voice response subsystem; and an authentication subsystem, wherein said automated voice response subsystem connects a call to said account holder to obtain a second set of authentication information, and wherein said authentication subsystem further compares said first set of authentication information with said second set of authentication information to determine if the transaction is authorized by said account holder.
24. 24. - The method of claim 23, characterized in that the transaction is carried out in accordance with the 3-D Secure protocol.
25. 25. A system for conducting a secure transaction between a merchant and an account holder, characterized in that it comprises: a server computer subsystem, said server computer subsystem comprises information in relation to at least one payment account that includes at least one first set of authentication information in relation to a holder of an account of said payment account; and a subsystem in an electronic, virtual way; wherein said subsystem in electronic, virtual form, provides an electronic form to said merchant, said electronic form receives a second set of authentication information from said merchant, and wherein said file server subsystem also compares said first set of information from said merchant. authentication with said second set of authentication information to determine whether the transaction is authorized by said account holder.
26. 26. The method of claim 25, characterized in that said transaction is carried out in accordance with the 3-D Secure protocol.