Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Lost orders after HPP payment. - intermitent. Osc 2.2


yahalimu

Recommended Posts

Hello,

I have recently been having a sporadic and intermittent problem with lost orders after a successful payment with a hosted payment page from our card processor. Sometimes its all good, sometimes not, so not repeatable.

The payment processor reports no errors.

The customer reports going through the payment process and then being bounced back to login rather than checkout_success. The customer reports the funds have left their account and shows as debited.

Initially I thought it was a session error so have been clearing the session table manually every few days. (It was getting rather large) but it has not helped. Its now happening a few times a day sometimes.

The payment provider calls the 'before_process.php' file after the transaction.

I have copied below the server logs (minus the browser details to aid reading) for a failed order and also for a completed order and also the before_process.php file..

Can anyone suggest a possible solution or something to investigate? Its driving me crazy...

  FAILED ORDER
86.180.216.251 - - [24/Mar/2020:18:13:08 +0000] "GET /checkout_shipping.php HTTP/1.1" 200 9010 "https://www.redacted.co.uk/shopping_cart.php"
86.180.216.251 - - [24/Mar/2020:18:13:11 +0000] "POST /checkout_shipping.php HTTP/1.1" 302 808 "https://www.redacted.co.uk/checkout_shipping.php"
86.180.216.251 - - [24/Mar/2020:18:13:11 +0000] "GET /checkout_payment.php HTTP/1.1" 200 9515 "https://www.redacted.co.uk/checkout_shipping.php"
86.180.216.251 - - [24/Mar/2020:18:13:15 +0000] "POST /checkout_confirmation.php HTTP/1.1" 200 9441 "https://www.redacted.co.uk/checkout_payment.php"  
86.180.216.251 - - [24/Mar/2020:18:14:17 +0000] "POST /checkout_process.php HTTP/1.1" 302 798 "https://pay.XXXXXXpayments.com/result.html?guid=f02a9852-ba8d-4f55-a6d0-8596f5c4c549"
86.180.216.251 - - [24/Mar/2020:18:14:17 +0000] "GET /login.php HTTP/1.1" 200 8388 "https://pay.XXXXXXpayments.com/result.html?guid=f02a9852-ba8d-4f55-a6d0-8596f5c4c549"

  COMPLETED ORDER
2.217.185.135 - - [24/Mar/2020:10:56:46 +0000] "POST /checkout_shipping.php HTTP/1.1" 302 4451 "https://www.redacted.co.uk/checkout_shipping.php"
2.217.185.135 - - [24/Mar/2020:10:56:46 +0000] "GET /checkout_payment.php HTTP/1.1" 200 9515 "https://www.redacted.co.uk/checkout_shipping.php"  
2.217.185.135 - - [24/Mar/2020:10:57:03 +0000] "POST /checkout_confirmation.php HTTP/1.1" 200 13096 "https://www.redacted.co.uk/checkout_payment.php"
2.217.185.135 - - [24/Mar/2020:11:00:56 +0000] "POST /checkout_process.php HTTP/1.1" 302 4451 "https://pay.XXXXXXpayments.com/result.html?guid=032ad3d9-b5da-4e90-b603-beba908757d6"
2.217.185.135 - - [24/Mar/2020:11:00:56 +0000] "GET /checkout_success.php HTTP/1.1" 200 8385 "https://pay.XXXXXXpayments.com/result.html?guid=032ad3d9-b5da-4e90-b603-beba908757d6"

 BEFORE_PROCESS.php below
 
<?php

  include('includes/application_top.php');

   global $_POST;

    $merchantid = $_POST['MERCHANT_ID'];
    $orderid = $_POST['ORDER_ID'];
    $account = $_POST['ACCOUNT'];
    $amount = $_POST['AMOUNT'];
    $timestamp = $_POST['TIMESTAMP'];
    $md5hash = $_POST['MD5HASH'];
    $result = $_POST['RESULT'];
    $message = $_POST['MESSAGE'];
    $pasref = $_POST['PASREF'];
    $authcode = $_POST['AUTHCODE'];


   echo '<form name="responseform" action="https://www.REDACTED.co.uk/checkout_process.php" method="POST" >
            <input type=hidden name="MERCHANT_ID" value="'.$merchantid.'">
            <input type=hidden name="ORDER_ID" value="'.$orderid.'">
            <input type=hidden name="ACCOUNT" value="'.$account.'">
            <input type=hidden name="AMOUNT" value="'.$amount.'">
            <input type=hidden name="TIMESTAMP" value="'.$timestamp.'">
            <input type=hidden name="MD5HASH" value="'.$md5hash.'">
            <input type=hidden name="RESULT" value="'.$result.'">
            <input type=hidden name="MESSAGE" value="'.$message.'">
            <input type=hidden name="PASREF" value="'.$pasref.'">
            <input type=hidden name="AUTHCODE" value="'.$authcode.'">
         </form>
         <script> document.responseform.submit(); </script>';

?>

 

Any ideas? Is this definately an issue with the website or could it be the processor?

 

Link to comment
Share on other sites

