Shopping Cart Orders
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.