The Make Shopping Cart Use Case sees the merchant web site redirect the customer’s browser to the acquirer’s web site. The acquirer’s web site uses a Cardholder Interface to display a form requesting the customer to supply cardholder and order fulfillment information. In order to display this information, the Cardholder Interface must parse the embedded XML document to extract the merchant identity, and order details. This data is used to populate the interface screens presented to the user from information provided in the Merchant Configuration database.
Once all required information is obtained from the cardholder, a transaction is created and handed off to the Transaction Verifier. The Transaction Verifier checks that all data supplied are valid and that any missing information can be obtained from the Merchant Configuration database. At this point, two types of errors can be generated: those that originated with the cardholder, and those that originated with the merchant. If the former is the case, the Cardholder Interface can request the customer to correct the supplied data and the transaction can be reprocessed during this session. In the latter case, the error is not recoverable during the current session; the customer must create a new shopping cart on the merchant system before proceeding. In either case, the error is reported back to the Cardholder Interface for display to the cardholder. An additional error report may be generated for the merchant or system administrator. If there is no error, then the completed and verified Transaction object is handed off to the Host Message Parser. A reference to the Transaction object is also handed to the Transaction Recorder for insertion into the database.
The Host Message Parser provides encapsulation of host messaging details. In this way, the acquiring system can reroute transactions to different host systems depending on predefined criteria. The Host Message Parser obtains message metadata from the Host Configuration database and then constructs a Host message from the supplied Transaction object. The resulting Host Message is then sent to the appropriate Host Connector for transmission to the host system.
The Host Connector sends a transaction to the host and awaits the response from the host. In the event of a failure of the host system to send a response within a predefined timeout setting, an error will be generated, recorded in the system database, and sent to a system administrator. Upon a successful response, the Host Connector constructs a new Host Message containing this response and returns this new Host Message to the Host Message Parser.
The Host Message Parser receives the Host Message and constructs a TransactionResponse object using metadata from the Host Configuration database. This TransactionResponse is handed to the Transaction Recorder for inclusion in the archival database. A reference of the TransactionResponse is then handed off to the Transaction Responder.
The Transaction Responder parses the appropriate information from the TransactionResponse and sends this to the Cardholder Interface. The Cardholder Interface uses this information along with the initial Transaction object to construct a return screen for the cardholder’s web browser reporting the final status of the order and supplying the final sales invoice, merchant contact information, and order confirmation data. The Transaction Responder also consults with the Merchant Configuration database and e-mails the order details to the merchant and/or pushes the transaction object back to a merchant defined URL using XML.
A cardholder order is a much simpler sequence because no interaction with the cardholder is required. Instead, the merchant is responsible for gathering all this information and passing it directly to a URL directly tied to the Transaction Verifier. The Transaction Verifier then does initial processing of the order to ensure that all required data is present and then performs some preliminary data validation. For example, it checks that the card number is a correctly formed number with a valid expiry date. Missing information is obtained from the Merchant Configuration database. If required information is still missing or any error is detected, program flow passes to the Transaction Responder, which creates a Response object documenting the error. This object is then used to return an XML message back to the merchant over the HTTP connection that initially sent the transaction.
If no error is generated, the transaction processing then proceeds as in a Shopping Cart Order use case. The exception is that no response to the user is required and the merchant response can be sent back over the same HTTP connection that initiated the transaction in the first place.
The Purchase Response sequence is a web interface for merchants. After authenticating the merchant identity, it provides an application middle-tier to effect backend database calls on the merchant’s transactions.
The Request MAC Key sequence allows the merchant to request a new key for computing MAC values. Required inputs are the merchant id, the merchant passphrase and the value of the current MAC Key against which to issue a renewal. Merchants can request a renewal at any time such as when an employee with access to the current key terminates their employment with the merchant. Because the information used in order transactions is very structured and highly predictable, it is expected that MAC keys will naturally expire within a predefined time interval. At most, keys should expire from one year of their issue. A better practice would have them expire at least every six months. Merchants generating a high volume of traffic might benefit from the security of having keys expire every three months.
When a new key is requested, the request is matched against the known merchant values of merchant id, passphrase and current key value. If this authentication is successful, then a new cryptographically strong randomly generated key is issued to the merchant over a secure web connection. This key is a four byte key with a specified sequential serial number. Upon request, the key is returned to the merchant over the secure web connection as a hexadecimal value and simultaneously stored within the merchant configuration database.
The sequence diagrams for the Process Recurring Transaction, Process Credit, Process Capture, and Process Authorization are identical to the Make Cardholder Order sequence diagram. The determination of which extension to use will be flagged in the XML document sent to the Transaction Verifier. A Make Shopping Cart Order always uses the Process Capture extension.
Links
[1] https://niedermayer.ca/user/login?destination=node/154%23comment-form
[2] https://niedermayer.ca/user/login?destination=node/155%23comment-form
[3] https://niedermayer.ca/user/login?destination=node/156%23comment-form
[4] https://niedermayer.ca/user/login?destination=node/157%23comment-form
[5] https://niedermayer.ca/user/login?destination=node/158%23comment-form