eCart Failure with Authorize.net

Recently, my client received three orders through his website. Two of those three were processed normally:

1. A confirmation email was sent
2. A confirmation was received from Authorize.net
3. The order was entered into the database
4. At the end of the day, the daily summary from Authorize.net showed the two orders

The third order was not processed properly:

1. No confirmation email was sent
2. A confirmation was received from Authorize.net
3. No entry was made in the database
4. At the end of the day, the daily summary from Authorize.net showed this order
5. The merchant account reflects the proper credit

The site was built with the latest distribution of eCart4 (PHP/MySQL).

What could cause something like this to happen?

I am not sure. Somehow the confirm page must have thought the order was denied even though it was not.

Are you able to reproduce the problem? Where there any errors on the page during the failed transaction?

It could be something as simple as your web site going down or Authrize.net taking too long to respond causing an error. It could have been your database was temporarily offline. It is really hard to say. That is not expected behavior in any circumstance.

The most important step in fixing a problem is being able to reproduce it. There must have been something different about that third order that caused the problem. Once you can reproduce the problem you can work on it and test to see if it is fixed. If you can't reproduce a problem there is no way to tell if it is fixed. Luckily software problems are almost always reproduceable once you figure out the source.

Ray:

On a live site, I don't have many opportunities to try to reproduce the problem, unfortunately.

There were no errors *reported*, either by the customer or by Authorize.net. As far as I know, the site was not down.

Here's what I know -

The failed transaction was completed on 3/3/09 at 14:21:02, and was approved by Auth.net. I have all of the details that were sent to Auth.net saved in a logfile that is written after each transaction has been submitted, so that I can see exactly what has been set to and returned by Auth.net. Less than an hour later another transaction was completed successfully. If you'd like to see this logfile data, I'll be happy to provide it.

Murray

Do you store the Authorize.net value for "Response Code"? That is what the eCart would key off of for whether to send the email and update the database.

If the "Response Code" is not 1, then the eCart thinks the transaction failed. Can you see the response code in that transaction?

Yes, I do store it in the log -

30 => x_ship_to_first_name=Mike
31 => x_ship_to_last_name=Mitchel
32 => x_ship_to_address=xxxx
33 => x_ship_to_city=Tacoma
34 => x_ship_to_state=WA
35 => x_ship_to_zip=xxxx
36 => x_ship_to_country=US
37 => x_ship_to_phone=xxxx
38 => x_ship_to_fax=xxxx
39 => x_recurring_billing=NO
This transaction has been approved.: 1
========= 14:21:02 Tue 03-Mar-2009 =========

The response was TRUE.

It appears there is no good reason... OH I have an idea... perhaps you use differnt triggers?

What is your trigger for the local checkout server behavior and what is your trigger for the store cart summary in database server behavior?

Ray, the triggers were not changed at all. The trigger on the confirm page is this to initiate the Auth.net handshake -

if (($_SERVER["REQUEST_METHOD"] == "POST") && (isset($_SERVER["HTTP_REFERER"]) && strpos(urldecode($_SERVER["HTTP_REFERER"]), urldecode($_SERVER["SERVER_NAME"].$_SERVER["PHP_SELF"])) > 0) && isset($_POST)) {

and this to trigger the cart summary to database -

<?php
// WA eCart Store Cart Summary in Db
if (($_SERVER["REQUEST_METHOD"] == "POST") && (isset($_SERVER["HTTP_REFERER"]) && strpos(urldecode($_SERVER["HTTP_REFERER"]), urldecode($_SERVER["SERVER_NAME"].$_SERVER["PHP_SELF"])) > 0) && isset($_POST)) // Trigger
{

Are those the ones you wanted to see?

OK, so the triggers look identical... you are sure that is the local checkout and summary triggers?

These triggers are "current page submit" triggers... they include intrinsic validation of sorts that makes sure someone has submitted the current page. However, it uses the HTTP_REFERRER value in order to do that, and sometimes, some people, will have that value blocked and removed from the header by antivirus or security software.

This trigger may not work for some people for that reason, so if you were using a different trigger for the local checkout that succeeded, I would have thought that was the culprit.

If they all use the same trigger, then the only way for some of the transaction to take place and then not the rest would be if it thought the transaction had failed, but there is no difference in the Response Code values, so that doesn't seem to be the case.

Unfortunately until we can reproduce the problem it will be difficult to diagnose. Double check to make sure the triggers are the same, but it appears they are.

I'm not quite sure which trigger you want though for the local checkout. There is no trigger on the checkout page - would it be on the confirm page?

Yes, on the confirm page. The server behavior will show as Local checkout... or are you using local or remote checkout?