Transaction authorization system

[0002] This application is a utility conversion of and claims the benefit of priority under 35 U.S.C. 119(e)(1) to U.S. provisional application serial No. 60/142,575, filed Jul. 6, 1999. The disclosure of the prior application is considered part of the disclosure of this application and is incorporated herein by reference.

[0003] The present invention relates generally to electronic commerce and more particularly to a method and apparatus for electronic transaction authorization over a network.

[0004] One problem regarding Internet e-commerce is that purchasers are generally required to provide personal and confidential information, such as charge card information and charge card billing data to an Internet merchant when purchasing goods or services from that merchant. The merchant, in turn, uses this information to obtain a transaction approval from a charge card authorization processor. The transmission of data from a purchaser's computer or terminal to the merchant Web site is generally protected by encryption.

[0005] However, once under the control of a merchant Web site, this personal data can be sold, rented, or otherwise used for commercial gain. Further, the storage and handling of this sensitive data by computer personnel at the merchant site may lead to unauthorized distribution of the data. Internet merchant sites are targets for hackers who may be able to obtain access to this data. In certain instances, accidental release of the data has been made by errors in the software programs that operate a given Web site. A purchaser who has had personal or charge card information compromised may then be the victim of unauthorized use of their charge cards or, in more severe cases, complete theft of their identity.

[0006] Another problem is the fraudulent use of charge cards. Since it is difficult to determine the identity of a remote purchaser, particularly as it relates to ownership of a given charge card, fraudulent charge card use has become popular on the Internet.

[0007] An additional problem is the use of E-mail addresses or real billing addresses obtained by a merchant during a purchase transaction. The merchant may continue to send unwanted solicitations to the purchaser long after a transaction is completed. In some cases, the abuse of the E-mail address may include sending the E-mail address to other parties, who may also send unwanted solicitations or “spam” to the purchaser.

[0008] A distributed real-time software application (referred to herein as “ZixCharge”) is provided that allows consumers to authorize transactions in a secure, private, and convenient manner for the purchase of goods and services over the Internet. The major architectural features of the ZixCharge system include a central repository of consumer data, a charge slip user interface, ZixCharge Web site application interface (hereinafter, ZAPI), a centralized approval service, a worldwide signature server and Internet shopping mall (referred to herein as “ZixMall”).

[0009] The ZixCharge system provides a central repository of consumer charge card information. Each charge card is linked to a specific E-mail address and digital signature. This information is normally provided by card issuing financial institutions and others, but can be entered under certain circumstances directly by consumers. The data is provided by a reputable source (either a card issuer or an individual each of which can be authenticated) that can irrefutably link a consumer's identity with their charge card information. The central repository is used to obtain a charge authorization without providing any personal information to the merchant.

[0010] The ZixCharge system provides a charge slip interface that allows a consumer to digitally sign for a purchase—just as the consumer would do in a retail store. The charge slip can be initiated by the merchant site, and can include the merchant logo, detailed purchase information, merchant advertising, and other information. The charge slip interface can be used by a consumer to select the payment type (if appropriate), shipping address options, and a method for merchant communications regarding the purchase. Once digitally signed, the charge slip information, including a certified time-stamp, is returned to the merchant Web site, but it cannot be opened or read there. It is fully encrypted so that only the ZixCharge central repository can read it.

[0011] The ZixCharge system includes a merchant to consumer interface, ZAPI, that resides on the merchant Web site. ZAPI provides all communication services between the merchant and the consumer during the charge slip portion of an authorization, and between the merchant and the central repository. ZAPI can be configured to offer a consumer who has failed an authorization, due to credit limits or other causes, the opportunity to select a different payment type in order to complete the transaction. After a transaction is approved, ZAPI provides the merchant with approval and shipping information. The merchant system can complete the transaction and fulfillment just as if the approval had been obtained directly by the merchant. ZAPI also ensures the transaction's validity. ZAPI combines three items, a certified time-stamp, the “hash” of the charge slip information and the returned encrypted charge slip from the consumer. ZAPI digitally signs the combination with the merchant's digital signature before sending the transaction to the central repository.

[0012] The ZixCharge system provides charge approval services at the central repository. All incoming charge slips are decrypted, validated by the previously mentioned “hash,” and authenticated by verifying the digital signatures of both the merchant and the consumer. The central repository formats an authorization message containing the required information to obtain a charge card authorization on behalf of both the consumer and the merchant and then forwards the-message to a charge card processor, normally over dedicated communication lines. Upon receiving approval, or not, for the authorization, the central repository sends the authorization information back to ZAPI at the merchant Web site. If a successful authorization has been obtained, the returned information will include any consumer authorized shipping information. E-mail communications for any transaction specific information is normally sent to the central repository and then forwarded to the consumer. This process allows the consumer to keep their respective E-mail address private. The merchant is also given a ZixCharge member ID. This enables the merchant to aggregate transactions for marketing purposes and to communicate with the consumer through the ID, but still protects the consumer's actual identity. The consumer can optionally block the forwarding of messages sent to the member ID.

[0013] The ZixCharge system utilizes a worldwide signature. server (central key server). The central key server, which can be distributed, allows the ZixCharge system to instantly authenticate both the merchant and the consumer in a transaction. The central key server further ensures that a given digital signature has not been revoked, suspended, changed or deleted. The central signature server also responds to requests for and issues certified time-stamps. The time-stamp certificate can be self-authenticated (authenticated by at least one signature whose public key is known) and is impossible to tamper with or change. This provides further authentication and validation.

[0014] The ZixCharge system can include an optional Internet shopping portal (referred to hereafter as the “ZixMall”). Merchants who accept payment, or allow other types of transaction authorizations, using the ZixCharge system, may be listed in the ZixMall. When consumers shop through the ZixMall, they are assured that the merchant respects their privacy and is willing to sell merchandise or services to them without collecting unnecessary personal information.

[0015] Aspects of the invention can include one or more of the following advantages. A distributed real-time software application (referred to herein as “ZixCharge”) is provided that allows consumers to authorize transactions in a secure, private, and convenient manner for the purchase of goods and services over the Internet. The system allows consumers to complete purchase transactions without merchants obtaining personal and charge card information from the consumer. ZixCharge transactions have three major participants: consumers, merchants and charge card issuers. Each of these participants benefits from the use of ZixCharge.

