Jump to content
ScotTek

Orders attached to wrong customer after payment

Recommended Posts

I am experiencing a problem with OSCommerce where occasionally after a customer completes an order through paypal, the order will get attached to a different customer and the confirmation will go out to that incorrect customer. I have updated to the most recent paypal standard plug-in but the problem still seems to be occurring. I dont know if this is related to something happening on the return from paypal or if it is an issue that is inside of oscommerce, but looking to see if anyone else has experience this problem. I am using osCommerce version 2-2 MS2. Also if someone can explain how this part of the process works with OSCommerce. That is how a confirm message gets sent after the order is complete, that may help me figure out what might be going wrong. Any help is appreciated.

 

Thanks,

 

-- Scott

Share this post


Link to post
Share on other sites

Same issue; first report from website owner was on 2/3/10. Now, I've seen it on 2 or 3 of the past 100 orders. In our case, authorize.net is processing the cc payments, so it's not specific to PayPal. I think it is related to the osCsid and Google. Scott, maybe we should talk. email me at cypriiva at gmail.com if you'd like.

 

Chris

 

 

 

I am experiencing a problem with OSCommerce where occasionally after a customer completes an order through paypal, the order will get attached to a different customer and the confirmation will go out to that incorrect customer. I have updated to the most recent paypal standard plug-in but the problem still seems to be occurring. I dont know if this is related to something happening on the return from paypal or if it is an issue that is inside of oscommerce, but looking to see if anyone else has experience this problem. I am using osCommerce version 2-2 MS2. Also if someone can explain how this part of the process works with OSCommerce. That is how a confirm message gets sent after the order is complete, that may help me figure out what might be going wrong. Any help is appreciated.

 

Thanks,

 

-- Scott

Share this post


Link to post
Share on other sites

I'm having the same problem, and it's with a different payment method (Debit card with ATOS)

It seems to be a very recent problem (for us anyway)

Did you guys figure out what the problem was?

 

 

Thanks

Edited by mafianumerique.com

Share this post


Link to post
Share on other sites

Well, I never received a response from the original poster. I hope he found his solution.

 

Seems that this is related to the OS Commerce session ID (osCsid). As it was set up, search engines could acquire (and publish) site links that include a session id. Then if two people were to go to the cart at around the same time (from links that included the same osCsid), the first one to log in would log in normally, but the 2nd person would tag along. So let's say Customer A logs in as "Customer A", and places an order, and then Customer B (using the same osCsid) places an order. I am not 100% on what Person B will see, but they'll put their bill to and ship to info in, and it will be processed (appropriately) using Customer B's payment info (at least in the situation I found). Then it will be stored as an order under the account of Person A. Problem!

 

How did I handle it?

 

First I asked Google to remove the problem links from their search results. This isn't good enough though: other search engines can do the same thing. Additionally, I've found forums and other social media sites where people did a cut-and-paste of a link from one of their site visits, and that link included the osCsid. Bad.

 

Anyway, next I went to Configuration - Sessions, and:

* set "prevent spider session" to true. I'm not sure that this is the best direction here, but I did it.

* set "recreate session" to true. This is the real heart of the solution, I think. Had this been set to true initially, then in the example situation described above, Customer A would have received this "bad" session ID from the search engine, and Customer B would have received that same session. However, when Customer A went to place an order, upon their login or setup of a new account, osCommerce would have FORCED a new (and random) session ID to be created. So by the time Customer B went to place their order, they wouldn't be tied to customer A anymore. And (of course) Customer B would also be assigned a new Session ID upon logging in or creating an account.

 

This appears to have cleared up the problems, which started on a Sunday, showed up several times before the fix was applied on Wednesday, and has not happened in the 2 weeks (?) since.

 

And I do not know why this popped up for us all around the same time. Hmmm....

 

Good luck, and please let me know if this worked for you.

 

Chris

 

If anyone else has thoughts on this, I'd still appreciate hearing them.

 

==============

 

I'm having the same problem, and it's with a different payment method (Debit card with ATOS)

