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.