[0016] Consumers benefit by having personal and credit card information, and purchasing histories kept confidential. Because fewer Web sites have the consumer's information, there is less chance of their identities or their credit cards being used by others. Consumers also have the convenience of only having to digitally “sign” a charge slip in order to complete a purchase.

[0017] Merchants benefit by realizing a dramatic reduction in fraudulent transactions. The reduction can be attributed to the use of digital signatures on charge slips which positively identify a party to a transaction. Merchants accepting ZixCharge transactions will have access to large numbers of Internet consumers who are members of the ZixCharge system. Many of the ZixCharge members will be new to Internet shopping—in fact—shopping only because ZixCharge protects their confidential information.

[0018] Card issuers benefit in numerous ways. Using the ZixCharge system, card issuers can control the dissemination (and abuse) of cardholder information and foster brand loyalty and goodwill with consumers. These types of features can be used by card issuers to differentiate their cards from the competition allowing them to retain existing and obtain new cardholders. In addition, card issuers can re-enforce their identity with prominent logo placement (display) throughout the purchase process. Finally, card issuers can realize new revenue from ZixCharge fees. These and other advantages will be readily apparent from the description below.

[0019] FIG. 1 shows an Internet payment authorization system.

[0020] FIG. 2 shows a charge slip for use with the Internet payment authorization system.

[0021] FIG. 3 shows a method for authorizing payment for a transaction using the Internet payment authorization system.

[0022] FIG. 4 shows a more detailed view of the payment authorization system of FIG. 1.

[0023] FIG. 5 is a context diagram showing the interaction of the various major components of the payment authorization system of FIG. 1.

[0024] A number of terms are used herein to describe transaction authorization systems and related entities.

[0025] “Consumer” or “Member” refers to the role that is played by anyone who shops for goods or services from merchants and uses payment system 100 (FIG. 1) to authorize the resulting purchases.

[0026] “Merchant” refers to an organization that sells goods and/or services to members using payment system 100 (FIG. 1) or to a Web site that performs hosted computing services on behalf of a merchant in the pursuit of e-commerce.

[0027] “Affiliate” as used herein, refers to an organization that is affiliated with payment system 100 (FIG. 1). Affiliates include sponsors and merchants. “Sponsor” refers to an organization that provides member information (i.e., E-mail address and credit card information). Sponsors include card issuers. “Card issuer” refers to a bank or other organization that issues charge cards.

[0028] “Internet Service Provider” (ISP) refers to an organization that provides Internet access. An ISP can be a Sponsor.

[0029] “Authorization Processor” or “Card Processor” refers to one of the organizations used by payment system 100 (FIG. 1) to authorize card purchases. Different merchants can use different card processors (e.g., First Data Corporation). An authorization processor is an affiliate.

[0030] “Transaction” refers to an interaction or exchange between a merchant and a consumer. Typically, a transaction is conducted remotely, that is using a medium, such as the Internet, to execute the transaction. As such, the parties to the transaction must be able to be authenticated to ensure the integrity of the transaction. A transaction can include the purchase of goods or services from the merchant, and require payment by the consumer. Other types of transactions can also be authorized using the methods disclosed herein.

[0031] “Shipping address” refers to a destination for delivery of goods or services for a transaction. The delivery can be made to a home address, an E-mail address, a URL or an IP address. In some transactions, no delivery is required, and as such the designation of a shipping address may not be required.

[0032] Referring now to FIG. 1, a top-level view of a payment system 100 is shown. Payment system 100 includes secure data center 102, charge slip interface 103, authorization processor 104, merchant Web site 106, mall 108, cardholder (member) 110 and credit card issuer 112.

[0033] Payment system 100 uses a central repository of consumer charge card information stored in secure data center 102. Each charge card account is linked to a specific E-mail address. This linkage allows for use of a verifiable digital signature for transaction authorizations. The paired data (charge card data and E-mail address) is normally provided by a reputable source, such as credit card issuer 112, that can link a consumer's E-mail identity with their charge card information.

[0034] Central Repository

[0035] Secure data center 102 is operable to obtain charge authorization services without requiring a consumer to provide personal and charge card information to the requesting merchant. In one implementation, the centralized data repository is not used for any other commercial purpose. In one implementation, secure data center 102 includes a central key server 105 for use in authenticating consumers and merchants.

[0036] Charge Slip Interface

[0037] Payment system 100 uses charge slip interface 103 to allow a consumer to digitally sign for a purchase authorization, just as the consumer would do in a retail store. The charge slip interface includes a charge slip application 118 and charge slip 114. Charge slip application 118 interfaces between the merchant (i.e., ZAPI 116) and secure data center 102 in authorizing a transaction. A charge slip, i.e., charge slip 114, is displayed on a consumer's computer terminal and can be initiated by merchant Web site 106 and can include: the merchant logo, detailed purchase information, merchant advertising, and other information as shown in FIG. 2.

[0038] When a consumer visiting the merchant Web site elects payment system 100 as the selected form of authorization for a transaction, then charge slip 114 is launched. Charge slip 114 is populated with purchase detail information including a merchant transaction number. Specifically, in one implementation, as the response to the consumer's request, the merchant's web server returns specific MIME data to the member's web browser. The browser can be configured to automatically launch charge slip 114 upon the receipt of the specific MIME data type. In one implementation, the MIME data contains the public key of the merchant. In another implementation, the charge slip can be implemented as an Active X control or a plug-in and can be directly started by the member's browser. Charge slip 114 can generate a random session key and send the session key to ZAPI 116 encrypted by the merchant's public key. ZAPI 116 returns to the charge slip including transaction specific information back to the member's browser encrypted by the session key. The charge slip information is signed by the merchant's signature before being encrypted by the session key.

[0039] In one implementation, a time stamp certificate is retrieved from a central time stamp certificate authority (central key server 105) and is attached to the charge slip information before it is signed. This time stamp certificate certifies the time of signing and authenticates other data as described in greater detail in co-pending application entitled “Secure Transmission System,” to Gary Liu et. al., filed Jun. 6, 1999, the contents of which are expressly incorporated herein by reference.

[0040] Charge slip application 118 executes on the member's computer and opens charge slip 114 sent from merchant Web site 106. Charge slip application 118 decrypts the charge slip information received from the merchant Web site using the session key or other decryption means depending on the method of encryption employed by the merchant site. Once opened, charge slip application 118 retrieves valid payment type aliases and shipping address aliases from secure data center 102 for each valid E-mail address for the member. In one implementation, valid E-mail addresses are stored in a directory managed by a signature manager. These aliases can be retrieved by sending a request to secure data center 102.

