Shopping Cart Order Class Diagram
In the Shopping Cart Order Use case, a great deal of effort is expended on gathering and verifying data. The information-gathering task is centered in the Cardholder Interface. This module is responsible for catching the Shopping Cart Order XML document and then querying the customer for their card and order fulfillment information. This information is then used to construct a Transaction object, which is in turn a composite of ShoppingCart, Address, and Cardholder objects. The Transaction object is then passed to the Transaction Verifier. If the Transaction Verifier reports an error back to the Cardholder Interface, the Interface must determine if this is an error correctable by the cardholder (such as a bad card number) or an unrecoverable error (such as an invalid MAC). In either case, a message should be displayed to the cardholder with possibly a new form to correct any missing or inaccurate cardholder information. If the error is merchant-generated, then it must be reported to the system for referral to the merchant’s technical personnel. For this reason, merchant-generated errors cause program flow to be routed immediately to the Transaction Responder. The Responder creates a Response object identifying the type of error and reports this error to the system administrator and/or merchant.
The Transaction Verifier is responsible for verifying that all the required information is present. Any missing information must be supplied by the Merchant Configuration settings or an error will result. The Transaction Verifier also ensures that the MAC is valid for the XML document supplied. Validating the MAC involves a number of tests:
The MAC must be validated against the specified merchant’s key.
The MAC must be verified to be using the current key.
If the MAC is not using the current key, then it must be verified to be using a key that has not yet expired.
The Transaction Verifier also provides a number of additional functions:
It verifies the Cardholder information. This could involve the mundane tasks of ensuring that the expiry date has not passed and the card number has a valid check digit. It could also involve some address verification procedures or fraud assessment. These latter two functions would most likely be passed to another module for processing.
It can calculate the shipping value and add this to the total value of the order if the merchant has opted to request the acquirer to perform this function.
If the Transaction Verifier detects no error, it passes the Transaction object on to the Host Message Parser. The Host Message Parser determines where the transaction is to be sent for back-end acquiring. It then uses a table of translation values to translate the required elements from the Transaction object into the host-specific string for the type of transaction to be processed.
The Host Message Parser then opens a connection to the specific host and sends the transaction string, then waits for a response. Upon receiving a response, it parses the response string into a Response object and passes this object to the Transaction Responder for further processing. Both the transaction and the response are logged to a database.
The Transaction Responder creates a Transaction Response XML document and calculates a MAC for this document using the merchant’s key. The Response object is optionally constructed into an e-mail document and delivered to the merchant and/or pushed to the merchant’s server. The Response object is also returned to the Cardholder Interface so that a web page can be constructed for the cardholder informing them of the status of their order.