[Done v1.3.9e] 1.3.9a Double Orders

I was excited to see this was on the fixed list, but it isn't fixed here.

http://www.zen-cart.com/forum/showthread.php?t=87761

Still happening post upgrade. What can I check? Thanks!

This most definitely is not fixed. In fact, it's happening like crazy. Doesn't anyone have any ideas??

I have never yet encountered a "double order" using the IPN module.

But I can categorically tell you that you will not have "double orders" if you use the more advanced Express Checkout module instead.

What's that saying? If a tree falls in the forest but no one is around, does it make a sound? Or something like that. Are you saying because it doesn't happen to you it doesn't happen? I'd be happy to send screen shots to show you the trees over here are really noisy. ;)

If I could fix it by just switching payment modules, I would. Except Express Checkout requires the customer to have a Paypal account. I have customers who don't have Paypal accounts and prefer to pay with a credit card. So that's out for me, I'm afraid.

If you could give me a clue where to look in my Zen files, I'd be greatly appreciative. Thank you. :)

I'm saying that in thousands of test transactions I can't recreate the symptoms you describe.

But if you can tell me how to exactly recreate the situation using a brand new clean uncustomized install of v1.3.9b, then it may be possible to concretely prevent the problem you describe. Without being able to recreate the symptoms, how do you expect a solution?

And, PayPal does not always require Express Checkout users to have a PayPal account. It varies based on several factors including geographic regions. For exact details, contact PayPal directly.

Strange, I logged into Paypal to check it out before posting and it says a Paypal account is required for Express. I suppose I could call them to find out more, but I'm not really interested in a payment module that doesn't cover everyone. Nor does it change the fact something is wrong and has always been wrong with IPN, at least in my Zen universe.

How on earth would I know how to recreate the symptom? The symptom is the sickness. I've asked customers if they refreshed the checkout page or how it might have happened, of course everyone says they didn't or don't know. Usually the customer-initiated double orders have two Paypal receipts and involve issuing a refund.

I don't really want to continue beating my head against the wall. My forehead is starting to get flat as it is. I simply thought you (or any Zen expert) might be able to suggest a place to start looking, given you know what files would be in play and this was specifically mentioned as having been fixed in 1.3.9a.

Unfortunately, it isn't fixed. At least not here.

ToniScraparoni:

.....How on earth would I know how to recreate the symptom? The symptom is the sickness....

The symptom is the red light on your dashboard indicating that something is not right. The headache is the symptom indicating that something in the body does not function as it should. Snapping the wire to the red light or popping a painkiller only eliminates the symptom but it does not fix the underlying problem. The symptom is not, never has been and never will be the sickness.

Bit off topic - but take this from a health care professional.

Gee, thanks, I needed that! I could have had a V-8.

You two can post about the semantics of symptoms and illnesses all night long. I'm not here to debate that. Or who really needs a health care professional.

I was merely wondering how I'm supposed to recreate something I have NO IDEA how it happens? Yet I've offered to submit evidence it DOES and has already happened, but nobody seems to care about that. It's seems like, if you pretend hard enough that I'm an delusional idiot, maybe both the problem and I will go away.

So I respectfully request if you don't have anything to contribute or suggest regarding a possible solution to this problem, please don't clutter up the thread. Most likely it will just die a quick little death since it seems pretty clear I'm not going to get any help on this issue. What double orders? :frusty:

Have you tried to uninstall and then re-install this payment mod? If not, make sure you take note of your PayPal configuration entries as they will be lost when you re-install.

ToniScraparoni:

Yet I've offered to submit evidence it DOES and has already happened, but nobody seems to care about that.It's not that I don't believe you. I just have no information to go on for trying to find any fix for you.

ToniScraparoni:

I was merely wondering how I'm supposed to recreate something I have NO IDEA how it happens?If you want developer help on the problem, then I need to know how to set up another store that works just like yours and consistently manifests the problem you describe.