[0041] Secure data center 102 returns payment type and shipping address alias information for each E-mail address based on the information that has been received from card issuer 112. In one implementation, the alias retrieval request and response can be encrypted by a secret key that is known to both the charge slip application and the secure data center. In order to make this secret key known to both the charge slip application and the secure data center, the key generation process described in co-pending application entitled “Secure Transmission System” can be slightly modified as follows. When the member generates the public/private key pair for an E-mail address, a random secret key is also generated. This secret key is saved to the corresponding key file and can be read by charge slip application 118 without requiring a signature phrase. When the public key and other information is posted to the central key server 105, as described in the co-pending application, this secret key is also posted to the key server. Since the data posted will be encrypted by the key server's public key, this secret key is never exposed to the outside world. The central key sever then saves this secret key in a database, but will not allow anyone except the secure data center to retrieve it.

[0042] During alias retrieval, when the secure data center receives the encrypted alias request for a particular E-mail address, the secure data center can retrieve the secret key associated with that E-mail address from the central key server 105. This allows the secure data center to decrypt the request and encrypt the information to be sent back to the charge slip application. In one implementation, secure data center 102 also confirms the validity of the merchant (within payment system 100) and the merchant's associated current processing status (i.e., OK, suspended, etc.).

[0043] When the aliases are returned, charge slip application 118 uses the information to populate fields of charge slip 114. Member 10 makes appropriate selections from the available choices of aliases, retrieves a time stamp, generates a digital signature and attaches the signature to the collective information. Once digitally signed, charge slip 114 (the collective information including time stamp certificate) is encrypted and returned to the merchant Web site 106, but it cannot be opened or read at merchant Web site 106. Charge slip 114 is encrypted using a public key for secure data center 102 so that only the secure data center can read it.

[0044] Charge slip 114 can include a plurality of selection boxes that can be used by member 110 to designate transaction options, e.g., a particular form of payment or delivery options. For example, charge slip 114 can include a field 115 for designating a particular payment type. Associated with each E-mail account, and stored at the secure data center 102, are member approved types of payment. Information returned from secure data center 102 can include aliases that will be used for designating the particular payment types associated with a given E-mail address. Member 110 can select from available payment options (that is, available pairs of valid E-mail addresses and payment type aliases) by selecting various different E-mail addresses using field 117. In one implementation, member 110 is allowed to enter a previously unknown payment type (and thus over-ride the payment types shown) by providing information such as charge card type, charge card number, charge card expiration date, card billing address, PIN number or other identifying data. Such information can be entered manually by typing the information into a form, or automatically entered from an existing local storage location, such as a “wallet”, using a drag and drop mechanism or other procedures. This newly entered payment information can be used only once, or can be added to the member's existing payment types stored at secure data center 102.

[0045] Secure data center 102 also can return designated shipping address aliases that can be displayed in a shipping address field 119 on charge slip 114. In one implementation, the shipping address aliases shown can be overridden and a new shipping address can be provided at the time the charge slip is presented. The newly entered shipping address(es) can be used only one time, or can be added to the member's existing shipping addresses stored at secure data center 102. In another implementation, no shipping address designation is required, for example when the transaction contemplates a direct digital download.

[0046] Once a desired payment type alias and a shipping address alias are selected, member 110 can digitally sign the charge slip information. The charge slip is signed by providing a signature phrase associated with a given E-mail address in signature phrase field 120 of the charge slip 114. The process for creating and using a signature phrase is described in greater detail in co-pending application “Secure Transmission System.” Charge slip application 118, executing at member 110, signs and then encrypts the charge slip information and returns the information to the merchant Web site 106. The process of signing the charge slip information can include retrieving a time stamp certificate from secure data center 102. In one implementation, the time stamp certificate includes merchant and recipient (analogous to sender and recipient) information and can be of the form described in greater detail in co-pending application “Secure Transmission System.”

[0047] In one implementation, the time stamp certificate is slightly different in that it can include two or more “recipients”: one recipient being the merchant and the other being the secure data center. In this case, the time stamp certificate certifies the time and content of the transaction and authenticates the status of all parties involved (the member, the merchant, and the secure data center). The time stamp certificate can be authenticated by a digital signature of the worldwide signature server (central key server 105), which in turn, can be authenticated by at least one public key hardwired into (or otherwise known by) the charge slip application 118, ZAPI 116, and secure data center 102. The use of such time stamp certificates simplifies the verification and authentication processes executed at secure data center 102 when validating authorization requests received.

[0048] The time stamp certificate is combined with the other charge slip information prior to signing. The combined data (charge slip data and time stamp certificate data) is digitally signed, encrypted by the public key of secure data center 102, and returned to ZAPI 116 at merchant Web site 106. By attaching the time stamp certificate to the signed charge slip information, the member can establish that his signature is active at the time of signing.

[0049] Merchant Charge System Interface—ZAPI

[0050] Payment system 100 includes an application (ZAPI 116) that resides on the merchant's computer and interfaces with the merchant Web site 106. ZAPI 116 provides all communication services between merchant Web site 106 and member 110 and between merchant Web site 106 and secure data center 102.

[0051] In one implementation, ZAPI 116 initiates charge slip application 118 which, in turn, presents charge slip 114. In one implementation, prior to initiation of the charge slip, a time stamp certificate is retrieved from the central key server 105. More specifically, ZAPI 116 takes a hash of certain charge slip information for the current transaction, and generates a request for a time stamp certificate from the central key server 105. The request for a time stamp certificate can include the hash. The central key server 105 can condition the return of the time stamp certificate upon the validation of the status of the requestor's (the merchant) public key, which is known to the central key server 105. The time stamp certificate, which now contains the hash submitted in the request, is returned to the requestor and then attached by ZAPI to the charge slip. The charge slip information and time stamp certificate can in turn be digitally signed by ZAPI on behalf of the merchant, encrypted, and transmitted to member 110. The certain information can include some or all of the transaction specific information, e.g., the transaction amount. Other data can be included so as to uniquely tie a time stamp certificate request, and its resultant time stamp certificate, to a specific transaction.

