Lost orders after HPP payment. - intermitent. Osc 2.2

[yahalimu]

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?

 

[yahalimu]

For some reason checkout_process thinks there's no session I think. I have no ideas on why.

[♥ecartz]

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? 

[yahalimu]

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.

 

[yahalimu]

STILL happening today despite removing all cookie banners.

Reduirects to the login page.

Totally at a loss to understand what could be happening.

[burt]

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

 

[yahalimu]

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.

 

 

[burt]

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.

[yahalimu]

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.

[ArtcoInc]

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

[yahalimu]

Sorry yes the www is there, was a typo.

[♥raiwa]

Try:

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

 

[yahalimu]

Tanks Raiwa, tried that but still very occasionally redirects to login still.

Its a mystery.

[burt]

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). 

[yahalimu]

HI,

That's logical as www is a sub-domain. (doh)

We shall see.

Thanks.

[yahalimu]

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.

 

[yahalimu]

Sorry to bump this but STILL getting lost orders.

Is it a Cookie Samesite attribute error maybe?

https://www.neowin.net/news/chrome-80-arrives-today-with-potentially-site-breaking-cookie-changes/

It started about the same time and maybe explains why it is so random if it happens.

[Guest]

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>

 

[♥ecartz]

On 4/2/2020 at 5:42 AM, yahalimu said:

Is it a Cookie Samesite attribute error maybe?

If it is, then updating to 1.0.7.7 should fix it. 

[yahalimu]

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)