US20060179007A1 - Centralized electronic commerce card transactions - Google Patents

Abstract

A central transaction server in electronic commerce card authorization system enables the electronic commerce card association to manage and monitor the authentication system. The central transaction server acts as an intermediary for all communications between the access control server used for authentication. If any portion of the authentication system fails, the central transaction server compensates by providing appropriate responses to other portions of the system. The centralized transaction server translates all incoming traffic into a format compatible with the intended recipient, enabling portions of the system to be upgraded without breaking compatibility with the non-upgraded portions. The centralized transaction server also enables the integration of formally separate portions of the authentication system into a single unit. The directory and the authentication history servers can be integrated into the central transaction server, and the central transaction server can initiate charges to the electronic commerce card automatically, bypassing the card acquirer.

Description

BACKGROUND OF THE INVENTION
• 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. 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 or other identifying information associated with the electronic commerce card. This ensures that the person possessing the electronic commerce card is actually authorized to use the electronic commerce card.
• Once a consumer has been authenticated as an authorized cardholder, the electronic commerce card transaction can be completed by the merchant. Previously, authentication and transaction processing used a decentralized, distributed computing model to communicate messages between merchants, card associations, and authentication servers. In this approach, there is no centralized point for collecting data and monitoring system performance. Instead, each end point in the system, such as merchants, authentication servers, and card issuers, must be asked to collect data and monitor performance of their portion of the overall system.
• This decentralized model makes it difficult for the electronic commerce card association, which is responsible for the entire system, to evaluate the system performance as a whole. Additionally, this lack of visibility of the entire system prevents the card association from spotting trends or patterns that would assist in understanding where and how to add new features. Furthermore, the decentralized model makes upgrades and migration difficult, as each end point must be able to communicate with its counterparts, regardless of the features or software versions supported. The decentralized model also increases support and service overhead, and decreases the fault tolerance of the system.
• Therefore, it is desirable to have an electronic commerce card authentication and transaction processing system that facilitates monitoring and management, increases overall reliability and fault tolerance, and simplifies system upgrades and migrations.
BRIEF SUMMARY OF THE INVENTION
• An embodiment of the invention includes a central transaction server in electronic commerce card authorization system to enables the electronic commerce card association to manage and monitor the entire authentication system. The central transaction server acts as an intermediary for all communications to and from the access control server (ACS) used to authenticate a cardholder. Additionally, if any portion of the authentication system fails, for example, a card issuer's ACS, the central transaction server can compensate by providing appropriate responses to other portions of the system. Additionally, the centralized transaction server enables portions of the system to be upgraded without breaking compatibility with the non-upgraded portions. As all traffic between merchant and cardholder systems and the card issuer ACS systems is routed through the centralized transaction server, the centralized transaction server can translate all incoming traffic into a format compatible with the intended recipient.
• In an embodiment, the central transaction server is adapted to receive an authentication request from a cardholder system, forward the authentication request to an access control server, and relay authentication information between the access control server and the cardholder system. The central authentication server also receives an authentication response from the access control server and forwards the authentication response to the cardholder system. The authentication response is adapted to be analyzed by a merchant system. In a further embodiment, the central transaction server is adapted to forward a copy of the authentication response to an authentication history server to be archived.
• In an additional embodiment, the central transaction server is further adapted to receive a verifying enrollment request from a directory server, and to send a verifying enrollment response to the directory server. In one implementation, the central transaction server is adapted to send the verifying enrollment response in response to a query to the access control server. In an alternate implementation, the central transaction server is adapted to send the verifying enrollment response to the directory server without querying the access control server, and is further adapted to query the access control server in response to receiving an authentication request.
• In another embodiment, the authentication request includes a pseudonym corresponding to an electronic commerce card account number and previously created by the central transaction server. Alternately, the authentication request includes a pseudonym previously created by a merchant system that corresponds to an electronic commerce card account number.
• In yet a further embodiment, the central transaction server is adapted to initiate a charge request via a card association network in response to receiving an authentication response from the access control server.
BRIEF DESCRIPTION OF THE DRAWINGS
• The invention will be described with reference to the drawings, in which:
• FIG. 1 illustrates a prior decentralized card authentication system;
• FIG. 2 illustrates an example card authentication system according to an embodiment of the invention; and
• FIG. 3 illustrates an example card authentication system according to an alternate embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
• FIG. 1 illustrates a prior decentralizedcard authentication system100.System100 enables cardholders to be authenticated when making electronic commerce card purchases online.Cardholder system105 initiates an online purchase by accessing amerchant computer110. In an embodiment,cardholder system105 accesses a website provided by themerchant computer110 via the Internet via a web browser. Alternatively,cardholder system105 can access themerchant computer110 via an alternate electronic communications network. Thecardholder system105 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 thecardholder system105 to submit her electroniccommerce card information150, such as a card number and expiration date, to themerchant system110. In an embodiment, a secure communication system, such as SSL, is used for all communications, including the electroniccommerce card information150.
• In response to the electroniccommerce card information150, 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 ofsystem100, there are numerous electronic commerce card issuers. Each electronic commerce card issuer is responsible for authenticating its own electronic commerce cards. To authenticate the electroniccommerce card information150, themerchant system110 must locate the authentication service of the electronic commerce card issuer associated with the electroniccommerce card information150.
• The merchant system sends a verifying enrollment request (VEReq)152 to adirectory server120 to locate the appropriate authentication service. In an embodiment, all authentication-related communication is coordinated by an authentication plug-in115 integrated with themerchant system110. The VEReq152 includes at least a portion of the electroniccommerce card information150 to be used by thedirectory server120 to identify the authentication service 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 thedirectory server120 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, thedirectory server120 is able to identify the appropriate authentication service.
• After identifying the authentication service, thedirectory server120 forwards the VEReq154 to an access control server (ACS)125 associated with the card issuer's authentication service. The ACS125 determines whether the card information provided in the VEReq154 can be authenticated. Card information may not be able to be authenticated by the ACS125 if, for example, the card information does not include a valid electronic commerce card number, or if there is no authentication information associated with the electronic commerce card number.
• If the electronic commerce card information provided in the VEReq154 can be authenticated, the ACS125 sends a verified enrollment response (VERes)156 back to thedirectory server120. The VERes156 includes a message indicating that the ACS125 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 ACS125 at a later time. The VERes also includes a URL to be accessed by thecardholder system105 to authenticate the cardholder. Forsystem100, the URL is associated with a web site provided by the ACS125. Upon receiving a VERes from the ACS125, thedirectory server120 forwards the VERes158 to themerchant system110.
• From the received VERes, themerchant system110 generates an authentication request. The authentication request includes the pseudonym created by theACS125 and transaction information associated with the cardholder's prospective purchase. The merchant system then forwards theauthentication request160 to thecardholder system105. In an embodiment, the authentication request is sent to thecardholder system105 with a web page having a redirection command, such as an HTTP redirect, to a web site hosted by theACS125. This web page also includes a URL for returning information to themerchant system110.
• In response the authentication request received from themerchant system110, thecardholder system105 accesses162 a web site hosted by theACS125. In accessing this web site, thecardholder system105 supplies theACS125 with the pseudonym originally created by the ACS for the VERes.
• The cardholder to authenticates her identity by presentingauthentication information164 to the web site provided by theACS125. In an embodiment, the cardholder authenticates her identity by providing to the ACS125 a password or other identifying information previously associated with the electronic commerce card. TheACS125 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, theACS125 matches the pseudonym received via theauthentication request162 with the pseudonym previously created forVERes156. 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.
• TheACS125 returns anauthentication response166 to thecardholder system105. Thecardholder system105 in turn forwards theauthentication response168 to themerchant system110. If theauthentication information164 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 also includes an error code identifying the reason for authentication failure.
• In addition to sending the authentication response to themerchant system110, a copy of theauthentication response167 is sent to anauthentication history server135. Theauthentication history server135 maintains an archive of all authentications performed by thesystem100. The authentication response is digitally signed to prevent thecardholder system105 or other third party systems from tampering with the contents of the authentication response.
• After receiving theauthentication response168, themerchant system110 validates the authentication response. To validate theauthentication response168, themerchant system110 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 the response is for the request originally submitted, the contents of the authentication response are analyzed to determine if authentication has been successful. If the authentication was not successful, themerchant system110 halts the transaction. If the authentication was successful, themerchant system110 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, themerchant system110 charges the electronic commerce card by submitting the card information to acard acquirer144. The card acquirer then sends the charge request over a privatecard association network148 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, which indicates that the electronic commerce card has been successfully verified, is included with the charge request.
• The decentralized nature of the electronic commercecard authentication system100 makes it difficult to be managed and monitored by electronic commerce card associations. Additionally, if any portion of thesystem100 fails, for example, a card issuer's ACS, there is no way for thesystem100 to compensate. The decentralized electronic commercecard authentication system100 is difficult to upgrade, as each end point of the system, for example the directory server and the numerous ACS and merchant systems, must all be upgraded simultaneously to ensure compatibility.
• FIG. 2 illustrates an example improvedcard authentication system200 according to an embodiment of the invention.Cardholder system205 initiates an online purchase by accessing amerchant computer210. In an embodiment,cardholder system205 accesses a website provided by themerchant computer210 via the Internet using a web browser. Alternatively,cardholder system205 can access themerchant computer210 via an alternate electronic communications network. Thecardholder system205 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 thecardholder system205 to submit her electroniccommerce card information250, such as a card number and expiration date, to themerchant system210. In an embodiment, a secure communication system, such as SSL, is used for all communications, including the electroniccommerce card information250.
• In response to the electroniccommerce card information250, 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. To authenticate the electroniccommerce card information250, themerchant system210 must locate the authentication service of the electronic commerce card issuer associated with the electroniccommerce card information250.
• The merchant system sends a verifying enrollment request (VEReq)252 to adirectory server220 to locate the appropriate authentication service. In an embodiment, all authentication-related communication is coordinated by an authentication plug-in215 integrated with themerchant system210. TheVEReq252 includes at least a portion of the electroniccommerce card information250 to be used by thedirectory server220 to identify the access control server (ACS)225 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 thedirectory server220 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, thedirectory server220 is able to identify the appropriate ACS.
• After identifying the ACS, thedirectory server220 forwards theVEReq272 to acentral transaction server280. As discussed in detail below, thecentral transaction server280 acts as a proxy for all communications between ACS systems and cardholder systems, merchant systems, authentication history servers, and directory servers. In response to theVEReq272, thecentral transaction server280 replies with aVERes274. In this embodiment, thecentral transaction server280 creates aVERes274 without checking with theACS225 to determine whether the card information can be authenticated. This is done for compatibility purposes, and, as discussed below, streamlines the authentication process.
• In an alternate embodiment, thecentral transaction server280 forwards the VEReq to theACS225.ACS225 returns a VERes, similar to that discussed above, to thecentral transaction server280. Thecentral transaction server280 alters the VERes received from theACS225 to direct thecardholder system205 to include a URL is associated with a web site provided by thecentral transaction server280, as discussed in detail below, rather than a web site provided by the ACS, as discussed insystem100. If theACS225 is not available, or an error is encountered while communicating with theACS225, or if the response from theACS225 cannot be understood, thecentral transaction server280 will generate a substitute VERes on behalf of the ACS, including an indication of why the response is being generated. Examples of these indicators include: 1) the cardholder has not provided authentication information; 2) the card issuer has not implemented the authentication system; 3) thecentral transaction server280 timed out waiting on a response from theACS225; and 4) the VERes received fromACS225 could not be understood by thecentral transaction server280. The indicator in included in the pseudonym associated with the card information and is used later in generating the Cardholder Authentication Verification Value.
• TheVERes274 created by thecentral transaction server280 includes a message indicating that theACS225 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 theACS225 at a later time. The VERes also includes a URL to be accessed by thecardholder system205 to authenticate the cardholder. Forsystem200, the URL is associated with a web site provided by thecentral transaction server280. Upon receiving a VERes from thecentral transaction server280, thedirectory server220 forwards theVERes258 to themerchant system210.
• From the received VERes, themerchant system210 generates an authentication request. The authentication request includes the pseudonym created by thecentral transaction server280 and transaction information associated with the cardholder's prospective purchase. The merchant system then forwards theauthentication request260 to thecardholder system205. In an embodiment, the authentication request is sent to thecardholder system205 with a web page having a redirection command, such as an HTTP redirect, to a web site hosted by thecentral transaction server280. This web page also includes a URL for returning information to themerchant system210.
• In response the authentication request received from themerchant system210, thecardholder system205 accesses262 the web site hosted by thecentral transaction server280. In accessing this web site, thecardholder system205 supplies thecentral transaction server280 with the authentication request, including the pseudonym created by thecentral transaction server280 earlier.
• Thecentral transaction server280 provides aVEReq254 to theACS225 associated with the card issuer's authentication service. TheACS225 determines whether the card information provided in theVEReq254 can be authenticated. If the electronic commerce card information provided in theVEReq254 can be authenticated, theACS225 sends a verified enrollment response (VERes)256 back to the central transaction server. In this embodiment, thecentral transaction server280 has integrated the step of sending a VEReq and receiving a VERes into the processing of authentication request from the cardholder system, which streamlines the authentication process. As discussed above, an alternate embodiment of thecentral transaction server280 previously sent a VEReq to theACS225, and thus does not need to repeat this communication.
• In response to theVERes256, thecentral transaction server280 sends the authentication request received from themerchant system210 via thecardholder system205 to theACS225. The cardholder authenticates her identity by presenting authentication information to the web site provided by theACS225. The central transactions server relays allcommunications276 between thecardholder system205 and theACS225. In an alternate embodiment,communications276 between the cardholder system and theACS225 occur directly without the central transaction server as an intermediary.
• In an embodiment, the cardholder authenticates her identity by providing to the ACS225 a password or other identifying information previously associated with the electronic commerce card. TheACS225 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, theACS225 matches the pseudonym received via the authentication request with the pseudonym previously created forVERes156. 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. In another embodiment, theACS225 and thecentral transaction server280 each generate their own unique pseudonym corresponding to the electronic commerce card. By allowing theACS225 to generate and use its own pseudonym to identify the electronic commerce card, theACS225 does not need to be changed to work with thecentral transaction server280.
• TheACS225 returns anauthentication response266 to thecentral transaction server280, which in turn forwards anauthentication response278 to thecardholder system205. Thecardholder system205 in turn forwards theauthentication response268 back to themerchant system210. If theauthentication information164 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 also includes an error code identifying the reason for authentication failure.
• If, for example, theACS225 does not support authentication functions, theACS225 is not operating or does not reply to thecentral transaction server280 within a predetermined period of time, or thecentral transaction server280 does not understand the VERes provided by theACS225, theACS225 cannot authenticate the electronic commerce card information. In response to an authentication failure by the ACS, for these example reasons or any other reason, an embodiment of thecentral transaction server280 can return an attempted authentication response to thecardholder system205. The attempted authentication response can authorize themerchant system210 to continue the transaction without authentication, or to halt the transaction. The action specified by the attempted authentication response can be determined by one or more business rules, for example, permitting a transaction to continue without authorization if the ACS is unavailable, but halting the transaction if the ACS returns an unintelligible VERes.
• In addition to sending the authentication response to themerchant system210, a copy of theauthentication response267 is sent from theACS225 to anauthentication history server235 via thecentral transaction server280. Theauthentication history server235 maintains an archive of all authentications performed by thesystem200.
• After receiving theauthentication response268, themerchant system210 validates the authentication response. The authentication response is digitally signed to prevent thecardholder system205 or other third party systems from tampering with the contents of the authentication response.
• To validate theauthentication response268, themerchant system210 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 the response is for the request originally submitted, the contents of the authentication response are analyzed to determine if authentication has been successful. If the authentication was not successful, themerchant system210 halts the transaction. If the authentication was successful, themerchant system210 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, themerchant system210 charges the electronic commerce card by submitting the card information to acard acquirer244. The card acquirer then sends the charge request over a privatecard association network248 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, which indicates that the electronic commerce card has been successfully verified, is included with the charge request.
• The use of a central transaction server insystem200 enables the electronic commerce card association to managed and monitored the entire authentication system easily. Additionally, if any portion of thesystem200 fails, for example, a card issuer's ACS, the central transaction server can compensate by providing appropriate responses to other portions of the system. Additionally, the centralized transaction server enables portions of the system to be upgraded without breaking compatibility with the non-upgraded portions. As all traffic between merchant and cardholder systems and the card issuer ACS systems is routed through the centralized transaction server, the centralized transaction server can translate all incoming traffic into a format compatible with the intended recipient.
• An additional advantage of the centralized transaction server is that it enables the integration of formally separate portions of the authentication system into a single unit. This integration increases reliability, decreases service overhead, and allows for streamlining of the authentication process.
• FIG. 3 illustrates an examplecard authentication system300 according to an alternate embodiment of the invention. In this embodiment, the functions of the directory server and the authentication history server have been integrated into the central transaction server and the card association network, enabling the elimination of several steps of the authentication process. As with other embodiments,cardholder system305 initiates an online purchase by accessing amerchant computer310. To complete a purchase, a cardholder uses thecardholder system305 to submit her electroniccommerce card information350 to themerchant system310.
• In response to the electroniccommerce card information350, themerchant system310 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 electroniccommerce card information350, themerchant system310 sends anauthentication request352 to thecardholder system305. The authentication request includes a pseudonym created by themerchant system310 and transaction information associated with the cardholder's prospective purchase. The pseudonym can be any type of code or number that can be uniquely linked to card information by thecentral transaction server380 at a later time.
• In an embodiment, the authentication request is sent to thecardholder system305 with a web page having a redirection command, such as an HTTP redirect, to a web site hosted by thecentral transaction server380. This web page also includes a URL for returning information to themerchant system310.
• In response the authentication request received from themerchant system310, thecardholder system305 accesses354 the web site hosted by thecentral transaction server380. In accessing this web site, thecardholder system305 supplies thecentral transaction server380 with the authentication request, including the pseudonym created by themerchant system310. Thecentral transaction server380 determines the card information from the pseudonym provided in the authentication request. The card information is then used by thecentral transaction server380 to identify theACS325 responsible for authenticating the cardholder, for example by comparing the electronic commerce card information with the electronic commerce card number ranges associated with card issuers.
• Thecentral transaction server380 sends a verifying enrollment request (VEReq)358 to theappropriate ACS325 to confirm that the ACS can authenticate the card information provided. Acopy356 of the VEReq is sent to thecard association network348 for archival. If theACS325 responds with a successful VERes, thecentral transaction server380 then facilitates the exchange ofauthentication information360 between thecardholder system305 and theACS325. Upon successful authentication, theACS325 sends anauthentication response362 to thecentral transaction server380. Thecentral transaction server380 in turns forwards acopy366 of the authentication response to thecardholder system305 and anothercopy364 of the authentication response to thecard association network348 for archival.
• Thecardholder system305 forwards a copy of theauthentication response368 back to themerchant system310. After receiving theauthentication response368, themerchant system310 validates the authentication response by verifying the digital signature associated with the authentication response to ensure that there has not been any tampering and analyzing the authentication response. If the authentication was not successful, themerchant system310 halts the transaction. If the authentication was successful, themerchant system310 can continue with the transaction by initiating a charge to the electronic commerce card provided by the cardholder. In an embodiment, themerchant system310 charges the electronic commerce card by submitting the card information to acard acquirer344. The card acquirer then sends thecharge request370 over a privatecard association network348 to be processed by the electronic commerce card issuer associated with the card.
• As the different portions of authentication system are integrated into thecentral transaction server380, additionally optimizations can be implemented. For example, in a further embodiment, thecentral transaction server380 initiates a charge to the electronic commerce card automatically when theACS325 returns a successful authentication response. In this embodiment, theacquirer344 is bypassed and thecentral transactions server380 sends the charge request directly to thecard association network348.
• 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 (31)

