Woocommerce: Mutliple Email Notifications for New Orders WC 3.0

[jondavy]

EXPLANATION OF THE ISSUE

STEPS TO REPRODUCE THE ISSUE

SYSTEM STATUS

### WordPress Environment ###

Home URL: http://store.stageonesports.com
Site URL: http://store.stageonesports.com
WC Version: 3.0.0
Log Directory Writable: ✔
WP Version: 4.7.3
WP Multisite: –
WP Memory Limit: 512 MB
WP Debug Mode: –
WP Cron: ✔
Language: en_US

### Server Environment ###

Server Info: Apache
PHP Version: 5.6.30-1+wpengine8
PHP Post Max Size: 100 MB
PHP Time Limit: -1
PHP Max Input Vars: 1000
cURL Version: 7.35.0
OpenSSL/1.0.1f

SUHOSIN Installed: –
MySQL Version: 5.6.35
Max Upload Size: 50 MB
Default Timezone is UTC: ✔
fsockopen/cURL: ✔
SoapClient: ✔
DOMDocument: ✔
GZip: ✔
Multibyte String: ✔
Remote Post: ✔
Remote Get: ✔

### Database ###

WC Database Version: 3.0.0
WC Database Prefix: wp_ucmfru_
woocommerce_sessions: ✔
woocommerce_api_keys: ✔
woocommerce_attribute_taxonomies: ✔
woocommerce_downloadable_product_permissions: ✔
woocommerce_order_items: ✔
woocommerce_order_itemmeta: ✔
woocommerce_tax_rates: ✔
woocommerce_tax_rate_locations: ✔
woocommerce_shipping_zones: ✔
woocommerce_shipping_zone_locations: ✔
woocommerce_shipping_zone_methods: ✔
woocommerce_payment_tokens: ✔
woocommerce_payment_tokenmeta: ✔
MaxMind GeoIP Database: ✔

### Security ###

Secure connection (HTTPS): ❌Your store is not using HTTPS. Learn more about HTTPS and SSL Certificates.
Hide errors from visitors: ✔

### Active Plugins (45) ###

LayerSlider WP: by Kreatura Media – 5.6.4
Advanced Custom Fields: Gallery Field: by Elliot Condon – 1.1.1
Advanced Custom Fields: Repeater Field: by Elliot Condon – 1.1.1
Advanced Custom Fields: by Elliot Condon – 4.4.11
Brankic Photostream Widget: by Brankic1979 | Modified by MPC Team – 1.4
Contact Form 7: by Takayuki Miyoshi – 4.7
CSS3 Responsive Web Pricing Tables Grids: by QuanticaLabs – 10.3
Envato WordPress Toolkit: by Envato – 1.7.3
Essential Grid: by ThemePunch – 2.0.9.1
Gravity Forms: by rocketgenius – 2.2.1
Product Sales Report Pro for WooCommerce: by Potent Plugins – 2.0.5
Icegram - Popups, Optins, CTAs & lot more...: by icegram – 1.10.3
WooCommerce Quickview: by James Kemp – 3.3.1
MPC Mega Menu: by Lee Chestnutt | Modified by MPC Team – 1.5
WPBakery Visual Composer: by Michael M - WPBakery.com – 4.11.2.1
MPC Extensions: by MassivePixelCreation – 3.8.2
MPC Importer: by MassivePixelCreation – 1.2
MPC Shortcodes: by MassivePixelCreation – 3.8.2
MPC Widgets: by MassivePixelCreation – 3.8.2
PayPal for WooCommerce: by Angell EYE – 1.3.3
ReadyShipper WooCommerce API: by TrueShip
LLC – 1.0.5

Really Simple CAPTCHA: by Takayuki Miyoshi – 1.9
Regenerate Thumbnails: by Alex Mills (Viper007Bond) – 2.2.6
Slider Revolution: by ThemePunch – 5.4.1
Subscribe2: by Matthew Robinson
Tanay Lakhani – 10.22 | Modified by MPC Team

