Acquirer Originated Message Formats
Transaction Response Document Type Definition
The acquiring system has a number of options to provide a response back to the merchant concerning the status of an order. At least three options are envisioned: e-mail notification, an acquirer-hosted merchant authenticated web site, and a server “push” by which the acquiring system responds to a transaction by sending a response to the merchant’s server in real time.
The system as described also incorporates a wide spectrum of information already held by the merchant. In the case of a Cardholder Order transaction, the merchant only requires the response status and authorization code from the acquirer to go ahead and fulfill the order. For most Shopping Cart Order transactions, the merchant may know that an order is being made, but may have no customer or order fulfillment details. For the simplest type of transaction, that of a “Buy Button”, the merchant may not even know that an order is made until informed of a transaction by the acquirer. For these reasons, any response must be flexible concerning the information that can be returned to the merchant following complete processing of a transaction by an acquirer.
However, regardless of the method chosen, a Transaction Response XML document describes the nature and construction of the data required by the merchant. A number of the elements of this response mimic the values available in the initial transaction request: order, destination and customer elements return to the merchant the values supplied by the customer in the case of a shopping cart transaction. They are redundant for cardholder transactions but can be supplied anyway. The MAC element is calculated by the acquiring system using the symmetric key shared by the acquiring system and the merchant. This MAC should always be included in an acquirer-generated response regardless of whether the merchant system chooses to validate it or not.
At a minimum, the response element includes the status keyword of the transaction--one of captured, authorized, denied, or credited--and timestamp of the response. Any other status indicates an untrapped error. If the transaction is in some sort of approved state, it will also include an auth_code from the cardholder’s issuing system.
A response can also include a number of other attributes: a primary and secondary return code can be used to supply more information on error conditions to the merchant for problem identification. A response message can supply an English expression of the interpretation of these return codes. An optional confidence indicator could be used to identify what level of confidence can be placed on the transaction. Orders destined for high-risk countries, locales or addresses could be flagged in this way. Such a field might be a useful value-added feature for merchants, but could expose the acquirer to some liability. As such, other issues need to be considered before deciding whether to use such a field.