1. An electronic commerce card authentication system comprising:

a central transaction server adapted to:

receive an authentication request from a cardholder system;

forward the authentication request to an access control server;

relay authentication information between the access control server and the cardholder system;

receive an authentication response from the access control server; and

forward the authentication response to the cardholder system.

2. The electronic commerce card authentication system ofclaim 1, wherein the authentication response is adapted to be analyzed by a merchant system.

3. The electronic commerce card authentication system ofclaim 1, wherein the central transaction server is adapted to forward a copy of the authentication response to an authentication history server to be archived.

4. The electronic commerce card authentication system ofclaim 1, wherein the central transaction server is further adapted to receive a verifying enrollment request from a directory server, and to send a verifying enrollment response to the directory server.

5. The electronic commerce card authentication system ofclaim 4, wherein the central transaction server is adapted to send the verifying enrollment response in response to a query to the access control server.

6. The electronic commerce card authentication system ofclaim 4, wherein the central transaction server is adapted to send the verifying enrollment response to the directory server with or without querying the access control server, and is further adapted to query the access control server in response to receiving an authentication request.

7. The electronic commerce card authentication system ofclaim 1, wherein the authentication request includes a pseudonym corresponding to an electronic commerce card account number and previously created by the central transaction server.

8. The electronic commerce card authentication system ofclaim 1, wherein the authentication request includes a pseudonym previously created by a merchant system that corresponds to an electronic commerce card account number.