[0052] Following the completion of charge slip application 118 launching processes, ZAPI 116 receives a package of encrypted information (a “charge slip package”) signed (by member 110), including charge slip information and a member time stamp certificate, back from member 110. In one implementation, ZAPI 116 combines a hash of certain unencrypted charge slip information with the returned encrypted package from charge slip 114. The combination can be digitally signed by ZAPI 116 using the merchant's digital signature before sending the combined information to secure data center 102. The certain information can include some or all of the transaction specific information. In one implementation, the certain information includes at a minimum the transaction amount. The process of including a confirming hash inside the signed information, allows secure data center 102 to ensure that no tampering has occurred between the time that the charge slip information is sent by ZAPI 116 to member 110 and the time at which it was returned to ZAPI 116.

[0053] The process of signing a document, such as the combined hash and returned encrypted charge slip package, is described in greater detail in co-pending application entitled “Secure Transmission System.”

[0054] In one implementation, ZAPI 116 can retrieve an additional time stamp certificate from the central key server 105, combine the time stamp certificate with the encrypted signed charge slip information (charge slip package) and the hash and then sign the combination. The signed data can be encrypted (forming the “encrypted signed combined charge slip information” or “ZAPI package”) and sent to secure data center 102.

[0055] ZAPI 116 can allow a member who has failed an authorization, due to credit limits or other causes, to select a different payment option and then to complete the transaction. In one implementation, the member is allowed to enter all necessary charge card information required to obtain an authorization. This information typically would include charge card type, card billing information, card number, card expiration date and so on. This information can be entered directly by the member or delivered from an electronic wallet or similar software product by drag and drop or other procedures. This feature allows a member to use any charge card accepted by the merchant, even those cards that were not previously registered with payment system 100.

[0056] In one implementation, a non-member who has a valid digital signature for an E-mail address can use the system for authorization of a transaction. The non-member can have a member account created at secure data center 102 as part of the transaction authorization process and use that account information for later authorizations. For example, when a non-member selects the authorization system described herein as a payment option, charge application can prompt the non-member for information required to authorize the transaction. In one implementation, the information can be used for a one time approval of the particular transaction or can be used to create an account for the non-member. In one implementation, the member (or non-member) is required to digitally sign any entered information. In either case, the charge card information is encrypted by the public key of secure data center 102 and forwarded through ZAPI 116 to the secure data center 102 for processing. These procedures retain all of the confidentiality features enjoyed by registered members.

[0057] After a transaction is approved, ZAPI 116 provides the merchant, via merchant Web site 106, with approval, E-mail communication preferences and shipping information. In one implementation, shipping address information is provided in the E-Commerce Modeling Language or “ECML” format. If designated by the merchant, this information can be provided in an alternate format. The merchant then completes the transaction recording and fulfillment as if the transaction approval had been obtained directly by the merchant.

[0058] Throughout the authorization process, ZAPI 116 adds to an event log. Events that can be logged include “received transaction from merchant,” “sent transaction to member,” “received signed transaction from member,” “sent package to secure data center,” “received approval from secure data center,” “sent approval to merchant,” “sent approval to member,” “received verification from merchant,” and “sent completion notice to secure data center.” These log records can be indexed by transaction number, and each record may contain an abundance of additional information regarding the transaction or the status of tasks. This log is useful for recovery purposes or in a forensic analysis of a transaction.

[0059] Note that payment system 100 does not normally change the merchant's current or existing charge card processes, including the clearing and charge-back processes. Payment system 100 is an extension of those existing merchant processes.

[0060] Centralized Approval Services

[0061] Payment system 100 provides charge approval services at secure data center 102. All incoming charge slip packages are decrypted, validated by the various time stamp certificates and hashes, and authenticated by verifying the digital signatures of both the merchant and the consumer. Secure data center 102, among the other verifications, verifies that the hash of the certain defined data (added by ZAPI 116) matches a hash derived from the same certain data received as part of the encrypted charge slip package (the encrypted charge slip package that is forwarded through the merchant Web site to secure data center 102).

[0062] Secure data center 102 formats an authorization request message containing the required information to obtain a charge card authorization on behalf of both the member and the merchant and then forwards the message to the merchant's charge card authorization processor over dedicated communication lines or other communication connections. In one implementation, the message can be forwarded to an alternate authorization processor.

[0063] Upon receiving approval, or not, for the authorization, secure data center 102 sends the authorization information and other information back to ZAPI 116 at merchant Web site 106. If a successful authorization has been obtained, the returned information will include any consumer shipping address information that was authorized by member 110 when the charge slip was signed. E-mail communications for any transaction-specific information can be sent through a forwarding proxy server to the member. The merchant can also be given a special member ID for other E-mail purposes or other purposes, such as aggregating purchasing history data. In one implementation, the merchant may send E-mail to the member ID at a forwarding proxy, which then sends the message to the consumer. The consumer is optionally allowed to block the forwarding of messages sent to the member ID.

[0064] In one implementation of payment system 100, charge slip data packages can be sent directly from charge slip application 118 to secure data center 102 with any resulting approval returned to charge slip application 118. This approach then allows charge slip application 118 to present the completed authorization directly to ZAPI 116 and correspondingly, to merchant Web site 106.

[0065] If the member has entered a new payment or shipping address when signing the charge slip 114, the member can also elect to have the new information saved by payment system 100 for later use.

[0066] In one implementation, payment system 100 allows a non-member to become registered by using charge slip 114 for a first time. In this case, the information provided for payment type and shipping address can be verified by appropriate external procedures prior to sending the authorization request to authorization processor 104

[0067] The Mall

[0068] Mall 108 can be an Internet shopping portal. Merchants who accept authorizations using payment system 100 can have a link posted at mall 108. When consumers shop at mall 108, they are assured that all the mall merchants respect their privacy and are willing to sell merchandise or services to them without collecting personal information that the merchant is not entitled to have. Alternatively, member 110 may directly access a merchant Web site 106 without using mall 108. The merchant may optionally allow these direct access customers to use payment system 100 by the inclusion of a special button or other indicator that allows the consumer to choose this payment procedure. In one implementation, this option is not allowed. Mall 108 provides a convenient mechanism for collecting and presenting merchants who allow authorizations using payment system 100.

[0069] Worldwide Signature Server