Do you force cookie use?  If not, perhaps the return URL is missing the session ID.  Maybe

 echo '<form name="responseform" action="' . tep_href_link('checkout_process.php', '', 'SSL') . '" method="POST" >

If you do, perhaps the cookie is getting lost when you leave the web site.  A cookie cleaner perhaps? 

Always back up before making changes.

Link to comment
Share on other sites

Hi,

Yes my thoughts also,

I have force cookie usage enabled.

I also have prevent spider sessions & Recreate Session also true, the rest false.

I've temporarily disabled the consent bar I'm using, although the OScid cookie should be enabled, we shall see if any changes but from reading checkout_process and sessions.php it's definitely a session issue of some sort.

New Phoenix site goes live in two weeks so not really a problem unless it also has the same issue.

 

Link to comment
Share on other sites

It's likely a session problem.  Two things immediately spring to mind;

  1. ensure your configure file is 100% correct (all paths are correct etc, cookie paths etc)
  2. set recreate_session to false

 

Link to comment
Share on other sites

Ok Thanks, I will try recreate_session to false.

Fairly sure cookie path is correct as I haven't changed it for years and only a small percentage of orders have the issue.

In the meantime I look at adding a header message in checkout_process, where it re-directs to login page, to give some customer feedback and asking to contact us.

 

 

Link to comment
Share on other sites

That is just a guess - I recall having some issues with login, add to cart, get logged out on a site.
Could not track the problem down and found that setting recreate_session false cured it.

Link to comment
Share on other sites

Nah didnt fix it.

Yet more today, a few others went through OK. I've checked the server log and it doesn't seem happen with a common browser.

This is my config file, fairly standard for an SSL site I think.

define('HTTP_SERVER', 'https://www.XXXX.co.uk');
  define('HTTPS_SERVER', 'https://XXXX.co.uk');
  define('ENABLE_SSL',true);
  define('HTTP_COOKIE_DOMAIN', 'www.XXXX.co.uk');
  define('HTTPS_COOKIE_DOMAIN', 'www.XXXX.co.uk');
  define('HTTP_COOKIE_PATH', '/');
  define('HTTPS_COOKIE_PATH', '/');
  define('DIR_WS_HTTP_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');

 

www.XXXX.co.uk is the common name on the SSL cert.

I think I'll admit defeat, now ITCHING to get the phoenix replacement site online now (booked for Easter) so hopefully the problem will disapear.

I suppose I could switch off force cookies but unsure how that will impact the site, I seem to remember force cookies is best.

Link to comment
Share on other sites

2 hours ago, yahalimu said:

  define('HTTP_SERVER', 'https://www.XXXX.co.uk');

  define('HTTPS_SERVER', 'https://XXXX.co.uk');
  define('ENABLE_SSL',true);
  define('HTTP_COOKIE_DOMAIN', 'www.XXXX.co.uk');
  define('HTTPS_COOKIE_DOMAIN', 'www.XXXX.co.uk');
  define('HTTP_COOKIE_PATH', '/');
  define('HTTPS_COOKIE_PATH', '/');
  define('DIR_WS_HTTP_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');

 

www.XXXX.co.uk is the common name on the SSL cert.

Shouldn't that be:

define('HTTPS_SERVER', 'https://www.XXXX.co.uk');

M

Link to comment
Share on other sites

Try:

  define('HTTP_COOKIE_DOMAIN', '');
  define('HTTPS_COOKIE_DOMAIN', '');

 

Link to comment
Share on other sites

define('HTTP_COOKIE_DOMAIN', 'www.XXXX.co.uk');
define('HTTPS_COOKIE_DOMAIN', 'www.XXXX.co.uk');

should be:

define('HTTP_COOKIE_DOMAIN', '.XXXX.co.uk');
define('HTTPS_COOKIE_DOMAIN', '.XXXX.co.uk');

(ie no WWW). 

Link to comment
Share on other sites

Looking at the specification:

https://tools.ietf.org/html/rfc6265#section-4.1.2.3

It clearly warns against adding the www so I assume that browsers are getting much more compliant than they were, especially Chrome.

Its been like this for many years without too many issues.

On 3/27/2020 at 12:55 PM, burt said:

ensure your configure file is 100% correct (all paths are correct etc, cookie paths etc)

 

On 3/27/2020 at 1:31 PM, yahalimu said:

Fairly sure cookie path is correct as I haven't changed it for years and only a small percentage of orders have the issue.

 

Another example where assumptions are the mother of all ****-ups.

 

Link to comment
Share on other sites

  • 4 months later...

I know this was a little while ago, but I just ran into this issue, and have a fix for it in case anyone else is looking.

I had to add this to the .htaccess, and the orders that use the Authorize.net SIM system are working again. 

<IfModule mod_headers.c>
Header always edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</IfModule>

 

Link to comment
Share on other sites

23 hours ago, fourmat said:

I had to add this to the .htaccess, and the orders that use the Authorize.net SIM system are working again.

Hi,

I tried that in my htaccess, got 500 server error, logs said not enough attributes.

For now I have worked around my cookie issue by forcing the correct session by passing the session ID back to checkout_process in the POST variables of my callback function but would be nice to fix the cookie issue. (without upgrading to 1.0.07.7)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...