9. The electronic commerce card authentication system ofclaim 1, wherein the central transaction server is adapted to initiate a charge request via a card association network in response to receiving an authentication response from the access control server.

10. A method of authenticating electronic commerce card information provided by a cardholder, the method comprising:

receiving an authentication request from a cardholder system;

forwarding the authentication request to an access control server;

relaying authentication information between the access control server and the cardholder system;

receiving an authentication response from the access control server; and

forwarding the authentication response to the cardholder system.

11. The method ofclaim 10, wherein the authentication response is adapted to be analyzed by a merchant system.

12. The method ofclaim 10, further comprising forwarding a copy of the authentication response to an authentication history server to be archived.

13. The method ofclaim 10, further comprising receiving a verifying enrollment request from a directory server, and sending a verifying enrollment response to the directory server.

14. The method ofclaim 13, wherein the verifying enrollment response is sent in response to a query to the access control server.

15. The method ofclaim 13, wherein the verifying enrollment response is sent to the directory server without querying the access control server, and further comprising querying the access control server in response to receiving an authentication request.

16. The method ofclaim 10, wherein the authentication request includes a pseudonym previously created by the central transaction server that corresponds to an electronic commerce card account number.

17. The method ofclaim 10, wherein the authentication request includes a pseudonym previously created by a merchant system that corresponds to an electronic commerce card account number.

