Store returns an error, but it actually runs on Authorize.net

[Cheri~]

If I save "All logged data regardless of severity"......

Is there any data inside this log file that is a security risk to give this to the server admin guys????

[lat9]

Is there a way to activate logs/debug?

This is the response I received from the server admins.......

"We access the server and verified the settings, no errors or problems have been identified.

We also check the webserver log and no error message is displayed for the domain entered.

In this way, we recommend checking with the Zencart support team how the logs/debug can be activated for the application in this way, we can help with the problem that is occurring."

To activate those PHP logs, since you're running on zc157, you can go to the admin's Configuration->Logging and set "Report All Errors (Storefront)" to IgnoreDups.

That will cause all PHP issues other than duplicate-constant warnings to be logged on your storefront.

[DrByte]

To simulate AIM transactions (actually, to make real "authorize-only" transactions in a "test" mode), you can use the attached script.
Set your account credentials in the first couple lines where it says PUT_YOUR_INFO_HERE.
Then upload it to your site.
Your hosting company can use the URL to that script as proof that problems exist ... and can run it again to ensure that whatever fixes they make have actually solved the problem ... without having to go through checkout in the store.

Don't leave the script on your server any longer than necessary, for security reasons.
And change your Transaction Key in your account (and in your store's module) after you delete the script.

You WILL incur service charges for each execution of the script, so this is another reason to delete it as soon as the problem is solved.

[Cheri~]

To activate those PHP logs, since you're running on zc157, you can go to the admin's Configuration->Logging and set "Report All Errors (Storefront)" to IgnoreDups.

That will cause all PHP issues other than duplicate-constant warnings to be logged on your storefront.

I changed this setting, ran a transaction.. the log under Admins > Admin activity Logs still doesnt show an error? are there logs somewhere else?
The store returns the same "Error There has been an error processing your credit card. Please try again." while the transaction actually went through fine.

[Cheri~]

To simulate AIM transactions (actually, to make real "authorize-only" transactions in a "test" mode), you can use the attached script.
Set your account credentials in the first couple lines where it says PUT_YOUR_INFO_HERE.
Then upload it to your site.
Your hosting company can use the URL to that script as proof that problems exist ... and can run it again to ensure that whatever fixes they make have actually solved the problem ... without having to go through checkout in the store.

Don't leave the script on your server any longer than necessary, for security reasons.
And change your Transaction Key in your account (and in your store's module) after you delete the script.

You WILL incur service charges for each execution of the script, so this is another reason to delete it as soon as the problem is solved.

okay.. so I dont get a CURL error BUT...... Im not sure it worked correctly? I used my AUthorize.net username?


CURL Message: '' CURL Error Number: 0

Authorize.net Response:
string(374) "*3*|*3*|*123*|*This account has not been given the permission(s) required for this request.*

[Cheri~]

Should I have put my AUthorize.net account in text mode first?

[DrByte]

The authnettest script submits a test transaction even if your account isn't in testing mode. I've used it with both live production accounts and sandbox accounts without issue.

Are you sure you used the correct transaction key (not your account password)?

Ironically, it's the "non-empty response" that is being tested ... and you got a non-empty response. But of course it wasn't a response to a completed payment, which is what you're trying to test ultimately.

[Cheri~]

The authnettest script submits a test transaction even if your account isn't in testing mode. I've used it with both live production accounts and sandbox accounts without issue.

Are you sure you used the correct transaction key (not your account password)?

Ironically, it's the "non-empty response" that is being tested ... and you got a non-empty response. But of course it wasn't a response to a completed payment, which is what you're trying to test ultimately.

Im sure its the transaction key. I changed two items in the script- user name and I used the transaction key straight out of the payment module. I ran a real transaction earlier and it when through on Authorize.net (but the cart still said it didnt) so Im sure the transaction key is right.

[DrByte]

I'm stumped.

[Cheri~]

okay............. so.. if youre stumped... maybe I need to start over......

Is there an uninstaller I should use, or just delete everything in that directory? and what about the database?