orders not showing in admin - authorize.net

[organicmd]

New store, using Authorize.net with AIM Zen-Cart v.1.3.8a, Patch 1
The first test charges we made live worked well, but now that others are registering and buying, the orders are not being recorded. I'm getting paid, and able to figure out the orders from the email confirmations, but have looked high and low in the forum and FAQs and can't find an answer that helps me.

Here is return from Authorize.net for one order. (I've xx'ed out the name and private info)

Mar-19-2010 01:30:47
=================================

Response Code: 1.
Response Text: This transaction has been approved.

Sending to Authorizenet: Array
(
[x_login] => *******
[x_tran_key] => *******
[x_relay_response] => FALSE
[x_delim_data] => TRUE
[x_delim_char] => |
[x_encap_char] => *
[x_version] => 3.1
[x_type] => AUTH_CAPTURE
[x_method] => CC
[x_amount] => 139.00
[x_currency_code] => USD
[x_card_num] => XXXXXXXXXXXXXXXX0262
[x_exp_date] => 0911
[x_card_code] => ****
[x_email_customer] => TRUE
[x_email_merchant] => TRUE
[x_cust_id] => 7
[x_invoice_num] => 4-7fPJCd
[x_first_name] => xxxxx
[x_last_name] => xxxxx
[x_company] =>
[x_address] => 1xx xxxxx Street
[x_city] => Palo Alto
[x_state] => California
[x_zip] => 943xx
[x_country] => United States
[x_phone] => 650-******
[x_email] => xxxxxx######################
[x_ship_to_first_name] => xxxxx
[x_ship_to_last_name] => xxxxx
[x_ship_to_address] => 1xx Bxxxxx Street
[x_ship_to_city] => Palo Alto
[x_ship_to_state] => California
[x_ship_to_zip] => 943xx
[x_ship_to_country] => United States
[x_description] => Healthy Eating Workshop, Spring, 2010 (qty: 1)
[x_recurring_billing] => NO
[x_customer_ip] => 63.145.232.66
[x_po_num] => Mar-19-2010 01:30:46
[x_freight] => 0.00
[x_tax_exempt] => FALSE
[x_tax] => 0.00
[x_duty] => 0
[Date] => March 19, 2010, 1:30 pm
[IP] => 63.145.232.66
[Session] => 9339f227dca2ebe90a41e5abff98e34a
[url] => https://secure.authorize.net/gateway/transact.dll
)


Results Received back from Authorizenet: Array
(
[0] => Response from gateway
[1] => 1
[2] => 1
[3] => 1
[4] => This transaction has been approved.
[5] => 03506C
[6] => Y
[7] => 2899822314
[8] => 4-7fPJCd
[9] => Healthy Eating Workshop, Spring, 2010 (qty: 1)
[10] => 139.00
[11] => CC
[12] => auth_capture
[13] => 7

<SNIP BY MODERATOR>

[DrByte]

In your list of orders in the admin, if you use the search to find the order, does it show up? In the above case, it's order #4.

If you can locate it that way, then something's setting the order status to 0 instead of to a valid number. If you then change the status (via the pulldown in lower left quadrant) to 2-Processing, and uncheck "notify customer" and click the submit button, the order should then show in the list normally.

If you can't locate it that way, then you've likely got a PHP error happening, which needs troubleshooting. Best tool for that is the one mentioned in Step 2a of this article: https://www.zen-cart.com/tutorials/index.php?article=82

[organicmd]

Still working on an issue relating to orders where authorize.net processes the charge, but the order never gets recorded (Thanks to DrByte for his previous help.

Installed enable_error_logging.php in both the /includes/extra_configures, and when no error logs created, tried putting it into /admin/includes/extra_configures

Sat with a customer as they did an order. At end of order, they now get an error, "Email Error: Could not instantiate mail function", which is a new problem. Tried doing this with email configured to PHP, SMTP, SMTPAUTH, and Sendmail, all with the same error.

Charge goes through, but order not recorded. Item remains in cart, so session not closed.

Only things in the /cache file are the debug logs for each of the sales strings sent back by authorize.net

Am I looking in the right place for the myDEBUG-xxxxx.log files?

Also tried creating /includes/local/configure.php to see if errors would show up as we went through the sale, but no errors showing.

When we first set up the cart, all was working. Went live, started getting sales, but none of them got recorded. Only able to figure out the sale from the email generated by authorize.net

v.1.3.8a with Patch1
PHP5.2

Any help much appreciated.

[DrByte]

Installed enable_error_logging.php in both the /includes/extra_configures, and when no error logs created, tried putting it into /admin/includes/extra_configures

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.

Sat with a customer as they did an order. At end of order, they now get an error, "Email Error: Could not instantiate mail function", which is a new problem. Tried doing this with email configured to PHP, SMTP, SMTPAUTH, and Sendmail, all with the same error.

When you do a test order by yourself, do you get the same problem?
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?

Charge goes through, but order not recorded. Item remains in cart, so session not closed.

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:

Only things in the /cache file are the debug logs for each of the sales strings sent back by authorize.net

Those authnet logs are to be expected when you have authnet debug log-to-file enabled.

Am I looking in the right place for the myDEBUG-xxxxx.log files?

Those files will be in the /cache folder as well, but *only* if PHP errors occur.

When we first set up the cart, all was working.

Including authnet transactions?

Went live

What do you mean by "went live"? Be very specific.

[organicmd]

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?

When you do a test order by yourself, do you get the same problem?

Yes, I do now.

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.

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.

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.

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?

[DrByte]

While testing for this error, should I leave the file both places?

There's no harm in leaving it in both places. All it will do is start recording PHP errors *if* they occur, which in a perfect world is never ;)

Requested password help, and that worked normally, and I got the email.

Okay, so it's not a general problem with email.

There is a template from templatemonster.

That could be a serious problem. TM is well known for breaking things in complicated hard-to-find ways.

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.

Does this problem occur with *all* products? or just with products added since the earlier successful transactions? What's unique about those newer products vs the older ones?

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.

To some degree, yes.

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?

Unlikely to be a problem. If it were a problem then I'd expect that your payments would be getting rejected, but you say they're going through fine. So I don't see it as a concern.