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 Transaction Verifier also provides a number of additional functions:
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.
Cardholder Orders are similar to Shopping Cart Orders except that no HTML interface is required. The Transaction Interface accepts an XML document and parses it into the component objects belonging to a Transaction object: Cardholder, Address, and Shopping Cart. These components are then passed on to the Transaction Verifier for creation of a Transaction Object. As in the Shopping Cart Order, the Transaction Verifier checks all aspects of the order with the exception of calculateShippingCosts. In the Cardholder Order, the price passed to the acquirer is always the final price.
If the Transaction Verifier discovers an error, processing flow is passed to the Transaction Responder. The Responder then generates a Response object documenting the details of this error and then passes the Response object back to the Transaction Interface as well as reporting the error to a system administrator and/or merchant. Otherwise, processing continues with the Host Message Parser. Order processing continues as per the Shopping Cart Order model.
The Purchase Response Class diagram is indicative of a general group of class diagrams where a merchant seeks to query the acquirer’s database concerning the status of a transaction. In some cases, these queries will be for a single transaction and in other cases, the query will seek an aggregate value such as the net or gross value of all purchases processed within a given period.
In all these cases, the class structure is comparable: a merchant points a browser to an SSL encrypted URL and logs onto the acquirer system with a username (or merchant id) and password. The Merchant Interface sends this data to the Merchant Authenticator for validation and upon a successful response, sends a cookie back to the merchant’s browser with a time-limited authentication token. This token is also stored by the acquirer system. As long as the two tokens match and the token has not expired, the merchant is deemed to be authenticated for all future connections. The token is also “freshened” with a new expiry date after every HTTP exchange.
With an authenticated session, the Merchant Interface will construct a query and send it to the Datastore Interface. The Datastore Interface will then run the query against the backend database and return the results.
It is important to note that the Datastore Interface must be protected from the end-user. Without this protection, there is a danger that the end-user could run a custom query against the database returning data that does not belong to the originating merchant.
Requesting a new MAC Key involves the Merchant authenticating themselves as in the previous example. At this point, there are two possible scenarios:
Links
[1] https://niedermayer.ca/user/login?destination=node/159%23comment-form
[2] https://niedermayer.ca/user/login?destination=node/160%23comment-form
[3] https://niedermayer.ca/user/login?destination=node/161%23comment-form
[4] https://niedermayer.ca/user/login?destination=node/162%23comment-form