DEV Community: Emdadul Huq

Why Shopify Merchants Need Smarter Discount Protection

Emdadul Huq — Thu, 03 Sep 2026 17:03:33 +0000

Discounts are one of the most effective tools Shopify merchants use to increase conversions, reward loyal customers, recover abandoned carts, and run seasonal promotions.

But there is another side to discounting that receives much less attention:

discount abuse and revenue leakage.

Creating a discount is easy. Controlling exactly who can use it, when they can use it, and under what conditions is much harder.

For stores running high-value promotions, VIP campaigns, influencer coupons, wholesale pricing, or limited-time offers, poorly controlled discounts can quietly reduce margins.

In this article, I want to explore the problem and how we approached it while building CrispShift Discount Guard.

The Problem With Traditional Discount Campaigns

Imagine a Shopify merchant creates the following promotion:

50% OFF
Minimum order: $700
Eligible customers: VIP only

The business expectation seems straightforward.

But several questions immediately appear:

How do we verify that the customer is actually a VIP?
What happens if another discount is already applied?
Can the coupon be combined with other promotions?
What happens if the code gets shared publicly?
Should the discount work outside the intended market?
How do we know when somebody attempted to use it incorrectly?

Without additional protection logic, a discount campaign can become difficult to control.

A promotional rule should therefore be treated as more than just:

discount = 50%

A more realistic model looks like:

discount = 50%

AND customer.tag = "vip"

AND order.total >= 700

AND campaign.active = true

AND duplicate_discount = false

AND market_allowed = true

This turns a simple discount into a policy-controlled discount.

Discount Protection as a Validation Layer

One useful way to think about discount protection is as an additional validation layer around the discount engine.

Instead of immediately asking:

What discount should this customer receive?

we first ask:

Is this checkout eligible to receive this discount?

Conceptually, the flow looks like this:

Checkout
   ↓
Campaign Detection
   ↓
Eligibility Validation
   ↓
Protection Rules
   ↓
Discount Calculation
   ↓
Apply / Reject

The validation layer can evaluate multiple conditions before allowing the discount.

For example:

function isEligible({ customer, cart, campaign }) {
  if (!campaign.active) {
    return false;
  }

  if (cart.total < campaign.minimumOrderAmount) {
    return false;
  }

  if (
    campaign.requiredCustomerTag &&
    !customer.tags.includes(campaign.requiredCustomerTag)
  ) {
    return false;
  }

  if (campaign.blockDiscountStacking && cart.hasExistingDiscount) {
    return false;
  }

  return true;
}

The actual implementation in a production Shopify app will naturally be more complex, but the principle remains the same:

validation should happen before the promotion is trusted.

Protecting Different Types of Discounts

Discount protection should not be limited to product discounts.

A merchant may need to protect:

Product discounts

Example:

20% off selected products

Rules could include:

Selected products only
Minimum quantity
Specific customer segment
Campaign schedule

Order discounts

Example:

$100 off orders above $700

Possible protections:

Minimum subtotal
Customer eligibility
Country restrictions
No conflicting promotions

Shipping discounts

Example:

Free shipping for VIP customers

Possible validation:

Customer tag = VIP
Market = US
Order total >= $150

Having the same protection model across product, order, and shipping discounts makes the campaign system easier to manage.

Preventing Duplicate Discount Stacking

One of the most important problems is unintended discount stacking.

Consider this scenario:

VIP50 → 50% OFF
WELCOME20 → 20% OFF

If both discounts are allowed simultaneously, the final discount may become significantly larger than the merchant intended.

The business expected:

50% maximum discount

but the checkout behavior might effectively produce something far more aggressive.

For high-margin businesses this may be acceptable.

For low-margin businesses, it can be extremely expensive.

A protection layer therefore needs to detect:

existing discount
+
incoming protected discount
+
combination policy

before determining whether the campaign should continue.

Customer Eligibility Should Be Explicit

Not every discount belongs to every customer.

For example:

VIP50

might only be intended for customers containing:

customer.tags = ["vip"]

