Authorize.net Help

[crionox]

Did the logs have any "response" info as well?
All you've reported is the initial transaction data sent "to" the gateway, not the response coming back.

This was all that was located in the log files within the docs folder (the above is a log file in its entirety). Are responses stored separately? Sorry, I'm new to the setup here.

David

[DrByte]

For authorize.net, the log details are all self-contained in individual files. The response should show after the transmission data.

I guess it's rather normal for the SIM module to not show any response data, since Zen Cart doesn't process a response.

If you're getting the "error" message on the Authorize.net page, you'll have to contact their technical support for further help.

[crionox]

Well, I did talk to the Authorize.net help line (chat, actually), but in the process also discovered the log files for the return authorization. I hadn't realized before that they were separate files.

So after looking at those, it seems the transaction in going through fine, but is failing when it comes to verifying the hash. Here is a copy of the return log:

Feb-11-2008 10:16:48
=================================

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

Results Received back from Authorizenet: Array
(
[x_response_code] => 1
[x_response_subcode] => 1
[x_response_reason_code] => 1
[x_response_reason_text] => (TESTMODE) This transaction has been approved.
[x_auth_code] => 000000
[x_avs_code] => P
[x_trans_id] => 0
[x_invoice_num] =>
[x_description] => Website Purchase from TriathlonDVD.com
[x_amount] => 64.95
[x_method] => CC
[x_type] => auth_only
[x_cust_id] => 2
[x_first_name] => David
[x_last_name] => Perry
[x_company] =>
[x_address] => 101 Main St.
[x_city] => Franklin
[x_state] => Tennessee
[x_zip] => 37064
[x_country] => United States
[x_phone] => 615-330-8718
[x_fax] =>
[x_email] => [email protected]
[x_ship_to_first_name] => David
[x_ship_to_last_name] => Perry
[x_ship_to_company] =>
[x_ship_to_address] => 101 Main St.
[x_ship_to_city] => Franklin
[x_ship_to_state] => Tennessee
[x_ship_to_zip] => 37064
[x_ship_to_country] => United States
[x_tax] => 0.0000
[x_duty] => 0.0000
[x_freight] => 0.0000
[x_tax_exempt] => FALSE
[x_po_num] =>
[x_MD5_Hash] => 12C09A79F1B0F818A9A4BF073C1A8886
[x_cavv_response] =>
[x_test_request] => true
[x_relay_form] => TRUE
[zenid] => 5923380061bcf5e36c57a7fbfc588424
[HashValidationValue] => 1817F8884A26A007598ACE1FE1332939
[HashMatchStatus] => FAIL
[url] => https://secure.authorize.net/gateway/transact.dll
)


To double-check that the hash values were correct, I re-saved the one from the zencart admin over to the authorize.net admin. So they're definitely the same, just not sure why that last bit is failing.

Thoughts? Thanks in advance for any help.

David

[crionox]

After working on a different zencart store with authorize.net payment, I noticed something in the setup that I thought would help my situation here. I didn't set a hash value in the authorize.net account, and also left it blank in the zencart setup. Seemed to work just fine. Granted, this new store was not hosted on godaddy, so not everything about the two situations were completely equal...

So I contacted Authorize.net help this morning, hoping that if I could just get the hash value on the account cleared, it might solve the situation. No such luck. They're not able to do that, and the guy from live help said he couldn't tell there was a value in our account (?). I then asked if we could just have the account reset, and he said he couldn't do that either.

The only pertinent information I really received (other than "sorry, we can't do that") was that the md5 hash value needed to be cleared from the store engine sending the data over. I can't actually tell from the logs that zencart does that (looks like it's only used on the return log from authorize.net).

All that to say, I'm now even more confused, and back to square one. Does anyone have ideas for what a reasonable next step might be? Thanks in advance.

David

[DrByte]

[x_MD5_Hash] => 12C09A79F1B0F818A9A4BF073C1A8886
[HashValidationValue] => 1817F8884A26A007598ACE1FE1332939
[HashMatchStatus] => FAIL

The x_MD5_Hash is the calculated value sent back from Authorize.net using the various data items it calculates from.
The HashValidationValue is the one calculated by Zen Cart using the same criteria.
If they don't match, then the transaction is deemed to be at risk. Hence the HashMatchStatus=FAIL.

The hash is calculated from the MD5-Hash entry in your Zen Cart admin (and the identical value in your authorize.net MD5 hash setting), along with other items including transaction value, etc.

There are only two causes of failure for the hash matching, as far as I know:
1. Incorrect hash phrase entered in both places
2. Fraudulent/spoofing transaction attempt.

[crionox]

I think I figured out what the issue is. The original hash value I entered into the zencart admin was longer than 20 characters. It was truncating down to first 20 characters, but the authorize.net settings were not (hence, they weren't matching up). I shortened it down and it appears to be working now.

Thanks for the help! It did help me narrow down where my problem was.

David