The proposed E-Commerce model is founded on a new message transmission protocol dubbed the “New Electronic Commerce Protocol” or “NECP”. NECP defines the following characteristics of the E-Commerce model:
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.
Essentially, a Shopping Cart Order message combines an order identifier, details about an order and a MAC.
At a minimum, the order identifier must include the merchant identity. If no order number is supplied, then it is created by the acquiring system, pre-incrementing the highest order number currently on record for that merchant. Similarly, if no timestamp value is supplied, it is created using the acquiring system’s clock. In this way, a merchant can use a URL on the catalog web-site to embed the entire XML document without having to dynamically generate a new XML document. The merchant thus has a quick and efficient “Buy Button” for products that do not require a full shopping cart experience. Because all other aspects of this order are static, the MAC can also be pre-generated. In this way the URL does not need to change until the product description or price changes or the merchant’s MAC key expires.
The order details element includes at a minimum, the transaction amount. It can also include the type of transaction. Available options include a purchase, a pre-authorization, a capture of a previously authorized amount, or a credit. If this field is not supplied, a “purchase” is assumed. The order details can also include optional attributes such as currency type and decimal precision. If these are not supplied, they are derived from the system or merchant defaults in the acquiring system.
A Shopping Cart Order normally includes a calculated MAC using the merchant’s current MAC key and an optional description attribute.
If the merchant has decided to opt out of generating MAC values and expressly informed the acquirer of this decision, then the MAC entity should be set to the value of “0”. Upon receiving this MAC value, the acquiring system will verify that the merchant has chosen this option from its own records of the specific merchant’s preferences.
A final issue involved in Shopping Cart Orders is the calculation of shipping or delivery options. The default configuration has the merchant calculating the shipping costs and adding it to the total cost of the bill before redirecting the customer to the acquirer. However depending on the merchant’s business practices, this could require the cardholder to enter duplicate information. For example, the cardholder might be prompted to provide their state or province twice: once to the merchant as part of the shopping cart creation process and again when entering the order fulfillment information on the acquirer’s site.
This redundancy shouldn’t be a problem for most cardholders if it kept to a minimum, however the DTD has two attributes designed to manage this redundancy. By default, “shipping_included” is set to ‘Y’ meaning that the shipping costs of fulfilling the order are included in the price. If this field is set to ‘N’, it will be expected that the order amount sent to the acquirer does not including shipping costs. These costs will then be calculated by the Cardholder Interface module based on merchant specified configurations. To aid this configuration, a “shipping_code” value is included in the DTD to supply any parametric values to pass to this calculation. Examples of these values could include total weight calculation of the order, or shipping method. This acquiring system would then use the shipping code along with the postal code or zip code of the destination address and some template configurations to calculate the shipping cost to add to the order.
A Cardholder Order is more detailed than a Shopping Cart Order. It requires a cardholder element. A cardholder element in turn requires a card and some minimum attributes of the cardholder’s identity.
At a minimum, the card entity includes the card number and the expiry date on the card. The definition also includes the ability to incorporate debit card and CVC verification as options.
Including additional information of the cardholder in the message can be used for demographic profiling and fraud detection. The question of how much cardholder data should be required is a business case question. These same arguments hold for the collection of order fulfillment attributes such as shipping addresses. Any decision would also involve legal implications for the sharing of consumer data between independent corporations.
The Cardholder Order message also includes a shopping_cart element almost identical to a Shopping Cart Order message except that in a Cardholder Order, the timestamp and order numbers are required elements. The inclusion of these requirements provides idempotency checks to ensure that a consumer did not make multiple purchases within a given transaction window because of some network error. This removes the possibility of incurring inadvertent duplicate charges.
Again, a MAC ensures that the transaction originated from the merchant and was unaltered during transmission.
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:
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.
[3] This step removes the ambiguity of what to do if the key is something like “0x00d7….” Some algorithms will truncate any leading zeros from a number regardless of its radix base, thereby rendering the number as a 15 byte key instead of 16 bytes. This step prevents such truncation.
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:
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.
[1] Hopefully, these two values will not be available to someone looking under a desktop blotter pad.
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:
Name |
Description |
Acceptable Values |
Default |
Merchant or System Value? |
---|---|---|---|---|
order_no |
An order number unique to this merchant |
Unique integer |
Next largest integer |
M |
timestamp |
The time an order is submitted to the acquirer |
YYYYMMDDHHMMSS |
Acquirer’s timestamp |
S |
trans_type |
The type of transaction being requested |
purchase, authorize, capture, credit |
purchase |
S |
description |
The description of the shopping cart contents |
Variable length string |
none |
M |
currency |
The national currency in which the transaction is denominated |
CA, US |
CA |
M |
precision |
The number of decimal places used by the denominated currency |
2, 3, 4 |
2 |
M |
uses_MAC |
Flag specifying those merchants who do not want the security of MAC authentication |
Y, N |
Y |
M |
redirect_ successURL |
The URL on the merchant’s site that the cardholder should be redirected to upon a successfully approved transaction |
URL string |
none |
M |
redirect_ failureURL |
The URL on the merchant’s site that the cardholder should be redirected to upon a failed transaction |
URL string |
none |
M |
redirect_ errorURL |
The URL on the merchant’s site that the cardholder should be redirected to upon an unexpected error |
URL string |
none |
M |
shipping_ calculation |
The algorithm/equation to use in calculating shipping costs |
Reference |
none |
M |
Links
[1] https://niedermayer.ca/user/login?destination=node/145%23comment-form
[2] https://niedermayer.ca/user/login?destination=node/146%23comment-form
[3] https://niedermayer.ca/user/login?destination=node/147%23comment-form
[4] https://niedermayer.ca/user/login?destination=node/148%23comment-form
[5] https://niedermayer.ca/user/login?destination=node/149%23comment-form
[6] http://asg.web.cmu.edu/rfc/
[7] http://www.unicode.org/charts/
[8] https://niedermayer.ca/user/login?destination=node/150%23comment-form
[9] https://niedermayer.ca/user/login?destination=node/151%23comment-form
[10] https://niedermayer.ca/user/login?destination=node/152%23comment-form