The campaign can define:

{
  "discount": {
    "type": "percentage",
    "value": 50
  },
  "eligibility": {
    "requiredCustomerTag": "vip",
    "minimumOrderAmount": 700
  }
}

The validation becomes deterministic:

Has VIP tag?
      ↓
     Yes
      ↓
Order >= $700?
      ↓
     Yes
      ↓
Apply Discount

Otherwise:

Reject Discount

This is much safer than allowing a campaign to depend only on possession of a coupon code.

Coupon Codes Are Not Secrets

This is an important principle.

A merchant may create a coupon like:

VIP50

and distribute it privately.

But once a code is:

sent through email,
shared with influencers,
posted in communities,
copied from checkout,
indexed by coupon websites,

it should no longer be considered secret.

Therefore:

knowing the coupon code should not automatically mean being eligible for the promotion.

Eligibility rules become the actual security boundary.

The coupon code is simply an identifier.

Detecting Suspicious Checkout Behavior

Another useful layer is checkout behavior monitoring.

Suppose a protected coupon is intended for a controlled acquisition campaign.

A system may want to detect signals such as:

Protected coupon applied
Customer does not satisfy campaign rules
Coupon entered manually
Multiple conflicting discounts detected
Unexpected checkout context

The important point is not necessarily to block every unusual event.

Instead, merchants should be able to define what constitutes unacceptable behavior for a particular campaign.

For example:

const protectionRules = {
  blockDuplicateStacking: true,
  requireCustomerTag: true,
  requiredTag: "vip",
  minimumOrderAmount: 700,
  blockInvalidCheckout: true
};

Different merchants can then apply different levels of protection.

Visibility Matters as Much as Blocking

Blocking invalid discounts solves only half the problem.

The merchant also needs to understand:

What was blocked?
Why was it blocked?
Which campaign was involved?
How often is it happening?
How much discount value may have been prevented?

For that reason, protection systems should maintain analytics around blocked attempts.

A simplified event might look like:

{
  "campaign": "VIP50",
  "status": "blocked",
  "reason": "missing_customer_tag",
  "cartTotal": 700,
  "discountValue": 350
}

Aggregating these events can help merchants identify patterns.

Estimating Protected Revenue

Suppose someone attempts to use:

50% OFF

on a:

$700 cart

and the attempt is rejected because the customer is not eligible.

The prevented discount value would be:

$700 × 50% = $350

This can be represented as estimated protected revenue or estimated protected discount value.

There is an important distinction here.

It is not necessarily confirmed revenue.

The customer may abandon the checkout after the discount is rejected.

Therefore analytics should clearly distinguish between:

Blocked discount value

and:

Confirmed paid-order revenue

Good analytics should never blur these two metrics.

Campaign Health Is Another Important Problem

Discount protection is not only about malicious or unauthorized usage.

Operational failures can also create problems.

For example:

Campaign active in database
        ↓
Discount engine failed to synchronize
        ↓
Merchant assumes campaign is working
        ↓
Checkout behaves differently

A discount management system should therefore provide visibility into:

Campaign Status
Engine Status
Synchronization Status
Protection Activity
Blocked Attempts

Instead of simply showing:

Active

a more useful operational state might be:

Campaign: Active
Engine: Synced
Protection: Enabled
Last Sync: Successful

This makes troubleshooting significantly easier.

Example: Protected VIP Campaign

Let's combine everything.

A merchant wants:

50% OFF for VIP customers
Minimum order: $700

Protection configuration:

{
  "campaign": "VIP50",
  "discount": {
    "type": "percentage",
    "value": 50
  },
  "rules": {
    "minimumOrderAmount": 700,
    "requiredCustomerTag": "vip",
    "blockDuplicateStacking": true,
    "blockInvalidCheckout": true
  }
}

Now consider three customers.

Customer A

VIP tag: Yes
Order: $900
Existing discount: No

Result:

✅ Discount allowed

Customer B

VIP tag: No
Order: $900
Existing discount: No

Result:

