Configuring Zencart for The Gateway using the Emulator

1)            With a working install of Zencart, enabled the Authorize.net (AIM) payment module. There are 4 settings in the module configuration that will be relevant to enabling traffic to the emulator

a.    Enable Authorize.Net (AIM) Module: Enables/disables the module in Zencart. This must be True for the module to work.

b.    Login ID: This will be a username (must be an API user) in The Gateway.

c.     Transaction Key: This is the password for the user entered in the Login ID field.

d.    MD5 Hash: This can be a value of the user’s choice, but it must match exactly (case-sensitive) the value entered in The Gateway (see below).

 

2)            Create an emulator in The Gateway that will be used for this integration. Save the values on the first screen, this will enable the fields tab.

a.    Method: Authorize.net AIM for Zencart uses Post

b.    Description: Any value recognizable to the user

c.     Source IP: An advanced option, allowing The Gateway to determine which Emulator profile to load based on the client IP address, as opposed to supplying an Emulator ID in the request

d.    Hash value: This corresponds to the Hash Value entered in the Authorize.net (AIM) payment module.

 

 

3)            Load the Authorize.net (Zencart) template. This will create a number of pre-mapped request and response fields needed to match the Authorize.net response and request to the The Gateway request and response.

 

4)            The Authorize.net AIM spec has several features which, although optional to Authorize.net, are required by Zencart.

a.            MD5 hash in the response: Authorize.net supports a hash of a pre-defined hash value, username, transaction id and amount returned in the response. Zencart will calculate this value and expect a match in the response from the The Gateway emulator. This is accomplished via the Field Formula in the Advanced Options of the Response field. As the screenshot below shows, the fields HashValue, Username, Transaction ID and Amount are included in a call to a MD5 function (all surrounded in parenthesis). Each value enclosed in square brackets is intended to be replaced with the actual value from that field. For example, [HashValue] will be replaced with the value specified in the previous steps (abcd in this example). This allows the return value of a given field to be dynamic, depending on the actual request and response values of a given transaction.

 

b.            Amount in the response:  Similar to MD5 this value depends on a FieldFormula, but it is very simple. This formula will simply be replaced with the Amount value passed in the request. No other modifications will be made.

 

 

5)            Finally, several of the Authorize.net fields do not have a direct value conversion to The Gateway. For example, an approval on The Gateway will have a Result Code of 0. On Authorize.net, an approval will have a Response Code of 1. It is not enough to simply map the Result Code of The Gateway to the Response Code of Authorize.net – 0 has no meaning for this field on Authorize.net. In addition to mapping the field, The Gateway’s Emulator will also use a Value Map to properly handle this field (found under Advanced properties of a field mapping)

 

This particular map will convert a result of 0 from The Gateway to a 1 for Authorize.net. Additionally, it will convert a value of 12 (decline) from The Gateway to a 2 for Authorize.net. Additional value maps can be added as needed.

Value Maps are also important for the Transaction Type field in the request. Similar to the Response Code, the conversion is not straight across.

 

These values are preloaded with the Authorize.net template.