Electronic commerce using a secure courier system

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to the processing of commercial transactions. More particularly, the invention relates to the secure processing of on-line commercial transactions.

2. Description of the Prior Art

A fast-growing trend on the Internet is the ordering and provision of information, goods, and services via the World Wide Web, electronic mail, and other means. A key issue for related to such electronic commerce is the authorization and satisfaction of payment for such goods and services in an efficient, reliable, and secure manner. A number of organizations have addressed this issue by establishing proprietary payment systems which vary widely in design, performance, and security features.

See, for example M. Linehan, G. Tsudik, Internet Keyed Payments Protocol (iKP), Internet-Draft <draft-tsudik-ikp-00.txt> (July 1995) (an architecture for secure payments that involves three or more participants in which a base protocol includes a number of options that can be selected to meet varying business or security requirements, for example by applying cryptographic techniques to minimize potential risks concerning payments over the open Internet).

See, also L. Stein, E. Stefferud, N. Borenstein, M. Rose, The Green Commerce Model, First Virtual Holdings, Inc., October 1994 (http://www.infohaus.com); N. Borenstein, M. Rose, The application/green-commerce MIME Content-type, First Virtual Holdings, Inc., October 1994 (http://www.infohaus.com); and Encryption and Internet Commerce, First Virtual Holdings, Inc., 1995 (http://www.infohaus.com); and First Virtual Holdings, Inc., Wired, pp. 51 (October 1995), MacWorld, pp. 114 (November 1995) (an on-line transaction clearing house in which accounts are established off-line via telephone, and in which a transaction requires an account number, where each transaction is confirmed by the clearing house via email); CyberCash, MacWorld, pp. 114 (November 1995) (an electronic payment system that uses cryptography to prevent eavesdroppers from stealing and unscrupulous merchants from overcharging); NetCheque, University of Southern California, MacWorld, pp. 114 (November 1995) (an on-line checking system in which an account holder can send an electronic document that a recipient can deposit electronically into a bank account as a check, where the document contains the name of the payer, financial institution, payer's account number, payee's name, and amount of check, and which includes a digital signature of the payer and which may include a digital signature of a payee); and DigiCash, MacWorld, pp. 114 (November 1995) (an Internet payment systems, referred to as eCash, that provides digital money without an audit trail, thereby protecting the privacy of parties to the transaction).

Additionally, electronic commerce systems have been proposed by Visa International Service Association in collaboration with Microsoft Corporation (Secure Transaction Technology, using digital signature to authenticate a credit card and merchant decal; see http://www.visa.com); and MasterCard (Secure Electronic Payment Protocol, a collection of elements including an authorized holder of a bankcard supported by an issuer and registered to perform electronic commerce, a merchant of goods, services, and/or information who accepts payment from the holder electronically, a MasterCard member financial institution that supports merchants by providing service for processing credit card based transactions, a certificate management system that provides for the creation and distribution of electronic certificates for merchants, financial institutions, and cardholders, and a network to interface the merchants, financial institutions, cardholders, and certificate management system; see http://www.mastercard.com). Payments in the real world are accomplished via such mechanisms as cash, checks, credit and debit cards, money, and postal orders. Electronic equivalents of all these payment systems are being developed. For example, iKP, ibid., addresses a subset of these mechanisms that involve direct payment transfers among accounts maintained by banks and other financial organizations. This includes credit and debit card transactions, as well as electronic check clearing, but excludes electronic cash and money orders because these require very different mechanisms. The stated goal of iKP is to enable Internet-based secure electronic payments while using the existing financial infrastructure for payment authorization and clearance. The intent is to avoid completely, or at least minimize, changes to the existing financial infrastructure outside of the Internet.

Payment systems incorporate tradeoffs among cost, timeliness, efficiency, reliability, risk management, and convenience. For example, some systems attempt to suppress fraud by inducing payment delays. Security in payment systems means minimizing risk to a level acceptable to participants. Risk management in existing systems is accomplished by varying combinations of technology, payment practices, insurance, education, laws, contracts, and enforcement. The state of the art uses cryptographic technology, such as public-key cryptography, to support payments among parties who have no preexisting relationship in a scalable manner.

Many existing cryptographic protocols, such as SSL (K. E. B. Hickman, The SSL Protocol, Internet Draft <draft-hickman-netscape-ssl-00.txt>, April 1995), SHTTP (E. Rescorla, A. Schiffman, The Secure HyperText Transfer Protocol, Internet Draft <draft-rescorla-shttp-0.txt>, December 1994), PEM (J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, RFC 1421, February 1993), MOSS (S. Crocker, N. Freed, J. Galvin, MIME Object Security Services, Internet Draft <draft-ietf-pem-mime-08.txt>, March 1995), and IPSP (R. Atkinson, Security Architecture for the Internet Protocol, Internet Draft <draft-ietf-ipsec-arch-02.txt>, May 1995), provide security functions for pairwise communication. For example, SSL provides privacy and authentication, but no non-repudiation, between clients and servers of application-layer protocols such as HTTP and FTP. Many payment systems involve three or more parties, i.e. buyer, seller, and bank. In such systems, certain types of risk can be ameliorated by sharing sensitive information only among a subset of the parties. For example, credit card fraud can be reduced by transmitting credit card account numbers between buyers and banks without revealing them to sellers.

As the Internet continues to grow, a significant portion of the economy may become inextricably interwoven with Internet-based on-line transactions. It would therefore be advantageous to provide a secure, reliable, and efficient mechanism for implementing transactions associated with on-line commerce.

SUMMARY OF THE INVENTION

A courier electronic payment system provides customers, merchants, and banks with a secure mechanism for using a public network as a platform for credit card payment services. The system governs the relationship between a Customer, Merchant, and Acquirer Gateway to perform credit card purchases over such networks as the Internet. The system uses a secure connection to simplify the problem of Internet-based financial transactions in accordance with an electronic payment protocol that secures credit card payments and certifies infrastructure that is required to enable all of the parties to participate in the electronic commerce, as well as to provide the necessary formats and interfaces between the different modules and systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of a transaction enterprise including flow diagram showing a payment processing protocol according to the invention;

FIG. 2 is a flow diagram showing a transaction according to the invention;

FIG. 3 is a flow diagram showing a capture protocol according to the invention; and

FIG. 4 is a flow diagram showing a settlement protocol according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention herein described implements a secure courier electronic payment system that provides customers, merchants, and banks with a secure mechanism for using a public network as a platform for credit card payment services. The described system governs the relationship between the Customer, Merchant, and Acquiring bank (referred to herein as the Acquirer Gateway) to perform credit card purchases securely over such networks as the Internet. The system uses a secure connection (transport) to simplify the problem of Internet-based financial transactions.

The electronic payment protocol described herein is a three-, four-, or more-way communications protocol. The primary parties are the Customer (buyer), the Merchant (seller), and the payment gateway (representing the Acquiring bank.) The issuing bank's involvement herein is assumed to be through the private networks in use by such bank today. Because such private networks are well understood in the art, the discussion herein does not address issues that are related to having the issuing bank attached to the Internet.

The protocol herein described is used to secure credit card payments and to certify infrastructure that is required to enable all of the parties to participate in the electronic commerce by using the internet, as well as to provide the necessary formats and interfaces between the different modules and systems. The system is designed to use the interactive model of the World Wide Web in common use today for client-server transactions on the Internet. However, the preferred embodiment of the invention is applicable to other delivery mechanisms, such as store-and-forward type mechanisms.

Electronic Commerce Using Credit and Debit Cards

The following discussion outlines the security issues involved in an electronic credit/debit card payment mechanism using the Internet. The security requirements can be divided into two classes:

connection (or channel) security, and

payment specific security.

Channel security can be provided by a secure transport layer (10; FIG. 1), while a higher layer electronic payment protocol (11) is needed to provide such features as signature, non-repudiation, and secondary encryption. The secondary encryption term defines encryption of certain data fields for decryption by a third party, not necessarily the recipient of the entire message. The payment protocol uses two secure channels, one channel between the customer and the merchant, and the other channel between the merchant and the acquirer or payment gateway. However, the payment specific financial messages communicated between the customer and the merchant are protected as part of the payment protocol without assumptions for a secure channel.

The protocol is designed to use an underlying secure transport layer for the following reasons:

Simplify the payment protocol because node-to-node authentication, privacy, and data integrity are automatically achieved by the transport layer. This removes the conditions of guaranteeing message integrity and privacy from the payment protocol.

Separate connection encryption, authentication, and integrity from the payment protocol provides for more flexibility in supporting future secure Internet Protocol (IP) or similar mechanisms.

The secure transport layer supports data privacy and integrity for the communications between any two nodes. This implies that two secure channels are setup, one channel between the customer and the merchant (12; FIG. 1) and the other channel between the merchant and the payment gateway (14). Also, authentication of the appropriate nodes is a function of the secure transport. In particular, the payment protocol assumes the following properties of the underlying secure transport:

Privacy

All channel communications between any two nodes in the system should be encrypted. This guards against any network snooping and does not give any information to possible attackers.

Authentication

There are two distinct forms of authentication that need to be addressed:

First, all merchants and acquirers should be authenticated to each other and to customers. Customer authentication is supported as an option.

Second, support for signature for proof of authorship and receipt for non-repudiation purposes may be necessary for some applications.

The first form of authentication can be achieved by a reliable secure transport mechanism. The second form must access the fields and values that need to be signed, and therefore should be performed in the application.

Data Integrity

Integrity is maintained at all times using a keyed message digest computation. This should be a part of the channel security mechanism. An extra layer of integrity is added to the message level using a hash of each message to avoid early termination type attacks, and to make sure that the messages arrive at the recipient unaltered.

The payment protocol, on the other hand, is concerned with payment specific issues. These issues are outlined below:

Confidentiality of the credit card number, PIN, and other customer information. These items are kept encrypted with regard to all parties, including the merchant handling the transaction.

Confidentiality of the specific order information from all parties other than the Merchant. This includes, for example the acquiring and issuing banks.

Digital signatures on the various messages communicated between the different parties to ensure authorship. It is important to point out that this is different from node authentication because, in several cases, message authorship proof is needed between two parties that are not directly communicating with each other.

Notation

K{value}=value encrypted under K using a symmetric-key algorithm.

PKx{key}=key encrypted under the Public Key (PK) for x using a public-key algorithm, where x can be C for customer, M for Merchant or A for Acquirer.

E{value}=encryption of value under a data encryption key that is encrypted under the public key of the recipient. This construction is commonly referred to as a digital envelope.

H(value)=The message digest of value using a negotiated message digest algorithm.

Cx, CERTx=The certificate of entity x.

Sx(Value)=The value combined with the digital signature of the entity x using its private key. The signature could be verified using the public key PKx from the certificate Cx. If entity x does not have a public-private key-pair, then a low grade signature can be generated using a hash of the Value with some information from x, for example a credit card number, some personal information about x, such as social security number, billing address information, or a PIN.

The protocol description herein applies to any account based payment mechanism, with an emphasis on credit cards. Thus, the basic protocol also applies to other payment methods.

Interactive Vs. Store-and-Forward Design Methodologies

The system described herein uses the advantages that an interactive environment provides to the customer and merchant. However, the basic scheme is usable for a store and forward mechanisms as well. An interactive environment, such as available using the World Wide Web, provides all parties with an immediate response that indicates the status of the messages communicated. An immediate acknowledge for the delivery of a payment message, for example, provides the customer with feedback as to the status of an order. Such facility is not available with a store-and-forward environment. It is considered important for a successful system to support state of the art mechanisms, such as the World Wide Web, because such system provides the user with an immediate feedback as to the status of the order, somewhat similar to a customer in the store payment model.

Protocol Design Requirements

The following discussion describes the requirements that the electronic payment system has to satisfy to meet the Business requirements of electronic commerce. There are different requirements for each of the entities involved. The following sections describe the requirements of the payment protocol applications. The protocol presented herein is similar to systems proposed by several other protocols from other vendors (see the discussion above), but supports a complete suite of credit/debit card transactions and uses a secure transport layer. The intention is to provide an efficient, secure protocol for processing payment transactions that is readily adopted by merchants and financial institutions.

In general, the protocol also includes an acknowledge for each message to provide the message sender with feedback as to the status of the message. Thus, the sender is expected to resend a message if an acknowledge is not received within a specified period of time.

The Customer Application (16; FIG. 1).

The customer possesses the following information:

Personal Account (Credit Card) Number (PAN), billing address information, PIN for various accounts, and any other confidential information that may be required for authorization purposes.

Name and shipping address information.

Optionally, one or more digital certificates.

A connection to a network, such as an interactive (World Wide Web for example) connection can exploit all of the features of the herein described system.

Customer Requirements

Unauthorized entities should not have any access to transactions on the wire.

The credit card information can be hidden from the merchant to prevent attacks on the Merchant's server by hackers on the Internet, as well as to prevent unauthorized charges by Merchants.

Optional receipts signed by the merchant to allow the customer to obtain proof of the transaction.

Prevention of unauthorized transactions, such as transaction replays by an attacker, modified transactions, or fake transactions.

The customer application implements all of the browsing and shopping functions, as well as generating Purchase Orders, payment information (PI), and signatures for transactions. Additional functions needed to support electronic credit card transactions are listed below:

Receive price and product information from the merchant and encrypt the transaction ID supplied from the merchant with the credit card number or other financial information. This information is made accessible to the acquirer only using the acquirer's public-key, which is extracted from the acquirer digital certificate.

Verify signatures from the merchant to ensure the origination of messages. Make sure the Order as supplied in the receipt matches the original order generated by the customer earlier.

Generate signatures on payment messages using an optional public key certificate.

The Merchant application (18; FIG. 1)

The Merchant possesses the following information:

Merchant ID number (MID) assigned by the acquirer to each Merchant. These MIDs may be globally unique or unique to a specific acquirer, depending on the implementation.

Merchant name and address.

Merchant digital certificate(s).

Name and information about the Merchant's Acquirer(s), including the Acquirer's financial certificate and information about how to communicate with the Acquirer's Gateway.

A database of all open transactions with corresponding Transaction IDs and AuthIDs with customer information.

Merchant Requirements

Efficient and automated operation of payment authorization and capture through the Internet or using existing internal capture systems.

Authenticated (signed) authorization and capture responses from the acquirer.

The Merchant's application provides all the server functions for the customers to obtain product information and pricing. It also serves as an intermediate between the customer and the acquirer. The merchant application should also include the following to allow performance of credit card transactions:

Generate a transaction ID for each customer order. The transaction IDs are generated sequentially and used only once. The transaction ID is used to track an order until it has been authorized by the acquirer.

Verify the acquirer signature on capture responses and the customer signature on receipts.

Generate receipts for customer signature optionally.

Generate digests of order information for the acquirer to verify authenticity of the purchase order.

The Acquirer (Gateway) Application (20; FIG. 1)

The Acquirer possesses the following information:

Acquirer name and address.

Acquirer digital certificate.

Names and information, including certificates, about the Merchants that are signed up with the Acquirer. This can be implemented as a database of merchants stored encrypted on the gateway machine.

A table with each merchant's current open Transaction IDs and corresponding AuthlDs tagged with each merchant's MID.

Acquirer's Requirements

Support for different methods of managing transactions, one time, recurring, and partial shipment included.

Authenticated transactions by signed-up merchants.

The acquirer application is typically an addition to a set of products that are needed to complete financial transactions over the Internet. The acquirer application performs the following functions:

Receive order amount and Transaction ID with customer financial information and perform credit card authorizations.

Receive capture requests and perform capture confirmation.

Translate a standard message format from the Merchant into the proper formats used by the existing authorization network (40; FIG. 1).

The Credit Card Based Electronic Commerce Payment Protocol

Message Definitions

This following discussion outlines and defines all the needed quantities and message components for the messages used in the payment protocol:

PAN: The personal account number for the card holder. Normally this is a credit card number.

Expiration Date: The 5 digit expiration date of the card.

Merchant ID: A unique number for each merchant assigned by the acquirer signing up the merchant. The merchant ID is unique for each acquirer, and thus includes the acquirer ID as part of it to generate a globally unique number. The acquirer ID is assigned by the card associations and is not transmitted alone as part of this system.

Transaction ID: A unique number assigned by the merchant for each transaction. The merchant and the card holder can use this number in conjunction with the merchant ID to identify any particular transaction.

Acquirer Certificate

Merchant Certificate

Total Amount

H(Order)

PIN

Billing address

Shipping Address

Resp-Code: Response code from the authentication process.

Auth-Code: A 6-digit number returned by the banking network to use for clearing/capture steps.

Icdata

CaptureResp: A response for the capture process.

Validity Period: Start and expiration dates for a message.

Date: Date and time stamp.

Digital Signature: A digital signature as defined in this document comprise the following:

The above format ensures that all signatures are fresh and dated. Providing the certificates with the signatures simplifies the exchange of the certificates.

Message Flow and Definition

The protocol described below assumes that merchants and credit card acquirers possess digital certificates. The client (customer) may possess one or more digital certificates as an option.

The protocol divides the needed operations into a set of basic protocols that are described first. The following discussion describes how each type of financial transaction is accomplished. All protocols support full privacy, authentication, non-repudiation, and integrity. The underlying Session layer provides all connection security functions, e.g. privacy, authentication, and integrity, from the channel's point of view. Any document or field (data element) level security operations are preferably performed at the application level.

The contents of each message depend on the actual operation (purchase, return, etc. . . . ) performed. Therefore, these contents are discussed under each operation section below.

The protocols outlined below start as the customer is ready to purchase some items from the merchant using a credit card. It is assumed that the customer is already finished with his shopping and has made the decision to purchase something.

The customer sends a message (19; FIG. 1) to the merchant requesting a price quote for the items of choice before the payment instruction message start.

The Date and Time fields in all the following messages are newly attached by the node creating the message. This allows the different entities to get higher assurance about the freshness of the transaction.

The Capture and settlement groups described below can replace modern methods, that use lease lines or private networks, without disrupting the protocol. This enables different acquirers to implement portions of the protocol in steps, while maintaining backwards compatibility with existing systems throughout the phase-in process. Initial implementations do not have to implement those sections.

Each Secure Courier message 19 includes two parts:

the message wrapper (30; FIG. 1), and

the message body (31; FIG. 1).

The contents of the message body of each message are described below. The message wrapper consists of the following elements:

Order Number, and

routing information.

Each of the messages below consists of two parts. The forward part is described in detail for each message, while an optional acknowledge is generated by the recipient and sent to the sender to ensure the receipt of the message. The acknowledge is a hash of the message, which actually proves the receipt by the appropriate recipient because of the use of the SSL layer that guarantees an authenticated channel. The time of receipt is concatenated to the hash and the concatenated message is used as an acknowledge.

In addition, each message is considered to be expired if it is received after the message's validity period is over.

To authenticate further the acknowledge messages, a digital signature can be used instead of a hash and the time stamp. If the original message has expired, then a denial is received instead and the sender is asked to repeat the operation.

In an authorization group (see FIG. 1) consisting of a customer C, a merchant M, and a Gateway G, a transaction (FIGS. 2 and 3) that includes the Purchase-Order, Payment Instruction (PI) message below causes the Merchant to respond with:

The Offer preferably has an expiration date beyond which the Merchant cannot guarantee the price quoted or the availability of the goods.

Due to the use of a secure transport layer, the Transaction ID (TxID) is used for book keeping purposes and optionally to prevent Merchants from replaying authorization requests. It is assumed that merchants have signed up with this service and that they are trusted to some extent. The PI value should be encrypted so that the Merchant's server, e.g. on the Internet, does not have any clear credit card numbers that can be accessed remotely.

The TxID is combined with the credit card information and encrypted in the PI message. This ensures that each message is different if the Merchant uses a unique TxID for each transaction. It may be difficult for the Gateway to track the sequence numbers for the TxIDs issued by any particular Merchant because they arrive out of sequence, in general, depending on the customer's response time to the Offer from the merchant prior to the beginning of the payment protocol. The Purchase-Order should be received by the Merchant prior to the expiration time of the Offer.

Messages can include a hash of all the message parts to add a level of integrity at the application level. This provides the recipient of a message with an extra degree of confidence that the complete unaltered message has been received. This hash can be included as part of a Secure Courier Message Wrapper that is described below.

A receipt is then issued at this stage if the authorization request was combined with a Capture operation.

The data needed by the client before the payment protocol starts are described below as part of the Offer message. These are usually communicated at the final stage of the shopping and negotiation stages.

Offer: M.fwdarw.C

SIGNM(Validity Period, Items, Payment Method, zip code or country (for shipping charges computation), Amount, Currency, Merchant ID (MID), Acquirer's certificate (CERTA), and transaction ID (TxID)).

The message is signed by the Merchant.

The Purchase-Order and the Payment Instruction messages below are sent together from the Card Holder to the Merchant.

Purchase-Order: C.fwdarw.M

Name, Validity Period, Items, Total Amount, Currency, Merchant ID (MID), transaction ID (TxID), and shipping address.

PI: C.fwdarw.M

The PI message is a signed message from the Card Holder using the Slip described below.

Slip

Version, current date, expiration date (Validity Period), Total Amount, Currency, Orderhash, MerAcqHash, Credit Card information (CardInfo).

where:

Order=Hash of the order description including any salt for minimizing attacks on the hash.

MerAcqhash=hash of the merchant ID, transaction ID and other merchant or acquirer data. This data is specific to the merchant-acquirer pair and is not needed by the buyer other than for inclusion in the PI message.

CardInfo=(Personal account number (PAN, expiration date, other optional information that may be needed by the payment processor/acquirer.

The PI is preferably sent encrypted to the Acquirer using the Acquirer's public key. In some cases, due to certain Merchant - Acquirer relationships, the PI may be sent in the clear. It is always recommended to encrypt the PI message using the following digital envelope construction.

The final message sent is formatted as follows:

where the SIGN operation is defined as above.

It may be necessary to send the PI without encryption in case of a merchant that performs the capture process independently. This is reflected in a capability field in the merchant certificate that instructs the acquirer software to send the credit card information back to the merchant. As discussed above, the data on the channel are encrypted by the secure transport, and the Merchant is the only entity that may receive the clear PI data from the acquirer. Normally, a merchant with a good history could be considered trustworthy and can obtain clear account numbers from the acquirer.

The PI can be sent in several forms using, for example the PACs #7 formats. These formats include: (unencrypted) content, encrypted, signed, enveloped, and signed and enveloped. The choice depends on the capabilities of the user and the navigator configurations. The payment gateway can decode any of these formats using the PACS handler. The recommended choice is the enveloped format described above.

Order-Inquiry: C.fwdarw.M

Date, (order number or MID, TxID), Orderhash. A hash of all previous components is added. Orderhash is the hash of the Purchase-Order and is used by the gateway to compare with the Orderhash value computed by the Merchant to verify the correctness of the Purchase-Order without actually having access to the details of the order.

This message is sent by the customer to the Merchant, at any time, to request the current status of the order. The possible responses are:

Order-Acknowledged;

Authorization-completed;

Goods-Shipped; or

Account-Billed.

These responses are communicated to the customer using the Order-Status message.

Order-Status: M.fwdarw.C

(Resp-Code, Auth-Code translated to language that the user can understand), Date, Time, (Order number or MID, TxID), Orderhash.

The Order-Status provides an acknowledge for the Order-Inquiry message. This message is implemented to provide the customer with a status on the order. Resp-Code and Auth-Code may be translated to the customer to understand the exact status of the order as listed in the Order-Inquiry above.

Auth-Request: M.fwdarw.G

SIGNM(MerchantInfo including MID, TxID, Validity Period, Total Amount, Orderhash, Auth-Capture, PI, payment method, batch sequence, optional invoice.)

Auth-Response: G.fwdarw.M

SA(Auth-Code, Date, Time, Current Amount, Orderhash, MID, TxID, optional PI for Capture through a different site). The Auth-Response also provides an acknowledge for the Auth-Request message.

Auth-Capture is a flag which is set if the Merchant is Capture the transaction at the time of authorization. Auth-Code is used as a transaction identifier for the above Order-Inquiry and Order-Status messages. The Acquirer's signature is attached in the case the Merchant needs to prove that the authentication response actually came from the Acquirer.

Receipt: M.fwdarw.C

SM (CaptureResp, Auth-Code, Validity Period, MID, TxID, amount, Order)

The receipt guarantees the Customer that the Merchant has committed to shipping the goods at the prices quoted and that the payment has been authorized by the bank. The acquirer signature is optional and depends on the particular rules set for electronic commerce.

The Receipt transaction can be implemented using a notification message, for example using an email message from the Merchant to the Customer, to retrieve the receipt information from a particular location on the Merchant's server.

Capture Group

A separate Capture transaction is necessary for the cases that require delayed time for payment from the authorization such as hotel and car rental transactions. It is also necessary when a customer's signature on a transaction receipt is required. Therefore, the protocol always assumes a separate capture transaction from the Merchant to the Gateway (see FIG. 1).

This portion of the protocol starts when the merchant is ready to ship the merchandise and/or charge the customer (see FIG. 4).

Capture-Request: M.fwdarw.G

Auth-Code, Validity Period, Orderhash, amount, MID, TxID, E(PI).

A Capture request does not suffer from a replay attack as with an authorization request because a capture request is attached to a particular AuthID that can only be exercised once.

Capture-Response: G.fwdarw.M

CaptureResp, Validity Period, Orderhash, amount, MID, TxID.

The message is signed by the acquirer as an acknowledge of the Capture-Request message.

The returned CaptureResp=-1 if unsuccessful, successful if any other value is returned.

Settlement and batch processing

It is expected that settlement may be performed in a variety of ways that may not involve the Internet. See FIGS. 1 and 5 in connection with the following.

Settlement-Request:

TotalAmount, MID, Date.

Settlement-Confirm:

SettlementCode, Action.

SettlementCode=-1 if the amount reported by the Merchant is not valid, valid otherwise. If -1 is returned, then the Merchant sends all AuthlDs with amount to the Acquirer until the difference is reconciled. Different policies may be applied by different acquirers to resolve these situations.

An Open-Batch message can be used by the Merchant to precede all Capture requests. A Close-Batch has to be sent at the end of the batch. More details on the batch processing features of Secure Courier are provided below.

Error Recovery

The following discussion addresses issues related to recovery from error conditions, generally from messages that have not been correctly delivered. Each portion of the protocol assumes that the previous sequence of messages have been completed and reached the intended recipients.

Error recovery is achieved by a two step process:

In the first step, the sender of a message repeats the message if an acknowledge is not received. There are two cases to be considered here:

if the original message was actually received then the recipient repeats sending the acknowledge,

otherwise the message is considered as new by the recipient and the appropriate action is taken.

The second step occurs when an acknowledge is not received after the message has expired. In this case, the transaction that generated the message has to be restarted.

Examples of error recovery are presented below. More details on error recovery for each of the Secure Courier message step are set forth below.

Errors in the Authorization Process

If the Auth-Response is not received by the merchant within a certain time frame, the Merchant repeats the process by sending the Auth-Request again if it has not expired yet. The Gateway responds with an Auth-Response. If the original Auth-Request was not received by the Gateway, then the message is sent to the bank. Otherwise, if this is a repeated message, only an Auth-Response is sent to the Merchant. If the original Auth-Request has expired, then the Merchant should consider the transaction invalid and should reissue the Offer with a new TxID. The same TxID should not be used more than once. A message to the gateway indicating that action may need to be sent.

Errors in the Capture Process

The same system works here as described above for the Authorization phase. If the Capture-Request message has expired and the Capture-Confirm does not reach the Merchant within a reasonable period of time, then the transaction should be considered invalid and the complete transaction sequence should be redone.

Errors in Receipt Delivery

If the Signed-Receipt message does reach the Merchant within a reasonable period of time, then another Receipt is sent. It the Receipt message has expired, then the transaction should be reversed, using another sequence of steps with a negative amount. This is only done if a receipt is mandatory according to the implementation.

Purchasing

The following discussion describes the purchasing process. Two different scenarios are possible, one for immediately delivered products and the other for delayed delivery.

Immediate Delivery of Goods

There is no differentiation here between immediate or delayed delivery to simplify the protocol. The Capture messages are separate from the Auth messages to enable the protocol to support all types of goods delivery.

The customer finishes shopping and browsing the merchant's mall, news-stand, or cyber store. A collection of items are kept in a shopping cart for price quotes. Once the customer chooses the payment option, a secure transport channel is established and the nodes exchange certificates. These certificates are made available to the payment protocol layers.

The customer sends the list of items to purchase to the merchant, including the type of payment method. The customer's application needs to specify which type of credit card is used to allow the merchant to supply the correct Acquirer's certificate. The merchant replies by sending an Offer message, including price quotes. A transaction ID sequence number is issued to the customer.

The customer's application prepares the Purchase-Order and PI messages using a credit card number. The merchant's application includes a time out mechanism to define an interval within which the customer must reply, otherwise the offer is invalid and the transaction ID may be reused. This is done to protect special prices that the merchant establishes for limited periods of time. The merchant receives the Order and E(Pi), prepares the H(Order) message, and sen