Authorize.net question (Test Account + SSL)

[esoin]

Thanks, DrByte, for the suggestion.

Is there any standard procedure for creating a MD5 hash? Will "12345" do?

I simply want to make a successful connection, just to know the API works.

My demo website is available at http://www.SaaSEcomm.com

Thanks again. Have a great day.

[DrByte]

It's just a simple phrase. "hello" is fine. It just has to be the same between both systems.

Their decision to call it "MD5 Hash" was probably unwise, considering the value is only "used" to create an MD5 hash, and is not in itself an MD5 generated/encrypted value.

[esoin]

Ahh, I see.

So, I emailed an authorize.net developer rep yesterday about my problem. He replied back with:

"Verify you are using the correct API login id and Transaction key which can be obtained from within your account settings. Also, with a test account you need to verify the cart is posting to the test server, https://test.authorize.net/gateway/transact.dll"

Now, I'm positive I have the correct API LOGIN/PW, transaction key. I have checked many times, copying and pasting the information directly from the A.NET test merchant account.

However, how do I verify that zen cart is posting to https://test.authorize.net/gateway/transact.dll ? I tried using the developer tool to find the above mentioned address, but I only found a few functions and if/else statements. I assume if I have the A.NET AIM module in "test mode" that it should be posting to the correct A.NET test server. Is there a better way to verify where zen cart is posting the information?

I tried changing the hash to "12345" and "hello" and still get the same error messages. I changed them both in zen cart and A.NET test merchant account.

My zen cart version is 1.3.8a. Is it worth trying to re-install the A.NET AIM module?

Also, I just got SSL installed onto my web server. I'm in the process of configuring SSL into zen cart.

Your time is much appreciated,

esoin

[esoin]

Wow, I THINK i found the problem.


I just noticed something in the A.NET Log file.

"
[Session] => 4a4c2470f47ddd2153a9874e1df72209
[x_test_request] => TRUE
[url] => https://secure.authorize.net/gateway/transact.dll
"

it seems to be posting to https://secure.authorize.net/gateway/transact.dll instead of https://test.authorize.net/gateway/transact.dll

What would be the best way to fix this? What variable determines where A.NET module post to? Should I go into the php file and hard-code in the correct test address.

Thanks again, DrByte.

[esoin]

Woohoo! I am no longer receiving the error messages mention above!

I went into authorizenet_aim.php and modified the URL to point to the correct test address. I hope this information helps others who have the same problem I was having.




My log file now states:

May-21-2008 01:37:07
=================================

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

What other ways can I verify that the transaction was completed and processed by A.NET? I tried logging onto my A.NET test merchant account, but couldn't find any information regarding my recent test order. I'll keep looking around.

I'm very thankful for the wonderful zen cart community, which is the #1 reason why I picked zen cart over other open source ecomm software.

[DrByte]

The Zen Cart authorize.net AIM module is already certified by Authorize.net.
There is no real benefit to using it with a developer account, unless you're actually developing some sort of new feature not already integrated.
That is why there is no presented switch offered to tell the code to post to the test server.

To use the Authorize.net modules, simply enable them with your live account, and start processing. The hard work of integration has already been done for you.

And, to address the argument that "well we have to test it", remember, the *best* test is to test a live account with live transactions ... because if you don't actually do that, you shouldn't be opening your store anyway.

Test transactions done in test mode do not get logged. They only verify communications are working, and that certain response codes are received when simulating good/bad transactions. They don't reflect real-world results.


That said, if you have no intention of actually using the software on a live store, and only intend to play in a sandbox, changing the url (as you mentioned) is one way to set up that world.

[esoin]

Yes, this is a sandbox.

You're absolutely right, step 2 for testing A.NET is to open a live account and test with real credit cards. Now that I can achieve a connection with A.NET, I'm confident about shelling out money to use a live account.