Authorize.net NOT WORKING for me!!

[DrByte]

I used the option to just secure the cart checkout . . .

Please describe *exactly* what you mean by this statement.

[DrByte]

Where can I find logs on the server for authorize.net?

If you have enabled Debug Log-to-File, then your Authorize.net logs should appear in your /cache folder, provided the folder's permissions are set to writable.

[corbykissler]

Okay - here's an update . . . i went into authorizenet_aim component and modified the email address that the logs were being sent to . .

got results back from my last transaction . . .it was approved but the MD5 hash gave the following error . . .


[69] => March 2, 2008, 12:35 am
[70] => 75.1xx.xxx.xxx
[71] => f3xxxxxxxxxxxxxxxxxxxxxxxxca
[Expected-MD5-Hash] => 3XXXXXXXXXXXXXXXXXXF
[HashMatchStatus] => FAIL

Names changed to protect the innocent . . .

I'll try flushing the hash value next - someone else said something about setting it to nothing, updating it, then setting it back . . .

[corbykissler]

Last two tests - -


Transactions being approved . .

Response Code: 1.
Response Text: This transaction has been approved.

but the MD5 Expected values changed both times .. . while line 71 stayed the same . .

Any help is appreciated . . . I'm definitely no expert on zen cart, but is it passing the session value as the hash value? Maybe it's just my version?

[corbykissler]

Please describe *exactly* what you mean by this statement.

Followed the tutorial for changing the configure.php file . .

I am using my own signed cert, known working.

// Define the webserver and path parameters
define('HTTP_SERVER', 'http://www.YOUR_SHOP.com');
define('HTTPS_SERVER', 'https://www.YOUR_SHOP.com');
define('ENABLE_SSL', 'true');

And then I thought I saw somewhere, a setting where SSL can be enabled just for the checkout process, so I flipped that switch until I get the "real" cert installed.

Man you have fast replies!

[corbykissler]

If you have enabled Debug Log-to-File, then your Authorize.net logs should appear in your /cache folder, provided the folder's permissions are set to writable.

Thanks - will check that area out.

Hmmm, lots of logs . . . :)

Let's see . . .transactions are all getting approved . . so

Response Code: 1.
Response Text: (TESTMODE) This transaction has been approved.



[0] => Response from gateway
[1] => 3
[2] => 0
[3] => 0
[4] => (TESTMODE) Unknown error.


This was one of the early errors.

All of my latest transactions are getting approved, so the cart appears to be communicating with Authorize.net.

So, here's a question. How long can the API Login be, or does it matter?

[DrByte]

The API login and transaction key are provided by Authorize.net. Zen Cart doesn't care about their length.
The MD5 hash has a max limit of 20 chars allowed on the Authorize.net side. Zen Cart will take whatever you give it ... but of course, you must use the same as what's on the Authorize.net side.


The MD5 hash value being compared is calculated from a number of portions of the transaction, including the transaction amount, your account name, transaction id, and your supplied MD5 phrase. Thus it's different for each transaction.

[corbykissler]

The API login and transaction key are provided by Authorize.net. Zen Cart doesn't care about their length.
The MD5 hash has a max limit of 20 chars allowed on the Authorize.net side. Zen Cart will take whatever you give it ... but of course, you must use the same as what's on the Authorize.net side.


The MD5 hash value being compared is calculated from a number of portions of the transaction, including the transaction amount, your account name, transaction id, and your supplied MD5 phrase. Thus it's different for each transaction.

Hmm, this is a really tough problem then. Any way to disable the hash error checking (at least the message).

The charges appear to be going through to the merchant and being approved.

I've checked the md5 values on both sides multiple times and changed them multiple times - they match. I'm wondering if I remove the AIM module and reinstall it with all the fresh settings . . .



Thanks again for your reply - don't know how you do it.

[corbykissler]

Hmm, this is a really tough problem then. Any way to disable the hash error checking (at least the message).

The charges appear to be going through to the merchant and being approved.

I've checked the md5 values on both sides multiple times and changed them multiple times - they match. I'm wondering if I remove the AIM module and reinstall it with all the fresh settings . . .



Thanks again for your reply - don't know how you do it.

Okay - update 1

In my admin settings - the curl proxy status was set to true with no value in the ip address. so I set CURL to false. Same result - Hash Error.

Update 2 - Went to authorize and made sure the web URL was represented correctly in the business information. Same result - Hash Error.



Going to uninstall and reinstall the module . . . . back in a bit.

Next step is to just disable the error message - saw somewhere someone did it through application_top.php . . .not recommended but I have 50k in sales over the next 2 months to book.

[corbykissler]

Okay - update 1

In my admin settings - the curl proxy status was set to true with no value in the ip address. so I set CURL to false. Same result - Hash Error.

Update 2 - Went to authorize and made sure the web URL was represented correctly in the business information. Same result - Hash Error.



Going to uninstall and reinstall the module . . . . back in a bit.

Next step is to just disable the error message - saw somewhere someone did it through application_top.php . . .not recommended but I have 50k in sales over the next 2 months to book.

Uninstall/Reinstall didn't work . . it's the same has value at authorize.net and zen cart . . .

GRRRR