Discount codes for digital downloads: run the sale without leaking your catalogue

Every download seller eventually creates their first discount code, usually in about forty seconds, five minutes before announcing a sale. A name, a percentage, done. The code goes in an email, a post, a podcast mention — and from that moment it is no longer really yours. It is a second price for your product, published in plain text, redeemable by anyone who can copy and paste.

Physical sellers get a natural brake on code abuse: stock runs out, shipping costs something. A download has none of that. The file costs nothing to copy, delivery is instant, and an escaped code can be redeemed a thousand times before you wake up. That does not make codes a bad idea — they are one of the few reliable levers a small seller has. It makes them a system to design, not a string to invent.

1. A code is a second price — price it like one

Before any mechanics: do the arithmetic on the discounted price, not the headline one. A percentage off lands on top of your per-sale costs — a platform percentage if your plan has one, plus the processor's percentage and its fixed per-transaction charge. The fixed part is why deep discounts on cheap files go underwater fast. Take 40% off a $10 download and you are selling a $6 file; the flat fee that was a nuisance at $10 is now a serious share of $6. Run the net, not the gross, for every code: discounted price, minus every fee at that price, minus the support cost of one more buyer. If the number embarrasses you, the code is wrong — shallower, shorter, or limited to a bundle whose basket absorbs the fixed fees.

Decide also what the code is for, in one sentence. A launch code rewards early buyers. A win-back code revives a list. A partner code measures a channel. A make-good code apologises to one person. Each job implies a different depth, lifespan, and audience — and a code created without a job defaults to the worst combination: deep, permanent, and public.

2. How codes leak (and why downloads leak faster)

Assume every code you share with more than one person becomes public. Not might — becomes. The routes are boringly predictable:

• Coupon aggregator sites scrape and republish codes from newsletters and social posts, often within hours. Your "list-only" code is on a coupon page before your launch weekend ends.
• Buyers share helpfully. A code posted in a community or Discord — usually by a happy customer doing friends a favour — outranks your own announcement in search within days.
• Codes are guessable. WELCOME10, LAUNCH20, BLACKFRIDAY and your product's name plus a round number will be tried, unprompted, by strangers and by browser extensions that test known code patterns at checkout. A predictable code is a standing public discount whether you announced it or not.
• Old codes never die on their own. A code from a podcast appearance two years ago keeps working — and keeps being found — unless something stops it.

Each leak is amplified for downloads, because redemption is frictionless and fulfilment instant: no warehouse notices a spike. The countermeasures are unglamorous: use unguessable strings for anything valuable (a random-looking code is ugly and that is the point), give each channel its own code so a leak tells you where it escaped, and never reuse a code across campaigns — reuse destroys your ability to tell which promotion sold anything.

3. Stacking: decide the math before a buyer does

Stacking is what happens when two discounts meet on one order: a code on a sale price, a code on a bundle, two codes at once. If you have not decided the rules, the checkout decides them for you — and checkouts, given ambiguity, tend to decide in the buyer's favour at the worst possible rate.

Set four rules explicitly, in whatever combination your checkout layer supports:

• One code per order, or several? One is the only safe default for downloads. Multi-code checkouts are where 20% + 20% quietly becomes nearly half off.
• Does the code apply to sale prices and bundles? A code that works on a bundle stacks your two biggest discounts by design. Exclude bundles and sale items unless the combined price is one you chose on purpose.
• Percentage or fixed amount? A fixed-amount code is predictable at every basket size. A percentage code grows with the basket — fine for a single file, dangerous on your largest bundle.
• What is the floor? Set a minimum order value or a maximum total discount. The floor stops a code combining its way to free — the one price at which a download, once delivered, can never be un-delivered.

Write the rules where buyers can see them, in the announcement itself: "one code per order, not valid on bundles, ends Sunday." Stated rules are what let you decline the inevitable "but it worked yesterday" email without a negotiation.

4. Expiry, caps, and single-use: the three locks

Every code needs three locks, and most sellers set only the first.

Expiry is a date and time, not a vibe. "Ends Sunday" means a specific Sunday at a specific hour in a specific timezone — and the code should switch itself off then, automatically. The evergreen code — created for a launch, never expired — is the most common way sellers discover they have run a permanent, unadvertised price cut for a year. If a code has no natural end (a standing partner code), give it a review date instead: check its redemptions and re-justify it or kill it.

A redemption cap limits total uses: the first 50 buyers, the first 100 orders. Caps convert a leak from an open-ended loss into a bounded one — the leaked code exhausts itself — and make "when it's gone, it's gone" true instead of theatrical. If your checkout supports per-buyer limits, one redemption per customer or email stops a single buyer farming a generous code across your whole catalogue.

