Communications Error Billing Address should match

I am on v1.3.9h
My site is http://tinyurl.com/6r9v7cm
I have the advanced shipper mod.

Searched all over the forums to find an answer to no avail.

I get a red block that says Communications Error - Please notify webmaster. Your credit card could not be authorized for this reason. Please correct the information and try again or contact us for further assistance.

Then to the right of Change Address image. Your billing address is shown to the left. The billing address should match the address on your credit card statement. You can change the billing address by clicking the Change Address button.

The address was correct (mine) and I get the same when I am in Testing Mode which is not address specific.

Curl is False

I am using Authorize.net (AIM) and have gone into authorize.net and adjusted all the AVS settings to see if I could get a working combination.

Not sure what else to try. So close to getting this cart rolling.

"Communications Error" suggests that your store is not able to talk to the Authorize.net server. That would be a hosting problem.

Try the curltester script mentioned here, and add ?authnet=1 to the URL to simulate testing talking to the authnet server.

This is what I got. The curl test script passes in Firefox, Chrome, and Safari. I sometimes get "28 connect() timed out!" though.
I find that when I do get that, a retry gets a good result immediately.

That timeout error is something you and your hosting company will have to resolve.

Time out error is resolved, still getting "Communications Error - Please notify webmaster. - Your credit card could not be authorized for this reason. Please correct the information and try again or contact us for further assistance. and next to Change Address. Your billing address is shown to the left. the billing address should match the address on your credit card statement. You can change the billing address by clicking the Change Address button.

My address is definitely correct, as I am using my card.

Getting Hash error Warning: Security hash problem. Please contact store-owner immediately. Your order has not been fully authorized.

Have done Hash multiple times.

My curl gives this at the end.

The following errors have occurred.
(13) The merchant login ID or password is invalid or the account is inactive.

EOF

Seems intuitive, but I have checked login many times. there is not a password. I have checked transaction key. and the account is active as I am in it.

stumped!

For (13) error, contact your merchant account services vendor.

I have contacted my authorize.net. seems to be working. Interestingly enough the charges are going through even though I am getting that error. and it hangs up there.

Could there be a conflict between Payment modules. Not sure how to check what modules are active. I went into Modules > Payment and I have Authorize.net (AIM) as green. Check/Money Order as Green and I put Paypal Express Checkout as Yellow as I thought that may be conflicting somehow.

Puzzling.

rliddle:

Could there be a conflict between Payment modules.
No .

Well that is one thing to knock off the list. I am at my wits end with this. It should not be that hard to actually collect the money.

What did Authnet tech support say was the exact cause of the (13) error that THEIR servers sent to your store?

What EXACTLY is your hosting company doing to diagnose and solve the intermittent problems with connecting?

Thanks for the reply.

Authorize.net says.

I would be happy to help you with this issue. This response will be returned if you are posting to our test server. You need to make sure you are posting to the following URL:
https://secure.authorize.net/gateway/transact.dllThe full documentation on this error can be found here:
https://support.authorize.net/authkb/index?page=content&id=A415&actp=search&viewlocale=en_US&searchid=1332769812867I have told them I am not in test mode, and asked them specifically what the issue is.

I am not sure that I am still having an intermittent problem connecting. Not sure how I can tell. the curl test does not seem to indicate that now.

If the Zen Cart module is NOT in "test mode" then it won't send transactions to the "test" server.

As for your intermittent problems connecting, if you're getting "Communications Error" messages, then ... you're having problems connecting. If those are gone, then I'm not sure I understand what your new symptoms are.

Hey, Dr. Byte, I'm now looking into this further for rliddle. I've gone over the same ground that he has and have some additional questions and information for you.

For one, there is a custom cart on the same hosting that is having no problems with a.net transactions. The original programmer wrote a small test script yesterday to prove that a.net is accessible via curl.

The cart itself seems to time out : Comm results: 28 Operation timed out after 15000 milliseconds with 0 bytes received

However, these transactions are showing up as charges at a.net. The one I just placed is showing up in my bank account.

Affirmed that he doesn't have to have a hash in zen cart even though he has one at a.net

Message in log:
[0] => Response from gateway
[1] =>
[Expected-MD5-Hash] => 5AC071C4301A4C14B0436639754B0498
[HashMatchStatus] => FAIL

CURL communication info: Array
(
[url] => https://secure.authorize.net/gateway/transact.dll
[content_type] =>
[http_code] => 100
[header_size] => 25
[request_size] => 218
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 14.999434
[namelookup_time] => 0.021844
[connect_time] => 0.152089
[pretransfer_time] => 0.56888
[size_upload] => 1058
[size_download] => 0
[speed_download] => 0
[speed_upload] => 70
[download_content_length] => -1
[upload_content_length] => 1058
[starttransfer_time] => 0.699188
[redirect_time] => 0
)

RAW data received
and there the log ends.

Can any settings at a.net make any difference such as relay response, receipt urls, silent post etc make a difference? Those settings were set up long ago and may well not be even appropriate to the working custom cart. But not sure as I never set anything up for those for customers anymore. I know they aren't required but wondering if his old settings could be a problem.

delia:

[0] => Response from gateway
[1] =>
[Expected-MD5-Hash] => 5AC071C4301A4C14B0436639754B0498
[HashMatchStatus] => FAILEach of those 4 lines is added by Zen Cart after receiving the response. The [0] line is added for readability.
The [1] line is the only actual response: blank
The [Expected-MD5-Hash] is the value it's looking for, but you'll notice that there is NO MD5-Hash returned from Authnet, so it has nothing to match against.
Hence the [HashMatchStatus]=FAIL which is the result of Zen Cart comparing the (non-existent) MD5-Hash received from Authnet against the Expected-MD5-Hash which ZC was looking for to validate the transaction.
delia:

CURL communication info: Array
(
[url] => https://secure.authorize.net/gateway/transact.dll
[content_type] =>
[http_code] => 100
[header_size] => 25
[request_size] => 218
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 14.999434
[namelookup_time] => 0.021844
[connect_time] => 0.152089
[pretransfer_time] => 0.56888
[size_upload] => 1058
[size_download] => 0
[speed_download] => 0
[speed_upload] => 70
[download_content_length] => -1
[upload_content_length] => 1058
[starttransfer_time] => 0.699188
[redirect_time] => 0
)This whole section is just a technical summary of the communciations taking place. The entry of note in this particular case is the HTTP_CODE of 100 ... which basically means the server acknowledged the connection (saying "100: please CONTINUE"), but evidently did nothing more than that, since it should have continued on and issued a 200 response along with all the values from the gateway, completing the transaction.

Figuring out what is wrong with this particular site and this particular merchant account is something that will most likely require deeper interaction with authnet tech support.

I can tell you that Zen Cart ONLY sends the prescribed list of name-value pairs, and then waits and listens for a response back from authnet. It's no more complicated than that as far as the software technology goes.

Problem solved.

Thanks to everyone (Delia) for their help. Tunrs out we needed to zero out the entry under Silent Post URL in authorize.net

Hope nobody else has to go through this.

Very odd, since according to the documentation AIM doesn't use that value for anything.

But the SIM setup instructions definitely advise leaving the field blank: https://www.zen-cart.com/tutorials/index.php?article=403