|
Background: StoreFront 99, released in January of 1999, included support for AuthorizeNet 2.5 transaction processing service. The AuthorizeNet 3.0 system did not go into live distribution until September of 1999 and is not supported by StoreFront 99. StoreFront 2000 was released in July of 1999 and included support for AuthorizeNet 3.0, which was still in beta at that time. When the AuthorizeNet 3.0 system "went live" in September of 1999, there were changes in the setup and configuration that were not present at the time StoreFront originally created and tested its support for AuthorizeNet 3.0. In October of 1999 LaGarde revised its support files for connecting to AuthorizeNet and those updates have been in all versions of StoreFront since version 4.03.3.
At the time of writing this article the current version of StoreFront, version 4.03.5, includes full support for AuthorizeNet.
To support a connection to the current AuthorizeNet 3.0 transaction processing system the merchant should first select the AuthorizeNet30 from the Transaction Methods list under the Transactions tab of the StoreFront Administrator. The merchant type should be set to Normal Authorization and the Payment Server Path should point to:
https://secure.authorize.net/gateway/transact.dll
One of the most problematic issues encountered in setting up a connection to AuthorizeNet is that the service no longer supports a return path to an https location on the merchant server. A normal StoreFront configuration calls for the transaction processor to respond back to the script that invoked the transaction to report the results of the transaction. This would mean that AuthorizeNet should post its results back to the confirm.asp file which would normally reside in a secure location on the merchant web. Because AuthorizeNet doesn't support posting results back to a secure location, workarounds are necessary. The best solution is to ensure that the secure location where the StoreFront check out forms and the confirm.asp file reside can be accessed through both an http and an https call. However, many hosts do not allow http calls to secure, https, directories. You should be able to test this by making a call to http://yoursecureweblocation.com/credit.htm If the file can be loaded under the http protocol, then this would indicate that the directory supports both http and https calls. If you get an error reporting that SSL is required, this will indicate that the directory and its contents can only be accessed under the SSL, from https://.
If your secure ssl directory does not support an http call, then you will need to duplicate the ssl directory and its contents in a non-secure, non-https location such as the root web. Once a copy of the ssl folder has been created, the Merchant Settings at AuthorizeNet will need to be configured cause transactions from AuthorizeNet to post back to the non-secure copy of the ssl folder.
Login in to the Merchant Setting area at AuthorizeNet and select the Merchant Settings link. There are three screens that should be configured on the AuthorizeNet site. The first is the Payment Form\Receipt Settings link; under this area, set all the payment form fields for the General Payment and Payment AuthorizeNet to NOT require any form fields.
In the next section,' Manage URLs' the setup should resemble the example below:
Finally, in the Automated Direct Connect (ADC) Settings screen, the Delimited Response should be set to No. The other fields will not matter once the delimited response is disabled.
This is all that is required for connecting to AuthorizeNet Transaction Processing Service. The file ccerrormsg.htm will load in the case of failed transactions and should be customized for handling these cases according to your store's policies.
Note: StoreFront is compatible with AuthorizeNet as of this date using the methods outlined above. StoreFront is not responsible for providing support for any changes that AuthorizeNet may make in the future.
|
