Authnet: An error occurred while trying to report this transaction to the merchant.

[DrByte]

Question: Is there a reason for using SIM instead of AIM?
AIM is much more secure and a much more pleasant shopping experience for customers.

[mstep]

Not sure what it could be why Authorize.net is having trouble connecting back with the merchant, because orders run with PayPal go thru just fine, and show up as new orders in the Cart Admin.

[mstep]

Simplicity, or so I thought. My understanding is that the difference between the two is that AIM requires SSL. Correct? Which we don't have, and I thought I would try it with SIM. If that is a solution then maybe that is what we should do.

[DrByte]

I agree ... it's puzzling. I had that happen once when the SIM module was first being rewritten, but the problem was resolved. I don't recall whether it had anything to do with coding, but I've never seen it again ... using the module I pointed you to earlier.

The AIM module doesn't rely on going to the auth.net site and coming back, and is less likely to have problems.

[mstep]

I'm thinking it has something to do with the server configuration. What about switching hosting to a company that specializes in Zen Cart and can provide knowledgeable tech support for issues like I am facing now. Can you recommend one of the Zen Host Certified companies for having good support? And getting the cart correctly installed and configured.

[DrByte]

Can you recommend one of the Zen Host Certified companies for having good support? And getting the cart correctly installed and configured.

Best thing to do is ask them.
We don't make recommendations. We leave it up to you to do your own research.

[DrByte]

Simplicity, or so I thought. My understanding is that the difference between the two is that AIM requires SSL. Correct? Which we don't have, and I thought I would try it with SIM. If that is a solution then maybe that is what we should do.

SSL isn't really that expensive, and you *should* have it to protect all your customers' information anyway ... not just their credit card numbers, but their name, address, phone, etc.
I won't shop anywhere that doesn't use SSL to protect my personal information. Period. I'm sure I'm not the only one with that view.

[mstep]

Well, it looks like we might need to switch hosting service. Before I do that, I want to try one more time.

Here is an email I got back from Authorize.net.
######################################################################____

Greetings from Authorize.Net!

When Authorize.Net is responding back to a script on your server our system waits 10 seconds for a response. If we do not get a response in 10 seconds, our server will time out and display an error page. In this case the customer will see the transaction results on an error page that Authorize.net generates.

If this happens we will either send an email to you indicating: "An error occurred while trying to report this transaction to the merchant. An email has been sent to the merchant informing them of the error. The following is a result of the attempt to charge your credit card"

or

The transaction will be declined within your Merchant Interface. The transaction detail will display (Unable to send notification to Customer).

If the customer closes the browser window before we receive data from your script to print to the screen we will change the transaction response reason code to 52.

To prevent these errors the first thing that you will need to look for is the order that your script executes. It is very important that something is printed to the screen before any other process is started. If your script prints to the screen first, we will recognize that you have received the transaction results.

To resolve this issue:
- Before doing anything else start writing to your receipt page. For example: print your page headers and the first part of the page body.
- Check that your script permissions are correct and that it can accept an HTTPS POST.
- Check that the script is not completing other functions before writing to the screen, such as writing to a database or sending emails.
- Please check to see if there are different processes that are used in your script for approvals, declines, or errors. Check each process to be sure that they will write to the screen before any other functions.
- Verify that your script is not using redirects upon receipt of the response from our servers. Redirects strongly are discouraged because they can potentially interfere with the process.
############################################################__

Does any of this make sense?

The only thing I can possibly think of is that it might have something to do with the Permissions I have set. As I said earlier the server would not let me change the Permissions to 777 (as the installation instructions say to), they are currently at 775. It still won't let me change them. Could this be a factor?

[DrByte]

It has nothing to do with permissions.

All their suggestions are based around the idea of your site not responding quickly to them after the customer is done making payment.

Your store pages appear to load fairly quickly ... so I'm a little surprised that they'd be finding it slow.

[mstep]

Okay. I guess all that I am left with is that the hosting server will not let them back in (for some reason that is beyond me, and them). Unless you have any other ideas, I guess the answer is to switch to a better host. After some research, Blue host looks to be a good one, and they have phone support, which I really like.

Thanks for all of your help with this matter.