Single-use codes are the third lock and the right tool for anything personal: a make-good for a failed delivery, a replacement for a buyer who paid twice. Generate a unique code per person instead of sharing one "special" code with twelve people — a unique code can be revoked individually, expires cleanly after its one use, and when one appears on a coupon site you know exactly whose copy it was. More admin, yes. Less than one leaked shared code.

5. Tie the code to delivery, not just to the price

A discounted order is still an order, and everything your delivery does at full price it must do at the sale price — and a few things matter more.

The buyer who paid 40% less should receive exactly the same delivery as the full-price buyer: the same personal download link, the same limits and expiry, the same licence key if the product issues one, the same stamped file if your PDFs are stamped per buyer. Sellers sometimes quietly degrade sale orders — fewer downloads, no key — and it always backfires: sale buyers are disproportionately new buyers, forming their first impression and most likely to need a re-download.

The reverse failure is worse: the discount that accidentally delivers more than full price does. A code applied to the wrong variant, a bundle code that unlocks the whole catalogue, a free-with-code order that skips licence-key generation and leaves the buyer with a file and no key. Test every code end to end — pay with it yourself, as a stranger would, and check what arrives: the right file, key, and limits. Before the announcement, not after the first support email.

Keep records per code, too. When a stamped file or licence key surfaces somewhere it should not be, the order it came from is how you trace it — and if that order came through a partner's code, the conversation starts from facts instead of vibes.

6. The support and refund tail of every sale

A promotion does not end when the code expires. It creates a tail of predictable emails — draft the answers before they arrive:

• "I bought yesterday at full price." Decide your policy now: many sellers apply the code retroactively within a few days — a partial refund of the difference buys disproportionate goodwill — and decline beyond that window, kindly, citing the stated dates. Either policy works; improvising per email does not.
• "The code didn't work." Usually an expired code, a code pasted in with spaces, or a bundle exclusion doing its job. Say which, in one line, and what you are offering instead if anything. A clear, fast, polite no keeps the honest half.
• Refunds on discounted orders. A refund returns what was paid — the discounted amount — and should revoke what was delivered: the download entitlement and any licence key. Watch for the discount-specific pattern: buy with a deep code, download, refund, keep the file. Per-buyer limits and refund-revocation make that pattern unprofitable.
• The chargeback from a sale buyer who does not recognise the amount on their statement — because it is the discounted one, not the price they remember seeing. Your delivery log (what was sent, when, to which email) is your evidence; keep it per order, not per product.

7. A pre-launch checklist: test the code like a stranger

Ninety seconds of setup deserves ten minutes of checking. Before any code goes public:

1. Create the code with an unguessable string, one job, one channel.
2. Set all three locks: expiry, total redemption cap, one-per-buyer if available. Single-use unique codes for anything personal.
3. Set the stacking rules: one code per order, bundles and sale items excluded unless deliberately included, a floor below which nothing applies.
4. Do the net-fee math at the discounted price, including fixed charges. Check the largest basket the code could apply to, not just the typical one.
5. Test-buy with the code on a clean browser: confirm the price, then confirm delivery — right file, link limits, key, and stamp.
6. Test the failure cases too: the code after expiry, on an excluded bundle, used twice. Each should fail politely and clearly.
7. Publish the rules with the code — end date, exclusions, one per order — in the announcement itself.
8. Calendar the day after expiry: review redemptions per code, kill anything evergreen, and note what the sale actually netted.

A code run this way becomes what it was supposed to be: a priced, bounded, measurable experiment that ends when you said it would.

Closing note on tooling: codes live on the checkout layer, so create and govern them wherever your payments run — your payment provider's coupon settings, or your storefront's — and judge any delivery tool only on what it does after the discounted payment lands. The tool behind this article, FileFreight, is one such delivery option: payment runs through your own Stripe account, and each buyer gets a personal download link, per-buyer PDF stamping on first download, and a licence key per paid order where enabled, with refunds revoking access automatically; a free plan at 5% per sale, or Pro at $19/month with 0% per-sale fees, on files up to 500 MB. The honest caveats: it is not a merchant of record and does not handle sales tax or VAT (that stays with you), it has no automatic importer (the first 20 sellers get a free white-glove migration instead), it is not a Shopify app, and it is delivery-only — no marketplace, no buyer library — from a new and small team, which is itself a risk to weigh. Whatever you use, the code discipline above is what protects the catalogue.