❌ Discount blocked
Reason: Customer eligibility

Customer C

VIP tag: Yes
Order: $900
Existing discount: Yes

Result:

❌ Discount blocked
Reason: Duplicate discount stacking

The coupon is identical in all three checkouts.

The context determines whether it should be accepted.

Building CrispShift Discount Guard

These problems motivated us to build CrispShift Discount Guard for Shopify.

The goal is not simply to create another discount generator.

The goal is to give merchants an additional control layer around their promotions.

The system focuses on areas such as:

Protected discount campaigns
Customer eligibility
Minimum order validation
Product eligibility
Country and market rules
Campaign scheduling
Duplicate discount protection
Checkout validation
Blocked-attempt analytics
Estimated protected revenue
Campaign and engine health

The broader idea is simple:

A promotion should behave like a business rule, not just a coupon code.

A Better Mental Model for Discounts

Traditionally, we might represent a promotion as:

Coupon → Discount

For more complex Shopify stores, I think a better model is:

Coupon
   ↓
Campaign
   ↓
Eligibility
   ↓
Protection
   ↓
Validation
   ↓
Discount
   ↓
Analytics

This gives merchants much greater control over promotional behavior.

Final Thoughts

Discount systems become more complicated as a Shopify store grows.

A small store may be perfectly comfortable with simple coupon codes.

But stores running:

influencer campaigns,
affiliate promotions,
VIP programs,
wholesale pricing,
high-value discounts,
seasonal campaigns,
customer-segment promotions,

need stronger controls.

The most important principle is:

Possessing a discount code should not automatically establish eligibility for the discount.

Treat discounts as policies.

Validate the checkout context.

Track rejected attempts.

Monitor campaign health.

And give merchants enough visibility to understand exactly how their promotions are being used.

That is the direction we're taking with CrispShift Discount Guard.

If you're building Shopify apps or working with complex discount strategies, I'd be interested to hear how you're approaching discount abuse, eligibility validation, and coupon leakage.

CrispShift Discount Guard:
https://apps.shopify.com/discount-guard-pro

Original article:
https://medium.com/@emdadul225/why-shopify-merchants-need-smarter-discount-protection-472de74165f9

How to Install Pyenv on Ubuntu 24.04

Emdadul Huq — Thu, 25 Jul 2024 06:07:36 +0000

Due to the slowness of repositories or even lack thereof being updated with specific versions of Python, I’ve decided to move some of my environments over to Pyenv to allow me to dynamically install and configure Python specifically for my environment. As it turns out this will also allow VS Code to allow me to choose the version of Python that I’d like to use when testing. So, here’s a quick guide to installing Pyenv on Ubuntu 24.04

Update and install dependencies

we need to ensure our package cache is updated, and then install the dependencies to download, and build python from pyenv.



sudo apt-get update && sudo apt-get install make build-essential

Install Pyenv using pyenv-installer



curl https://pyenv.run | bash

Configure user profile to use pyenv

Ensure the following is in your ~/.bash_profile (if exists), ~/.profile (for login shells), ~/.bashrc (for interactive shells), or ~/.zshrc



# Load pyenv automatically by appending
# the following to 
# ~/.bash_profile if it exists, otherwise ~/.profile (for login shells)
# and ~/.bashrc (for interactive shells) :

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

Optionally enable pyenv-virtualenv



eval "$(pyenv virtualenv-init -)"

Reload your profile



source ~/.profile

Install python using pyenv



pyenv install <version>

Set your python version

pyenv shell — select just for current shell session
pyenv local — automatically select whenever you are in the current directory (or its subdirectories)
pyenv global — select globally for your user account

Validate your installation of python



python3 --version

Reference Pyenv

How to configure an Nginx server on Ubuntu 22.04 with Django and uWSGI

Emdadul Huq — Sat, 09 Sep 2023 09:43:41 +0000

1. Update Your Server

It’s always a good idea to start by updating your server.

sudo apt-get update
sudo apt-get upgrade

Now we have the latest and greatest packages installed on the server.