[0070] Secure data center 102 can use a worldwide signature server (i.e., central key server 105) for both time stamp certificate issuance and for verifying certain digital signature key attributes. Alternatively, the signatures can be self-authenticating by attaching a time stamp certificate signed by a central key server's signature which, in turn, is authenticated by at least one public key hardwired into (or otherwise known by) the program that verifies the signature. The central key server 105 is described in greater detail in co-pending application, entitled “Secure Transmission System.” The worldwide signature server can provide instant key or E-mail address status indicators which can demonstrate if a key is active, pending, revoked, suspended, changed, deleted and so on. In one implementation, the central key server 105 is co-located with secure data center 102.

[0071] Card Issuers

[0072] Card issuer 112 generally provides credit services to consumers. Card issuer 112 can be a financial institution. Card issuer 112 functions as any conventional card issuer, making credit determinations based on the individual account holders. Card issuer 112 interfaces with member 110 and secure data center 102. Assuming credit is to be extended or has been extended to the member 110, card issuer 112 prompts member 110 for an E-mail address to associate with the account. Card issuer 112 transmits information including member's 110 E-mail address, other identifying data and card information to secure data center 102. Secure data center 102 uses the E-mail address, in part, to validate the digital signature provided by member 100 on charge slips which are normally submitted through merchant Web site 106.

[0073] In one implementation, card issuer 112 can link a member's checking or other account to payment system 100 to allow for payments to be made from the account by signing with a digital signature on charge slip 114 and without issuing physical debit or similar cards.

[0074] Alternatively, the paired information (E-mail and charge card) can be provided by an Internet service provider or others, such as a utility company.

[0075] Payment System Processes

[0076] Referring now to FIGS. 1 and 3, a payment system authorization process is shown. Card issuer 112 offers payment system 100 to a consumer, e.g., member 110 (1). Member 110 can respond via secure means, providing their E-mail address back to card issuer 112 (2). The E-mail address can be sent by secure E-mail to card issuer 112 using a secure messaging system or by other means, such as telephone call centers that have authentication abilities.

[0077] Card issuer 112 validates the E-mail and, if valid, submits charge card information for the member and the E-mail address to secure data center 102 (3). Member 110 is sent information regarding how payment system 100 operates (4).

[0078] Member 110 can visit mall 108 and link to a merchant Web site 106 that offers products or services and that accepts payment system 100 authorizations (5). Mall 108 can include a plurality of links to merchant Web sites that support payment system 100 (6). In one implementation, a plurality of malls can be included with payment system 100 compatibility. In another implementation, the member can directly traverse to a merchant Web site and select payment system 100 at that time.

[0079] At merchant Web site 106, member 110 elects various products or services and, at the time for payment, is given an option for payment choices. If member 110 elects payment system 100, then a charge slip will be launched as described above. In one implementation, the choice of payment system 100 is automatic, either through linking or by exclusivity. The charge slip information is signed by ZAPI 116 on behalf of the merchant, encrypted by the session key and then transmitted to member 110. A time stamp certificate can be retrieved and attached to the charge slip prior to signing, encrypting and transmitting to member 110.

[0080] The charge slip user interface is presented to member 110. More specifically, application 118 opens charge slip 114, retrieves payment type aliases and shipping address aliases from secure data center 102 and populates charge slip 114 with the transaction information, payment and shipping aliases. The member selects the payment, shipping and other options, and digitally signs the charge slip information (7). The digital signature can be validated by secure data center 102. Signing of a document, e.g., charge slip 114, is discussed in greater detail below. The signing process can include the retrieval of a time stamp certificate from secure data center 102. The signed charge slip (including time stamp certificate) is encrypted and returned to ZAPI 116 at merchant Web site 106.

[0081] ZAPI 116 forwards the encrypted charge slip along with other information to secure data center 102 (8). In one implementation, ZAPI 116 can combine a hash of certain unencrypted charge slip information with the returned encrypted signed charge slip information. The combination can be digitally signed by ZAPI 116 using the merchant's digital signature before sending the information (the ZAPI package) to secure data center 102. This process of combining a confirming hash in the signed information, allows the secure data center 102 to ensure that no tampering has occurred between the time that the charge slip information is sent by ZAPI 116 to member 110 and the time at which it was returned to ZAPI as a signed and encrypted charge slip.

[0082] Payment system 100 provides charge approval services at secure data center 102. All incoming charge slip packages (ZAPI packages) are decrypted, validated by the various time stamp certificates and hashes, and authenticated by verifying each digital signature of both the merchant and the consumer. Secure data center 102, among the other verifications, verifies that the hash of certain defined data (added by ZAPI 116) matches a hash derived from the same certain data fields received inside the encrypted charge slip package (the encrypted charge slip package that is forwarded through the merchant Web site to secure data center 102).

[0083] Secure data center 102 formats an authorization request message containing the required information to obtain a charge card authorization on behalf of both the purchaser and the merchant and then forwards the message to charge card authorization processor 104 over dedicated communication lines or other communication connections (9). In one implementation, the message may be forwarded to an alternate authorization processor.

[0084] Upon receiving approval (10), or not, for the authorization, secure data center 102 sends the authorization and shipping information and other information back to ZAPI 116 at merchant Web site 106 (11). If a successful authorization has been obtained, the returned information will include any consumer shipping information that was authorized by member 110 at the time the charge slip was signed. In one implementation, shipping information is provided in an E-Commerce Modeling Language or “ECML” format.

[0085] If the member has entered a new payment type or shipping address when signing the charge slip or if the member is new, the member can elect to have the new information entered into payment system 100 for later use. In one implementation, payment system 100 allows a non-member to become registered by using the charge slip 114 for the first time. The payment and shipping address may be verified by an appropriate procedure prior to sending the authorization request to authorization processor 104. ZAPI, as a final step in the process, notifies both charge slip application 118 (12) and secure data center 102 (step not shown) that the transaction has been accepted by the merchant, and in the case of charge slip application 118, provides the approval information that can then be displayed to or printed by member 110. The merchant completes the transaction recording as if the approval had been obtained directly by the merchant.

[0086] Transaction authorization information can be made available for secure on-line review by member 110 or can be sent by secure E-mail to member 110 (13).

[0087] Referring now to FIG. 4, a detailed view of the major functional components of the charge authorization portion of payment system 100 is shown. The components include accounting application 400, call center application 402, affiliate liaison application 404, management reporting application 406, server application 408, charge system information web site application 410, mall web site application 411, sponsor application(s) 412, affiliate database 414, member database 416, authorization transaction database 418, financial summary database 420, key files 421 and 422, log file 424, merchant application(s) 425, ZAPI 116, and charge slip application 118.

