yahalimu Posted March 24, 2020 Share Posted March 24, 2020 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 More sharing options...
yahalimu Posted March 24, 2020 Author Share Posted March 24, 2020 For some reason checkout_process thinks there's no session I think. I have no ideas on why. Link to comment Share on other sites More sharing options...
♥ecartz Posted March 25, 2020 Share Posted March 25, 2020 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 More sharing options...
yahalimu Posted March 25, 2020 Author Share Posted March 25, 2020 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 More sharing options...
yahalimu Posted March 27, 2020 Author Share Posted March 27, 2020 STILL happening today despite removing all cookie banners. Reduirects to the login page. Totally at a loss to understand what could be happening. Link to comment Share on other sites More sharing options...
burt Posted March 27, 2020 Share Posted March 27, 2020 It's likely a session problem. Two things immediately spring to mind; ensure your configure file is 100% correct (all paths are correct etc, cookie paths etc) set recreate_session to false Link to comment Share on other sites More sharing options...
yahalimu Posted March 27, 2020 Author Share Posted March 27, 2020 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 More sharing options...
burt Posted March 27, 2020 Share Posted March 27, 2020 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 More sharing options...
yahalimu Posted March 27, 2020 Author Share Posted March 27, 2020 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 More sharing options...
ArtcoInc Posted March 28, 2020 Share Posted March 28, 2020 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 More sharing options...
yahalimu Posted March 28, 2020 Author Share Posted March 28, 2020 Sorry yes the www is there, was a typo. Link to comment Share on other sites More sharing options...
♥raiwa Posted March 28, 2020 Share Posted March 28, 2020 Try: define('HTTP_COOKIE_DOMAIN', ''); define('HTTPS_COOKIE_DOMAIN', ''); About Me: http://www.oscommerce.com/forums/user/249059-raiwa/ Need help? How To Get The Help You Need Is your version of osC up to date? You'll find the latest osC community version CE Phoenix here. Public Phoenix Change Log Cheat Set on Google Sheets Link to comment Share on other sites More sharing options...
yahalimu Posted March 30, 2020 Author Share Posted March 30, 2020 Tanks Raiwa, tried that but still very occasionally redirects to login still. Its a mystery. Link to comment Share on other sites More sharing options...
burt Posted March 30, 2020 Share Posted March 30, 2020 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 More sharing options...
yahalimu Posted March 30, 2020 Author Share Posted March 30, 2020 HI, That's logical as www is a sub-domain. (doh) We shall see. Thanks. Link to comment Share on other sites More sharing options...
yahalimu Posted March 30, 2020 Author Share Posted March 30, 2020 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 More sharing options...
yahalimu Posted April 2, 2020 Author Share Posted April 2, 2020 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. Link to comment Share on other sites More sharing options...
Guest Posted August 20, 2020 Share Posted August 20, 2020 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 More sharing options...
♥ecartz Posted August 20, 2020 Share Posted August 20, 2020 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. Always back up before making changes. Link to comment Share on other sites More sharing options...
yahalimu Posted August 21, 2020 Author Share Posted August 21, 2020 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.