Social Media and Share Icons (Ultimate Social Media): by UltimatelySocial – 1.6.6
Woocommerce Exclude Categories PRO: by Alvaro Neto – 2.0
WooCommerce Bulk Stock Management: by WooCommerce – 2.2.6 – 2.2.7 is available
WooCommerce Email Customizer: by WooThemes – 1.1.5
WooCommerce - Facebook Tab: by WooThemes – 1.2.0
WooCommerce MultiStep Checkout: by Mubashir Iqbal – 2.3.6
OneSaas Connect: by OneSaas – 2.0.6.7
WooCommerce Order Status Manager: by WooThemes / SkyVerge – 1.6.3 – 1.7.0 is available
WooCommerce Print Invoices/Packing Lists: by WooThemes / SkyVerge – 3.1.7 – 3.2.0 is available
WOOF - WooCommerce Products Filter: by realmag777 – 2.1.6.1
WooCommerce Password Protected Categories: by Barn2 Media – 1.5.3
WooCommerce Shipment Tracking: by WooCommerce – 1.6.3 – 1.6.4 is available
WP All Import - WooCommerce Add-On: by Soflyy – 1.3.2
WooCommerce: by Automattic – 3.0.0
WooSidebars: by WooThemes – 1.4.3
WooCommerce Helper: by WooCommerce – 1.7.2 – Network enabled
Yoast SEO: by Team Yoast – 4.5
WP All Export Pro: by Soflyy – 1.4.5
WP All Import Pro: by Soflyy – 4.4.3
WP101 Video Tutorials: by WP101Plugin.com – 0.3

### Settings ###

API Enabled: ✔
Force SSL: ✔
Currency: USD ($)
Currency Position: left
Thousand Separator: ,
Decimal Separator: .
Number of Decimals: 2
Taxonomies: Product Types: external (external)
grouped (grouped)
simple (simple)
variable (variable)


### WC Pages ###

Shop base: #5 - /shop/
Cart: #6 - /cart/
Checkout: #7 - /checkout/
My account: #8 - /my-account/

### Theme ###

Name: Blaszok
Version: 3.8.2
Author URL: http://mpcreation.net
Child Theme: ❌ – If you're modifying WooCommerce on a parent theme you didn't build personally
then we recommend using a child theme. See: How to create a child theme

WooCommerce Support: ✔

### Templates ###

Overrides: blaszok/woocommerce/archive-product.php
blaszok/woocommerce/cart/cart-empty.php
blaszok/woocommerce/cart/cart-shipping.php
blaszok/woocommerce/cart/cart-totals.php
blaszok/woocommerce/cart/cart.php version 2.3.8 is out of date. The core version is 3.0.0
blaszok/woocommerce/cart/cross-sells.php version 1.6.4 is out of date. The core version is 3.0.0
blaszok/woocommerce/cart/mini-cart.php
blaszok/woocommerce/cart/shipping-calculator.php
blaszok/woocommerce/checkout/form-billing.php
blaszok/woocommerce/checkout/form-checkout.php
blaszok/woocommerce/checkout/form-shipping.php
blaszok/woocommerce/content-product.php version 2.5.0 is out of date. The core version is 2.6.1
blaszok/woocommerce/content-product_cat.php version 2.5.2 is out of date. The core version is 2.6.1
blaszok/woocommerce/content-single-product.php
blaszok/woocommerce/loop/add-to-cart.php
blaszok/woocommerce/loop/loop-end.php
blaszok/woocommerce/loop/loop-start.php
blaszok/woocommerce/loop/no-products-found.php
blaszok/woocommerce/loop/pagination.php
blaszok/woocommerce/loop/result-count.php
blaszok/woocommerce/loop/sale-flash.php
blaszok/woocommerce/myaccount/form-add-payment-method.php version 2.1 is out of date. The core version is 2.6.0
blaszok/woocommerce/myaccount/form-edit-address.php version 2.1.0 is out of date. The core version is 2.6.0
blaszok/woocommerce/myaccount/form-login.php version 2.2.6 is out of date. The core version is 2.6.0
blaszok/woocommerce/myaccount/my-address.php version 2.2.0 is out of date. The core version is 2.6.0
blaszok/woocommerce/myaccount/my-orders.php
blaszok/woocommerce/notices/error.php
blaszok/woocommerce/notices/notice.php
blaszok/woocommerce/notices/success.php
blaszok/woocommerce/order/order-details.php version 2.5.3 is out of date. The core version is 3.0.0
blaszok/woocommerce/order/tracking.php
blaszok/product-searchform.php
blaszok/woocommerce/single-product/meta.php version 1.6.4 is out of date. The core version is 3.0.0
blaszok/woocommerce/single-product/product-image.php version 2.0.14 is out of date. The core version is 3.0.0
blaszok/woocommerce/single-product/product-thumbnails.php version 2.3.0 is out of date. The core version is 3.0.0
blaszok/woocommerce/single-product/related.php version 1.6.4 is out of date. The core version is 3.0.0
blaszok/woocommerce/single-product/review.php version 2.5.0 is out of date. The core version is 2.6.0
blaszok/woocommerce/single-product/sale-flash.php
blaszok/woocommerce/single-product/tabs/additional-information.php version 2.0.0 is out of date. The core version is 3.0.0
blaszok/woocommerce/single-product/tabs/description.php
blaszok/woocommerce/single-product/tabs/tabs.php
blaszok/woocommerce/single-product/up-sells.php
blaszok/woocommerce/single-product-reviews.php

