Quote Originally Posted by DrByte View Post
Those are the correct places to put the files in order to cause recording of PHP syntax/error problems triggered by the storefront or the admin respectively.
While testing for this error, should I leave the file both places?
Quote Originally Posted by DrByte View Post
When you do a test order by yourself, do you get the same problem?
Yes, I do now.
Quote Originally Posted by DrByte View Post
When you use *other* email-generating operations such as create-new-account or contact-us, do you receive those emails? Or do you get similar errors?
Requested password help, and that worked normally, and I got the email.
Quote Originally Posted by DrByte View Post
What's different in your store vs a brand new uncustomized install?
ie: a brand new clean fresh install with no addons or customizations works just fine for me when the Authnet AIM module is configured according to the published instructions:
There is a template from templatemonster.
Quote Originally Posted by DrByte View Post
Including authnet transactions?
Yes, once we had the site up with Authorize.net, we put through about three charges successfully. I have not changed the site since then, other than adding some products.
Quote Originally Posted by DrByte View Post
What do you mean by "went live"? Be very specific.
Notified people interested in a class we were giving that they could pay for it at the site. About 7 people did so. They were able to register, and show as customers. They paid, and we got paid, but none of the orders were recorded. All of the development of the store was done with the site live. Never used the "site down for maintenence" feature.

I mentioned that the session is not closing, with the item left in the cart after the charge is processed by authorize.net. Is there a clue here.

One other thing I find:
Using authorize.net account on another site as well. Not a subdomain, but a totally different account, but also at BlueHost.com. Could this in any way be causing a problem?