2. Use a Virtual Environment for Python

The venv module allows you to create virtual Python environments. This allows you to isolate installed packages from the system.

After installing venv, make a directory to house your virtual environments, and then create a virtual environment named env using venv. You can call your virtual environment whatever you prefer.

sudo apt-get install python3-venv
mkdir Workstations && cd Workstations
python3 -m venv env

Now activate your virtual environment.

source env/bin/activate

You will see the name of your virtual environment in the parenthesis as a prefix to your env

3. Create a Django Project

Now we install the Django web framework using the pip package installer.

pip install Django

Next let’s create a Django project with django-admin which should be on your path by default. Feel free to choose a project name that suites you. For example we will use the name of our project called mysite.

django-admin startproject mysite
cd mysite

Now test our project using following commands:

python manage.py runserver 0.0.0.0:8000

In a browser, you should be able to visit mysite:8000 and see the default Django landing page, if not, you might you be see a error message like this:

if you see this error message, add your domain name to the mysite/settings.py file.

Try to visit mysite.com:8000 again and this time you will see the Django landing page.

4. Get Started with uWSGI

First we need to install the web server gateway interface (WSGI). In this case, we will be using uWSGI. You will also need the development packages for your version of Python to be installed.

sudo apt-get install python3.8-dev
sudo apt-get install gcc
pip install uwsgi

We will see to send requests from the client to Nginx which will pass them to a socket that will hand them off to uWSGI before finally being given to Django.

Create a file called server-test.py with the following content:

def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    return [b"Hello World!"]

Let's test our uWSGI directly talking to python with the following command

uwsgi --http :8000 --wsgi-file server-test.py

In a browser, you should be able to visit mysite.com:8000 and see the test Hello World!

If this works for you, we have demonstrated that uWSGI is able to pass requests to Python.

Now we can similarly serve the Django Project with the following command:

uwsgi --http :8000 --module mysite.wsgi

Note that this works because the path mysite/wsgi.py exists.

5. Configure the Nginx Web Server

Install Nginx with apt-get as follows:

sudo apt-get install nginx

Now with Nginx installed, you will be able to visit the default Welcome to nginx! page in your browser at http://mysite.com .

Let’s tell Nginx about our Django project by creating a configuration file at /etc/nginx/sites-available/mysite.conf. Change the highlighted lines to suite your needs.

# the upstream component nginx needs to connect to
upstream django {
    server unix:///home/emdad/mysite/mysite.sock;
}
# configuration of the server
server {
    listen      80;
    server_name mysite.com www.mysite.com;
    charset     utf-8;
    # max upload size
    client_max_body_size 75M;
    # Django media and static files
    location /media  {
        alias /home/emdad/mysite/media;
    }
    location /static {
        alias /home/emdad/mysite/static;
    }
    # Send all non-media requests to the Django server.
    location / {
        uwsgi_pass  django;
        include     /home/emdad/mysite/uwsgi_params;
    }
}

We need to create the /home/emdad/mysite/uwsgi_params file highlighted above on line 26 as well.

uwsgi_param  QUERY_STRING       $query_string;
uwsgi_param  REQUEST_METHOD     $request_method;
uwsgi_param  CONTENT_TYPE       $content_type;
uwsgi_param  CONTENT_LENGTH     $content_length;
uwsgi_param  REQUEST_URI        $request_uri;
uwsgi_param  PATH_INFO          $document_uri;
uwsgi_param  DOCUMENT_ROOT      $document_root;
uwsgi_param  SERVER_PROTOCOL    $server_protocol;
uwsgi_param  REQUEST_SCHEME     $scheme;
uwsgi_param  HTTPS              $https if_not_empty;
uwsgi_param  REMOTE_ADDR        $remote_addr;
uwsgi_param  REMOTE_PORT        $remote_port;
uwsgi_param  SERVER_PORT        $server_port;
uwsgi_param  SERVER_NAME        $server_name;

Next we can publish our changes by creating a symbolic link from sites-available to sites-enabled like so:

sudo ln -s /etc/nginx/sites-available/mysite.conf /etc/nginx/sites-enabled/

We must edit the mysite/settings.py file to explicitly tell Nginx where our static files reside.

First add import os at the very beginning:

"""
Django settings for mysite project.
Generated by 'django-admin startproject' using Django 3.1.2.
For more information on this file, see
https://docs.djangoproject.com/en/3.1/topics/settings/
For the full list of settings and their values, see
https://docs.djangoproject.com/en/3.1/ref/settings/
"""
import os
from pathlib import Path
# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent

and STATIC_ROOT = os.path.join(BASE_DIR, "static/") at the very end:

...
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/3.1/howto/static-files/
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, "static/")

With these changes in place, we can now tell Django to put all static files in the static folder.

python manage.py collectstatic

Restart the Nginx server to apply changes.

sudo /etc/init.d/nginx restart

At this point if you visit http://mysite.com a browser, you will probably see an Nginx 502 Bad Gateway error,

mkdir media
wget https://www.google.com/logos/doodles/2020/thank-yo…c-transportation-workers-6753651837108759-2xa.gif -O media/media.gif

Finally visit http://mysite.com/media/media.gif in a browser and you should see the image

6. Get Nginx, uWSGI, and Django to Work Together

Let’s take this one step further and have Nginx, uWSGI, and Django work together with the help of the UNIX socket.

uwsgi --socket mysite.sock --module mysite.wsgi --chmod-socket=666

You can actually try the above command without the --chmod-socket=666 argument and/or with a --chmod-socket=664 argument instead. If either of those work for you, just keep that in mind going forward.

Once again, visit http://mysite.com in a browser, and this time you should see the default Django landing page!

7. Configure uWSGI for Production

we configure a file at the root of your Django project called mysite_uwsgi.ini .

[uwsgi]
# full path to Django project's root directory
chdir            = /home/emdad/mysite/
# Django's wsgi file
module           = mysite.wsgi
# full path to python virtual env
home             = /home/emdad/env
# enable uwsgi master process
master          = true
# maximum number of worker processes
processes       = 10
# the socket (use the full path to be safe
socket          = /home/emdad/mysite/mysite.sock
# socket permissions
chmod-socket    = 666
# clear environment on exit
vacuum          = true
# daemonize uwsgi and write messages into given log
daemonize       = /home/emdad/uwsgi-emperor.log

You can then proceed to start up uwsgi and specify the ini file:

uwsgi --ini mysite_uwsgi.ini

visit http://mysite.com in a browser and see the default Django landing page if everything works correctly.

As one last configuration option for uWSGI, let’s run uWSGI in emperor mode. This will monitor the uWSGI config file directory for changes and will spawn vassals (i.e. instances) for each one it finds.

cd /home/emdad/mysite/env/
mkdir vassals
sudo ln -s /home/emdad/mysite/mysite_uwsgi.ini /home/emdad/env/vassals/

Now you can run uWSGI in emperor mode as a test.

uwsgi --emperor /home/emdad/env/vassals --uid www-data --gid www-data

Visit http://mysite.com a browser and you will see the default Django landing page if everything works correctly.

Finally, we want to start up uWSGI when the system boots. Create a systemd service file at /etc/systemd/system/emperor.uwsgi.service with the following content:

[Unit]
Description=uwsgi emperor for mysite domains website
After=network.target
[Service]
User=emdad
Restart=always
ExecStart=/home/emdad/mysite/env/bin/uwsgi --emperor /home/emdad/mysite/env/vassals --uid www-data --gid www-data
[Install]
WantedBy=multi-user.target

Enable the service to allow it to execute on system boot and start it so you can test it without a reboot.

systemctl enable emperor.uwsgi.service
systemctl start emperor.uwsgi.service

Visit http://mysite.com a browser and you will see the default Django landing page if everything works correctly.

Check the status of the service and stop it as follows:

systemctl status emperor.uwsgi.service
systemctl stop emperor.uwsgi.service

Now reboot your system to make sure that your website is accessible at startup.