[0088] Accounting application 400 resides on the computers of the accountants. Accounting application 400, among other duties, computes merchant billing information and sponsor fee information and generates financial reports. In one implementation, accounting application 400 resides at secure data center 102.

[0089] Call center application 402 resides on the call center agent's computer, allowing the agent to support the members. Call center application 402 is enabled to access customer static data and securely access customer transactions. In one implementation, call center application 402 resides at secure data center 102 allowing call center agents to perform their duties (including remotely) on thin-client computers.

[0090] Affiliate liaison application 404 resides on the computer of the affiliate liaison. A liaison interfaces with affiliates. Liaisons are responsible for registering and providing support for inquiries made by affiliates. Liaisons can utilize liaison application 404 when registering affiliates and in support of affiliate inquiries. In one implementation, the registering and support functions are done online or by call center personnel. In one implementation, liaison application 404 resides at secure data center 102 allowing call center or liaison agents to perform their duties (including remotely) on thin-client computers.

[0091] Management reporting application 406 resides on the computers of the business unit managers, allowing them to exercise business oversight.

[0092] Server application 408 resides on one or more servers located at secure data center 102. Server application 408 is responsible for handling authorization requests, requesting authorization from the appropriate authorization processor 104 and sending the authorization to ZAPI 116. In one implementation, the authorization is sent directly to charge slip application 118.

[0093] Server application 408 also handles automatic communication with members including sending E-mail messages to members. Server application 408 also manages the primary databases including storing, maintaining, and querying affiliate information in affiliate database 414, member information in member database 416, transaction information in authorization transaction database 418 and financial summary information in financial summary database 420. Server application 408 can be configured to periodically generate and send member statements by secure E-mail. All internal communications sent or received by server application 408 are typically encrypted.

[0094] Charge system information web site 410 resides on a charge Web server computer and is used for advertising product features and can support member and merchant account inquiry and maintenance.

[0095] Mall application 411 resides on a Web server and is used to link members to merchant Web sites or to link members to sponsor Web sites.

[0096] Payment system 100 and its various components interface with a plurality of external data repositories. Affiliate database 414 stores information about merchants, sponsors or other affiliates. Authorization transaction database 418 stores transaction information. Financial summary database 420 stores summary financial information. Key file 421 resides on the member's computer and stores the encryption-related information, such as keys for E-mail addresses. Key file 422 resides on the merchant's computer and stores encryption-related information, such as private keys. Log file 424 resides on the merchant's computer and stores log and status entries. Member database 416 stores detailed information about members, including E-mail addresses, shipping address information, charge card information and the like.

[0097] Payment system 100 interacts, either directly or indirectly, with numerous external systems. Authorization processor 104 (FIG. 1) includes charge card authorization capabilities and software. A computer telephony interface is provided that can be of the form of commercial off-the-shelf software (call center application 402) and is used by call center agents to handle telephony issues. Merchant software (425), such as e-commerce shopping software, used by a merchant to sell goods and services to members, communicates with payment system 100. Network operations center software (not shown) allows operators to observe payment system 100 performance on a real-time basis in order to identify and handle operational problems, and to forecast future hardware and software needs. Sponsor software (412) is owned and used by a sponsor to register members and update their information.

[0098] A secure messaging service (not shown) can be used to send communications to members. In one implementation, ZixMail™, available from CustomTracks Corporation, Dallas, Tex., provides secure messaging services.

[0099] Security, such as encryption and decryption, can be implemented using the systems and methods described in co-pending application entitled “Secure Transmission System.” The engines, processes and methods described therein can be used to encrypt, decrypt, authenticate and validate messages as well as to digitally sign data and to retrieve time stamp certificates from a secure source, such as the central key server 105. Any security method, while described herein as separate, may be built directly into any component of payment system 100.

[0100] ZAPI 116 normally resides on the merchant's computer. ZAPI 116 interfaces with merchant software and is responsible for encrypting and decrypting payment system 100 internal communications. Other ZAPI 116 functions include sending and receiving information to and from charge slip application 118 and sending and receiving information to and from secure data center 102.

[0101] Charge slip application 118 resides on the member's computer and allows the member to authorize transactions, including payment transactions for goods and services. Charge slip application 118 presents charge slip 114 (FIG. 1) to the member and is responsible for validating merchant information, encrypting and decrypting internal payment system 100 communications, requesting member alias information from server application 408 and sending encrypted transaction-related information to ZAPI 116.

[0102] Referring now to FIG. 5, a context diagram is shown that provides a context for the interaction of the various components of the transaction authorization system with external actors, data repositories, and systems.

[0103] The components interact with various human roles or organizations including affiliates, sponsors, card issuers, Internet service providers, merchants, card processors, members, accountants, administrators, business unit managers, call center agents, merchant liaisons, operators, sponsor liaisons and the like.

[0104] Member Initialization

[0105] Members must establish an account with payment system 100 and download the client (member) applications, such as charge slip application 118, that are required in order to securely communicate with payment system 100. The member establishes a payment system 100 account by providing one or more E-mail addresses to a charge card issuing financial institution or others. The member is also required to create or have created a digital signature for each of the E-mail addresses using a digital signature manager. The details of the signature manager application are described in greater detail in the co-pending application “Secure Transmission System.” The digital signature manager application is used to establish one or more digital signatures for the member or merchant including storing member encryption keys in key file 421 or merchant keys in key file 422.

[0106] After a digital signature is established for an E-mail address, and the association of the E-mail address with the charge card is entered into the database of the secure data center, the member is ready to authorize transactions from a merchant Web site. The member can then identify products or services to purchase using merchant provided Web site interface software and can authorize payment using the secure payment system 100 disclosed herein.

[0107] Merchant Initialization

[0108] A merchant must obtain a merchant account and install ZAPI 116 software in order to be payment system 100-enabled. This is required prior to processing payment authorizations using payment system 100.

[0109] Member Authorization for Payments