Outdated Templates: ❌Learn how to update

[claudiulodro]

EXPLANATION OF THE ISSUE

STEPS TO REPRODUCE THE ISSUE

I need this information to investigate the issue.

[mikejolley]

https://wordpress.org/support/topic/duplicate-order-emails-with-3-0/

[roykho]

I also ran into this issue a couple times. Doesn't happen every time but still. It seems sometimes the cron job gets stuck and keeps repeating.

So on every refresh of the page, that cron job persists. Normally after the job is done, it should not show on that page anymore. ( Using WP Crontrol ).

[jondavy]

Issue: System sends multiple auto-generated emails to customer for new orders marked as processing.
Reproduce issue: It is a system generated issue that automatically reproduces.

[DavidAnderson684]

Could the fact that WP cron can fire a single registered cron event multiple times be relevant here? This is how easy it is to get WP cron to fire events multiple times: if you run your webserver and MySQL on the same machine, and do anything to drive up the load average so that the CPUs are fully occupied (i.e. load average > number of CPUs), and then fire off a few concurrent HTTP requests, then it'll more-or-less happen every time. It's the norm, not the exception.

It's a few years ago now, but a WP core dev (can't find the reference - sorry!) told me that this is not considered a defect, and that plugins should be ready to handle the same event being fired by wp-cron multiple times, as if it were part of the official API. WP cron hasn't changed since then. WP cron is a horrible tangle of nasty race conditions and defective design, mostly owing to it storing every cron event in a single serialized array/option. And this means too that on busy stores, you risk losing events you thought you'd scheduled entirely due to concurrent access. That happens this way: WP loads the 'cron' option early; it gets cached; then when you save it, that cached array is what gets updated and written to the database. (There's no locking when writing; and the locking when reading has a serious design flaw that means it often fails). Meanwhile, some other PHP process is doing the same, i.e. writing its own version of the array to the same option, but without yours. And if your server is overloaded, or busy, this is just so very distressingly easy to do.

But it can't always have been the case that this was not considered a defect; in fact, this ticket is still open, after 7 years: https://core.trac.wordpress.org/ticket/11800

Hence plugins where it matters have to reinvent the wheel with a different API (one that could actually be relied on!), e.g. (already bundled in Subscriptions): https://github.com/Prospress/action-scheduler .

Sadly, it's not even possible to write a plugin to replace WP-Cron with something more sane (e.g. one row per cron job) - the hooks don't exist. Patches exist, but stuck in Trac: https://core.trac.wordpress.org/ticket/32656 . So, solutions get implemented on a plugin-by-plugin basis, with semaphore locks, alternative engines with their own APIs, etc. :-(

[mikejolley]

@justinshreve @claudiosanches @claudiulodro Do we need to revert this after all and work on action schedular for core? :/ I like that checkout is quick, but if it's causing breakage we cannot fix..

[claudiulodro]

Is there an easy fix?
E.g.

• Set a metadata on the order when the email is scheduled and also store the value in the cron args.
• After the e-mail is fired remove the metadata from the order object. If the order object doesn't have the metadata, don't fire the e-mail.

That should prevent sending more than one of the same scheduled e-mail.

[DavidAnderson684]

@claudiulodro Unfortunately, that just adds a second race-prone lock, on top of WP cron's existing race-prone lock. So, it might reduce the percentage a bit (I would suspect very little, because of MySQL query cacheing), but it can't eliminate the issue.

The problem is that when there's load, it's easy for two PHP processes which are fired at a similar time to both see the same thing when they read the database, before the other process's UPDATE gets through. i.e. if they're checking a naive "is it locked?" field (i.e. not implementing a true semaphore lock), they both get the same answer, "no, it's not". And if you're waiting until an email has been fired, that's comparatively a big window; talking to an SMTP server can bring in multi-second delays. If in a log file (I code on a backup/restore plugin with over 1 million installs) I see WP cron fire a duplicate cron event 15 seconds later, I'm not that surprised (though of course, smaller gaps are more common - e.g. same-second, 1 second).

And that's just read locks. WP cron has no write locks (which it needs because of storing all jobs in a single MySQL row - it wouldn't need them if it stored them one-per-line). Consider this scenario, in which both processes run at the same rate (i.e. this one is not load, but concurrency):