So, exactly how is your site different from a brand new fresh clean uncustomized install of Zen Cart?
Including, but not limited to, product types, attributes assigned to the purchased products, product settings, tax settings, shipping settings, payment settings, all admin settings, currencies, languages, addons, .htaccess changes, customizations made, and the list goes on. Oh, and your PayPal account settings too ... how do yours differ from the posted instructions here: http://www.zen-cart.com/wiki/index.php/PayPal

If that list can be used to create a new store that consistently replicates the problem you describe, then something more can be done to fix the issue.

We also have a shop that's still getting double orders with Paypal standard (IPN + PDT) - even after the .js 'submit' button fix posted a while back by PaulM. It would appear that it's not necessarily always caused by the customer clicking the 'Submit' button twice.

Typically, each of the orders will have a different order No., and be timed a few seconds apart - sometimes 1 second apart.

The first order will contain the callback response from Paypal (order status = 'Processing') but not the grey block with all the transaction info in.

The second order will have the grey block with the transaction info, and will also be 'Processing'.

In our experience, the customer gets charged only once though.

There's a post at the end of this thread that suggests the problem may lie in the callback being initiated twice - once by the IPN (which might generate the first order) and then again by the PDT (which might then generate the second, duplicate, order) and that the solution may lie in changing 'rm => 2' to 'rm => 1' in includes/modules/payment/paypal.php around line 200.

http://www.zen-cart.com/forum/showthread.php?t=120386

Maybe worth a try?

Pixxi:

There's a post at the end of this thread that suggests the problem may lie in the callback being initiated twice - once by the IPN (which might generate the first order) and then again by the PDT (which might then generate the second, duplicate, order)In part that's likely where the problem occurs, likely due to a race-condition; however, that's what was addressed in 1.3.9a, along with a callback logic error, hence the matter being marked as resolved in 1.3.9a.

Pixxi:

and that the solution may lie in changing 'rm => 2' to 'rm => 1' in includes/modules/payment/paypal.php around line 200.
http://www.zen-cart.com/forum/showthread.php?t=120386
Maybe worth a try?
Not recommended. That's merely a bandage, not a fix, and will potentially result in lost orders, which is a much worse situation than what's being discussed at hand.

frank18:

Have you tried to uninstall and then re-install this payment mod? If not, make sure you take note of your PayPal configuration entries as they will be lost when you re-install.

I followed the 1.3.9a upgrade instructions to uninstall the module, upgrade, then reinstall.

DrByte:

It's not that I don't believe you. I just have no information to go on for trying to find any fix for you.

If you want developer help on the problem, then I need to know how to set up another store that works just like yours and consistently manifests the problem you describe.

So, exactly how is your site different from a brand new fresh clean uncustomized install of Zen Cart?
Including, but not limited to, product types, attributes assigned to the purchased products, product settings, tax settings, shipping settings, payment settings, all admin settings, currencies, languages, addons, .htaccess changes, customizations made, and the list goes on. Oh, and your PayPal account settings too ... how do yours differ from the posted instructions here: http://www.zen-cart.com/wiki/index.php/PayPal

If that list can be used to create a new store that consistently replicates the problem you describe, then something more can be done to fix the issue.

That would be quite a long list. A list I would be happy to compile for you. Or, if you have the time and the inclination, you're more than welcome to come over and see for yourself. I'd be happy to give you admin and server access. Please let me know if that would be acceptable. If so, also where I can send your login credentials.

Pixxi:

We also have a shop that's still getting double orders with Paypal standard (IPN + PDT) - even after the .js 'submit' button fix posted a while back by PaulM. It would appear that it's not necessarily always caused by the customer clicking the 'Submit' button twice.

Typically, each of the orders will have a different order No., and be timed a few seconds apart - sometimes 1 second apart.

The first order will contain the callback response from Paypal (order status = 'Processing') but not the grey block with all the transaction info in.

The second order will have the grey block with the transaction info, and will also be 'Processing'.

In our experience, the customer gets charged only once though.

Pixxi, thank you for your post. Not that I'm happy you're having issues, but I'm glad to see I'm not alone.