[0110] Member 110 must authorize any payments through payment system 100. The authorization process is described below in great detail. Prior to completion of a successful transaction authorization, a number of pre-conditions are presumed to be valid. The member must have an account with payment system 100 or be able to establish one. The member typically enters a merchant Web site via mall 108 or an affiliated mall. The member has selected at least one item or service for purchase from a merchant. The merchant's public key and member's public key being used are active. The member remembers his signature pass phrase. The member has an approvable payment method that has been registered with payment system 100. All required computers, external services and systems are available.

[0111] Referring again to FIGS. 4 and 5, the authorization process begins when the member requests purchase authorization by payment system 100 (1). Typically this occurs when a member selects a check out payment option at the merchant site that indicates payment system 100 as part of the check out procedure. The merchant software then requests a purchase authorization from ZAPI 116 (2). In one implementation, the merchant software sends a message to ZAPI 116 containing merchant information (including data such as the merchant ID code, the merchant's transaction number, date, time, Web site URL, the referring mall identifier, optional promotional logo, and the merchant's approved payment methods) and transaction information-(including optional tagged text, the authorization amount and the location for the charge slip on member's screen). In one implementation, some or all of the merchant information may already reside within ZAPI 116.

[0112] Upon receipt of the request, ZAPI 116 reads the merchant's key file 422 (3). Thereafter, ZAPI 116 retrieves a merchant's time stamp certificate from the central key server 105 (4). The retrieval request can include the merchant's public key (or hash thereof) and certain purchase information. In one implementation, the merchant software also initiates charge slip application 118 on the member's computer (5). In one implementation, the charge slip is launched by sending the merchant's public key as a specific MIME data type to the member's web browser. In another implementation, the charge slip can be implemented as an ActiveX control or a plug-in and can be directly started by the browser.

[0113] Charge slip application 118 generates a session key and sends it encrypted by the public key of the merchant to ZAPI (6). ZAPI 116 digitally signs the combined purchase information and the time stamp certificate. ZAPI 116, using the session key, symmetrically encrypts the combined and signed data and forwards it to charge slip application 118 to obtain a member 110 approval (8).

[0114] Charge slip application 118 decrypts the merchant's encrypted package using the session key. Charge slip application 118 validates the merchant signature as that signature relates to the information sent. Thereafter, charge slip application 118 generally notifies the member that a charge slip is opening (12). In one implementation, charge slip application 118 displays a dialog box that includes a message similar to “Creating Charge Slip” to the member. Charge slip application 118 reads key files 421 (13). More specifically charge slip application 118 retrieves signature information from key files 421. Each key file 421 includes, among other data (some of which is encrypted by a symmetric key associated with the signature phrase), an E-mail address and an associated encryption keys (private key, public key, and a secret key shared between the member and the central key server 105).

[0115] Charge slip application 118 creates and encrypts a member and merchant information request. This encrypted request is ultimately forwarded to server application 408 as will be described in greater detail below. In one implementation, the request is symmetrically encrypted using the secret key shared between the member and the central key server 105 as described above. In one implementation, the encrypted data includes the hash of the member's E-mail address(es), the hash(es) of the corresponding member and merchant public key(s), the merchant ID code, the merchant's transaction number and a mall identifier. Charge slip application 118 sends the encrypted member and merchant information request to server application 408 (15).

[0116] Server application 408 first retrieves the secret key for the corresponding E-mail address from the central key server 105 and uses it to decrypt the member and merchant information request. In one implementation, each E-mail address has its own secret key used for encryption. Upon validation of the decrypted data. (if necessary), server application 408 queries member database 416 for payment type aliases and shipping address aliases (17). Server application 408 also queries affiliate database 414, using the merchant ID code to obtain the merchant's name and other information.(18).

[0117] Server application 408 logs an initial record in authorization transaction database 418 (19). In one implementation, server application 408 logs a unique transaction number, the merchant's code, the merchant's transaction number, the mall identifier, certain hash data and date and time information (local server date and time).

[0118] Server application 408 gathers the information retrieved from the queries and creates and encrypts a member and merchant information response using the same secret key or keys that it uses to decrypt the request. In one implementation, the member and merchant response information includes, all available payment type aliases, shipping address aliases, the unique transaction sequence number from the authorization transaction database 418, the merchant name (and other information) and certain merchant status flags. Finally, server application 408 sends the encrypted member and merchant response information to charge slip application 118 (21).

[0119] Charge slip application 118 decrypts, using the same secret keys, the member and merchant response information and populates the charge slip with the returned data. Charge slip application 118 thereafter displays charge slip 114 to the member (23). In one implementation, charge slip 114 includes a header information area, a transaction information area, a member options area and a signature area. The header information area can include the date, the time, the merchant's transaction number, Web site URL, a promotional logo and text (rendered) (e.g., see FIG. 2). The transaction information area can include text detailing the transaction and promotional information from the merchant. The member options area can include the choice of signature E-mail addresses, payment type aliases (those that match the merchant's approved payment methods), shipping addresses and E-mail communication method. The signature area can include the authorization amount, a displayed logo for the branded signature vendor, a text-type box in which to type the required signature pass phrase, an “authorize” button and a “cancel” button. In one implementation, a promotional area for sponsors can be included.

[0120] The member selects an E-mail address from the available choices displayed on charge slip 114 (24). The available E-mail addresses correspond to particular member accounts that have been registered with the payment system and which have digital signatures on the member computer. The selection is validated by entering the signature pass phrase associated with the E-mail address as is described in greater detail below.

[0121] Charge slip application 114 responds by displaying the associated payment type aliases and shipping address aliases for the selected E-mail signature (25). The member completes the charge slip by selecting a payment type alias and a shipping address alias, typing the correct signature pass phrase and clicking on the authorization button (26). Charge slip application 118 notifies the member that it is awaiting authorization by displaying a message similar to “Authorizing—Please Wait” (27).

[0122] As part of the authorization process, charge slip application 118 obtains a time stamp certificate from central key server 105 (28). In one implementation, the time stamp certificate is self-authenticating and verifies the merchant's key status and the member's key status at the time the member authorized the transaction (by signing and clicking the authorize button). The time stamp certificate can include a hash of certain charge slip information and can have additional merchant validation information as well. A slightly modified time stamp certificate that allows multiple “recipients” can authenticate all parties involved in the transaction, as described above.

[0123] Charge slip application 118 combines the charge slip data and the time stamp certificate and then digitally signs the combination. Charge slip application 118 then encrypts the combined data and sends it to ZAPI 116 (30). In one implementation, the purchase authorization request is encrypted with the public key of the secure data center charge server 408 (the server executing server application 408).

