If you do have debugging turned on within the auth.net SIM setup, then there should be logfiles which will contain more details. By design, the error message presented to customers when declined is vague.

Is auth.net SIM in test or production?

Have you tried using a real, valid CC instead of test number?
Do you have a temporary, test product priced @ $0.01?

Can you switch to the classic green template and test to verify your template is not causing the issue?
What happens if you use the same credentials and setup auth.net AIM for a short, testing period?

Just trying to get you to a point where you can provide the debug file. From there, DrByte will probably have to offer his expert words of wisdom.

We did finally get a SIM_Debug file from a customer transaction. We have removed customer's information. It says in the return info log that the transaction has been approved, and the cc numbers have been captured in the authorize account, yet we have no record in our zen cart of the customer's order and had to contact them directly to find out what they ordered. I noticed the [HashMatchStatus] => FAIL and have already corrected that, but we still have the same issue. The cart just loops over and over again, and doesn't complete the order in the cart.

Sent to Authorizenet: Array
(
[x_login] => *******
[x_amount] => 26.86
[x_currency_code] => USD
[x_method] => CC
[x_type] => AUTH_ONLY
[x_cust_ID] => 236
[x_email_customer] => FALSE
[x_company] =>
[x_first_name] => xxxxx
[x_last_name] => xxxxx
[x_address] => 123 Street
[x_city] => City
[x_state] => New Jersey
[x_zip] => xxxxx
[x_country] => United States
[x_phone] => xxxxxxxxxx
[x_fax] =>
[x_email] => [email protected]
[x_ship_to_company] => xxxxxxxxx
[x_ship_to_first_name] =>xxxxxx
[x_ship_to_last_name] => xxxxxx
[x_ship_to_address] => 123 Street
[x_ship_to_city] => city
[x_ship_to_state] => state
[x_ship_to_zip] => xxxxx
[x_ship_to_country] => United States
[x_solution_id] => A1000003
[x_version] => 3.1
[x_Customer_IP] => 00.000.00.00
[x_relay_response] => TRUE
[x_relay_URL] => http://oursite.com/store/index.php?main_page=checkout_process&action=confirm
[x_invoice_num] =>
[x_duplicate_window] => 120
[x_allow_partial_Auth] => FALSE
[x_description] => Website Purchase from SCI/ Standard Chemical
[x_fp_sequence] => 942
[x_fp_timestamp] => 1434135711
[x_fp_hash] => e77a4181a095d09482ab2fce9cb4a09a
[x_show_form] => PAYMENT_FORM
[x_receipt_link_method] => POST
[x_receipt_link_text] => Click here to complete your order.
[x_receipt_link_url] => http://oursite.com/store/index.php?main_page=checkout_process
[zenid] => b3517fe6223ca384c84b190f3ce82b5a
[url] => https://secure.authorize.net/gateway/transact.dll
)

Jun-12-2015 03:02:32

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

Results Received back from Authorizenet: Array
(
[x_response_code] => 1
[x_response_reason_code] => 1
[x_response_reason_text] => This transaction has been approved.
[x_avs_code] => Y
[x_auth_code] => 07002D
[x_trans_id] => 7257376551
[x_method] => CC
[x_card_type] => Visa
[x_account_number] => XXXX1234
[x_first_name] => xxxxx
[x_last_name] => xxxxxx
[x_company] =>
[x_address] => 123 Street
[x_city] =>city
[x_state] => state
[x_zip] => xxxxx
[x_country] => United States
[x_phone] => xxxxxxxxxx
[x_fax] =>
[x_email] => [email protected]
[x_invoice_num] =>
[x_description] => Website Purchase from xxxxxxxxxxxxx
[x_type] => auth_only
[x_cust_id] => 236
[x_ship_to_first_name] => xxxxx
[x_ship_to_last_name] => xxxxxx
[x_ship_to_company] => xxxxxxxxxxxx
[x_ship_to_address] => 123 Street
[x_ship_to_city] => city
[x_ship_to_state] =>state
[x_ship_to_zip] => xxxxx
[x_ship_to_country] => United States
[x_amount] => 26.86
[x_tax] => 0.00
[x_duty] => 0.00
[x_freight] => 0.00
[x_tax_exempt] => FALSE
[x_po_num] =>
[x_MD5_Hash] => 74EBC45B6220FD07D93B7A8985893C5B
[x_cvv2_resp_code] =>
[x_cavv_response] =>
[x_test_request] => false
[securityToken] => aeb2a99eaf3c5e1dba342a6f0f841f62
[zenid] => b3517fe6223ca384c84b190f3ce82b5a
[HashValidationValue] => 05F85F263AD4EC04E264137EA30AE7B0
[HashMatchStatus] => FAIL
[url] => https://secure.authorize.net/gateway/transact.dll
)

Does it make any difference if you set auth.net SIM to capture instead of authorize?

