500: internal error with Authorize.net final checkout

[DrByte]

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

[swortis]

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

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

[DrByte]

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.

[swortis]

** url removed ***

[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?

[DrByte]

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

[Merlinpa1969]

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