Authorize.net NOT WORKING for me!!

ok I have several websites where I coded the para to work with authorize.net but with my zencart it is not working well.

when I try to buy something it says that the credit card cannot be authorize...

any ideas?

should I use the AIM or SIM method? I put in my id and password and still no go. help please.

jraccord:

ok I have several websites where I coded the para to work with authorize.net but with my zencart it is not working well.

when I try to buy something it says that the credit card cannot be authorize...

any ideas?

should I use the AIM or SIM method? I put in my id and password and still no go. help please.

I'm getting the same problems . . .new to Zen Cart - Love it - will donate if I can get this working . .

ck256

"I'm having the same problem" is too generic a statement ... esp since the previous poster was quite vague in what their full situation is.

So, let's start from the top.

• What version of Zen Cart are you using?
• What addons/contributions do you have installed?
• Who is your hosting company?
• What is your URL?
• Which Authorize.net module are you using?
• What exactly have you done to set it up?
• What exactly are you doing when the problem occurs?
• What exactly is the problem you're experiencing? including exact error messages.

DrByte:

"I'm having the same problem" is too generic a statement ... esp since the previous poster was quite vague in what their full situation is.

So, let's start from the top.

• What version of Zen Cart are you using?

• What addons/contributions do you have installed?

• Who is your hosting company?

• What is your URL?

• Which Authorize.net module are you using?

• What exactly have you done to set it up?

• What exactly are you doing when the problem occurs?

• What exactly is the problem you're experiencing? including exact error messages.

thanks Dr. Byte - U R right, I think I made my post out of frustration . . apology to the forum.

So we're using the latest current version of Zen Cart - clicking version says our cart appears to be current.

No add-ons/contributions have been installed.

Hosting Zoom is the host.

checkout.fedexkinkosclass.com is the url

We're looking at using authorize.net AIM module - no other modules are installed.

For setup, I put my api login id, generated a new transaction key from authorize, entered that into zen module, and put the md5 hash value (password) in the module as well. have tried different combinations of test/production mode both on site and authorize.net.

Problem occurs on final confirm stage of order (I assume this is when the calls go out to authorize).

The problem error message is as such:
Warning WARNING: Security hash problem. Please contact store-owner immediately. Your order has not been fully authorized.

corbykissler:

... and put the md5 hash value (password) in the module as well.

...

The problem error message is as such:
WARNING: Security hash problem. Please contact store-owner immediately. Your order has not been fully authorized.

Authorize.net only allows an MD5 passphrase of up to 20 characters.
Please choose something shorter than 21 characters and put it in your authorize.net profile.
Then go to your Zen Cart AIM module and enter that same passphrase in the AIM module's settings.

Then your transaction should work fine.

DrByte:

Authorize.net only allows an MD5 passphrase of up to 20 characters.
Please choose something shorter than 21 characters and put it in your authorize.net profile.
Then go to your Zen Cart AIM module and enter that same passphrase in the AIM module's settings.

Then your transaction should work fine.

the one I have chosen is eleven characters, but I will try the suggestion and reduce the number of characters.

If that still doesn't work, turn on debug mode and post the log output here.

I have debug turned on .. not getting emails tho - which I think is strange . .

Also maybe related - I defined my admin email with one address, then went back and changed it, emails are not going to my new email address and the default email address is still the old address.

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

I looked in the include directory .. nothing there for authorize . .

So here's another interesting thing. . . when I put both systems in production mode . . I got a decline on my card and the hash error.

Merchant recorded the item as a decline . .

Trying again .. . . :)

Same Error - Bad Hash - Guess we'll what turns up on the merchant report on Monday . .

Would still like a look at the logs . .

To use AIM you must have SSL enabled on your server.

Does that mean all over the site, or just in the cart stuff? I used the option to just secure the cart checkout . . .

Will this cause a failure?

corbykissler:

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

Please describe exactly what you mean by this statement.

corbykissler:

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.

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 . . .

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?

DrByte:

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!

DrByte:

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?

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.

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.

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 . . .

:frusty:

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 . . .

:frusty:

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