18. The method ofclaim 1, further comprising initiating a charge request via a card association network in response to receiving an authentication response from the access control server.

19. An information storage medium including a set of instruction adapted to operate an information processing device to perform a set of steps, the set of steps comprising:

receiving an authentication request from a cardholder system;

forwarding the authentication request to an access control server;

relaying authentication information between the access control server and the cardholder system;

receiving an authentication response from the access control server; and

forwarding the authentication response to the cardholder system.

20. The information storage medium ofclaim 19, wherein the authentication response is adapted to be analyzed by a merchant system.

21. The information storage medium ofclaim 19, wherein the set of steps further comprises forwarding a copy of the authentication response to an authentication history server to be archived.

22. The information storage medium ofclaim 19, wherein the set of steps further comprises receiving a verifying enrollment request from a directory server, and sending a verifying enrollment response to the directory server.

23. The information storage medium ofclaim 22, wherein the verifying enrollment response is sent in response to a query to the access control server.

24. The information storage medium ofclaim 22, wherein the verifying enrollment response is sent to the directory server without querying the access control server, and the set of steps further comprise querying the access control server in response to receiving an authentication request.

25. The information storage medium ofclaim 19, wherein the authentication request includes a pseudonym previously created by the central transaction server that corresponds to an electronic commerce card account number.

26. The information storage medium ofclaim 19, wherein the authentication request includes a pseudonym previously created by a merchant system that corresponds to an electronic commerce card account number.

27. The information storage medium ofclaim 19, wherein the set of steps further comprises initiating a charge request via a card association network in response to receiving an authentication response from the access control server.

28. The method ofclaim 14, further comprising:

receiving the verifying enrollment response from the access control server in response to the query; and

forwarding the verifying enrollment response to the directory server.

29. The method ofclaim 28, further comprising:

modifying the verifying enrollment response received from the access control server; and

forwarding the modified verifying enrollment response to the directory server.

30. The information storage medium ofclaim 22, further comprising:

receiving the verifying enrollment response from the access control server in response to the query; and

forwarding the verifying enrollment response to the directory server.

31. The information storage medium ofclaim 30, further comprising:

modifying the verifying enrollment response received from the access control server; and

forwarding the modified verifying enrollment response to the directory server.

Images