The month closes and the revenue looks fine. The margin does not. You open the discount report and there it is: SARAH20, the code you wrote for one creator with 40,000 followers, redeemed 912 times. Sarah's post did well, but it did not do 912-well, and the orders do not look like her audience. They are first-time buyers, spread across the country, most of them landing on a product page directly and checking out in under two minutes with a cart sitting exactly at the qualifying threshold. Somewhere in week two the code stopped being Sarah's and became everyone's, and the only reason you found out is that you happened to look.
The other version of this is smaller and just as constant. You set a welcome code to one use per customer, and a regular takes it four times using four inboxes. The community boards have a thread for this in almost every language, usually titled with some variation of discount code, same customer, multiple email addresses. Shopify's own answer has been consistent for years: the restriction is matched on the email, there is no secondary verification, and the request has been passed to the product team. Both stories are the same story. A discount code is a password that you print in public and hope only the right people type.
What Shopify actually does, and where it stops
Shopify gives you two real controls, and it is worth being precise about what each one does. The first is a cap on total redemptions, which limits how expensive the leak gets but not whether it happens, and which is blunt in the wrong direction: set it at 1,000 and a leaked code burns through your best customers' goodwill for a thousand orders before it stops. The second is limit to one use per customer, which sounds like identity and is actually string matching. Shopify ties the restriction to the customer record on the checkout, and that record comes from the email typed into the form. A second inbox is a second customer. A plus-addressed alias is a second customer. Guest checkout under a work address is a second customer. The setting reliably stops the honest shopper who tried to reuse a code and reliably fails against anyone who did not want to be stopped, which is the same shape of problem as the per-customer purchase limit that resets every order.
What Shopify does not do is notice. There is no leak detection anywhere in the admin. Nothing alerts you when a code's redemption rate jumps tenfold overnight, nothing flags that 94 percent of a creator code's redemptions came from people who had never bought from you and never saw the post, and nothing at all tells you that a browser extension is auto-applying your code at checkout for shoppers who arrived ready to pay full price. From the platform's point of view, a valid code was entered and accepted. That is the whole transaction. The discount report will tell you how many times a code was used, accurately, whenever you decide to go and read it.
Unique single-use codes are the standard advice, and they genuinely work, because a code that dies on first use cannot be shared twice. They also move the work rather than removing it. Now you are minting batches of codes, matching each one to a person, delivering it, tracking which were used, expiring the rest, and doing it again for the next campaign. Creators dislike them, because a unique code cannot be spoken aloud in a video or printed in a caption, which is exactly how creator codes are meant to travel. So most stores keep a public code for the channels that need one and accept the risk, which is a reasonable choice right up until the code leaks and nobody notices for three weeks.
Shopify records the redemption perfectly. It has no opinion about whether the person redeeming it was ever supposed to have the code.
The automation instinct is to hand this to Shopify Flow, and Flow can do the second half of the job. It can see which discount codes were applied to an order and can tag, hold, or cancel that order, which is useful once you already know a specific code is compromised. It cannot do the first half, which is noticing. Every condition Flow evaluates reads one order in isolation, and a leak is not a property of any order. It is a shape across many of them: the pace of redemptions climbing hour over hour, the first-time-buyer share rising, the average cart drifting down toward the qualifying minimum, traffic arriving from cities the campaign never ran in. No single order looks wrong. This is the same structural wall that duplicate order detection runs into, and it has the same consequence: the comparison happens in a human's head, on a schedule, or it does not happen.
Why doing it by hand never keeps up
The manual version is a monthly ritual, and monthly is the problem. A leak has a half-life measured in days. A code posted to a coupon site on Tuesday is being auto-applied by extensions across the internet by Thursday, and by the time it turns up in a month-end margin review it has paid for itself several hundred times over in discounts you never offered. Every day of delay is money, and the review that would have caught it is competing with everything else in a merchant's week.
The response is worse than the delay. Having found the leak, the obvious move is to deactivate the code, and deactivating a code is a blunt instrument that hits the wrong people first. Sarah's post is still live and still sending real traffic, and those shoppers now hit a checkout that rejects the code she promised them, which produces exactly the support ticket and the abandoned cart you were trying to avoid. Meanwhile the customer who legitimately has the code in an email from you gets declined for something a stranger did. Kill the code and you punish your buyers; leave it and you fund a coupon site. A merchant deciding this at 11pm usually picks whichever error they can live with, not the right answer.
And the reuse case does not respond to effort at all. Spotting that four orders under four email addresses share a shipping address and a card is a query nobody runs, which is the same identity problem behind the customer Shopify counts three times and the reason a blocklist built on an email address never holds. The abuse is cheap to commit and expensive to detect, which is the definition of a job for software.
What the automation actually has to do
A working answer is not a stricter rule. It is a watcher with judgement: something that knows what normal looks like for each code, notices when a code stops behaving like itself, decides whether that is a good day or a leak, and responds in a way that costs the abuser something and the customer nothing. As a Dugong playbook, in plain prose, it reads like this:
# trigger
On every discount code redemption
# steps
1. Watch each code's pace, first-time-buyer share,
cart size, and traffic source against its own
normal
2. Judge leak or good day: a campaign spike comes
with the campaign, a leak comes from nowhere,
from strangers, at the minimum cart
3. Retire the compromised code and issue single-use
codes to the people who should have had it
4. Protect the honest buyer: honor the code for
shoppers who really received it, do not decline
a real customer mid-checkout
5. Match the person, not the string, when the same
welcome code returns under a new alias
6. Tell the creator and fix the commission before
the invoice is paid
Six lines, and the judgement they imply is the entire product. Knowing that a code doing 30 redemptions an hour is fine on launch night and alarming on a Tuesday three weeks later. Reading the difference between a creator's audience, which browses, adds a second item, and buys from a link, and an extension's traffic, which lands on one product and checks out at the threshold in ninety seconds. Choosing the proportionate response: sometimes retire and replace, sometimes just add a minimum spend or exclude your thinnest-margin products, sometimes only tag the suspect orders so the finance side of the house can settle the affiliate invoice with real numbers. And writing the note to Sarah that starts with the good news, that her code worked, before the part where 700 of those redemptions were not hers.
Why this is a compiler problem, not an app problem
There are apps for the pieces. Some generate unique codes in bulk. Some detect coupon extensions in the browser and hide the discount field. Some monitor a list of coupon sites for your codes. Each one solves a slice and none of them makes the decision, because the decision is not mechanical. Is this spike a leak or a good day. Is this code worth saving or worth replacing. Does this customer get honored or declined. Does this creator get an email or an adjusted invoice. Those calls depend on your margin, your campaign calendar, and how much a given customer is worth to you, and they change every week. A fixed rule holds them badly in both directions: too tight and you decline real buyers at the last step of a purchase, too loose and you fund a coupon aggregator's business model out of your gross margin.
It also sits in a neighborhood this desk keeps mapping. Its closest relative is the discount code that double-dips your sale, where the code is legitimate and the stacking is not. The behavioral read that separates a real buyer from a discount hunter is the same one behind segmenting repeat customers. The bot side of the problem shares machinery with card testing, where a burst of small orders is the tell, and the judgement about whether to intervene mid-purchase is the one the high-risk flag hands you without any evidence. On the promotion side, the same watcher that catches a leak is the one you want running real quantity breaks and a scheduled sale without a person at the keyboard.
Picture a coffee roaster running a creator program with 30 codes. On a Wednesday, code BREW15 goes from four redemptions a day to sixty in an afternoon, all first-time buyers, all landing on one product page, all at a cart within a dollar of the free-shipping threshold, all from search rather than the creator's link. Without the playbook, this is discovered in a month-end review after roughly 1,400 discounted orders and a commission invoice nobody can defend. With it running, the pattern trips within the hour. The code is retired for new traffic, single-use replacements go out to the creator's real subscriber list, the 60 leaked orders are tagged for the finance review, the creator gets a note before she hears it from anyone else, and the merchant reads about all of it in a two-line summary the next morning.
The workflow worth building this week
If you run creator codes, welcome codes, win-back codes, or anything a customer can type at checkout, some of your discount spend is already going to people it was never meant for, and you cannot currently see how much. That is the uncomfortable part: this is not a problem that announces itself, it is a problem that shows up as margin that is slightly worse than it should be, quarter after quarter. Start with visibility, because a watcher that only ever tells you what your codes are doing already beats a monthly report, and it pairs with the same compounding logic behind the Shopify automations no one builds.
Describe it the way you would brief a sharp analyst: keep an eye on every discount code we run; learn what normal looks like for each one; if a code starts getting redeemed far faster than usual, mostly by people who have never bought from us, on carts sitting right at the threshold, tell me and stop the bleeding without declining anyone who legitimately has the code; if the same welcome code keeps coming back from what is obviously one person under new email addresses, catch it; and when a creator code leaks, draft the note to the creator and flag the affected orders so we do not pay commission on traffic she never sent. That is the brief. The compiler handles the baseline, the comparison, the timing, and the tone, and your discount budget goes to the customers you actually meant to give it to.
If you are a Shopify merchant with a leaked-code story, a creator
program that got expensive, or a welcome code that one person has
used eleven times, the inbox is open:
field-notes@dugong.live. We are collecting case studies
for the next issue.