Jump to content

How to prevent "rapid fire" duplicate orders from same customer


Recommended Posts

Hey all,

 

I've got a problem with a hyperactive "rapid fire" customer who managed to generate three (3) orders in one go.  In traffic analysis this customer only visited the checkout page only once, and all three orders were generated in the same moment.

 

I use PayPal Europe payment module to process the payment and finalize order, and use multi-page checkout (not single page).

 

Of course the customer only meant to place one order and immediately freaked out and started flooding me with messages.  Interestingly the messages were also coming in with duplicates (through WordPress contact form).  I was able to recreate this scenario by rapidly pushing submit button multiple times.  I think the problem is a faulty mouse, faulty touchscreen or a faulty user who drank too many caffeinated beverages.  The user in question was using Microsoft Edge browser.

 

Now, my PayPal merchant account is configured to reject duplicate payments so this customer was charged only once, but nevertheless there were duplicate store orders generated.

Is there a way in PrestaShop to prevent duplicate orders from the same user in a short span of time?  Perhaps like a 10-second timeout or something, to prevent the multi-click scenario?

 

My PrestaShop store is version 1.6.1.4

 

Insight and suggestions are appreciated.

Edited by r00tb33r (see edit history)
Link to comment
Share on other sites

Anyone?  This is basically a need to filter out multiple submit requests in one checkout session.  As I stated for some users more than one order (duplicates) are generated.  There has to be a way to handle this.

Link to comment
Share on other sites

I don't understand how that is possible -- why are orders that don't come back with a successful paypal transaction being added to the orders table? Which PayPal service are you using to process payments? Have you set the payment failed page in PayPal to the same as Payment successful? That could be your issue but this is a bit above my experience level I'm just taking a shot at it since no else has responded. As far as I know, what you describe should not happen with a properly configured PrestaShop just using the out of the box configuration. 

Link to comment
Share on other sites

I don't understand how that is possible

Beats me. But it has happened before, I had a few doubles, but this is the first triple.

-- why are orders that don't come back with a successful paypal transaction being added to the orders table?

I think that's the key issue, all duplicate orders in PrestaShop have the same PayPal transaction ID, so this would imply that repeat payment submissions are not returned as unsuccessful even though no new PayPal charges are generated.

So it seems that PrestaShop or the PayPal module considers it a "successful" transaction. Looks like a bug (logic error) in PrestaShop or the payment module.

Which PayPal service are you using to process payments?

I use the official PayPal module that everyone else uses I believe it's best known as "PayPal Europe". The checkout mode for PayPal is "Express".

Have you set the payment failed page in PayPal to the same as Payment successful?

Default. Whatever is the default in PrestaShop and/or the official PayPal module.

That could be your issue but this is a bit above my experience level I'm just taking a shot at it since no else has responded.

Thanks for trying. At least it brought us to a useful fact, the fact that duplicates get the same PayPal transaction ID and therefore were not considered "failed".

As far as I know, what you describe should not happen with a properly configured PrestaShop just using the out of the box configuration.

Not sure what I hope for more, me screwing up configuring something or that there is a bug in PrestaShop and/or payment module. Edited by r00tb33r (see edit history)
Link to comment
Share on other sites

If the problem only materializes when people press the submit button multiple times in rapid concession I don't know if I would call that a bug.

I didn't remember at first but I actually did have a similar problem with a half-dozen or so orders on one store two years ago. Also PayPal but different PayPal module. The issue was people pressing the button and there being a delay so they would press it again. That was because the site was too slow and people get impatient -- if something doesn't happen immediately they feel like they need to press something again. Because the slowness was a problem in the entire store I moved to much better hosting -- solved the slowness and nobody has had a double order in so long I had completely forgotten about that issue.

I'd consider moving to better hosting if the problem is lag. If that isn't the problem then maybe just edit the checkout page to have some text telling people not to press the button twice. The latter won't stop everyone but it will stop some and for the others you can point them to the instruction when they complain. Being pro-active and contacting them when this happens before the customer even notices will also ease the conflict. None of the small number of customers who had this problem were upset as their money was refunded before they even noticed and we wrote to them to explain what is happening.

If you want a more elegant solution then custom code adding a delay triggered by pressing the submit button which makes it impossible for customers to press it again would be one option. To be honest I'm surprised PayPal successfully processes of two transactions with identical amounts from the same card and with all the same details in rapid secession -- you'd think there would be an automated tripwire for something like that.

Link to comment
Share on other sites

If the problem only materializes when people press the submit button multiple times in rapid concession I don't know if I would call that a bug.

The bug is the logic error where the duplicate checkout request returns the same transaction ID instead of failing and returning unsuccessful payment, because PayPal does refuse to charge twice.

