completed checkout ends up in shopping cart

[coffman]

I am have a problem with the checkout process. I have been running my store on osCommerce MS2 for a couple of years now. And I am guessing this has been happening for quite some time, I just did not know it until someone told me about a week or so ago.

 

The problem is that every so often when a customer successfully checks out from my store, they end up on the shopping cart page with the notice that their shopping cart is empty. Most folks just leave it at that and see the email notification and know that their order went through. Others will place the order a second time (not good). When this happens I have no way of knowing unless I contact them.

 

I have noticed when groking through my apache log files that there is not a checkout_success access for each submittal of checkout_confirmation.php.

 

Can someone please give me a tip on how to best approach this problem.

 

Oh yea. I am running authorize.net as my only payment method. I setup some file logging to show me what authorize.net returns to see if I can glean anything from that, but it appears to be the same no matter what.

 

Is there some place in the checkout_confirmation page I can put something to log progress so a can see when the customer goes to the shopping cart page instead of the success page.

 

Thanks for any help.

[Guest]

you should probably update your suthorize.net to the latest . . .

[coffman]

Probably not a bad idea to update authorize.net, but I would rather know what is going wrong first before making more changes to my site.

[coffman]

I am progressing through debugging this problem and have been able to duplicate it 'once'. It seems to be non-deterministic :( It happened to me using a money order payment method I created from the standard COD payment method. So it is not a function of authorize.net

 

I am basically creating a temporary file and printing status and vars into this file from within the checkout_process.php, etc... using fopen and fwrite. I am doing this on a test site currently, but may setup logging on my main site so I can capture when the problem occurs for customers and look at differences.

 

For now I added a line to my empty_cart line in the english/shipping.php file that says.

 

"if you just confirmed your order, the order has been received - Thanks."

 

Not the best, but it may keep folks from double ordering :)

 

Hope this info is useful to others..

-Michael

[user99999999]

Hi,

 

It sounds like you customer is getting logged out or the session was lost causing checkout_success.php to redirect to shopping_cart.php.

 

One of the print invoice contribs has some javascript that logs the customer out and caused a problem like this.

[coffman]

Dave: Thanks for the tip. I am not using that contrib. And the user is not actually being logged out. I placed some print statements into the top of checkout_payment, checkout_process, checkout_success and general.php (tep_redirect function). The format of the output is "filename: location/data" Here is the output that I get:

 

checkout_confirmation.php: top
checkout_process.php: top
checkout_process.php: Calling checkout_success.php
functions/general.php(tep_redirect): http://ts.suncreekmusic.com/checkout_success.php
functions/general.php(tep_redirect): 1 - Location: http://ts.suncreekmusic.com/checkout_success.php
functions/general.php(tep_redirect): 2 - Location: http://ts.suncreekmusic.com/checkout_success.php
checkout_process.php: top
checkout_process.php: registered(sendto)
functions/general.php: http://ts.suncreekmusic.com/checkout_payment.php
functions/general.php: 1 - Location: http://ts.suncreekmusic.com/checkout_payment.php
functions/general.php: 2 - Location: http://ts.suncreekmusic.com/checkout_payment.php
checkout_payment.php: top
functions/general.php: http://ts.suncreekmusic.com/shopping_cart.php
functions/general.php: 1 - Location: http://ts.suncreekmusic.com/shopping_cart.php
functions/general.php: 2 - Location: http://ts.suncreekmusic.com/shopping_cart.php

 

checkout_process calls checkout_success, but checkout_success is never seen. I put a print in the top of the file before the application_top is included and nothing. This makes no sense to me. Why would the redirect end up back in the checkout_process.php file ? Here is the code I have in the top of the *success.php file:

//DEBUG
 $fn= '/tmp/debug-log';
 $fh = fopen($fn,'a');
 fwrite($fh,"checkout_success.php: top\n"); //DEBUG

 require('includes/application_top.php');

 

Ultimatley I hit the payment script and sendto has already been unregistered. As you can see, then the payment script forwards to the shopping cart page thinking I tried to checkout without any items in my cart....

 

Thanks

