[Done v1.3.9e] 1.3.9a Double Orders

[DrByte]

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.

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.

[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.

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?

[DrByte]

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.

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.

[ToniScraparoni]

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.

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.

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.

[Pixxi]

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..._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?

[DrByte]

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.

[DrByte]

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.

[ToniScraparoni]

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.

[ToniScraparoni]

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.

[DrByte]

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.