You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
HI NIck
Not sure what could cause the following issue but the only change I have made to the live site recently is to upgrade to PHP Version 5.4.32.
No core files or database tables have been altered for a few months, and checkout has been running seamlessly since V7.
The only mod was the image gallery mod you done a few months back.
Anyway the problem:
Customer 1 creates an order number(00020) and proceeds to the Sagepay Payment Form Method. Sagepay receive all the correct details and price and processes the payment.
Customer 2 creates an order number but gets the same order number(00020). Proceeds to Sagepay, but sagepay refuse the order as it has the same order number as customer 1. Customer 2 returns to site, new order number created(00021) and proceeds to Sagepay. Pay the correct amount.
In the meantime, Customer 1 has received an order confirmation(00020) but it has all the billing details, order items and costings of Customer 2. The only correct part on the confirmation is that it has Customer 1's email address.
Customer 2's order confirmation(00021) is correct except it has the email address of Customer 1.
Customer 1 returns to site to find the items still in their shopping cart. They go to the contact form to email me The contact form includes all of Customer 2's details.
I contact Customer 1 and ask them to return to the shopping cart and proceed to the check out page. The checkout page contains all Customer 2's details which they correct accordingly. Order number 00020 has now been updated correctly.
So it seems an order number can be created and passed to the payment provider, but another user is able to create an order with the same number, and overwrite the details of the original order.
Could the upgrade to PHP 5.4 be causing this issue.
It has occured twice in the last 10 days.
Offline
Have you done any delation of old invoices? I have seen times when an invoice was delated but the items did not get removed from the database which caused the old invoice to be used on new sales orders.
John
Offline
No definitely not deleted any items from the ecom_orders table as I know this causes problems if you don't also delete from the orderitems table.
Apart from that, it isn't just adding additional items. Once customer 1 has proceeded to Sagepay, customer 2 has completed highjacked customer 1's order number in every aspect except the email address.
Session ID's are different, and both users were logged into their individual accounts(not guests).
Last edited by zanart (10-08-2014 04:14:52)
Offline
The invoice deletion issue was a problem in V7 when the BOM xmod was installed. It wasn't properly deleting order items when orders were deleted from BOM. That was corrected early on.
This sounds more like a crossed session id issue. Did you publish any links with a session id variable in them (sid CGI variable)?
Check the session ids saved for both of these orders. Are they the same? A couple of good SQL statements to run if you think crossed IDs are an issue:
DELETE FROM ecom_cart
UPDATE core_users SET lastsid=''
DELETE FROM core_sessions
That will clear all carts and drop all session info for a fresh start.
Offline
Session Id's for customer and and customer 2 were different.
Cart Id's were different.
It has nothing to do with order numbers being deleted as the problem occured before I would have had time to delete anything.
Looking more into it, it seems that when customer 1 was off site and on the sagepay payment page, customer 2 has hijacked customer 1's order number AND account. When customer 1 returned from sagepay their order was updated as pending shipment but had all of customer 2's details and order items.
Customer 2 processed their order with a new order number, but their order contained customer 1's email address. Customer 2's order also indicated that Guest Checkout Status was False. However this was incorrect. Customer 2 does not have an account and checked out as a guest. However as they had somehow hijacked customer 1's order including email address, ccp has associated their order with customer 1's account.
Nothing in the account gallery mod, including the new cookie, would cause this problem would it??
I am keeping an eye on all payment receipts to make sure they match the amount on the ccp invoice and will let you know if I have any more problems.
Offline
Nothing in the gallery mod done for you could affect this. Very strange. I'd recommend the same approach, wait and see if it replicates, which it likely won't.
Offline
ANother instance has come to light of this problem.
Should it be possible for Paypal to process two payments with the same order number??
I have two payments in my paypal account that have the same CCP order number.
Processed 30 seconds apart.
The order number in ccp relates to the second paypal payment.
The details of the first payment are completely unknown to CCP as the products and customer details have been completely overwritten by the 2nd payment.
Offline
It sounds like you've got a second store running somewhere that's taking orders. I know that sounds strange, but I've seen dev stores produce orders before. This wasn't the first order of the day was it?
Offline
This was order 27 of the day.
I use date format order numbers
The developer version runs off a completely different database so couldn't be an issue.
The latest two problem orders were paid for within 30 seconds of each other, both on paypal.
It should be noted that this latest problem has only just come to light. It actually happened on 27/9 which is around the date the first problem occurred. I haven't had any new issues arise. Maybe there was just a glitch somewhere that has resolved itself.
Offline
would the ecom_cart table being nearly 600mb be an issue??
Offline