Skip to content

Fraud-proof every one-per-customer code

Every “one use per customer” code on your store shares the same weakness: Shopify counts accounts, and accounts are free. A person with an alias habit — sarah+1@gmail.com, a spare Outlook address, a guest checkout — is a new customer every time. This playbook closes that hole across your entire store, not just one code.

One scope fact shapes the whole plan, so it goes first:

One click on the Fraud Guard page — Activate now. Protection switches on with email and phone matching, and PromoLock reads up to a year of your discounted orders so past redeemers are recognized from day one. That history is what makes attempt four look like attempt four instead of a fresh face.

Step 2: audit which codes are actually once-per-customer

Section titled “Step 2: audit which codes are actually once-per-customer”

Fraud Guard’s same-code check only blocks codes whose discount is set to one use per customer — a deliberately multi-use code is never touched, because cross-account use of it is legitimate. So walk your live discounts (native Shopify admin, other apps, PromoLock) and ask of each: is this meant to be one per person?

  • Meant to be once — welcome offers, comeback codes, compensation codes: confirm the one-use-per-customer setting is actually ticked. In PromoLock it’s One use per customer under Usage limits; native and app discounts have their own equivalent toggle. The moment it’s set, Fraud Guard is watching that code — no further configuration.
  • Meant to be shared — a general sale code everyone uses: leave it multi-use. Fraud Guard will correctly ignore it.

The audit usually finds the leak: a code everyone treats as once-per-person that was never actually configured that way. Fraud Guard can’t enforce an intention that isn’t set.

Step 3: move unique-code campaigns into bulk sets

Section titled “Step 3: move unique-code campaigns into bulk sets”

Here’s where the scope fact bites. If a campaign hands out many different codes — every recipient their own — then same-code protection alone isn’t enough: each code is individually guarded, but one person holding five different codes can redeem all five. Stopping that takes the set-wide guard, and it only exists for PromoLock bulk sets.

So for campaigns you run through unique codes — welcome flows, email blasts, partner drops — generate them as a bulk set with the set’s Fraud protection guard on (it’s the default). One person, one code from the whole set, regardless of aliases. A unique-code campaign minted by an outside app can’t get this — which is worth weighing when you decide where campaigns live.

Step 4: tune strictness with evidence, not fear

Section titled “Step 4: tune strictness with evidence, not fear”

Start with what activation gave you: Exact match on email and phone. Live with it for a couple of weeks. If you still see farming with slight variations — same street, name spelled three ways — add Similar match at Balanced strictness and read the live examples under each dial before saving. Escalate to stricter settings only when the pattern is in front of you.

The reason to be calm about all of this: Fraud Guard blocks only on a definite match, and when in doubt, the sale goes through. The failure mode is one leaked discount — never a blocked genuine customer.

  • Your once-per-customer codes’ rows in Analytics — after the audit and Fraud Guard, their loss lines should flatten; what remains is the campaign working as designed.
  • AOV and repeat-customer numbers in Shopify — welcome-offer farming shows up as “first orders” that never become second orders. Fewer fake first-timers means truer numbers.
  • Expecting blocks on a multi-use code. By design, Fraud Guard ignores codes without the once-per-customer setting — set the limit first.
  • Expecting set-wide protection on another app’s unique codes. Same-code protection applies to them individually; one-person-one-code-per-campaign is a PromoLock bulk set feature. Migrate the campaign if that guarantee matters.
  • Going straight to Loose similar-matching. A common surname in one city becomes support tickets. Balanced first, evidence before strictness.
  • Skipping the audit. Activation without step 2 protects only the codes that were already configured correctly — which is usually the smaller half.