Time 0: PHP process A starts, and reads the autoloaded "cron" array from the options table.
TIme 1: PHP process B starts, and reads the autoloaded "cron" array from the options table.
Time 2: PHP process A adds an event to its version of the array, my_event_a, and writes the array to the database.
Time 3: PHP process B adds an event to its version of the array, my_event_b, and writes the array to the database.

Result: my_event_a vanishes into the aether and is never seen again. Hopefully it wasn't for anything you cared about!

IMO, WP-Cron should have been taken round the back of the shed and hit with a spade many years ago. Not being able to fix it with a plugin is the icing (if you have any influence with any core devs... https://core.trac.wordpress.org/ticket/32656 ... sorry to repeat myself!!).

[DavidAnderson684]

So, FWIW (it's not a solution, but by-the-by), there is actually a plugin that does hook into WP cron and store its stuff a table instead of a single row, via the rather nasty hack of filtering on pre_option when the cron array is saved and working out what's being changed in it. Details: https://core.trac.wordpress.org/ticket/15148

[DavidAnderson684]

The pr seems to add one more naive/race-prone database lock (check lock row, if locked then quit, else set as locked) on top of WP-Cron's existing one. That means that the timings of concurrent requests have to be such that requests fall into two race windows, instead of just one. But the probability of hitting two in the situations where you were already likely to hit one is pretty high, in my experience (with UpdraftPlus and attempts to prevent duplicate backups due to the WP-Cron design flaw).

On the plus side, I think you'll escape the problem of events which vanish into the aether via using one row per scheduled item.

Why not lock the queue with a real semaphore instead of a naive row check? This can be done via relying on the consistency guarantees of SQL. Example (N.B. You have to ensure the options table entries involved are pre-created, that's in a separate file):
http://plugins.svn.wordpress.org/updraftplus/trunk/includes/class-semaphore.php

N.B. WP_Background_Process abuses the transients API by using it as a reliable temporary data store, which it is not. It is a data store for data which can be potentially lost and the consumer is ready to re-create if needs be. The difference is subtle, because the default store-in-MySQL back-end has the properties of a real reliable temporary data store; but this is incidental; see: https://core.trac.wordpress.org/ticket/20316#comment:47 . It's legitimate for the transient store to be a memory cache that drops the value immediately if it sees fit. i.e. This class will normally work; but I don't know whether that's the design intention of it, or whether it's intended to "always" work (modulo freak events in the class of database corruption, MySQL crash, rather than more 'ordinary' ones like "memcached was short of memory so decided to drop it").

Sorry if all this is already known/intentional. I thought that since I'd already added by £0.02 I'd better comment on the pr in case silence was understood as an implied "this will work perfectly".

[mikejolley]

@DavidAnderson684 The background process class uses transients for locks, not for the data. The data is stored as options, like WP cron.

Yes tables would be better, but I can hardly build that into a point release :p We'll have to look into a more robust system in the future. For now;

• This lets you disable defered emails via filter
• This uses background processing to reduce likelihood of events firing multiple times or not at all
• This uses cron only as a fallback

[DavidAnderson684]

@mikejolley I was unclear - when I was talking about "data store" in relation to WP_Background_Process, I was meaning the transient storage - I was aware that the email data isn't going through that class. What I was referring to is the fact that because it stores the lock using WP's transient API, on some sites, there will be times when you want the "is it locked?" check to return "yes", but it won't, because of the transient API's nature as something that may drop the stored value well before the time you indicated. Sites that use MySQL as the transient store are safe from this problem.

This is a separate issue from the previous paragraph: "This uses background processing to reduce likelihood of events firing multiple times or not at all" - what I try to say in my previous comment is that, on my memory of testing solutions of this sort (around 3 years ago, but WP Cron hasn't changed since then), the pr will only cause a very small reduction in that likelihood. It should, however, remove the "not at all" case, AFAICT.

A semaphore-based lock that relies upon SQL's consistency properties doesn't involve new tables - it involves 3 new options in the options table.

I won't have any more time for comments this afternoon, as I have things scheduled now. But I'd suggest testing it on a setup on which you have the the webserver and MySQL on the same machine, and you write something that allows you to ramp the CPU usage up to 100%. Then schedule some events, and fire off concurrent HTTP requests, and view the results. When I've done this test on WP Cron, the chances of duplicate events are very high - there's no secret sauce involved. Having reproduced that, it should then be easy to verify whether I'm right about the 'naive lock' in the pr not bringing much more to the table in terms of preventing those duplicates.

[DavidAnderson684]

@mikejolley I might be missing some subtlety of how "background events" differ from wp-cron. I couldn't see the substantial difference, from the code. WP Cron's default setup tries to make things run in the background too, via loopback HTTP calls, and then lock checking, and on my brief look a this pr, I thought it was functionally identical. But am rushing somewhat.

[DanielSantoro]

Only adding a ticket here so I can follow along with updates. Thanks for the hard work, all. :)

556674-zd-woothemes

[mikejolley]

@DavidAnderson684 I think some of what you're saying is true. There is a difference afaik - cron events here are all independent and run whenever, or not at all. Whereas the background class tries to load itself once (using the lock transients) and does the events in batches. I think thats more stable. It won't fix everything of course but we don't have a more robust scheduler available right now.

[mikejolley]

And yeah, we could kill it for now :) But the filter is there to disable this as needed which was not there before.

[frankug]

I know this has been closed but we have a similar issue still with Woocommerce 3.08. Only with orders paid by paypal. We get 2 new order emails. if the customers chooses any other gateways including paypal pro, cash on delivery etc. we have no problem. Is anyone aware of this issue?

[scotthopkins]

Similar to frankug above... we get two new order emails sent to customer and to admin...
we also use PayPal and are on Woocommerce 3.08.

they are identical emails sent at the same time... I can't tell if they are sent at the same second - but definitely in the same minute based on my outgoing mail log.

[keepsmilyn]

We too are having duplicate (identical) order notifications being sent and using PayPal with woocommerce 3.0.8. FYI: They aren't being sent to the admin multiple times, just the email address under Woocommerce -> Settings -> Emails -> New Orders -> Recipient(s) field.

[scotthopkins]

Hi - I've added this to functions.php - to see if it has any impact

/** Disable deferred email sending */
add_filter( 'woocommerce_defer_transactional_emails', '__return_false' );

[galbaras]

Coming late to this party, @DavidAnderson684 , I run wp_cron from a cron job every 15 minutes, making duplication of jobs unlikely, but still got 2 copies of new order admin messages (not sure about customer, but I'm guessing they did too).

@scotthopkins since the default behavior is to defer, your filter is unlikely to be doing anything. You might want to test deferring by returning true, though, just in case.

@mikejolley the key here may be the PayPal gateway, because people keep mentioning it, but is it also possible that WC_Background_Emailer is adding more than one 'dispatch_queue' action to 'shutdown'?

[scotthopkins]

@galbaras thanks for clarifying - I am in no way an expert :) will test

[elshorshino]

Same as frankug, scotthopkins & keepsmilyn - Getting duplicate order emails only with Paypal. Interestingly, it's not happening with every Paypal order just 2 out of the last 5.

[scotthopkins]

@elshorshino - I will also add I have found it is not every order... I can't see any pattern... some new, some existing... no difference in how woo has processed the order from what I can tell.

I notice this issue is closed - how do we open it again - are we meant to - I'm new to github and proper protocols for interacting here. Thank you.

[elshorshino]

@scotthopkins - indeed, something like this is pretty hard to troubleshoot when it's intermittent! Think its best to create a new issue as this one has been closed. Just had a quick look and there doesn't seem to be any similar open issues...

[mikejolley]

@elshorshino @scotthopkins

woocommerce_defer_transactional_emails is no longer needed. This feature is disabled.

Mail is sent right away like in 2.6.x. If it's not, use mail logging plugin, debug conflicts.

[scotthopkins]

@mikejolley appreciate your attention... yeah it was a long shot and sorry for the confusion... it is not that there is a delay in mail - it's doubles of order mails being created and sent - not on every order and with the PayPal gateway being the common thing among us so far.

[mikejolley]

Have you checked order notes? Those record the status changes for things like IPN.

[elshorshino]

@mikejolley Yes, seems the order notes are duplicated too, I get two messages of "Order status changed from Pending payment to Processing."

[mikejolley]

Same time? Do you have both PDT and IPN enabled?

[scotthopkins]

@mikejolley - YES both PDT and IPN are enabled... maybe that is the culprit.

on my install for the orders that created double emails I see in notes that it goes from pending to processing - then to complete... and shows both PDT and IPN.
https://www.dropbox.com/s/mwks7vhog2qvnbu/Screenshot%202017-06-21%2021.31.44.png?dl=0

for orders where it does not happen it goes from pending to complete - with no processing step and only PDT OR IPN
https://www.dropbox.com/s/683xl60zr578jqr/Screenshot%202017-06-21%2021.37.11.png?dl=0

I checked my paypal log a day ago and from memory, it only ever showed payment as complete in there... no errors etc.

[elshorshino]

@mikejolley @scotthopkins same here, shows both PDT and IPN on orders with the issue.

[scotthopkins]

@mikejolley what is recommended here then please... PDT or IPN as that seems to be the obvious reason :)

so we should really remove the PDT token? As from what I am reading just now IPN carries more information than PDT in the transaction?

from Paypal KB
_"IPN is best for back-end operations, while PDT is a front-end feature and can't receive notifications of updates on pending, refunded, or reversed transactions."_

https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1142&actp=RSS

[mikejolley]

If IPN works, it's better. I suspect IPN and PDT are coming in at the same time so it thinks the order needs updating.

[scotthopkins]

@mikejolley ok - will remove PDT token and monitor - THANKS !! I guess this must be new behaviour somehow :)

[andrewfitz]

I experience the same issue, get responses from both PDT and IPN. This did not happen in the past, even when both were enabled. How would you choose which to pick? Even if you put in token for PDT, how do you disable IPN, or why would you? If you can't disable IPN to use just PDT, then why have PDT as an option if it results in duplicates? Is this caused by a bug or feature? Google and issues searches for this issue don't bring much up, so it seems fairly new problem.

[galbaras]

My duplicate emails are also associated with having both PDT and IPN notes in the order. Seems like a bug, in WC, because PayPal has only processed the payment once, but WC has done it twice.

Assuming a payment transaction can be uniquely identified (I'm guessing with the '_transaction_id' post meta), it should be matched before creating redundant notes, or possibly before doing anything else with it, provided that its completion status hasn't changed.

This seems a better way than disabling the safety of having two confirmation methods.

@mikejolley ?

[bekarice]

fwiw it may be worth opening a new issue for this @mikejolley wrt PayPal -- have seen other issues with IPN / PDT both processing at the same time, firing actions multiple times. for example, if they come in at the exact same time, it triggers a race condition with order auto-exports when the order is paid; exports are processed twice since the meta flag to mark it as exported isn't persisted yet + the action fires multiple times.

You'll often see duplicated order notes as well in this set up, which isn't ideal, so I'm sure that order emails and exports probably aren't the only things seeing duplication.

[galbaras]

For the time being, is the solution to disable PDT?

[elshorshino]

Seems like it for now - @scotthopkins how have you got on since you disabled PDT?

[mikejolley]

@bekarice It's pretty much related to https://github.com/woocommerce/woocommerce/issues/12467 With the current system I don't see how it can be preventable if the DB is hit at the same time. I guess 3.0.x just made that race condition window greater because of the gap between reading and writing order data.

[galbaras]

@mikejolley perhaps using background processing is a good thing, because some reconciliation can then be done by transaction ID and changes can only be committed to the order once, emails sent, etc. Basically, when transactions occur, a slight delay shouldn't matter too much to users, but incorrect inventory and too many emails might.

[keepsmilyn]

So is there a way to stop the duplicate emails, even just temporarily for now?

It's concerning to know that it may also put duplicate orders and order notes in the admin too. We use the order data to auto-export orders to a third party system and worried this may start sending duplicate order info. Eeek! Our client hasn't advised of any such issue yet, but perhaps when we update their woo to the latest version it may start occurring. :-(

[galbaras]

Yes. Clear the PayPal Identity Token field in the PayPal gateway settings (WooCommerce->Settings->Checkout->PayPal).

BTW, after posting about background handling of transactions, I realised it would be far better to use semaphors. They are quick and specific and, if implemented via the database, will prevent concurrent handling of anything. There may be a need for separate semaphors to prevent double transaction confirmation and incorrect inventory counting, but this method can help with both things.

[keepsmilyn]

Have removed the PayPal identity Token, now to wait for the next order. Sigh!

By the way, do I need to have any IPN settings changed as per the tool tip on this field since its no longer being used. Tool tip on this field says: "This will allow payments to be verified without the need for PayPal IPN".

[galbaras]

What you've done disables PDT, not IPN. IPN should continue to work, assuming it did before. Since that's what I've done, I seriously hope I'm right ;P

[scotthopkins]

Hi - just updating that this seems to have resolved it for me... thanks.

[amouratoglou]

I have this problem..paypal orders are created . no emails sent.
because the user doesn't complete the payment.

other payment methods, work perfect, send emails normally.

[frachello]

I have this problem and have both PDT and IPN enabled.
The orders that generate 2 completed order emails to the customer have both the PDT and IPN completed payments notes. The orders that correctly generate only one email have either the PDT and IPN completed payments notes.
If I disable PDT would I risk problems (unsent customer notification emails) with the orders that would naturally trigger PDT and not IPN?

[scotthopkins]

Hi - if you read through everything above PDT is not needed... I removed it and have had no issue - we sell subscriptions and one time.

from Paypal KB
"IPN is best for back-end operations, while PDT is a front-end feature and can't receive notifications of updates on pending, refunded, or reversed transactions."

https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1142&actp=RSS

[frachello]

Thank you @scotthopkins. I removed the PDT token from the Woocommerce / PayPal settings and made a test purchase. It all worked fine.
Would you suggest also disabling PDT on my Paypal.com settings, under website payments?

[scotthopkins]

Your welcome - I did but it's up to you of course :)

[glaing]

@scotthopkins This worked for me too!

[TomasHurtz]

Hello - I am also seeing duplicated emails - but I believe this might be related to duplicated orders in my case

For one customer, the duplicated order then cancels automatically after the stock timeout which has caused a lot of complaints and confusion!

PDT is only operational on some of the sites, but others are also experiencing this - where there is only Stripe.

[nosgihderf]

Hey! Was this issue resolved as I'm seeing this happen now? I'm not using PayPal but using Stripe.

[Braintelligence]

@nosgihderf Were you able to fix your problem? I'm also running into this while using Stripe currently.

[opicron]

+1 on removing PDT token, solved it for me-- shouldnt this be something which Woocommerce checks/warns about?

[dsychungaos]

We have the same issue, we thought it happens only on stripe gateway, yet recently found one paypal order had the same issue.
Happens randomly, once in a few days, some sent 2-8 emails, but a few can sent up to 13 emails. The customers are receiving email with the same content.

[gondre]

same issue here. woocommerce_payment_complete is often called twice, and the issue happens with Paypal (I'm using PDT and have disabled IPN) but also with Stripe.