[GeneZ]

Michael,

Your note about checkout_process completing but checkout_success not firing sounds like a similar situation I had in the CGI world some time ago. We found that giving a browser a not-fully-qualified URL can have nondeterministic failures. Now, osCommerce fully qualifies redirects by the convention of calling tep_href_link before calling tep_redirect, so that isn't exactly the problem - but possibly the right track.

 

Since you observed checkout_process trying to go to checkout_success but the latter never running, the redirect is clearly suspect. A couple of thoughts that I had:

1 - try to determine if anything is written out from the beginning of checkout_process up until the redirect. I can imagine header problems if errant text is spit out before a redirect

2 - would it be an option for you to move (or include) the HTML from checkout_success into checkout_process instead of doing a redirect? Very much a kludge, but if that final redirect is the problem, perhaps the "western medicine approach" (i.e. cut it out) would fit the bill.

 

Good luck.

 

Gene

[coffman]

I am still intermittently having this problem with my site and was wondering if I could get some advise on how to troubleshoot php a little better. The problem is exactly like described above and is intermittent.

 

Description: With the user in the checkout_confirmation.php page the user selects the 'confirm order' button. Instead of ending up on the checkout_success.php page, they end up back in the shopping cart. Here is my understand of what should happen.

 

checkout_confirmation.php calls checkout_process.php

checkout_process.php includes application_top.php (to setup the session)

checkout_process.php excecutes code included from authorizenet (a module I have installed)

checkout_process.php then makes the following call:

 

tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));

 

This function lives in includes/functions/general.php

 

The function looks like:

 

  function tep_redirect($url) {
if ( (ENABLE_SSL == true) && (getenv('HTTPS') == 'on') ) { // We are loading an SSL page
  if (substr($url, 0, strlen(HTTP_SERVER)) == HTTP_SERVER) { // NONSSL url
	$url = HTTPS_SERVER . substr($url, strlen(HTTP_SERVER)); // Change it to SSL
  }
}

header('Location: ' . $url);

tep_exit();
 }

 

and then the checkout_success.php page should display. Every so often this does not happen. The checkout_success.php is never read and instead the process re-enters the checkout_process.php page. At this point the cart is empty and session vars have been unset so after several hops, the user ends up back at the shopping cart page.

 

I put statements around the header call to print to a file and both of them print. I also put print statements at the begining of the checkout_success.php and it does not print when there is a problem. It is like the header call does not seem to work (again intermittently).

 

I tried placing the actual header call directly in the checkout_process.php file and basically the same thing happens. It intermittently will just pass right by the call (seemingly). Is there a way to trouble shoot this? Are there things in the session/environment that could be getting munged? Placing a sleep(5) just before the call seems to help ( i don't have as many sessions wind up in the cart page after confirmation ). But I don't seem to understand how some kind of race conditon would prevent the header call from working.

 

Any clues on what to look at to try and figure this out? I am very frustrated. I am sure I am loosing a few customers because of this issue....

 

Oh yes. I also created a file called test.ph that basically hast the header call to checkout_success.php in it and then typed it into my browser immediately after a test checkout ended up in the shopping cart page. Low and behold, it works and takes me to the success page, go figure.

 

I hope this description makes sense.

 

Thanks for any help..

[coffman]

I am not sure if anyone is reading this or not, but I have learned at least something. Here are 2 cases, each of which make no sense to me related to the problem I am having.

 

- If I remove checkout_success.php and replace it with an empty file. After confirming my order I get a popup asking if I want to download the file checkout_process.php

 

- If I place only the following in the checkout_process.php file:

<?php 
 $fn= '/tmp/debug-log';					 //DEBUG
 $fh = fopen($fn,'a');					  //DEBUG
 fwrite($fh,"checkout_success.php: top\n"); //DEBUG
 fwrite($fh,"checkout_success.php: sendto = $sendto\n"); //DEBUG
?>

 

Nothing shows up in the /tmp/debug-log file listed above

 

Can someone please help me understand how the file is processed and why almost nothing I do can cause my site to consistently process the checkout_success.php file..

 

Thanks.