Help: eProcessing Network Questions - Using Authorize.net AIM Module

[spidercreations]

I did get it to work, but I'm not sure if there is something that I have missed - that could cause a security issue so this needs to be checked and I'd appreciate it if someone would provide me a "yes that will work" or "no, don't do that" answer.

Here was my process...

Testing

• Installed a second implementation of Zen Cart at a new URL, but installed version 1.3.7.1, not the new 1.3.8a version
• Went into /includes/modules/payment and updated line 380 of authorizenet_aim.php to reference the following URL - https://www.eprocessingnetwork.com/cgi-bin/an/order.pl - instead of the authorizenet URL.
• Accessed the admin section of Zen Cart, went to Modules > Payment and updated the Authorize.net (AIM) payment module to include the correct Login ID and Transaction Key (used the Restrict Key).

Note: At this point it was clear the options in the right sidebar for the Authorize.net (AIM) payment module for version 1.3.7.1 of Zen Cart was quite different than 1.3.8a. As an example, there was no HASH5 reference.

• I created a test product and was able to successfully get an authorization. I did not get the "Your credit card could not be authorized for this reason. Please correct the information and try again or contact us for further assistance." error.

Work Around for 1.3.8a

• I took the authorizenet_aim.php file that was used in the 1.3.7.1 version of Zen Cart (the old version I modified above) and used that file to replace the new file that is in Zen Cart 1.3.8a. Processing worked correctly.

Questions

• Is what I did OK to do?
• I think there are other authorizenet PHP files in other folders. Should those also be used to replace their 1.3.8a versions?

Cheers

[DrByte]

Using the older version simply loses all the bugfixes and improvements offered in the newer version.
I think what you're doing is overkill.
All you needed to do was change the URL and comment out the hash-protection logic, and maybe change the field delimiters.

[spidercreations]

Using the older version simply loses all the bugfixes and improvements offered in the newer version.
I think what you're doing is overkill.
All you needed to do was change the URL and comment out the hash-protection logic, and maybe change the field delimiters.

I changed the URL and spent quite a bit of time with eProcessing Network trying to get it to work. They said they were noting a "slight" trend and asked if I could try the previous version.

What it comes down to is that it was not working by just changing the URL. It's working now. I am concerned primarily about security.

Can you provide information on how to comment out the hash-protection logic (which lines where) and change field delimiters? I'm not familiar how to do that.

I'm willing to work on this - and as noted - document my solutions and process.

[DrByte]

Turning off the hash-evaluation: http://www.zen-cart.com/forum/showpo...93&postcount=6

Delimiter: http://www.zen-cart.com/forum/showpo...73&postcount=2

[merclord]

I am using zencart 1.3.8a and I am having a similar problem with the eProcessingNetwork module. My Host control panel gives me the option to switch between PHP 4 and 5. Whenever I try to use PHP version 5, the module always gives an error msg and returns me to Step 2 of the checkout. I always get the same error message that only appears in the URL:

https:// x-cream.net/index.php?main_page=checkout_payment&payment_error=eProcessingNetwork&error=The+ credit+card+number+starting+with++was+not+entered+correctly%2C+or+we+do+not+acce pt+that+kind+of+card.+Please+try+again+or+use+another+credit+card.

I don't think the transaction is ever leaving zencart. I believe that the actual values of the form are being lost somewhere, but I can't figure out where. If you look closely at the URL you will notice that the actual credit card number is missing.

There are few PHP options that I can change in my control panel but I'm not a Unix person so I have no idea what I'm doing. All I know for sure is that when I switch to PHP 4 it works fine. I also know that it can work fine with PHP 5 because my old host server is running PHP 5 and it works. This has something to do with the PHP 5 configuration on my new host server. But I'm clueless. Please help!

Oh, and the reason I need PHP 5 is because I've installed an affilate program that won't work on PHP 4.

[merclord]

I solved my own problem! It turns out that there was a setting in my php.ini file that was causing all the trouble. Set

register_long_arrays = On

By default my host server had this configured to be Off. This was preventing any of the values from the variables in the eProcessingNetwork module to submitted when moving from Step 2 to Step 3. This was generating an error and causing the script to simply return to Step 2. I did not have this problem when I configured my apache control panel to php 4. But I need to use other applications that require php 5. My guess is that this is not something that can be configured in PHP 4.

I think this might help a few people trying to use the official eProcessingNetwork module v1.01.
BTW: I am running zencart 1.3.8a

[DrByte]

I solved my own problem! It turns out that there was a setting in my php.ini file that was causing all the trouble. Set

register_long_arrays = On

By default my host server had this configured to be Off. This was preventing any of the values from the variables in the eProcessingNetwork module to submitted when moving from Step 2 to Step 3. This was generating an error and causing the script to simply return to Step 2. I did not have this problem when I configured my apache control panel to php 4. But I need to use other applications that require php 5. My guess is that this is not something that can be configured in PHP 4.

I think this might help a few people trying to use the official eProcessingNetwork module v1.01.
BTW: I am running zencart 1.3.8a

Okay, so that means that your module is using the $HTTP_GET_VARS and/or $HTT_POST_VARS array variables for handling GET and POST data.
PHP 5 has deprecated those variables, and they're not supported in upcoming PHP 6.
You'll want to change the code to use $_GET instead of $HTTP_GET_VARS and $_POST instead of $HTTP_POST_VARS (similar with $HTTP_REQUEST_VARS and $HTTP_SERVER_VARS if you have them), if you want the code to be compatible moving forward.

Ref: http://www.php.net/manual/en/ini.cor...er-long-arrays