It seems to be a very recent problem (for us anyway)

Did you guys figure out what the problem was?

 

 

Thanks

Share this post


Link to post
Share on other sites

Well, I never received a response from the original poster. I hope he found his solution.

 

Seems that this is related to the OS Commerce session ID (osCsid). As it was set up, search engines could acquire (and publish) site links that include a session id. Then if two people were to go to the cart at around the same time (from links that included the same osCsid), the first one to log in would log in normally, but the 2nd person would tag along. So let's say Customer A logs in as "Customer A", and places an order, and then Customer B (using the same osCsid) places an order. I am not 100% on what Person B will see, but they'll put their bill to and ship to info in, and it will be processed (appropriately) using Customer B's payment info (at least in the situation I found). Then it will be stored as an order under the account of Person A. Problem!

 

How did I handle it?

 

First I asked Google to remove the problem links from their search results. This isn't good enough though: other search engines can do the same thing. Additionally, I've found forums and other social media sites where people did a cut-and-paste of a link from one of their site visits, and that link included the osCsid. Bad.

 

Anyway, next I went to Configuration - Sessions, and:

* set "prevent spider session" to true. I'm not sure that this is the best direction here, but I did it.

* set "recreate session" to true. This is the real heart of the solution, I think. Had this been set to true initially, then in the example situation described above, Customer A would have received this "bad" session ID from the search engine, and Customer B would have received that same session. However, when Customer A went to place an order, upon their login or setup of a new account, osCommerce would have FORCED a new (and random) session ID to be created. So by the time Customer B went to place their order, they wouldn't be tied to customer A anymore. And (of course) Customer B would also be assigned a new Session ID upon logging in or creating an account.

 

This appears to have cleared up the problems, which started on a Sunday, showed up several times before the fix was applied on Wednesday, and has not happened in the 2 weeks (?) since.

 

And I do not know why this popped up for us all around the same time. Hmmm....

 

Good luck, and please let me know if this worked for you.

 

Chris

 

If anyone else has thoughts on this, I'd still appreciate hearing them.

 

==============

 

Chris, I am now making the same changes in configurations - sessions (Prevent Spider Sessions true, Recreate Session true) and will report back if it works. Thanks very much!

Share this post


Link to post
Share on other sites

I made those configuration changes, but my store would not issue a new session id. I found and installed a contribution called Session Regeneration and then it worked like it should. Problem solved! Thanks for putting me on the right track.

Share this post


Link to post
Share on other sites

If some spiders crawled Your site and along with site url they have taken the oscid part in url.

 

This oscid part is the session id.

 

Now if two customer s reach the site from that spider they will have same sessin id and this messup will happen.

 

Make sure that Kill spider session is set to true.

plus if previouly any search engines are displaying oscsid in the search results then YOu need to take corrective actions.

 

Satish


Ask/Skype for Free osCommerce value addon/SEO suggestion tips for your site.

 

Check My About US For who am I and what My company does.

Share this post


Link to post
Share on other sites

I made those configuration changes, but my store would not issue a new session id. I found and installed a contribution called Session Regeneration and then it worked like it should. Problem solved! Thanks for putting me on the right track.

 

hmm.. Isn't there already a "Recreate Session" switch in Configuration/Sessions?

 

here is the help text associated with it:

Recreate the session to generate a new session ID when the customer logs on or creates an account (PHP >=4.1 needed).


define('PROJECTS', 'Something that goes on forever!');

Share this post


Link to post
Share on other sites

To correct the problem I had with customer orders showing up under other customer's accounts (likely due to customers coming in from Google with the same session ID), I changed my site settings as follows:

 

Force Cookie Usage = true

Prevent Spider Sessions = true

Recreate Session = true

 

However, I am still having customer orders show up under the wrong account.  Is there some other setting change that needs to be made?  This happens about once per week and looks to be that the order from a customer who checks out without creating a account gets attached to a customer who created an account.

 

My site does not accept Paypal, so it is not a Paypal issue in this case.

 

Thanks for any help you can provide!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×