For reference in this thread, here's the Paypal tech email reply to LissaE that the post I quoted above referred to:

Dear Lissa,

We have already verified that we do not send a txn_type of unique through either IPN or PDT. I have seen that this variable is used by Zen Cart in the Zen Cart forums. The only thing more you could do is implement raw logging to see what you are actually receiving from us.

I do see that your shopping cart is passing the variable rm=2 which causes the return method to be a POST.

From HTML posted by your cart:
<input type="hidden" name="rm" value="2" />

According to our docs at https://cms.paypal.com/us/cgi-bin/?c...t_ID=developer/e_howto_html_Appx_websitestandard_htmlvariables, "If set to “2” and if a “return” value is submitted, the buyer will be sent back to the return URL using a POST method, to which all available transaction variables will also be posted."

If it is an option within the Zen Cart you may want to change that variable to "1" so that the return is a GET. Or just remove that line altogether. With PDT the information is sent via a GET so it would be best to avoid conflicting instructions.

Since you are using both IPN and PDT you will receive duplicate posts from PayPal. The only thing further I could recommend is disabling one or the other, or adjust the coding in your script to deal with duplicate posts.

Regards,

http://www.zen-cart.com/forum/showthread.php?t=118940

Dr Byte,

Since leaving the PDT field empty in the Paypal module doesn't always seem to work for all people (and since PDT is apparently the more reliable of the two methods), what would be the likely outcome of un-ticking the IPN checkbox in the Paypal admin (ie turning IPN off at Paypal) - could the Paypal module work with PDT alone?

The whole reason why PayPal added PDT support in the first place was because the IPN architecture is flakey and prone to failure.
Neither IPN nor PDT are ideal solutions for submitting orders in an advanced system like Zen Cart. Both have significant limitations.

While turning off IPN at PayPal would force your site to only receive orders via PDT, that also prevents your site from receiving notices about refunds, captures, voids, fraud flags, echecks clearing, and more. So, that's not an ideal solution.

And, setting rm=1 will cause the IPN response system to receive no data because it's expecting it in POST format, not GET format. And, Zen Cart has security measures in place to limit long GET strings commonly used by hackers to cause trouble.

I still maintain that Express Checkout is a much better choice than relying on IPN to complete orders. (Express still uses IPNs to handle cleared echecks, refund updates, etc, but is NOT used for completing orders at checkout, since a much more advanced and reliable method is used during the checkout process.)
And, in v1.3.9b you'll find that the request to create an account when using Express Checkout is less likely to appear except in certain geographic regions where PayPal has particular reasons (sometimes regulatory) to require an account to be created.

ToniScraparoni:

I'd be happy to give you admin and server access. Please let me know if that would be acceptable. If so, also where I can send your login credentials.
I appreciate your offer, but would prefer not to have access to your admin area.

Right. That's what I thought. ;)

I called Paypal to ask about Express Checkout and spoke to Rachel. She says there won't be a difference to the customer, they'll still have the option to use a credit card. So I'm going to try switching. It seems like even more doubles are coming through since upgrading (now to 1.3.9b).

Fingers crossed this goes smoothly. :unsure:

Switched modules to Express, and then no one could check out. Similar to other threads I found on this issue, the customer is told their address isn't confirmed and redirected back to the cart, even when the address is confirmed.

If I change the module setting not to require a confirmed address, orders go through, but I'm without seller protection.

I fail to see how Express is superior. Obviously there's an ongoing issue in the communication between Paypal and the Express module, just as there is with IPN. Given these discussions have been taking place for three years, and the advice given is not to require a confirmed address, I guess it's something no one cares about fixing. Or whether Zen merchants are protected.

So I'm back to IPN and being the double order police, the lesser of two evils.

Once again, without being equipped with the information I need to replicate the problems you're reporting, either with Express or IPN, there's not much I can do to help you. I've tried all kinds of combinations of settings and options and customer addresses and countries and currencies and taxes ... and can't consistently recreate the problems you describe when building on a clean uncustomized install.

I'd help if I could. But, I must wait on you.