I didn't remember at first but I actually did have a similar problem with a half-dozen or so orders on one store two years ago. Also PayPal but different PayPal module. The issue was people pressing the button and there being a delay so they would press it again. That was because the site was too slow and people get impatient -- if something doesn't happen immediately they feel like they need to press something again. Because the slowness was a problem in the entire store I moved to much better hosting -- solved the slowness and nobody has had a double order in so long I had completely forgotten about that issue.

I forgot about it too until this person exploded into my inbox.

I'd consider moving to better hosting if the problem is lag. If that isn't the problem then maybe just edit the checkout page to have some text telling people not to press the button twice. The latter won't stop everyone but it will stop some and for the others you can point them to the instruction when they complain. Being pro-active and contacting them when this happens before the customer even notices will also ease the conflict. None of the small number of customers who had this problem were upset as their money was refunded before they even noticed and we wrote to them to explain what is happening.

I don't think hosting had anything to do with it this time.

Actually the particular person in question has a faulty mouse I think because their contact messages through my fast WordPress site also had duplicate submissions.

In my case I have nothing to refund to them because PayPal doesn't take their money the second time, which is even more confusing to the customers when they get two orders and two receipts and think I took their money more than once.

Also the message on the checkout page, as well as any messages I send to the customer don't really do much to reinforce customer's faith in reliability of my site. Half of them don't even understand the difference between giving their financial information to me or to PayPal. Unfortunately the audience of my store is predominately not computer literate. For example most of them don't have a PayPal account and instead use guest checkout on PayPal. I need these dummies to have confidence in my store and my business. The store platform should keep the user from doing something they're not supposed to be able to do.

If you want a more elegant solution then custom code adding a delay triggered by pressing the submit button which makes it impossible for customers to press it again would be one option.

Elegant solution is when the store platform filters out duplicates or invalid orders. I consider a duplicate of a PrestaShop order with the same PayPal transaction ID to be invalid.

I thought about creating a band-aid fix for this problem. Disabling or hiding the submit button using JavaScript once it's clicked. One problem though, what happens if two click events fired off before event handler runs the code to hide the button?

To be honest I'm surprised PayPal successfully processes of two transactions with identical amounts from the same card and with all the same details in rapid secession -- you'd think there would be an automated tripwire for something like that.

That's why I call it a bug, it does trip PayPal, it prevents a duplicate payment, but PrestaShop thinks the payment was successful, even though no new PayPal charge was performed for 2nd and 3rd request, and so on.

 

The question is, do I file this under PrestaShop checkout bug or under PayPal module?

Edited by r00tb33r (see edit history)
Link to comment
Share on other sites

I don't think people with defective trigger action mice is the explanation -- if a mouse was doing that people would have all kinds of issues and then just replace the mouse.

If it is happening on multiple sites -- multiple buttons is really strange. If lag causing people to intentionally multi-click is not the issue then the other common thing between two sites on different platforms is the server -- do you use some non-standard setup like HHVM or something?  I have no idea if that would explain it but top of my head because yesterday a non-PrestaShop site I was setting up was doing all kinds of strange behaviour in a php 7.0 environment and then worked perfectly once I switched to php 5.6

Link to comment
Share on other sites

I don't think people with defective trigger action mice is the explanation -- if a mouse was doing that people would have all kinds of issues and then just replace the mouse.

And I do think that it's the issue with this specific user, as this user and this user alone was triggering multiple submits for both orders and messages. I have not had it like that with any other user. I'm pretty sure it's something with their input device but nevertheless the sales platform should filter out those order submits.

 

I deal with a special kind of customer, these are the sort of people who tend not to be computer literate. Comes with the territory unfortunately. They are the sort of people who loathe shopping online, always ask to speak to me on the phone, and always beg me to process orders by phone (which I can't).

If it is happening on multiple sites -- multiple buttons is really strange.

But that's what happened. And with one specific user. I have not had it exactly like that with other users.

If lag causing people to intentionally multi-click is not the issue then the other common thing between two sites on different platforms is the server -- do you use some non-standard setup like HHVM or something?  I have no idea if that would explain it but top of my head because yesterday a non-PrestaShop site I was setting up was doing all kinds of strange behaviour in a php 7.0 environment and then worked perfectly once I switched to php 5.6[/size]

No, I'm still on PHP 5.4 on nginx and MySQL 5.5.51, on real hardware, not VM. Been running like this for over a year. I'm using the default config provided by HostGator.

 

My store is not fast but it's tolerable. PrestaShop is not known for being fast from what I've seen.

Link to comment
Share on other sites

  • 1 year later...
  • 1 month later...

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
×
×
  • Create New...