eCart Failure with Authorize.net

[msummers194171]

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?

[Ray Borduin]

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.

[msummers194171]

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

[Ray Borduin]

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?

[msummers194171]

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.

[Ray Borduin]

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?

[msummers194171]

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?

[Ray Borduin]

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.

[msummers194171]

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?

[Ray Borduin]

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

[msummers194171]

Remote checkout.

[Ray Borduin]

My guess is that it is the triggers. Change the triggers to use the button press trigger instead of current page submit and I think it will correct the problem. That is the only thing I can think of is that the user with this problem had referrer blocking software and that is why the triggers weren't initiated to send the email or update the database... because the referral blocking prevented the triggers from firing.

Referral blocking seems more and more common, we will likely move to automatically using the button press trigger in a future release.

[msummers194171]

Thanks, Ray. Perhaps I'll be able to make contact with the purchaser to find out. If I can what should I ask him to get a 'semi-definitive' answer? 8)

[Ray Borduin]

If you find out his browser you might be able to get them to look at their settings to see if it is enabled in his browser, but I'm not familiar with where it necessarily is in all browsers.

You could ask them about firewall settings... or probably the most definitive test would be to create a test page for them to go to. The page should have a submit button and a textarea with the value:

<?php echo((isset($_SERVER['HTTP_REFERRER']))?$_SERVER['HTTP_REFERRER']:""); ?>

If you go to the page and submit the form, it should show the current page location.

Ask him to do the same and if he does not see the current page name, that is the issue.

[msummers194171]

Great suggestion - I'll do that! I'll post the results back here.

[msummers194171]

http://www.squarewheelindustries.com/test-referrer.php

I just did it, and got nothing. And you?

[Ray Borduin]

and you put the textarea default value as:

<?php echo((isset($_SERVER["HTTP_REFERER"]))?$_SERVER["HTTP_REFERER"]:"") ?>

Let me do a test real quick... maybe I made a mistake... it comes up blank for me too.

[Ray Borduin]

I created a page and it worked for me:

--------------------------


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<meta http-equiv="imagetoolbar" content="no" />
<meta name="MSSmartTagsPreventParsing" content="TRUE" />
<meta name="robots" content="index,follow" />
</head>

<body>
<form id="form1" name="form1" method="post" action="untitled1.php">
Please just submit the form
<textarea name="testing" id="testing" cols="45" rows="5">http://localhost/mydesk/untitled1.php</textarea>

<input type="submit" name="TestIt" id="TestIt" value="Submit" />
</form>
</body>
</html>

[Ray Borduin]

The source code is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<meta http-equiv="imagetoolbar" content="no" />
<meta name="MSSmartTagsPreventParsing" content="TRUE" />
<meta name="robots" content="index,follow" />
</head>

<body>
<form id="form1" name="form1" method="post" action="untitled1.php">
Please just submit the form
<textarea name="testing" id="testing" cols="45" rows="5"><?php echo((isset($_SERVER["HTTP_REFERER"]))?$_SERVER["HTTP_REFERER"]:"") ?></textarea>

<input type="submit" name="TestIt" id="TestIt" value="Submit" />
</form>
</body>
</html>

[msummers194171]

Darn spellchecker! Try again...

It's HTTP_REFERER!

<textarea name="testing" id="testing" cols="45" rows="5"><?php echo((isset($_SERVER['HTTP_REFERER']))?$_SERVER['HTTP_REFERER']:""); ?>
</textarea>

[msummers194171]

Works for me, by the way -

https://www.squarewheelindustries.com/test-referer.php

(I renamed the page - sorry)

[Ray Borduin]

Yes, now see if it works for the user that had difficulty on your site.

My guess is that it will not, and this was the source of the problem. Because you have remote checkout, which only depends on the form submit, the trigger didn't matter to that part of the process, but it prevented the rest of the code from running.

[msummers194171]

Ray - according to the client, the test showed the referer properly. I'm checking to make sure that the test was done from the same computer as the original order.

Here's an interesting thought. I could recommend to my client that he issue this customer a $10 credit, in return for which the customer would place another order (there are items that this would cover). If that order goes through OK, then we know that either a) he didn't use the same computer as before, or b) he did, and the failure was at the server side of things.

Meanwhile, I'm checking with the host for their server logs....

Murray

[Ray Borduin]

I'm pretty sure it is the referrer issue. It is relatively common and with remote checkout the results would be exactly what you described.

[msummers194171]

So, I don't understand why our test didn't reveal this failure then.... Why would that be? Is the failure an intermittant thing?

[Ray Borduin]

No it shouldn't be. My guess is that he originally did the transaction from another location or computer. Maybe even the same computer on a different network. It should be consistent.

[msummers194171]

So - the solution would be to change the trigger from 'this page' to 'form submit'?

[Ray Borduin]

Change it to the button press event. That way when another page submits into this page it won't happen.

[msummers194171]

Ray - so I should change it to "Button: Submit_order pressed? And I'm not following your "...when another page submits into this page..." - are you thinking that this was part of the problem, or are you just saying that it's a safe way to trigger the saving of this data in the database, and a good alternative to the original 'current page submit' choice?

[Ray Borduin]

Just saying it is a good alternative that should still make sure the current page is submitting but won't have this problem.

[msummers194171]

Thanks for your help with this, Ray! I'll keep you posted.

By the way, there is a funny thing with the UI for those server behaviors. If I change the trigger selection, and then click on the OK button, it always selects the first element in the list (any form post, I think). To make my selection take, I have to a) select it, and b) click on some other field before clicking on the OK button. I assume you already have that in the queue, though....

[Ray Borduin]

Yes, unfortunately this started happenning after our CS4 updates. CS4 was automatically greying out input type="image" buttons until rollover. To avoid that problem we changed them to images with links, but that seems to have caused an issue with the last field updated in any interface not being stored properly. We will be addressing this issue in dot releases as time is available.