500: internal error with Authorize.net final checkout

Wondering if anyone can suggest a way of troubleshoot an authorize.net AIM setup. I'm getting a 500 (internal error) on the final step of checkout (Testing Mode). Server logs don't shed any light at all on the problem.

How can I troubleshoot this issue?

Thanks!

500 (internal error)
How can I troubleshoot this issue?
Talk to you host about this as there is little you can do about it even if you can determine what it is.

What version of Zen Cart?
What patches have you installed?
What addons/contributions have you installed?
Who is your host?
If you switch to a different payment module, does this same problem continue?

**Version: **ZC 1.3.7 - patched through the equiv. of 1.3.7.1

**Addons: **Super Orders, ImageHandler, IntegratedCOWOA

Host: InMotionHosting.com

Error does not occur with other payment options (such as COD)

Thanks for the help!

Ask your host whether your hosting account supports CURL, and whether any proxy is required.

CURL is supported. The binary is located at /usr/bin/curl

If you're using Zen Cart v1.3.7, go to this post and grab the updated AIM module code I posted there.
http://www.zen-cart.com/forum/showpost.php?p=310464&postcount=45

Install it, turn on Debug Logging to file, and test again.

If it doesn't work, post the log for analysis. It'll be in the /cache folder.

Still getting an 500 internal error. However, not seeing anything in /cache (unless you mean a different cache directory not at root?)

Tried setting the error log to "Log File" and "Log and Email" - neither appeared to create a log file

I meant the 'cache' folder at the root of your zen cart install ... perhaps "public_html/cache" for you ?
In order to write the logs, the folder needs to be read-write .. ie: chmod 777

shot in the dark.. does it require mod_rewrite?

The authorize.net AIM module shouldn't have any connection with nor be impacted by any mod_rewrite settings.

This is getting seriously frustrating...

Still nothing being written to the cache folder (which is at the root of the zen cart install and chmod 777..) There's an .htaccess file in there and an index.php file as well. Should there be?

Still getting the 500 internal server error.....

DrByte:

I meant the 'cache' folder at the root of your zen cart install ... perhaps "public_html/cache" for you ?
In order to write the logs, the folder needs to be read-write .. ie: chmod 777

You can test CURL on your server using the following script

Please unzip this curltest.zip file , and upload the curltest.php file to your server ... into the public_html folder.

Then point your browser to www.your_domain.com/curltest.php

If uploading the unzipped file to your server and running it via your browser doesn't bring back a Success message, then CURL support is not operating properly.

By default it tests non-SSL mode. To test in SSL mode, add ?ssl=1 to the URL when running it via your browser.

You can test connection to various services by adding various parameters:
?linkpoint=1
?authnet=1
?paypal=1

If you can share your URL on the forum, we may be able to help diagnose the limitations further.

NOTE: In v1.3.9, you'll find a newer version of this file in your /extras/ folder as /extras/curltester.php
You DO NOT need to download THIS one if you've got that one in your 1.3.9 site already.

*** url removed ****

Okay, the problem is using CURL to talk to SSL URLs, ie: https:// addresses, which authorize.net requires.

It seems your host doesn't support SSL with their CURL setup ... it gives the 500 INTERNAL SERVER ERROR when testing SSL destinations.

You'll need to talk to your host about that.

The host is claiming that cURL w/SSL support is already enabled and compiled. What are you seeing in those test results that I can report to them to demonstrate it is not working correctly?

Thanks!

If you run it regularly, without parameters, you get good results.

If you run it pointing to an SSL address, you get the 500 INTERNAL SERVER ERROR:
<snip>
same if you point it to the authnet server:
<snip>

But if you do the same from the Zen Cart server, where CURL is configured to use SSL when requested, it works fine.
<snip>
(ie: in this case it gives an HTTP Response 200 ("ok"), and provides the feedback from auth-net that the test parameters didn't include a username/password (which is of course intentional since all we're testing is communications, not authentication).

Ok - it appears the problem is 'php suexec' which is running on the server. If they recompile php on the server without suexec the curl test works fine, but everything else seems to break (including WordPress, and other php heavy apps)

Can the payment module be adjusted to work php suexec?

I don't see why suexec would have any influence on CURL making an external SSL call.

We use phpsuexec on several servers and cURL works just fine,

make sure that when they recompile php using phpsuexec that they include cURL in the compile