You mention capture but the log indicates authorize only.

If you enable AIM instead of SIM, can you complete the checkout process?

I meant that the transaction is in the authorize account. We have sim set to authorize, because some orders are freight shipping, and we need to determine the freight company to be used, then add the cost to customer's invoice before actually charging the card.

I just meant for the sake of testing, edit the setup to capture.
Also, for the sake of testing, setup AIM and see if things work.

The option now is to wait for someone like DrByte to offer words of wisdom.

We have this working now. It was yet another setting off in the Authorize account. All seems fine now. Thank you sooo very much for your time and help RixStix!! I appreciate all of your input.

WebWeaver2000:

We have this working now. It was yet another setting off in the Authorize account. All seems fine now. Thank you sooo very much for your time and help RixStix!! I appreciate all of your input.

Mind sharing with the class after all of this, what the setting was that was overlooked or needed modification? Maybe not the specific final value but at least the thing that needed to be looked at to address this? Someone is more than likely to come across this especially since the title of the thread was changed a while back and find no solution at the end if this last piece of info is not provided. Please help others with this last bit.

WebWeaver2000:

We have this working now. It was yet another setting off in the Authorize account. All seems fine now. Thank you sooo very much for your time and help RixStix!! I appreciate all of your input.
Which specific setting was "off"?

WebWeaver2000:

We have this working now. It was yet another setting off in the Authorize account. All seems fine now. Thank you sooo very much for your time and help RixStix!! I appreciate all of your input.

I'm having the exact same problem: Zen Cart 1.5.4, Auth.net checkout works, but no order info is saved in the database. I have followed the threads on this, and set my receipt URLs, since the Zen Cart documentation is incorrect.

WebWeaver2000 has apparently solved the problem, and now won't tell us how they did it, which is nice.

Can anyone help?

Nocturnaloner:

I'm having the exact same problem: Zen Cart 1.5.4, Auth.net checkout works, but no order info is saved in the database. I have followed the threads on this, and set my receipt URLs, since the Zen Cart documentation is incorrect.

WebWeaver2000 has apparently solved the problem, and now won't tell us how they did it, which is nice.

Can anyone help?

Sorry to get personal with this, but isn't that unnecessarily pretty strong of a statement? Won't tell??? Seems to me that it is hasn't told, as in may not have visited/revisited this thread since two people had asked for statement of "solution". Sure all should (could) share, and it is truly voluntary to do so and there are "hints" all around for users to close out their issue with the solution that worked for them, but in this public area, the above post could be similar to announncingg to the world that a tree has fallen in the forrest, if they aren't looking then they may not know... Hopefully in spite of the statement of refusal to help, webweaver2000 will 1) finally remember what it was that was done now that it has been 6 months (wow, that long? I remember writing that message) and 2) at least will pony up the solution, perhaps after being contacted by PM?

Anyways, I'm guessing that there is a bit of frustration pent up about the issue, and that some of that has bled over to this post. It doesn't help though if the posts (as appears here) to get personal attack like.

mc12345678:

Sorry to get personal with this, but isn't that unnecessarily pretty strong of a statement? Won't tell???

Ah, you're probably right. "Didn't" tell. There we go.

Now, in the hopes of possibly making up for that terrible breach in etiquette, allow me to offer what might finally be a solution to this issue:

The documentation is wrong. The instructions that are at the top of the plugin page in the admin are wrong. At least they were for my case.

SETTINGS
Your "response" and "receipt" URL settings in your Authorize.net Merchant Profile can be left BLANK, or can be set to point to http://your_domain.com/foldername/index.php?main_page=checkout_payment

Nope!

The correct Default Receipt URL and Default Response URL are as follows:

https://your_secure_domain.com/foldername/index.php?main_page=checkout_process

Note the checkout_process NOT checkout_payment, and note that no additional arguments like "&action=confirm" should be added.

if you use https://your_secure_domain.com/foldername/index.php?checkout_process&action=confirm, leaving out main_page= it won't work.

If you leave them blank, it won't work. There you go!

Nocturnaloner:

The instructions that are at the top of the plugin page in the admin are wrong. At least they were for my case.
Hmmm. Yes, there's a mistake in the on-screen-admin instructions.
Much more detailed instructions are at: https://www.zen-cart.com/content.php?303-how-to-set-up-the-authorizenet-sim-payment-module

Thanks for posting back your findings. We'll fix that help text with the upcoming v1.5.5 release.

I am having the same issues, same symptoms as originally stated. Any pointer to the updated instructions? Using instructions from the link provided above doesn't seem to work for me. https://www.zen-cart.com/content.php...payment-module

What version of Zen Cart? While this FAQ (https://www.zen-cart.com/content.php?291-how-to-set-up-the-authorizenet-aim-payment-module) doesn't address the change in the checkout_payment vs. checkout_process end-point, it does have a fair amount of information.