[0124] When ZAPI 116 receives the encrypted package from charge slip application 118, it combines confirming information (such as a hash of certain data) with the package and then digitally signs the combination. ZAPI 116 encrypts the combined data and sends the package to server application 408 (34). The package can be encrypted either with public key encryption (using the public key of charge server 408) or with a symmetric key encryption (using a key known to both charge server 408 and ZAPI 116). This shared key may be established and periodically re-established using any key exchange protocol.

[0125] Server application 408 decrypts the data package and verifies all signatures and time stamp certificates to ensure data authenticity and consistency. If necessary, server application 408 queries member database 416 for payment card and other information (35). The information retrieved normally includes the actual charge card information, such as card number, expiration date, PIN (if available), billing address data and shipping address data. Server application 408 logs the updated transaction in authorization transaction database 418 (36). More specifically, server application 408 updates the partial transaction including the server date and time, the member's E-mail address, the member's card number and card expiration date (and PIN, if applicable), the selected shipping address, the authorization amount and E-mail communication method selection. Server application 408 also queries the affiliate database for an approval processor associated with the given merchant or card type (37). In one implementation, server application 408 sends a query to affiliate database 414 that includes the merchant code and the payment card type. The affiliate database 414 response includes the appropriate card processor identifier, the leased line or other communication method to the authorization processor and the appropriate transaction number to use during approval processing.

[0126] Server application 408 requests purchase authorization from the identified gateway (38). More specifically, server application 408 sends a request that includes the merchant identifier, the assigned transaction number, the name of the member, the card number, the expiration date, the billing address and the total charge. The gateway (authorization processor 104 of FIG. 1) notifies server application 408 that the purchase was authorized, or not (39). More specifically, the gateway sends a response to server application 408 that includes the transaction number and the approval code.

[0127] Server application 408 creates a member ID that will be returned to ZAPI 116 (and then to the merchant) along with the approval code and shipping address information. This member ID code may be used by the merchant to track purchasing history for each member without actually knowing the identity of the member. In one implementation, the member ID is created by applying a one-way of two-way hash function to data that includes the member account number and the merchant account number. This type of system can be used to produce the same member ID for each merchant, but will always yield a different ID for any other merchant. In this way, colluding merchants cannot aggregate a member's activities from multiple Web sites.

[0128] Server application 408 logs the additional transaction information, including tagged text and the approval code, in the authorization transaction database 418 (41). Server application 408 thereafter creates a data package to return to ZAPI 116. In one implementation, this data package includes the merchant transaction number, the shipping address, the approval code, the approval amount, the transaction number and a modified/encrypted (if appropriate) credit card number (for reconciliation/confirmation processing by merchant). Server application 408 optionally digitally signs and then encrypts the data package using the pre-established symmetric key. Server application 408 then sends the encrypted package to ZAPI 116 (44).

[0129] ZAPI 116 decrypts the package. ZAPI 116 validates the package as having been sent by server application 408 (charge server). ZAPI 116 then notifies merchant software 116 that the purchase was authorized (45). In one implementation, ZAPI 116 sends a message to merchant software 116 that includes the merchant transaction number, the shipping address (optionally in ECML format), member ID, E-mail communication information, the authorization code and the authorization amount. ZAPI 116, following the notification of merchant software 116 of the completed transaction approval, sends a message to server application 408 (46) to indicate that the merchant was successfully notified of the approval. This message can include such information as the transaction number and member ID and can be encrypted using the same procedures as used in previous ZAPI 116 to server application 408 communications. Server application 408 then finalizes the transaction record in authorization transaction database 418 (47) and marks the record as completed. Failing to complete this step would open inconsistencies in records between the merchant and authorization processor 104, which in turn, would lead to difficulties in reconciliation procedures between the parties. Again, the communication between ZAPI and the charge server can be encrypted by the pre-established symmetric key.

[0130] ZAPI 116 then generates and encrypts a display authorization message that is to be sent to charge slip application 118. The display authorization message can include the authorization code and the URL of the next window in the merchant's Web site. ZAPI 116 sends the message to charge slip application 118, encrypted by the session key between ZAPI and the charge slip application (49).

[0131] Charge slip application 118 decrypts the display authorization message. Charge slip application 118 notifies the member that the purchase was authorized (50). More specifically, charge slip application 118 displays a notification to the member that can include an authorization text message, the authorization code, an exit button and a print button. The member can depress the print button (51), resulting in the printing of a charge slip image for the member. The member can thereafter depress the exit button (52) and the transaction is complete.

[0132] Charge slip application 118 closes charge slip 114 ending the session and forwards the member to the merchant's next URL (if any) (by either direct the current web browser window to the new URL or open a new browser window with the new URL)(53). If all of the steps complete, the following post conditions are guaranteed: 1) the transaction is authorized; 2) the complete transaction is stored in transaction authorization database 418; 3) the merchant is notified of the approval; and, 4) the member is forwarded to the merchant-designated next URL.

[0133] The process described in relation to FIG. 5 is success oriented. If at any point in time a fault or error condition arises, the transaction can be halted. In general, faults can arise when any of the indicated steps can not be properly completed. When a fault arises, one or more remedial steps can be performed or the transaction can be terminated. If the transaction is terminated, the merchant and member can be notified. As described above, if the member has insufficient credit to make the purchase (or otherwise fails authorization based on the authorization reply), ZAPI 116 can request that charge slip application 118 allow the member to make another selection from the remaining available payment type aliases (if any) and then to attempt to complete the transaction anew.

[0134] While this invention has been described in terms of several preferred implementations, it is contemplated that alterations, modifications and permutations thereof will become apparent to those skilled in the art upon a reading of the specification and study of the drawings. For example, the system can be used to provide any form of transaction authorization, regardless of whether specific payments or other monetary transfers are implied. Payment system 100 can be used for authorization of payments from pre-paid balance accounts or for authorizations to accounts that will be billed to, or charged to, a consumer at a later time. In addition, while a system has been described where ZAPI sends charge authorization requests to the server application, the request can be directly sent to the server application by the charge slip application. The authorization response then can be sent back to the charge slip application and the charge slip application can then notify the merchant through ZAPI that the transaction is approved or denied. Furthermore, certain terminology has been used for the purposes of descriptive clarity, and should not be construed to limit the invention.