The message format of shopping cart transactions will be formatted using XML or URL encoded XML. The Data Type Definitions (DTDs) of these message formats are included in the Appendices.

There are two types of messages sent by a merchant: Shopping Cart Orders and Cardholder Orders.

Shopping Cart Orders allow the customer to fill a “shopping cart” on the merchant’s site. At checkout time, the merchant site redirects the customer to the acquirer site and passes along a summary of the shopping cart along with the order amount. Once redirected, the customer then supplies card and order fulfillment information using the acquirer’s SSL encrypted web site. With this method, the merchant does not need an SSL encrypted web-site.

In the case of a merchant that chooses the Cardholder Orders option, the locus of control for collecting cardholder information passes to the merchant. The merchant must have an SSL encrypted web-site. The merchant thus gathers the information from the cardholder and controls the customer’s entire shopping experience. The merchant then passes the transaction information along to the acquiring system using a Cardholder Order XML document.

Transaction Response Document Type Definition

The acquiring system has a number of options to provide a response back to the merchant concerning the status of an order. At least three options are envisioned: e-mail notification, an acquirer-hosted merchant authenticated web site, and a server “push” by which the acquiring system responds to a transaction by sending a response to the merchant’s server in real time.

The system as described also incorporates a wide spectrum of information already held by the merchant. In the case of a Cardholder Order transaction, the merchant only requires the response status and authorization code from the acquirer to go ahead and fulfill the order. For most Shopping Cart Order transactions, the merchant may know that an order is being made, but may have no customer or order fulfillment details. For the simplest type of transaction, that of a “Buy Button”, the merchant may not even know that an order is made until informed of a transaction by the acquirer. For these reasons, any response must be flexible concerning the information that can be returned to the merchant following complete processing of a transaction by an acquirer.

However, regardless of the method chosen, a Transaction Response XML document describes the nature and construction of the data required by the merchant. A number of the elements of this response mimic the values available in the initial transaction request: order, destination and customer elements return to the merchant the values supplied by the customer in the case of a shopping cart transaction. They are redundant for cardholder transactions but can be supplied anyway. The MAC element is calculated by the acquiring system using the symmetric key shared by the acquiring system and the merchant. This MAC should always be included in an acquirer-generated response regardless of whether the merchant system chooses to validate it or not.

At a minimum, the response element includes the status keyword of the transaction--one of captured, authorized, denied, or credited--and timestamp of the response. Any other status indicates an untrapped error. If the transaction is in some sort of approved state, it will also include an auth_code from the cardholder’s issuing system.

A response can also include a number of other attributes: a primary and secondary return code can be used to supply more information on error conditions to the merchant for problem identification. A response message can supply an English expression of the interpretation of these return codes. An optional confidence indicator could be used to identify what level of confidence can be placed on the transaction. Orders destined for high-risk countries, locales or addresses could be flagged in this way. Such a field might be a useful value-added feature for merchants, but could expose the acquirer to some liability. As such, other issues need to be considered before deciding whether to use such a field.

The specified MAC encryption function to be used with NECP is the HMAC with MD5 hashing. The specification for HMAC, authored by Krawczyk, Bellare and Canetti is found in RFC2104.[1] While HMAC describes the procedure for message authentication using a cryptographic hash function, it does not define the specific cryptographic hash function. NECP uses MD5 as its hashing algorithm because MD5 has been well researched, has benefited from successfully identified weaknesses in its predecessors (notably MD4), and has been rigorously tested and yet appears secure. It is readily available as a library function on many platforms and in many languages and results in a 16-byte hash.

One important question is whether the MD5 hashes, produced by different libraries for different languages on different platforms are consistent. Because the MAC values for NECP will be generated on one machine and then verified on another, this is an important concern. Because the hashing algorithm operates on a byte-level representation of the data to be hashed, the actual representation of the data can affect the resulting hash value. For these reasons, NECP resolves these ambiguities by invoking the following specifications:

1. The data to be encoded must be in Unicode representation.[2]  Alternatively, the resulting hash must be identical to a hash generated from the same data in Unicode representation.
2. All encryption keys will be 16 byte keys. If the first byte of an encryption key is 0, then the first byte of resulting key array will be stored as zero. If the first byte of an encryption key is less than 16 decimal (f hex), but greater than zero, then the first hexadecimal digit stored in the key’s byte array will be zero.[3]
3. All keys will be distributed as hexadecimal digits and all MACs will be represented as hexadecimal digits.

The algorithm to compute the HMAC value as specified in RFC2104 is as follows:

MD5(K XOR opad, MD5(K XOR ipad, text))

Where ipad is the byte 0x36 repeated B times and opad is the byte 0x5C repeated B times.

4. append zeros to the end of K to create a B byte string (e.g., if K is of length 20) bytes and B=64, then K will be appended with 44 zero bytes 0x00)
5. XOR (bitwise exclusive-OR) the B byte string computed in step (1) with ipad
6. append the stream of data 'text' to the B byte string resulting from step (2)
7. apply H to the stream generated in step (3)
8. XOR (bitwise exclusive-OR) the B byte string computed in step (1) with opad
9. append the H result from step (4) to the B byte string resulting from step (5)
10. apply H to the stream generated in step (6) and output the result

NECP only requires keys to generate MACs. Encryption is not a function of NECP. In the case of Shopping Cart Orders, encryption is not required. In the case of Cardholder Orders, the SSL encryption layer of the acquirer’s web server is relied upon to provide the data encryption function.

NECP uses a 16 byte symmetrically key generated by a cryptographic grade pseudo random number generator. A key of this size allows for 3.4E38 possible combinations. A brute force attack testing 1 million keys a second would still require 1.1E22 millennia to try all combinations.

The management of key generation is important to the security of the protocol. This importance is best illustrated given some hypothetical scenarios:

• A key is used to generate MACs for a merchant. This merchant is a particularly active one and a malefactor is able to sniff all transactions from the merchant to the acquirer. Given sufficient volumes and time, the malefactor is able to reverse engineer the key used to generate the MACs. Replacing MAC keys on a regular basis would mitigate this form of attack.
• An employee of the merchant’s hosting company terminates her employment. She has knowledge of the MAC generation key. She then takes this key and sets up a spoofing site to embarrass her former employer. Allowing the employer to “sunset” a current key and obtain a fresh key would foil this form of attack.
• The merchant moves its electronic storefront to a new hosting provider. The merchant wants to severe all ties with its former hosting provider. Allowing the merchant to sunset a current key and obtain a fresh key would protect the merchant.

The key generation function is supplied by the acquirer using an SSL encrypted web enabled interface. To obtain a key on behalf of a merchant, the merchant’s username and password must be supplied to the key generator.

If this is not the first key generated for the merchant, then the requester must supply some knowledge of the most recent former key, such as the first four bytes. In this way, the requester must demonstrate knowledge available only to the merchant as well as demonstrate knowledge of the merchant’s current environment.[1]

At the time of requesting a new key, the requester can also request the period to expire the previous key. If this were a routine key change, then some default period such as one week would allow for the merchant to operate using either key during this interim period. If this is a security-related change, then the current key can be expired immediately.

The new key value and its serial number along with the expiration date of the current key are stored by the acquiring system in its database. The new key’s value and serial number and a confirmation of the expiration of the old key are returned to the requester.

NECP allows considerable latitude in the content sent with a transmission. When parameters are omitted from a transmission, the acquiring system constructs these parameters from default values common to all merchants or default values specific to a particular merchant.

In addition, some configurations are not specified in the XML DTDs but are needed for the end-to-end shopping experience of the customer.

Available default values include: