Coupons -> Allowed Emails don't work as expected

[francas]

Describe the bug
A coupon may be used by any user (even guest) regardless of billing email.

To Reproduce
Steps to reproduce the behavior:

1. Setup a coupon and add test@gmail.com to Allowed Emails
2. Try to use the coupon while logged in with a user with different billing email or as a guest
3. Coupon is applied regardless of Allowed Emails

Expected behavior
Coupon should be applied only if the billing email is in Allowed Emails list.

Isolating the problem (mark completed items with an [x]):

• I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active.
• This bug happens with a default WordPress theme active, or Storefront.
• I can reproduce this bug consistently using the steps above.

WordPress Environment

``` ` ### WordPress Environment ###

WordPress address (URL): https://provita.lt
Site address (URL): https://provita.lt
WC Version: 4.0.1
REST API Version: ✔ 1.0.7
WC Blocks Version: ✔ 2.5.14
Action Scheduler Version: ✔ 3.1.4
WC Admin Version: ✔ 1.0.3
Log Directory Writable: ✔
WP Version: 5.4
WP Multisite: –
WP Memory Limit: 256 MB
WP Debug Mode: –
WP Cron: ✔
Language: lt_LT
External object cache: –

Server Environment

Server Info: LiteSpeed
PHP Version: 7.2.29
PHP Post Max Size: 64 MB
PHP Time Limit: 60
PHP Max Input Vars: 5000
cURL Version: 7.62.0
OpenSSL/1.0.2k

SUHOSIN Installed: –
MySQL Version: 5.5.5-10.2.31-MariaDB
Max Upload Size: 64 MB
Default Timezone is UTC: ✔
fsockopen/cURL: ✔
SoapClient: ✔
DOMDocument: ✔
GZip: ✔
Multibyte String: ✔
Remote Post: ✔
Remote Get: ✔

Database

WC Database Version: 4.0.1
WC Database Prefix: wp_
Total Database Size: 7.54MB
Database Data Size: 5.47MB
Database Index Size: 2.07MB
wp_woocommerce_sessions: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_api_keys: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_attribute_taxonomies: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_downloadable_product_permissions: Data: 0.02MB + Index: 0.06MB + Engine InnoDB
wp_woocommerce_order_items: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_order_itemmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_tax_rates: Data: 0.02MB + Index: 0.06MB + Engine InnoDB
wp_woocommerce_tax_rate_locations: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_shipping_zones: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_woocommerce_shipping_zone_locations: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_shipping_zone_methods: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_woocommerce_payment_tokens: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woocommerce_payment_tokenmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_woocommerce_log: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_actionscheduler_actions: Data: 0.02MB + Index: 0.11MB + Engine InnoDB
wp_actionscheduler_claims: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_actionscheduler_groups: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_actionscheduler_logs: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_cartflows_ca_cart_abandonment: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_cartflows_ca_email_history: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_cartflows_ca_email_templates: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_cartflows_ca_email_templates_meta: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_commentmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_comments: Data: 0.30MB + Index: 0.38MB + Engine InnoDB
wp_dpd_barcodes: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_dpd_manifests: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_links: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_litespeed_img_optm: Data: 0.02MB + Index: 0.09MB + Engine InnoDB
wp_litespeed_optimizer: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_multiparcels_shippings: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_multiparcels_shipping_shipments: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_options: Data: 2.34MB + Index: 0.14MB + Engine InnoDB
wp_postmeta: Data: 0.16MB + Index: 0.06MB + Engine InnoDB
wp_posts: Data: 1.52MB + Index: 0.06MB + Engine InnoDB
wp_shipment_batch_process: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_termmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_terms: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_term_relationships: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_term_taxonomy: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_usermeta: Data: 0.06MB + Index: 0.03MB + Engine InnoDB
wp_users: Data: 0.02MB + Index: 0.05MB + Engine InnoDB
wp_wc_admin_notes: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_wc_admin_note_actions: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_wc_category_lookup: Data: 0.02MB + Index: 0.00MB + Engine InnoDB
wp_wc_customer_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_download_log: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_order_coupon_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_order_product_lookup: Data: 0.02MB + Index: 0.06MB + Engine InnoDB
wp_wc_order_stats: Data: 0.02MB + Index: 0.05MB + Engine InnoDB
wp_wc_order_tax_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB
wp_wc_product_meta_lookup: Data: 0.02MB + Index: 0.09MB + Engine InnoDB
wp_wc_tax_rate_classes: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_wc_webhooks: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_woo_shippment_provider: Data: 0.06MB + Index: 0.00MB + Engine InnoDB
wp_yoast_seo_links: Data: 0.02MB + Index: 0.02MB + Engine InnoDB
wp_yoast_seo_meta: Data: 0.05MB + Index: 0.00MB + Engine InnoDB

Post Type Counts

attachment: 28
cookielawinfo: 2
custom_css: 2
customize_changeset: 6
nav_menu_item: 16
page: 10
post: 10
product: 1
revision: 155
shop_coupon: 4
shop_order: 3
wpforms: 1

Security

Secure connection (HTTPS): ✔
Hide errors from visitors: ✔

Active Plugins (20)

Akismet Anti-Spam: by Automattic – 4.1.4
GDPR Cookie Consent: by WebToffee – 1.8.7
Customer Reviews for WooCommerce: by ivole – 3.103
Estonian Shipping Methods for WooCommerce: by Konekt OÜ – 1.5.8.1 – Not tested with the active version of WooCommerce
Google Analytics for WordPress by MonsterInsights: by MonsterInsights – 7.10.4
Google Analytics Opt-Out: by WP-Buddy – 2.3.2
Jetpack by WordPress.com: by Automattic – 8.4.2
LiteSpeed Cache: by LiteSpeed Technologies – 2.9.9.2
Loco Translate: by Tim Whitlock – 2.3.3
"LP Express" Shipping Method for WooCommerce: by Martynas Žaliaduonis – 1.0.5 – Not tested with the active version of WooCommerce
Perfect WooCommerce Brands: by QuadLayers – 1.8.3
Unique Headers: by Ryan Hellyer – 1.7.12
WC Hide Shipping Methods: by Rynaldo Stoltz – 1.3
Advanced Shipment Tracking for WooCommerce: by zorem – 2.9.5
WooCommerce Cart Abandonment Recovery: by CartFlows Inc – 1.2.5
Checkout Field Editor for WooCommerce: by ThemeHigh – 1.4.2
WooCommerce Payment Gateway - Paysera: by Paysera – 2.5.6 – Not tested with the active version of WooCommerce
WooCommerce Admin: by WooCommerce – 1.0.3
WooCommerce: by Automattic – 4.0.1
Yoast SEO: by Team Yoast – 13.5

Inactive Plugins (2)

Coming Soon Page, Under Construction & Maintenance Mode by SeedProd: by SeedProd – 5.1.0
Query Monitor: by John Blackbourn – 3.5.2

Dropin Plugins (1)

advanced-cache.php: advanced-cache.php

Settings

API Enabled: –
Force SSL: –
Currency: EUR (€)
Currency Position: left
Thousand Separator:
Decimal Separator: ,
Number of Decimals: 2
Taxonomies: Product Types: external (external)
grouped (grouped)
simple (simple)
variable (variable)

Taxonomies: Product Visibility: exclude-from-catalog (exclude-from-catalog)
exclude-from-search (exclude-from-search)
featured (featured)
outofstock (outofstock)
rated-1 (rated-1)
rated-2 (rated-2)
rated-3 (rated-3)
rated-4 (rated-4)
rated-5 (rated-5)

Connected to WooCommerce.com: ✔

WC Pages

Shop base: #822 - /
Cart: #7 - /krepselis/
Checkout: #8 - /checkout/
My account: #9 - /mano-paskyra/
Terms and conditions: #45 - /taisykles/

Theme

Name: Shopisle Child Theme
Version: 1.0
Author URL: http://provita.lt
Child Theme: ✔
Parent Theme Name: Shop Isle
Parent Theme Version: 1.1.60
Parent Theme Author URL: https://themeisle.com
WooCommerce Support: ✔

Templates

Overrides: shopisle-child/single-product-reviews.php

Action Scheduler

Complete: 36
Oldest: 2020-04-09 17:26:59 +0300
Newest: 2020-04-25 13:26:51 +0300

`

</details>

[tammullen]

Hi @francas

Thank you for submitting the issue. However, I can’t reproduce the issue you reported using the steps you provided. Everything is working as expected on my end.
​

I set up a coupon with email restriction

I applied the coupon to an order with a different email address to that listed in the coupon

As expected I was not able to use it
​
Please provide us with more details about the issue which may help us to evaluate it further such as any other coupon settings.

I also see that you have several plugins installed and that you don’t use one of our default themes which could cause an issue. Please test your site for theme and plugins conflict. To do that, you’d need to deactivate all plugins except for WooCommerce and switch the default theme such as Storefront. Then test again.
​
If the issue is resolved with the default theme and all plugins deactivated, it means that one of your plugins or a theme is causing the issue. You will then need to enable it one by one and test every time you do that in order to figure out which plugin is causing the issue.

[Marcoevich]

Similar issue here: #26305

I have tested this as well. When logged in with an email address that doesn't belong to the coupon, the coupon applies to the cart without issue. (there should be a check here). So from the perspective of the user, the coupon is applied succesfully. Only when the complete order button is pressed during checkout, it becomes clear that the coupon cannot be applied and it will be removed from the cart. Imho this is one step too late. This coupon shouldn't have been applied in the first place.

[francas]

I agree, the validation should definitely be triggered on coupon add, not order complete action.

[tammullen]

Hi @Marcoevich and @francas

Thanks for your feedback, we do the coupon verification on the placing order step as the billing details can be modified up until this point and the billing details will be part of coupon validation.

[francas]

From the User Experience standpoint, it makes no sense for a user to see the coupon successfully added to only later witness it to be removed. I would definitely not buy from such store as I'd feel they're making fool of me.

If billing details are also a part of validation, then maybe it is wise to split the validation in two, or just add additional trigger for "coupon add" action.

[Marcoevich]

You have the function get_email_restrictions which is called in check_customer_coupons in your wc-cart-class. Wouldn't it be possible to call this function when pressing the apply coupon button on the cart page? You already have the functionality in place, just need to call it earlier :)

[homeworker]

The validation should be triggered on coupon add, not on order complete action.
Think for a moment you are a guest client or old client, you place the order convinced that you get the discount and then when you place the order you have no discount applied (happen with paypal payment for example).
Why not ask the email at same time with the coupon if you are a guest and validate on coupon add for registered one?

[zdenys]

This is indeed confusing from the user perspective. Another report in 3444258-zen.

[zdenys]

Another case of a confused user in 25224820-hc.

@tammullen is there a chance the default behavior do the coupon verification on the placing order step as the billing details can be modified up until this point and the billing details will be part of coupon validation will be changed? Or should the public documentation clarify the current expected behavior to avoid continuous confusion?

[Marcoevich]

Even with documentation there will be continuous confusion. I would still rather have this corrected to improve the user experience.

[sukafia]

Hmmm... another report here 3796626-zen. I also find this really confusing.

[zigang93]

any manual/hardcode way to change this weird behaviour? I agreed that the validation should definitely be triggered on coupon add, not order complete action.

[apmwebdev]

Another report in 27845696-hc.

[tammullen]

Adding needs developer feedback label to get developer input on if the validation can be performed earlier.

[daschenbrener]

Anyone with any type of update or work for this?

[attacking6]

about a year passed and still people reporting this, is it really hard to do such a thing?

[joshangehr]

Came across this one today and glad I found this issue. I agree with the above that the coupon should not be applied unless the billing email address matches one in allowed emails. Retroactively removing a coupon after it's already visually been applied to the cart does present a confusing and poor customer UX.

It seems like the argument for the tradeoff is that the billing address can still be changed before the order is placed. This makes sense, but as a customer, I wouldn't be surprised if the coupon code entered—one that applies only to my email address—did not work if I left that field blank. The error message would ideally inform me that the coupon isn't valid, which would prompt me to enter the correct email address and continue the checkout experience.

[csmcneill]

Another report in 31565453-hc.

[hassanyousufx]

Did anyone solve this issue?

[ChasHenrySEO]

Thank you [image: Logo] <https://chlocalmedia.com/> Charles (Chas) Henry Founder & Managing Director C.H. Local Media, LLC An Award Winning Marketing Agency <https://chlocalmedia.com/multi-award-winning-tupelo-marketing-agency/> T: (662) 589-2427 | M: (662) 610-1919 E: ***@***.*** | chlocalmedia.com 2217 MS-370 | Baldwyn, MS 38824 [image: Facebook icon] <https://www.facebook.com/chlocalmedia> [image: LinkedIn icon] <https://www.linkedin.com/company/chlocalmedia> [image: Twitter icon] <https://twitter.com/chlocalmedia> [image: Youtube icon] <https://www.youtube.com/channel/UC1fXf1GiU9XiHxuGTTVJD8w> [image: Instagram icon] <https://www.instagram.com/chlocalmedia> "*Empowering You To Build A Strong Brand and Successful Business In Your Industry & Community*." [image: Banner] <https://chlocalmedia.com/> The content of this email is confidential and intended for the recipient specified in the message only. It is strictly forbidden to share any part of this message with any third party, without the written consent of the sender. If you received this message by mistake, please reply to this message to let us know and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

…

On Wed, Jul 12, 2023 at 7:58 AM Barry Hughes ***@***.***> wrote: @ChasHenrySEO <https://github.com/ChasHenrySEO> it sounds a little like perhaps you or someone else has added restrictions in the coupon editor, that didn't previously exist? Might be worth revisiting how things are configured there. Otherwise, it may be better to create a new issue, or even start with a support thread <https://wordpress.org/support/plugin/woocommerce/>. — Reply to this email directly, view it on GitHub <#26289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A46YF4PDXQVGJ3SHMJGK4LDXP2NOZANCNFSM4MQWILFQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[barryhughes]

Changing team allocation: this seems like it is equally applicable to the 'classic' and Blocks-driven experience, but we probably do not have bandwidth to address the first of those.

[ZoZoLee]

This is a huge problem with guest users!
The coupons show that they have been applied correctly, even though there is no email address entered. This would make some amount of sense, if the discount was then applied automatically when they enter the correct email address. However, this does not occur. The notice still says "Applied Successfully" but no discount is applied unless they enter the code again.
If they have to enter the code again after entering their email address anyway, why in the world can't we just have an error code stating than an email address must be entered before applying the coupon?
The fake "Coupon Successful" message causes so much confusion.
many people check out without realizing that the code has never actually applied, and then want refunds for their missing discounts.
This is a mess!

[elizaan36]

👋 The ideal solution would be for the coupon field to trigger an error if an unauthorized email is used to apply a coupon (whether the coupon is valid or not.)

To simplify things, we can use an error string that can be applied to all use cases. Although it's not exact feedback for the user we feel that presenting a dynamic error message based on the use case would overcomplicate the experience. This solution will solve the main problem in this issue, which is the confusion caused by deferred validation of the coupon code.

Enter a valid coupon

cc @pmcpinto if you have additional thoughts on this.

[wavvves]

@elizaan36 looking at this from the opposite angle, wouldn't it discourage and mislead guests and users planning to use the correct email address to complete the checkout flow?

What do you feel about a specific error message, in this case, declining gracefully the coupon eg:

Poor choice of words, I know, but the general idea is informing the user what is wrong while admitting the coupon possibility. 🤔

[elizaan36]

Yes, it's not direct feedback but the intention was to solve the main problem efficiently. If we'd like to present an error string specifically for this use case, the message can change to something like, “Not authorized to use this coupon”. Or referring to exactly what needs to change as in your suggestion.

[wavvves]

Hi @elizaan36 👋🏼

I opened a draft PR to investigate the possibility of changing this behaviour according to your suggestion, but found some blockers.

Validating the coupon upfront and prevent applying it would mean that it couldn't be added on Cart as there is no way to change the billing address there, and validating it on Checkout would mean changing the information sent to the apply coupon endpoints, which needed to contain the email field data. Simply adding validation to deny the coupon would prevent it from ever being added on guest and accounts with mismatching emails, as seeing the coupon applied on Cart and Checkout would mean the user would have to update it through my account in a separate process.

I detailed my findings and suggestions in this RFC pdFofs-1GQ-p2 as I think this needs a bit more work finding a clear path to proceed.

cc @pmcpinto

[MBATeam-Jamie]

@wavvves thank you for attempting to address the issue. I do not believe you must return a "this coupon could be valid" message. The behavior would be improved simply by not claiming success when the user hasn't met the conditions for applying the coupon.

[wavvves]

Hi @MBATeam-Jamie, thanks for the feedback.
You might want to have a look at the open PR #43872. Any feedback would be appreciated :)

[namiokuzono]

7701180-zd-a8c

[pmcpinto]

Hey @wavvves when do you plan to complete this work? It's still assigned to cycle 1. Should we move it to cycle 2?

[ahirhemant]

Hey @wavvves,

I'm still experiencing the same issue with creating coupon codes for specific users based on their email addresses. Even without logging in, the coupon code gets applied successfully, which shouldn't be the case. Ideally, users should be prompted to provide a valid email or receive a related message when attempting to apply the coupon.

Could you please advise on the proper implementation to ensure that the coupon code is applied only for logged-in users or those whose email addresses meet the specified criteria?

Thanks
Ahir

[wavvves]

Hey @wavvves when do you plan to complete this work? It's still assigned to cycle 1. Should we move it to cycle 2?

Hi @pmcpinto, sorry I missed this ping. This has been put in progress again, and some work and planning were required to accommodate context-based messages for cart and checkout (there was no similar system in place). It is now a small tweak away from being up for review and merge (I'll push for a merge tomorrow).

[wavvves]

Hey @wavvves,

I'm still experiencing the same issue with creating coupon codes for specific users based on their email addresses. Even without logging in, the coupon code gets applied successfully, which shouldn't be the case. Ideally, users should be prompted to provide a valid email or receive a related message when attempting to apply the coupon.

Could you please advise on the proper implementation to ensure that the coupon code is applied only for logged-in users or those whose email addresses meet the specified criteria?

Thanks Ahir

Hi @ahirhemant
Work is in progress and nearb conclusion, you can follow the progress here #43872

Currently, allowed emails coupons are being validating only when placing orders (so they will be applied on cart and checkout regardless of ownership). The mentioned PR will change this behaviour to validate at the moment the coupon is inserted, requiring the correct billing email to be used.

[pmcpinto]

@wavvves thanks for the update. This will be included in 8.8, correct?

[ahirhemant]

Hi @wavvves this will be in 8.6.2 Version ?

[wavvves]

@wavvves thanks for the update. This will be included in 8.8, correct?

Hi @pmcpinto, That's the plan, yes. The porter role delayed this a bit, but the plan is to get reviewer-requested changes approved tomorrow and merge them before the 8.8 code freeze.

[wavvves]

Hi @wavvves this will be in 8.6.2 Version ?

Hi @ahirhemant, no, this will be released as part of WooCommerce 8.8 release.

[dsmithweb-a8c]

7888174-zen

[namiokuzono]

7964652-zd-a8c

[HOTMAMAGP]

I'm having an issue with allowed emails whereby I enter the emails, save and when I go back the field is empty and the email addresses I inserted are gone...So anyone who has the coupon code effectively can use it

[darcie]

@HOTMAMAGP this sounds like a different issue, and I recommend contacting support or creating a new issue if you have performed conflict testing and it remains. Get support in our forum here: https://wordpress.org/support/plugin/woocommerce/