WO2005048032A2 - Managing attempts to initiate authentication of electronic commerce card transactions - Google Patents

Managing attempts to initiate authentication of electronic commerce card transactions Download PDF

Info

Publication number
WO2005048032A2
WO2005048032A2 PCT/US2004/035054 US2004035054W WO2005048032A2 WO 2005048032 A2 WO2005048032 A2 WO 2005048032A2 US 2004035054 W US2004035054 W US 2004035054W WO 2005048032 A2 WO2005048032 A2 WO 2005048032A2
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
card
response message
merchant system
electronic commerce
Prior art date
Application number
PCT/US2004/035054
Other languages
French (fr)
Other versions
WO2005048032A3 (en
Inventor
Sue Devine
Original Assignee
Visa Usa, Inc.
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa Usa, Inc., Visa International Service Association filed Critical Visa Usa, Inc.
Priority to CA002545737A priority Critical patent/CA2545737A1/en
Priority to EP04796106A priority patent/EP1723582A4/en
Priority to AU2004290297A priority patent/AU2004290297B2/en
Publication of WO2005048032A2 publication Critical patent/WO2005048032A2/en
Publication of WO2005048032A3 publication Critical patent/WO2005048032A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Definitions

  • Electronic commerce cards are frequently used by consumers to make purchases from merchants over the Internet.
  • Electronic commerce cards include credit cards, debit cards, prepaid purchase cards, travel cards, or any other system that can be used instead of cash to purchase goods or services.
  • electronic commerce card associations and/or issuers have instituted authentication systems to ensure that electronic commerce cards are only used by authorized cardholders.
  • One example of an authentication system enables a cardholder to associate a password or other identifying information with an electronic commerce card. To make a purchase online, the consumer must provide the password associated or other identifying information with the electronic commerce card. This ensures that the person possessing the electronic commerce card is actually authorized to use the electronic commerce card.
  • Typical card processing systems use a decentralized, distributed computing model in which information is exchanged between merchants, electronic commerce card issuers and the card association to authenticate cardholders. Because of the distributed nature of the card processing system, authentication will fail if any portion of the system, such as a merchant system or a card issuer system, does not support its portion of the authentication. With thousands of card issuers and millions of merchants using a typical card processing system, deploying an authentication system among so many different entities is a difficult task. Additionally, merchants are reluctant to include authentication functions if the authentication system is only supported by a small number of card issuers.
  • the card association assigns liability for fraudulent transaction based upon a party's compliance with the authentication system. For example, liability for fraudulent transactions is borne by the card issuer and not the merchant when the merchant complies with the authentication system, even in cases where the card issuer does not support authentication.
  • an embodiment of the card processing system includes the ability to track and record attempts by merchants to initiate authentications, even in circumstances where the card issuer does not support authentication or can not authenticate the card information its receives.
  • an electronic commerce card authentication system includes a directory server adapted to receive a verification request message from a merchant system.
  • the verification request message requests an indication of whether a card account is capable of being authenticated.
  • the directory server is further adapted to determine whether the card account is capable of being authenticated and to communicate a verification response message with the merchant system in response to a determination that the card account is not capable of being authenticated.
  • the verification response message instructs the merchant system to submit an authentication request to an attempts access control server.
  • the attempts access control server is adapted to receive authentication requests from merchant systems when an access control server associated with the card account is unable to authenticate the card account.
  • the electronic commerce card authentication system also includes an access control server adapted to receive an authentication request message from the merchant system and to communicate an authentication response message with the merchant system.
  • the authentication response message includes an indication that the merchant system attempted an authentication.
  • another embodiment of the access control server is further adapted to communicate a copy of the authentication response message with an authentication history server to be archived.
  • the verification response message indicates the location of the access control server.
  • the access control server is further adapted to validate the authentication request message.
  • the directory server is further adapted to communicate the verification request message with an access control server associated with the card issuer associated with the card account.
  • the directory server is adapted to communicate a verification response message with the merchant system.
  • the verification response message includes an indication that an authentication should be attempted.
  • Still another embodiment of the electronic commerce card authentication system includes an access control server adapted to receive the verification request message from the directory server, determine whether the card account is capable of being authenticated, and communicate a verification response message with the merchant system in response to a determination that the card account cannot be authenticated.
  • the verification response message includes an indication that an authentication should be attempted with a different access control server.
  • the access control server is adapted to alternately communicate a verification response message with the merchant system in response to a determination that the card account can be authenticated, wherein the verification response message includes an indication that an authentication should be attempted with the access control server.
  • a further embodiment of the electronic commerce card authentication system includes an electronic commerce card association adapted to assign liability for a potentially fraudulent transaction to a card issuer in response to the authentication response message that includes an indication that the merchant system attempted an authentication.
  • Figure 1 illustrates a decentralized card processing system
  • Figure 2 illustrates an example card authentication system according to an embodiment of the invention.
  • DETAILED DESCRIPTION OF THE INVENTION [0011]
  • Figure 1 illustrates a decentralized card processing system 100.
  • System 100 enables cardholders to be authenticated when making electronic commerce card purchases online.
  • Cardholder system 105 initiates an online purchase by accessing a merchant computer 110.
  • cardholder system 105 accesses a website provided by the merchant computer 110 via the Internet via a web browser.
  • the cardholder system 105 can be any type of communications device, for example a personal computer, a personal digital assistant, or a telephone.
  • a cardholder uses the cardholder system 105 to submit her electronic commerce card information 150, such as a card number and expiration date, to the merchant system 110.
  • electronic commerce card information 150 such as a card number and expiration date
  • a secure communication system such as SSL, is used for all communications, including the electronic commerce card information 150.
  • the merchant system In response to the electronic commerce card information 150, the merchant system initiates an authentication procedure to determine whether the electronic commerce card information is valid and has been provided by an authorized cardholder.
  • the merchant system In an embodiment of system 100, there are numerous electronic commerce card issuers. Each electronic commerce card issuer is responsible for authenticating its own electronic commerce cards.
  • the merchant system 110 To authenticate the electronic commerce card information 150, the merchant system 110 must locate the authentication service, if any, of the electronic commerce card issuer associated with the electronic commerce card information 150.
  • a directory server 120 maintains a directory specifying the location and capabilities of all card issuer systems in the card processing system 100. The capabilities of card issuer systems include whether the card issuer system supports authentication.
  • the merchant system sends a verifying enrollment request (VEReq) 152 to a directory server 120 to locate the appropriate card issuer system.
  • all authentication-related communication is coordinated by an authentication plug-in 115 integrated with the merchant system 110.
  • the VEReq 152 includes at least a portion of the electronic commerce card information 150 to be used by the directory server 120 to identify the card issuer system associated with the cardholder's electronic commerce card.
  • each electronic commerce card issuer is assigned a different range of electronic commerce card numbers.
  • This embodiment of the directory server 120 includes a list of all electronic commerce card issuers and their associated electronic commerce card number ranges. By comparing the electronic commerce card information with the list of electronic commerce card issuers, the directory server 120 is able to identify the appropriate card issuer system.
  • the directory server 120 determines if the card issuer supports authentication. If the card issuer does not support authentication, then the authentication process is halted. Otherwise, the directory server 120 forwards the VEReq 154 to an access control server (ACS) 125 associated with the card issuer's authentication service.
  • the ACS 125 determines whether the card information provided in the VER'eq 154 can be authenticated. Card information may not be able to be authenticated by the ACS 125 if, for example, the card information does not include a valid electronic commerce card number, or if there is no authentication information, such as a password or other identifying information, associated with the electronic commerce card number.
  • the ACS 125 sends a verified enrollment response (VERes) 156 back to the directory server 120.
  • the VERes 156 includes a message indicating that the ACS 125 can authenticate the electronic commerce card information and a pseudonym corresponding to the card number.
  • the pseudonym can be any type of code or number that can be uniquely linked to card information by the ACS 125 at a later time.
  • the VERes also includes a URL to be accessed by the cardholder system 105 to authenticate the cardholder. For system 100, the URL is associated with a web site provided by the ACS 125.
  • the directory server 120 Upon receiving a VERes from the ACS 125, the directory server 120 forwards the VERes 158 to the merchant system 110.
  • the merchant system 110 From the received VERes, the merchant system 110 generates an authentication request.
  • the authentication request includes the pseudonym created by the ACS 125 and transaction information associated with the cardholder's prospective purchase.
  • the merchant system then forwards the authentication request 160 to the cardholder system 105.
  • the authentication request is sent to the cardholder system 105 with a web page having a redirection command, such as an HTTP redirect, to a web site hosted by the ACS 125. This web page also includes a URL for remrning information to the merchant system 110.
  • the cardholder system 105 accesses 162 a web site hosted by the ACS 125. In accessing this web site, the cardholder system 105 supplies the ACS 125 with the pseudonym originally created by the ACS for the VERes.
  • the cardholder to authenticates her identity by presenting authentication information 164 to the web site provided by the ACS 125.
  • the cardholder authenticates her identity by providing to the ACS 125 a password or other identifying information previously associated with the electronic commerce card.
  • the ACS 125 uses the pseudonym provided by the cardholder system to identify the electronic commerce card being supplied by the cardholder and retrieve authentication information previously associated with the electronic commerce card.
  • the ACS 125 matches the pseudonym received via the authentication request 162 with the pseudonym previously created for VERes 156.
  • the pseudonym expires after a limited period of time, for example five minutes, to prevent fraudulent reuse of the authentication request.
  • the ACS 125 returns an authentication response 166 to the cardholder system 105.
  • the cardholder system 105 in turn forwards the authentication response 168 to the merchant system 110. If the authentication information 164 provided by the cardholder matches the authentication information previously associated with the electronic commerce card, the authentication response includes a message indicating that the authentication was successful. Alternatively, the authentication response can include a message indicating that the authentication failed. In a further embodiment, the authentication response may also include an error code identifying the reason for authentication failure.
  • a copy of the authentication response 167 is sent to an authentication history server 135.
  • the authentication history server 135 maintains an archive of all authentications performed by the system 100.
  • the authentication response is digitally signed to prevent the cardholder system 105 or other third party systems from tampering with the contents of the authentication response.
  • the merchant system 110 validates the authentication response. To validate the authentication response 168, the merchant system 110 first verifies the digital signature associated with the authentication response to ensure that there has not been any tampering. Once the authentication response is determined to have arrived intact, and is a response to the original authentication request, the contents of the authentication response are analyzed to determine if authentication has been successful. If the authentication was not successful, the merchant system 110 halts the transaction. If the authentication was successful, the merchant system 110 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, the merchant system 110 charges the electronic commerce card by submitting the card information to a card acquirer 144.
  • the card acquirer then sends the charge request over a private card association network 148 to be processed by the electronic commerce card issuer associated with the card.
  • an electronic commerce indicator and a Cardholder Authentication Verification Value (CAW) which indicates that the electronic commerce card has been successfully verified, is included with the charge request.
  • CAW Cardholder Authentication Verification Value
  • the card association assigns liability for fraudulent transaction based upon a party's compliance with the authentication system. For example, the card association can specify that if a merchant implements its portion of the authentication system, the merchant will not be responsible for the cost of fraudulent transactions. This provides an incentive to merchants to implement the authentication system.
  • an embodiment of the invention also shifts liability for fraudulent transactions away from the merchant and onto the card issuer when the merchant complies with the authentication system, even in cases where the card issuer does not support authentication. Rewarding merchants for their "good-faith" effort to authenticate cardholders creates an incentive for merchants to implement authentication in as many transactions as possible. Additionally, as this embodiment imposes liability on card issuers for fraudulent transactions regardless of their compliance with the authentication system, card issuers have the incentive to implement authentication to mitigate their risks as much as possible.
  • an embodiment of the card processing system includes the ability to track and record attempts by merchants to initiate authentications, even in circumstances where the card issuer does not support authentication or can not authenticate the card information its receives.
  • Figure 2 illustrates an example of this embodiment of the card processing system 200 according to an embodiment of the invention.
  • cardholder system 205 initiates an online purchase by accessing a merchant computer 210.
  • cardholder system 205 accesses a website provided by the merchant computer 210 via the Internet using a web browser.
  • cardholder system 205 can access the merchant computer 210 via an alternate electronic communications network.
  • the cardholder system 205 can be any type of communications device, for example a personal computer, a personal digital assistant, or a telephone.
  • a cardholder uses the cardholder system 205 to submit her electronic commerce card information 250 to the merchant system 210.
  • the merchant system 210 In response to the electronic commerce card information 250, the merchant system 210 initiates an authentication procedure to determine whether the electronic commerce card information is valid and has been provided by an authorized cardholder. To authenticate the electronic commerce card information 250, the merchant system 210 contacts the directory server 220.
  • the directory server 220 maintains a directory specifying the location and capabilities of all card issuer systems in the card processing system 200. The capabilities of card issuer systems include whether the card issuer system supports authentication.
  • the merchant system 210 sends a verifying enrollment request (VEReq) 252 to the directory server 220 to locate the appropriate card issuer system.
  • all authentication-related communication is coordinated by an authentication plug-in 215 integrated with the merchant system 210.
  • the VEReq 252 includes at least a portion of the electronic commerce card information 250 to be used by the directory server 220 to identify the card issuer system associated with the cardholder's electronic commerce card.
  • each electronic commerce card issuer is assigned a different range of electronic commerce card numbers.
  • This embodiment of the directory server 220 includes a list of all electronic commerce card issuers and their associated electronic commerce card number ranges. By comparing the electronic commerce card information with the list of electronic commerce card issuers, the directory server 220 is able to identify the appropriate card issuer system.
  • the directory server 220 determines if the card issuer supports authentication. If the card issuer does not support authentication, the directory server 220 creates and sends a special "attempted" verifying enrollment response (VERes) 258 to the merchant system 210. As discussed below, the attempted VERes 258 includes information, such as a URL, locating a website operated by a special attempts ACS.
  • the directory server 220 determines that the ACS associated with the card issuer does support authentication, the directory server 220 forwards the VEReq 254 to an access control server (ACS) 225 associated with the card issuer's authentication service.
  • the ACS 125 determines whether the card information provided in the VEReq 154 can be authenticated. Card information may not be able to be authenticated by the ACS 125 if, for example, the card information does not include a valid electronic commerce card number, or if there is no authentication information, such as a password or other identifying information, associated with the electronic commerce card number.
  • the directory server 220 sends the VEReq 254a to the attempts ACS 230 with an indicator that authentication cannot be performed by the ACS 225.
  • the indicator informs the attempts ACS 230 of the reason that authentication cannot be performed, for example, the cardholder has not provided authentication information for her card, the card issuer is not participating in the authentication system, the directory server 220 timed out waiting for a response from the card issuer's ACS 225, or some other error occurred.
  • the attempts ACS 230 In response to receiving the VEReq 254a, the attempts ACS 230 generates VERes 256a that includes a pseudonym for the card information and the location of the attempts ACS, such as a URL. The attempts ACS 230 returns the VERes 256a to the directory server 230 to be forwarded to the merchant system 210. In another embodiment, if the card information cannot be authenticated by the ACS 225, the ACS 225 creates and sends an attempted VERes 256 to the directory server 220, which in turn forwards the attempted VERes 258 to the merchant system 210.
  • the ACS 125 sends a normal verified enrollment response (VERes) 156 back to the directory server 120, and the authentication proceeds as described in system 100.
  • VERes normal verified enrollment response
  • the attempted VERes 258 includes a message indicating that authentication can be attempted by the merchant and a pseudonym corresponding to the card number.
  • the pseudonym can be any type of code or number that can be uniquely linked to card information at a later time.
  • the attempted VERes also includes a URL to be accessed by the cardholder system 205 to record the authentication attempt.
  • the URL is associated with a web site provided by the Attempts ACS 230.
  • the Attempts ACS 230 is operated by the card association.
  • the merchant system 210 Upon receiving an attempted VERes from the directory server 220, the merchant system 210 generates an authentication request.
  • the authentication request includes the pseudonym included with the attempted VERes and transaction information associated with the cardholder's prospective purchase.
  • the merchant system then forwards the authentication request 260 to the cardholder system 205.
  • the authentication request is sent to the cardholder system 205 with a web page having a redirection command, such as an ' HTTP redirect, to a web site hosted by the Attempts ACS 230. This web page also includes a URL for returning information to the merchant system 210.
  • the cardholder system 205 accesses 262 a web site hosted by the Attempts ACS 230. In accessing this web site, the cardholder system 205 supplies the Attempts ACS 230 with the authentication request received from the merchant system 210.
  • the Attempts ACS 230 determines whether the authentication request is valid.
  • the authentication information such as the pseudonym associated with the card information, expires after a limited period of time, for example five minutes, to prevent fraudulent reuse of the authentication request.
  • the Attempts ACS 230 If the authentication request is determined to be valid, the Attempts ACS 230 generates an authentication tracking number, which uniquely identifies a particular authentication attempt, and an authentication results code, which includes an indicator that identifies the reason for performing an attempted authentication, for example the cardholder has not provided authentication information for her card, the card issuer is not participating in the authentication system, the directory server 220 timed out waiting for a response from the card issuer's ACS 225, or some other error occurred.
  • the Attempts ACS 230 returns an authentication response 266 to the cardholder system 205 to be forwarded to the merchant system 210.
  • the authentication response is digitally signed to prevent the cardholder system 205 or other third party systems from tampering with the contents of the authentication response.
  • the Attempts ACS 230 returns an authentication response for every valid authentication request it receives without actually authenticating the cardholder.
  • a copy of the authentication response 267 is sent to an authentication history server 235.
  • the authentication history server 235 maintains an archive of all authentications attempted in the system 200.
  • the cardholder system 205 forwards the authentication response 268 to the merchant system 210.
  • the authentication response includes a message indicating that the authentication was attempted.
  • the authentication response may also include an error code identifying the reason for authentication failure.
  • the merchant system 210 validates the authentication response. To validate the authentication response 268, the merchant system 210 first verifies the digital signature associated with the authentication response to ensure that there has not been any tampering. Once the authentication response is determined to have arrived intact, the merchant system 210 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, the merchant system 210 charges the electromc commerce card by submitting the card information to a card acquirer 244. The card acquirer then sends the charge request over a private card association network 248 to be processed by the electronic commerce card issuer associated with the card. In a further embodiment, an electronic commerce indicator and a Cardholder Authentication Verification Value (CAW), which indicates that the electronic commerce card has been successfully verified, is included with the charge request.
  • CAW Cardholder Authentication Verification Value
  • the CAW is a cryptographic value including data fields • —enabling the electronic commerce card association to verify that authentication was actually attempted by the merchant.
  • the CAW includes the authentication tracking number and authentication results code generated by the Attempts ACS 230 and forwarded to the merchant system in the authentication response 268.
  • the CAW may also include card information, such as an account number and expiration date, other information, and a random or unpredictable number.
  • a card association can use the data fields in the CAW to link the data collected by the authentication attempt with the data submitted in the charge request.
  • the merchant or the card association can refer back to its copy of the authentication response to determine whether the merchant or the card issuer should be responsible for the costs of the fraudulent transaction.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

To encourage widespread implementation of an electronic commerce card authentication system by the numerous different card issuers and merchants, the card association assigns liability for fraudulent transaction based upon a party's compliance with the authentication system. To enable this feature, an embodiment of the card processing system includes the ability to track and record attempts by merchants to initiate authentications, even in circumstances where the card issuer does not support authentication or can not authenticate the card information its receives. A directory server determines whether a card account is capable of being authenticated. If the card issuer cannot authenticate the card account, the directory server instructs the merchant system to attempt authentication with an alternate access control server. The alternate access control server is adapted to communicate an authentication response message with the merchant system indicating that the merchant system attempted an authentication.

Description

MANAGING ATTEMPTS TO INITIATE AUTHENTICATION OF ELECTRONIC COMMERCE CARD TRANSACTIONS
BACKGROUND OF THE INVENTION [0001] Electronic commerce cards are frequently used by consumers to make purchases from merchants over the Internet. Electronic commerce cards include credit cards, debit cards, prepaid purchase cards, travel cards, or any other system that can be used instead of cash to purchase goods or services. To prevent fraud, electronic commerce card associations and/or issuers have instituted authentication systems to ensure that electronic commerce cards are only used by authorized cardholders. One example of an authentication system enables a cardholder to associate a password or other identifying information with an electronic commerce card. To make a purchase online, the consumer must provide the password associated or other identifying information with the electronic commerce card. This ensures that the person possessing the electronic commerce card is actually authorized to use the electronic commerce card.
[0002] Typical card processing systems use a decentralized, distributed computing model in which information is exchanged between merchants, electronic commerce card issuers and the card association to authenticate cardholders. Because of the distributed nature of the card processing system, authentication will fail if any portion of the system, such as a merchant system or a card issuer system, does not support its portion of the authentication. With thousands of card issuers and millions of merchants using a typical card processing system, deploying an authentication system among so many different entities is a difficult task. Additionally, merchants are reluctant to include authentication functions if the authentication system is only supported by a small number of card issuers.
[0003] It is therefore desirable to have an incentive for merchants and card issuers to implement an authentication system. It is further desirable that the authentication system provide merchants with proof of compliance with the authentication system.
BRIEF SUMMARY OF THE INVENTION [0004] To encourage widespread implementation of the authentication system by the numerous different card issuers and merchants, in an embodiment of the invention the card association assigns liability for fraudulent transaction based upon a party's compliance with the authentication system. For example, liability for fraudulent transactions is borne by the card issuer and not the merchant when the merchant complies with the authentication system, even in cases where the card issuer does not support authentication. To enable this feature, an embodiment of the card processing system includes the ability to track and record attempts by merchants to initiate authentications, even in circumstances where the card issuer does not support authentication or can not authenticate the card information its receives.
[0005] In an embodiment, an electronic commerce card authentication system includes a directory server adapted to receive a verification request message from a merchant system. The verification request message requests an indication of whether a card account is capable of being authenticated. The directory server is further adapted to determine whether the card account is capable of being authenticated and to communicate a verification response message with the merchant system in response to a determination that the card account is not capable of being authenticated. The verification response message instructs the merchant system to submit an authentication request to an attempts access control server. The attempts access control server is adapted to receive authentication requests from merchant systems when an access control server associated with the card account is unable to authenticate the card account.
[0006] In an embodiment, the electronic commerce card authentication system also includes an access control server adapted to receive an authentication request message from the merchant system and to communicate an authentication response message with the merchant system. The authentication response message includes an indication that the merchant system attempted an authentication. Additionally, another embodiment of the access control server is further adapted to communicate a copy of the authentication response message with an authentication history server to be archived. In a further embodiment of the electronic commerce card authentication system, the verification response message indicates the location of the access control server. In still another embodiment, the access control server is further adapted to validate the authentication request message.
[0007] In an additional embodiment of the electronic commerce card authentication system, the directory server is further adapted to communicate the verification request message with an access control server associated with the card issuer associated with the card account. In response to a determination that the access control server is inoperable, the directory server is adapted to communicate a verification response message with the merchant system. The verification response message includes an indication that an authentication should be attempted.
[0008] Still another embodiment of the electronic commerce card authentication system includes an access control server adapted to receive the verification request message from the directory server, determine whether the card account is capable of being authenticated, and communicate a verification response message with the merchant system in response to a determination that the card account cannot be authenticated. The verification response message includes an indication that an authentication should be attempted with a different access control server. The access control server is adapted to alternately communicate a verification response message with the merchant system in response to a determination that the card account can be authenticated, wherein the verification response message includes an indication that an authentication should be attempted with the access control server.
[0009] A further embodiment of the electronic commerce card authentication system includes an electronic commerce card association adapted to assign liability for a potentially fraudulent transaction to a card issuer in response to the authentication response message that includes an indication that the merchant system attempted an authentication.
BRIEF DESCRIPTION OF THE DRAWINGS [0010] The invention will be described with reference to the drawings, in which:
Figure 1 illustrates a decentralized card processing system; and
Figure 2 illustrates an example card authentication system according to an embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION [0011] Figure 1 illustrates a decentralized card processing system 100. System 100 enables cardholders to be authenticated when making electronic commerce card purchases online. Cardholder system 105 initiates an online purchase by accessing a merchant computer 110. In an embodiment, cardholder system 105 accesses a website provided by the merchant computer 110 via the Internet via a web browser. The cardholder system 105 can be any type of communications device, for example a personal computer, a personal digital assistant, or a telephone. [0012] To complete a purchase, a cardholder uses the cardholder system 105 to submit her electronic commerce card information 150, such as a card number and expiration date, to the merchant system 110. In an embodiment, a secure communication system, such as SSL, is used for all communications, including the electronic commerce card information 150.
[0013] In response to the electronic commerce card information 150, the merchant system initiates an authentication procedure to determine whether the electronic commerce card information is valid and has been provided by an authorized cardholder. In an embodiment of system 100, there are numerous electronic commerce card issuers. Each electronic commerce card issuer is responsible for authenticating its own electronic commerce cards.
[0014] To authenticate the electronic commerce card information 150, the merchant system 110 must locate the authentication service, if any, of the electronic commerce card issuer associated with the electronic commerce card information 150. A directory server 120 maintains a directory specifying the location and capabilities of all card issuer systems in the card processing system 100. The capabilities of card issuer systems include whether the card issuer system supports authentication.
[0015] The merchant system sends a verifying enrollment request (VEReq) 152 to a directory server 120 to locate the appropriate card issuer system. In an embodiment, all authentication-related communication is coordinated by an authentication plug-in 115 integrated with the merchant system 110. The VEReq 152 includes at least a portion of the electronic commerce card information 150 to be used by the directory server 120 to identify the card issuer system associated with the cardholder's electronic commerce card. In an embodiment, each electronic commerce card issuer is assigned a different range of electronic commerce card numbers. This embodiment of the directory server 120 includes a list of all electronic commerce card issuers and their associated electronic commerce card number ranges. By comparing the electronic commerce card information with the list of electronic commerce card issuers, the directory server 120 is able to identify the appropriate card issuer system.
[0016] After identifying the card issuer system, the directory server 120 determines if the card issuer supports authentication. If the card issuer does not support authentication, then the authentication process is halted. Otherwise, the directory server 120 forwards the VEReq 154 to an access control server (ACS) 125 associated with the card issuer's authentication service. The ACS 125 determines whether the card information provided in the VER'eq 154 can be authenticated. Card information may not be able to be authenticated by the ACS 125 if, for example, the card information does not include a valid electronic commerce card number, or if there is no authentication information, such as a password or other identifying information, associated with the electronic commerce card number.
[0017] If the electronic commerce card information provided in the VEReq 154 can be authenticated, the ACS 125 sends a verified enrollment response (VERes) 156 back to the directory server 120. The VERes 156 includes a message indicating that the ACS 125 can authenticate the electronic commerce card information and a pseudonym corresponding to the card number. The pseudonym can be any type of code or number that can be uniquely linked to card information by the ACS 125 at a later time. The VERes also includes a URL to be accessed by the cardholder system 105 to authenticate the cardholder. For system 100, the URL is associated with a web site provided by the ACS 125. Upon receiving a VERes from the ACS 125, the directory server 120 forwards the VERes 158 to the merchant system 110.
[0018] From the received VERes, the merchant system 110 generates an authentication request. The authentication request includes the pseudonym created by the ACS 125 and transaction information associated with the cardholder's prospective purchase. The merchant system then forwards the authentication request 160 to the cardholder system 105. In an embodiment, the authentication request is sent to the cardholder system 105 with a web page having a redirection command, such as an HTTP redirect, to a web site hosted by the ACS 125. This web page also includes a URL for remrning information to the merchant system 110.
[0019] In response the authentication request received from the merchant system 110, the cardholder system 105 accesses 162 a web site hosted by the ACS 125. In accessing this web site, the cardholder system 105 supplies the ACS 125 with the pseudonym originally created by the ACS for the VERes.
[0020] The cardholder to authenticates her identity by presenting authentication information 164 to the web site provided by the ACS 125. In an embodiment, the cardholder authenticates her identity by providing to the ACS 125 a password or other identifying information previously associated with the electronic commerce card. The ACS 125 uses the pseudonym provided by the cardholder system to identify the electronic commerce card being supplied by the cardholder and retrieve authentication information previously associated with the electronic commerce card. In an embodiment, the ACS 125 matches the pseudonym received via the authentication request 162 with the pseudonym previously created for VERes 156. In a further embodiment, the pseudonym expires after a limited period of time, for example five minutes, to prevent fraudulent reuse of the authentication request.
[0021] The ACS 125 returns an authentication response 166 to the cardholder system 105. The cardholder system 105 in turn forwards the authentication response 168 to the merchant system 110. If the authentication information 164 provided by the cardholder matches the authentication information previously associated with the electronic commerce card, the authentication response includes a message indicating that the authentication was successful. Alternatively, the authentication response can include a message indicating that the authentication failed. In a further embodiment, the authentication response may also include an error code identifying the reason for authentication failure.
[0022] In addition to sending the authentication response to the merchant system 110, a copy of the authentication response 167 is sent to an authentication history server 135. The authentication history server 135 maintains an archive of all authentications performed by the system 100. The authentication response is digitally signed to prevent the cardholder system 105 or other third party systems from tampering with the contents of the authentication response.
[0023] After receiving the authentication response 168, the merchant system 110 validates the authentication response. To validate the authentication response 168, the merchant system 110 first verifies the digital signature associated with the authentication response to ensure that there has not been any tampering. Once the authentication response is determined to have arrived intact, and is a response to the original authentication request, the contents of the authentication response are analyzed to determine if authentication has been successful. If the authentication was not successful, the merchant system 110 halts the transaction. If the authentication was successful, the merchant system 110 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, the merchant system 110 charges the electronic commerce card by submitting the card information to a card acquirer 144. The card acquirer then sends the charge request over a private card association network 148 to be processed by the electronic commerce card issuer associated with the card. [0024] In a further embodiment, an electronic commerce indicator and a Cardholder Authentication Verification Value (CAW), which indicates that the electronic commerce card has been successfully verified, is included with the charge request.
[0025] Because of the decentralized nature of the electronic commerce card authentication system used in system 100, merchants and card issuers are required to implement their respective portions of the authentication system in order for the system to function properly. In order to encourage widespread implementation of the authentication system by the numerous different card issuers and merchants, in an embodiment of the invention, the card association assigns liability for fraudulent transaction based upon a party's compliance with the authentication system. For example, the card association can specify that if a merchant implements its portion of the authentication system, the merchant will not be responsible for the cost of fraudulent transactions. This provides an incentive to merchants to implement the authentication system.
[0026] As an additional incentive, an embodiment of the invention also shifts liability for fraudulent transactions away from the merchant and onto the card issuer when the merchant complies with the authentication system, even in cases where the card issuer does not support authentication. Rewarding merchants for their "good-faith" effort to authenticate cardholders creates an incentive for merchants to implement authentication in as many transactions as possible. Additionally, as this embodiment imposes liability on card issuers for fraudulent transactions regardless of their compliance with the authentication system, card issuers have the incentive to implement authentication to mitigate their risks as much as possible.
[0027] In order to implement this incentive of shifting liability for fraudulent transactions, an embodiment of the card processing system includes the ability to track and record attempts by merchants to initiate authentications, even in circumstances where the card issuer does not support authentication or can not authenticate the card information its receives. Figure 2 illustrates an example of this embodiment of the card processing system 200 according to an embodiment of the invention.
[0028] In card processing system 200, cardholder system 205 initiates an online purchase by accessing a merchant computer 210. In an embodiment, cardholder system 205 accesses a website provided by the merchant computer 210 via the Internet using a web browser. Alternatively, cardholder system 205 can access the merchant computer 210 via an alternate electronic communications network. The cardholder system 205 can be any type of communications device, for example a personal computer, a personal digital assistant, or a telephone. To complete a purchase, a cardholder uses the cardholder system 205 to submit her electronic commerce card information 250 to the merchant system 210.
[0029] In response to the electronic commerce card information 250, the merchant system 210 initiates an authentication procedure to determine whether the electronic commerce card information is valid and has been provided by an authorized cardholder. To authenticate the electronic commerce card information 250, the merchant system 210 contacts the directory server 220. The directory server 220 maintains a directory specifying the location and capabilities of all card issuer systems in the card processing system 200. The capabilities of card issuer systems include whether the card issuer system supports authentication.
[0030] The merchant system 210 sends a verifying enrollment request (VEReq) 252 to the directory server 220 to locate the appropriate card issuer system. In an embodiment, all authentication-related communication is coordinated by an authentication plug-in 215 integrated with the merchant system 210. The VEReq 252 includes at least a portion of the electronic commerce card information 250 to be used by the directory server 220 to identify the card issuer system associated with the cardholder's electronic commerce card. In an embodiment, each electronic commerce card issuer is assigned a different range of electronic commerce card numbers. This embodiment of the directory server 220 includes a list of all electronic commerce card issuers and their associated electronic commerce card number ranges. By comparing the electronic commerce card information with the list of electronic commerce card issuers, the directory server 220 is able to identify the appropriate card issuer system.
[0031] After identifying the card issuer system, the directory server 220 determines if the card issuer supports authentication. If the card issuer does not support authentication, the directory server 220 creates and sends a special "attempted" verifying enrollment response (VERes) 258 to the merchant system 210. As discussed below, the attempted VERes 258 includes information, such as a URL, locating a website operated by a special attempts ACS.
[0032] If the directory server 220 determines that the ACS associated with the card issuer does support authentication, the directory server 220 forwards the VEReq 254 to an access control server (ACS) 225 associated with the card issuer's authentication service. The ACS 125 determines whether the card information provided in the VEReq 154 can be authenticated. Card information may not be able to be authenticated by the ACS 125 if, for example, the card information does not include a valid electronic commerce card number, or if there is no authentication information, such as a password or other identifying information, associated with the electronic commerce card number.
[0033] In an embodiment of the invention, if the ACS 225 does not respond to the VEReq 254, because, for example, it is not operating or is unable to authenticate the card information, or if the directory server 220 determines that the card issuer does not support authentication, the directory server 220 sends the VEReq 254a to the attempts ACS 230 with an indicator that authentication cannot be performed by the ACS 225. The indicator informs the attempts ACS 230 of the reason that authentication cannot be performed, for example, the cardholder has not provided authentication information for her card, the card issuer is not participating in the authentication system, the directory server 220 timed out waiting for a response from the card issuer's ACS 225, or some other error occurred.
[0034] In response to receiving the VEReq 254a, the attempts ACS 230 generates VERes 256a that includes a pseudonym for the card information and the location of the attempts ACS, such as a URL. The attempts ACS 230 returns the VERes 256a to the directory server 230 to be forwarded to the merchant system 210. In another embodiment, if the card information cannot be authenticated by the ACS 225, the ACS 225 creates and sends an attempted VERes 256 to the directory server 220, which in turn forwards the attempted VERes 258 to the merchant system 210.
[0035] If the electronic commerce card information provided in the VEReq 154 can be authenticated, the ACS 125 sends a normal verified enrollment response (VERes) 156 back to the directory server 120, and the authentication proceeds as described in system 100.
[0036] The attempted VERes 258 includes a message indicating that authentication can be attempted by the merchant and a pseudonym corresponding to the card number. The pseudonym can be any type of code or number that can be uniquely linked to card information at a later time. The attempted VERes also includes a URL to be accessed by the cardholder system 205 to record the authentication attempt. For system 200, the URL is associated with a web site provided by the Attempts ACS 230. In an embodiment, the Attempts ACS 230 is operated by the card association.
[0037] Upon receiving an attempted VERes from the directory server 220, the merchant system 210 generates an authentication request. The authentication request includes the pseudonym included with the attempted VERes and transaction information associated with the cardholder's prospective purchase. The merchant system then forwards the authentication request 260 to the cardholder system 205. In an embodiment, the authentication request is sent to the cardholder system 205 with a web page having a redirection command, such as an ' HTTP redirect, to a web site hosted by the Attempts ACS 230. This web page also includes a URL for returning information to the merchant system 210.
[0038] In response the authentication request, the cardholder system 205 accesses 262 a web site hosted by the Attempts ACS 230. In accessing this web site, the cardholder system 205 supplies the Attempts ACS 230 with the authentication request received from the merchant system 210.
[0039] In response to receiving an authentication request from the cardholder system 205, the Attempts ACS 230 determines whether the authentication request is valid. In an embodiment, the authentication information, such as the pseudonym associated with the card information, expires after a limited period of time, for example five minutes, to prevent fraudulent reuse of the authentication request. If the authentication request is determined to be valid, the Attempts ACS 230 generates an authentication tracking number, which uniquely identifies a particular authentication attempt, and an authentication results code, which includes an indicator that identifies the reason for performing an attempted authentication, for example the cardholder has not provided authentication information for her card, the card issuer is not participating in the authentication system, the directory server 220 timed out waiting for a response from the card issuer's ACS 225, or some other error occurred.
[0040] The Attempts ACS 230 returns an authentication response 266 to the cardholder system 205 to be forwarded to the merchant system 210. The authentication response is digitally signed to prevent the cardholder system 205 or other third party systems from tampering with the contents of the authentication response. In an embodiment, the Attempts ACS 230 returns an authentication response for every valid authentication request it receives without actually authenticating the cardholder.
[0041] In addition to sending the authentication response to the cardholder system 205, a copy of the authentication response 267 is sent to an authentication history server 235. The authentication history server 235 maintains an archive of all authentications attempted in the system 200.
[0042] The cardholder system 205 forwards the authentication response 268 to the merchant system 210. The authentication response includes a message indicating that the authentication was attempted. In a further embodiment, the authentication response may also include an error code identifying the reason for authentication failure.
[0043] After receiving the authentication response 268, the merchant system 210 validates the authentication response. To validate the authentication response 268, the merchant system 210 first verifies the digital signature associated with the authentication response to ensure that there has not been any tampering. Once the authentication response is determined to have arrived intact, the merchant system 210 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, the merchant system 210 charges the electromc commerce card by submitting the card information to a card acquirer 244. The card acquirer then sends the charge request over a private card association network 248 to be processed by the electronic commerce card issuer associated with the card. In a further embodiment, an electronic commerce indicator and a Cardholder Authentication Verification Value (CAW), which indicates that the electronic commerce card has been successfully verified, is included with the charge request.
[0044] hi an embodiment, the CAW is a cryptographic value including data fields —enabling the electronic commerce card association to verify that authentication was actually attempted by the merchant. In this embodiment, the CAW includes the authentication tracking number and authentication results code generated by the Attempts ACS 230 and forwarded to the merchant system in the authentication response 268. The CAW may also include card information, such as an account number and expiration date, other information, and a random or unpredictable number. A card association can use the data fields in the CAW to link the data collected by the authentication attempt with the data submitted in the charge request. [0045] If the electronic commerce card used to complete the transaction turned out to have been fraudulently used, either the merchant or the card association can refer back to its copy of the authentication response to determine whether the merchant or the card issuer should be responsible for the costs of the fraudulent transaction.
[0046] Although the invention has been discussed with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive, of the invention. For example, the present invention can be utilized with any authentication system. Thus, the scope of the invention is to be determined solely by the claims.

Claims

WHAT IS CLAMED IS: 1. An electronic commerce card authentication system comprising: a directory server adapted to: receive a verification request message from a merchant system, wherein the verification request message requests an indication of whether a card account is capable of being authenticated; determine whether the card account is capable of being authenticated; and communicate a verification response message with the merchant system in response to a determination that the card account is not capable of being authenticated, wherein the verification response message instructs the merchant system to submit an authentication request.
2. The electronic commerce card authentication system of claim 1, wherein the directory server is adapted to determine whether the card account is capable of being authenticated by identifying a card issuer associated with the card account.
3. The electronic commerce card authentication system of claim 2, wherein the verification request message includes at least a portion of a card number associated with the card account, and wherein the directory server is adapted to compare the portion of the card number with a range of card numbers associated with the card issuer.
4. The electronic commerce card authentication system of claim 1, further comprising: an access control server adapted to receive an authentication request message from the merchant system and to communicate an authentication response message with the merchant system, wherein the authentication response message includes an indication that the merchant system attempted an authentication.
5. The electronic commerce card authentication system of claim 4, wherein the verification response message indicates the location of the access control server.
6. The electronic commerce card authentication system of claim 4, wherein the access control server is further adapted to validate the authentication request message.
7. The electronic commerce card authentication system of claim 4, wherein the access control server is further adapted to communicate a copy of the authentication response message with an authentication history server to be archived.
8. The electronic commerce card authentication system of claim 2, wherein the directory server is further adapted to communicate the verification request message with an access control server associated with the card issuer associated with the card account; and to communicate a verification response message with the merchant system in response to a determination that the access control server is inoperable, wherein the verification response message instructs the merchant system to submit an authentication request.
9. The electronic commerce card authentication system of claim 2, further comprising an access control server adapted to: receive the verification request message from the directory server; determine whether the card account is capable of being authenticated; communicate a verification response message with the merchant system in response to a determination that the card account cannot be authenticated, wherein the verification response message includes an indication that an authentication should be attempted with a different access control server; and communicate a verification response message with the merchant system in response to a determination that the card account can be authenticated, wherein the verification response message includes an indication that an authentication should be attempted with the access control server.
10. The electronic commerce card authentication system of claim 4, further comprising an electronic commerce card association adapted to assign liability for a potentially fraudulent transaction to a card issuer in response to the authentication response message, wherein the authentication response message includes an indication that the merchant system attempted an authentication.
11. A method of initiating an authentication of an electronic commerce card, the method comprising: receiving a verification request message from a merchant system, wherein the message requests an indication of whether a card account is capable of being authenticated; determining whether the card account is capable of being authenticated; and communicating a verification response message with the merchant system in response to a determination that the card account is not capable of being authenticated, wherein the verification response message instructs the merchant system to submit an authentication request.
12. The method of claim 11 , wherein determining includes identifying a card issuer associated with the card account.
13. The method of claim 12, wherein the verification request message includes at least a portion of a card number associated with the card account, and wherein determining further includes comparing the portion of the card number with a range of card numbers associated with the card issuer.
14. The method of claim 11 , further comprising: receiving an authentication request message from the merchant system; and communicating an authentication response message with the merchant system, wherein the authentication response message includes an indication that the merchant system attempted an authentication.
15. The method of claim 14, wherein the verification response message indicates the location of the access control server.
16. The method of claim 14, further including validating the authentication request message.
17. The method of claim 14, further including communicating a copy of the authentication response message with an authentication history server to be archived.
18. The method of claim 12, further including communicating the verification request message with an access control server associated with the card issuer associated with the card account; and communicating a verification response message with the merchant system in response to a determination that the access control server is inoperable, wherein the verification response message instructs the merchant system to submit an authentication request.
19. The method of claim 12, further comprising: receiving, by an access control server, the verification request message from a directory server; determining, by the access control server, whether the card account is capable of being authenticated; communicating, by the access control server, a verification response message with the merchant system in response to a determination that the card account can not be authenticated, wherein the verification response message instructs the merchant system to submit an authentication request to a different access control server; and communicating, by the access control server, a verification response message with the merchant system in response to a determination that the card account can be authenticated, wherein the verification response message includes an indication that an authentication should be attempted with the access control server.
20. The method of claim 14, further comprising assigning liability for a potentially fraudulent transaction to a card issuer in response to the authentication response message, wherein the authentication response message includes an indication that the merchant system attempted an authentication.
PCT/US2004/035054 2003-11-06 2004-10-21 Managing attempts to initiate authentication of electronic commerce card transactions WO2005048032A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA002545737A CA2545737A1 (en) 2003-11-06 2004-10-21 Managing attempts to initiate authentication of electronic commerce card transactions
EP04796106A EP1723582A4 (en) 2003-11-06 2004-10-21 Managing attempts to initiate authentication of electronic commerce card transactions
AU2004290297A AU2004290297B2 (en) 2003-11-06 2004-10-21 Managing attempts to initiate authentication of electronic commerce card transactions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/704,331 US7039611B2 (en) 2003-11-06 2003-11-06 Managing attempts to initiate authentication of electronic commerce card transactions
US10/704,331 2003-11-06

Publications (2)

Publication Number Publication Date
WO2005048032A2 true WO2005048032A2 (en) 2005-05-26
WO2005048032A3 WO2005048032A3 (en) 2005-08-04

Family

ID=34552097

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/035054 WO2005048032A2 (en) 2003-11-06 2004-10-21 Managing attempts to initiate authentication of electronic commerce card transactions

Country Status (5)

Country Link
US (1) US7039611B2 (en)
EP (1) EP1723582A4 (en)
AU (1) AU2004290297B2 (en)
CA (1) CA2545737A1 (en)
WO (1) WO2005048032A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8688574B2 (en) 2009-01-08 2014-04-01 Visa Europe Limited Payment system
US8706577B2 (en) 2009-01-06 2014-04-22 Visa Europe Limited Payment system

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7702916B2 (en) * 2003-03-31 2010-04-20 Visa U.S.A. Inc. Method and system for secure authentication
US7515901B1 (en) * 2004-02-25 2009-04-07 Sun Microsystems, Inc. Methods and apparatus for authenticating devices in a network environment
KR20070065358A (en) * 2004-09-13 2007-06-22 익셉트, 인코포레이티드 Purchasing alert methods and apparatus
US7482925B2 (en) * 2005-06-24 2009-01-27 Visa U.S.A. Apparatus and method to electromagnetically shield portable consumer devices
US20070055597A1 (en) * 2005-09-08 2007-03-08 Visa U.S.A. Method and system for manipulating purchase information
US7873799B2 (en) * 2005-11-04 2011-01-18 Oracle America, Inc. Method and system supporting per-file and per-block replication
US7596739B2 (en) * 2005-11-04 2009-09-29 Sun Microsystems, Inc. Method and system for data replication
US7865673B2 (en) * 2005-11-04 2011-01-04 Oracle America, Inc. Multiple replication levels with pooled devices
US7828204B2 (en) * 2006-02-01 2010-11-09 Mastercard International Incorporated Techniques for authorization of usage of a payment device
BRPI0621426A2 (en) * 2006-03-24 2011-12-13 Metabank information management system and method
US10346837B2 (en) 2006-11-16 2019-07-09 Visa U.S.A. Inc. Adaptive authentication options
US8504451B2 (en) 2006-11-16 2013-08-06 Visa U.S.A. Inc. Method and system using candidate dynamic data elements
US9940627B2 (en) 2006-12-26 2018-04-10 Visa U.S.A. Inc. Mobile coupon method and system
US8615426B2 (en) 2006-12-26 2013-12-24 Visa U.S.A. Inc. Coupon offers from multiple entities
CN101647040A (en) * 2006-12-26 2010-02-10 维萨美国股份有限公司 Mobile payment system and method using alias
US8923827B2 (en) 2007-01-09 2014-12-30 Visa U.S.A. Inc. Mobile payment management
US7866551B2 (en) * 2007-02-15 2011-01-11 Visa U.S.A. Inc. Dynamic payment device characteristics
US8505826B2 (en) * 2007-04-16 2013-08-13 Visa U.S.A. Anti-interrogation for portable device
US7860790B2 (en) * 2007-06-04 2010-12-28 Visa U.S.A. Inc. Systems and methods for automatic migration of a consumer between financial accounts
US7809637B2 (en) * 2007-06-04 2010-10-05 Visa U.S.A. Inc. Portability of financial tokens
US7627522B2 (en) * 2007-06-04 2009-12-01 Visa U.S.A. Inc. System, apparatus and methods for comparing fraud parameters for application during prepaid card enrollment and transactions
US8290832B2 (en) * 2007-06-04 2012-10-16 Visa U.S.A. Inc. Method and system for handling returned prepaid payment cards
US8165938B2 (en) * 2007-06-04 2012-04-24 Visa U.S.A. Inc. Prepaid card fraud and risk management
US20080300895A1 (en) * 2007-06-04 2008-12-04 Monk Justin T Method and system for handling returned payment card account statements
US8146806B2 (en) * 2007-06-04 2012-04-03 Visa U.S.A. Inc. Prepaid negative balance fee processing and fee diversion
US8604995B2 (en) * 2007-06-11 2013-12-10 Visa U.S.A. Inc. Shielding of portable consumer device
US8359630B2 (en) * 2007-08-20 2013-01-22 Visa U.S.A. Inc. Method and system for implementing a dynamic verification value
US20090063334A1 (en) * 2007-08-28 2009-03-05 Alistair Duncan Business-to-business transaction processing utilizing electronic payment network
US9292850B2 (en) 2007-09-10 2016-03-22 Visa U.S.A. Inc. Host capture
US8170527B2 (en) 2007-09-26 2012-05-01 Visa U.S.A. Inc. Real-time balance on a mobile phone
US20090103730A1 (en) * 2007-10-19 2009-04-23 Mastercard International Incorporated Apparatus and method for using a device conforming to a payment standard for access control and/or secure data storage
US20090119170A1 (en) 2007-10-25 2009-05-07 Ayman Hammad Portable consumer device including data bearing medium including risk based benefits
US8038068B2 (en) * 2007-11-28 2011-10-18 Visa U.S.A. Inc. Multifunction removable cover for portable payment device
US9098851B2 (en) * 2008-02-14 2015-08-04 Mastercard International Incorporated Method and apparatus for simplifying the handling of complex payment transactions
US9715709B2 (en) 2008-05-09 2017-07-25 Visa International Services Association Communication device including multi-part alias identifier
WO2010005681A1 (en) 2008-06-16 2010-01-14 Visa U.S.A. Inc. System and method for authorizing financial transactions with online merchants
US9542687B2 (en) 2008-06-26 2017-01-10 Visa International Service Association Systems and methods for visual representation of offers
US8707319B2 (en) * 2008-06-26 2014-04-22 Visa International Service Association Resource location verification by comparing and updating resource location with a location of a consumer device after a threshold of location mismatches is exceeded
US20090327135A1 (en) * 2008-06-26 2009-12-31 Loc Duc Nguyen Credit card paired with location identifiable device for point of service fraud detection
US8219489B2 (en) * 2008-07-29 2012-07-10 Visa U.S.A. Inc. Transaction processing using a global unique identifier
US8341084B2 (en) 2009-06-08 2012-12-25 Mastercard International Incorporated Method, apparatus, and computer program product for topping up prepaid payment cards for offline use
US8977567B2 (en) 2008-09-22 2015-03-10 Visa International Service Association Recordation of electronic payment transaction information
US9824355B2 (en) 2008-09-22 2017-11-21 Visa International Service Association Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US10706402B2 (en) 2008-09-22 2020-07-07 Visa International Service Association Over the air update of payment transaction data stored in secure memory
US8612305B2 (en) 2008-10-31 2013-12-17 Visa International Service Association User enhanced authentication system for online purchases
US9317876B2 (en) * 2009-02-24 2016-04-19 Blake Bookstaff Automatically adding gratuity to amount charged in electronic transaction
US11348150B2 (en) * 2010-06-21 2022-05-31 Paypal, Inc. Systems and methods for facilitating card verification over a network
SG187832A1 (en) 2010-08-12 2013-03-28 Mastercard International Inc Multi-commerce channel wallet for authenticated transactions
US10692081B2 (en) 2010-12-31 2020-06-23 Mastercard International Incorporated Local management of payment transactions
US9818111B2 (en) 2011-04-15 2017-11-14 Shift4 Corporation Merchant-based token sharing
US9256874B2 (en) 2011-04-15 2016-02-09 Shift4 Corporation Method and system for enabling merchants to share tokens
US8688589B2 (en) * 2011-04-15 2014-04-01 Shift4 Corporation Method and system for utilizing authorization factor pools
US10726400B2 (en) 2013-06-10 2020-07-28 The Toronto-Dominion Bank High fraud risk transaction authorization
US10521791B2 (en) * 2014-05-07 2019-12-31 Mastercard International Incorporated Systems and methods for communicating liability acceptance with payment card transactions
EP3933736A1 (en) * 2020-06-30 2022-01-05 Mastercard International Incorporated Techniques for performing authentication in ecommerce transactions

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2592510B1 (en) * 1985-12-31 1988-02-12 Bull Cp8 METHOD AND APPARATUS FOR CERTIFYING SERVICES OBTAINED USING A PORTABLE MEDIUM SUCH AS A MEMORY CARD
US5826245A (en) * 1995-03-20 1998-10-20 Sandberg-Diment; Erik Providing verification information for a transaction
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
WO2001082246A2 (en) * 2000-04-24 2001-11-01 Visa International Service Association Online payer authentication service
US20010056409A1 (en) * 2000-05-15 2001-12-27 Bellovin Steven Michael Offline one time credit card numbers for secure e-commerce
US20020013765A1 (en) * 2000-05-23 2002-01-31 Gil Shwartz Intrinsic authorization for electronic transactions
US7120607B2 (en) * 2000-06-16 2006-10-10 Lenovo (Singapore) Pte. Ltd. Business system and method using a distorted biometrics
WO2002071176A2 (en) * 2001-03-08 2002-09-12 Cyota Inc. Transaction system
JP2002300311A (en) * 2001-03-30 2002-10-11 Hitachi Ltd Roaming service system and accounting server, router, authentication server, clearance server, telephone directory server, and computer software
US7111789B2 (en) * 2001-08-31 2006-09-26 Arcot Systems, Inc. Enhancements to multi-party authentication and other protocols
US6805289B2 (en) * 2002-05-23 2004-10-19 Eduardo Noriega Prepaid card payment system and method for electronic commerce

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of EP1723582A4 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8706577B2 (en) 2009-01-06 2014-04-22 Visa Europe Limited Payment system
US8942997B2 (en) 2009-01-06 2015-01-27 Visa Europe Limited Payment system
US8688574B2 (en) 2009-01-08 2014-04-01 Visa Europe Limited Payment system
US11669816B2 (en) 2009-01-08 2023-06-06 Visa Europe Limited Payment system

Also Published As

Publication number Publication date
AU2004290297A1 (en) 2005-05-26
AU2004290297B2 (en) 2010-08-26
EP1723582A2 (en) 2006-11-22
EP1723582A4 (en) 2008-05-21
WO2005048032A3 (en) 2005-08-04
US7039611B2 (en) 2006-05-02
CA2545737A1 (en) 2005-05-26
US20050102234A1 (en) 2005-05-12

Similar Documents

Publication Publication Date Title
AU2004290297B2 (en) Managing attempts to initiate authentication of electronic commerce card transactions
AU2004255011B2 (en) Managing activation of cardholders in a secure authentication program
AU2004288988B2 (en) Centralized electronic commerce card transactions
US7366702B2 (en) System and method for secure network purchasing
US8245044B2 (en) Payment transaction processing using out of band authentication
US7360694B2 (en) System and method for secure telephone and computer transactions using voice authentication
US8296228B1 (en) Dual transaction authorization system and method
US8768837B2 (en) Method and system for controlling risk in a payment transaction
US6343284B1 (en) Method and system for billing on the internet
US20060173776A1 (en) A Method of Authentication
ZA200606715B (en) System and method for secure telephone and computer transactions

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2545737

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2004290297

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2004796106

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2004290297

Country of ref document: AU

Date of ref document: 20041021

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2004290297

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 2004796106

Country of ref document: EP