500: internal error with Authorize.net final checkout

[swortis]

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!

[kobra]

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.

[DrByte]

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?

[swortis]

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!

[DrByte]

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

[swortis]

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

[DrByte]

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.

[swortis]

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!

[DrByte]

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

[swortis]

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?