Loyalty Points Fraud Prevention: $75 Minted in 94s

I Set Out to Fix Redemption. I Found a Mint.

I built a loyalty program for a DTC fashion brand I run in San Diego. The reported problem was simple and ugly: nobody could redeem their points. Customers earned credit, went to check out, and the discount silently failed. That was the bug I sat down to fix.

While I was in there auditing the redemption side, I found the opposite problem on the earn side. And it was worse.

The review-for-points endpoint was wide open. Anyone could submit a review and get store credit instantly. No purchase required. No check on whether they'd reviewed that product before. No ceiling on how much a single account could mint.

So I went looking for abuse, the way you'd test any door by trying to kick it in. I found a farm immediately. One account had minted 1,500 points (about $75 in store credit) across 15 submissions in 94 seconds. Ninety-four seconds. That's not a customer leaving feedback. That's someone running a script, or just clicking very fast and laughing.

Here's the core doubt every operator should sit with before launching any rewards program: if you pay customers to take an action, what stops people from gaming it?

The honest answer is nothing. Not unless you build the locks yourself.

That's the thing about loyalty points fraud prevention. It isn't a feature you bolt on after launch. It's the structure the program has to stand on, or the whole thing quietly bleeds money. I built this loophole with my own hands, shipped it, and only caught it because I happened to be auditing something else.

Most teams never audit. Which is exactly why I want to walk you through what I found.

The Anatomy of an Open Earn Endpoint

Three reward tiers, zero gates

The earn structure was generous and that was the whole problem. Submit a text review, get 100 points. Add a photo, 150. Post a video, 400.

The Open Earn Endpoint with Three Tiers and Zero Gates

All of it instant-vest. The moment you hit submit, the points landed in your account as spendable store credit.

Now look at what was missing. There was no purchase gate, so anyone could submit, buyer or not. There was no dedup, so the same person could review the same product over and over and collect every time. There was no cap, so a single account could mint points without limit.

Three reward tiers, zero gates. That's not a loyalty program. That's a vending machine that pays you to press the button.

The numbers that exposed the farm

When I pulled the data, the picture was damning. The system had minted $490 in points. And 55% of the accounts that earned those points had spent exactly $0 with the brand.

The Numbers That Exposed the Farm

More than half the people farming rewards had never bought a thing.

Two patterns proved it was deliberate, not accidental. The first was the 1,500-points-in-94-seconds account I already mentioned, a clear scripted run. The second was subtler: alias pairs. Two emails that looked coordinated, reviewing the same products, double-dipping in a rhythm that doesn't happen by chance.

The detail that stung most? The schema already had a fraud flag column, a glow_flagged-style field meant to mark suspicious accounts. It existed. It was just never written to. Not once.

So the flag was there. The enforcement never was.

That is the single most common failure mode I see in incentive systems. Someone designs the right guardrail, ships the table, and then never wires up the logic that actually populates it. The intention is in the code. The protection is not. And nobody notices, because free points don't file bug reports.

The Five Locks Every Reward Endpoint Needs

Here's the reusable checklist. If you reward any customer action, these five locks are the difference between a loyalty program and an open mint. None of them are exotic. All of them are deterministic.

The Five Locks Every Reward Endpoint Needs

Verified-buyer gate (fail-closed)

Require at least one real order before any points get credited. No purchase, no reward.

The critical word is fail-closed. If the order lookup is uncertain (the API times out, the record is ambiguous, the lookup throws) you deny the credit. You do not default to crediting and sort it out later. A verified buyer gate that fails open is no gate at all. When in doubt, the points don't move.

Per-product dedup

One reward per product per person, enforced at the database level. Not in the app code, where a race condition or a retry can slip two through. At the database, with a uniqueness constraint on the pair of email and product.

This is your points dedup velocity foundation. If the same person tries to review the same product twice, the second write fails hard. No double-dipping, no alias pair farming the same item.

Velocity flagging

More than 3 submissions in 24 hours gets flagged for review. Not auto-rejected, flagged.

Real customers don't review 15 products in 94 seconds. Review reward farming has a signature, and the signature is speed. Velocity flagging is what would have caught my farmer on submission number four instead of letting all fifteen through.

Lifetime cap

Put a ceiling on total review points per account. No single person should be able to mint unbounded store credit no matter how many legitimate-looking reviews they post.

The cap bounds your worst-case loss. Even if every other lock somehow fails, the damage from one account is capped at a number you chose on purpose.

Pending-vest clawback window

Points no longer vest instantly. They sit in a 3-day pending window. A clawback cron runs against that window and pulls points back for any review that gets archived, removed, or flagged before it vests.

This is the lock that turns instant-vest convenience into a fraud-resistant flow. You trade a tiny bit of UX immediacy for a real chance to catch abuse before the credit becomes spendable.

One implementation note that matters: all crediting now routes through the same member-creating RPC, so the path is consistent and auditable. Every point that gets minted leaves the same trail.

Every one of these is a deterministic check. No model is guessing whether someone is a fraudster. These are rules, written once, enforced every time. That's the heart of rules-first design for money-moving decisions. When real money or store credit is on the line, you want hard rules doing the gating, not an LLM making a judgment call it can be talked out of.

The Hard Part Wasn't the Fix. It Was Who to Punish.

Claw back the farmers, not the customers

Building the five locks was the easy part. A few days of work and the door was shut going forward.

The hard part was the past. I had $490 of already-minted points sitting in accounts, and a lot of it was fraudulent. What do I do with it?

The technically correct answer is brutal: reset everyone's points to zero, re-run the rules cleanly, and let only the legitimate earns survive. It's the answer a security engineer gives. It's also a business disaster.

So I didn't do that. I clawed back $112.50, and only from accounts with zero orders, plus a handful of quarantined test accounts I'd created myself during development. The clear farmers. The people who never bought anything and minted credit out of thin air.

The trust hazard of taking back real points

Here's the part that matters. I deliberately preserved $357.50 of points belonging to real paying customers, even the ones whose earn path was technically loose.

Clawback Decision, Farmers vs Real Customers

Some of those customers earned points through the same open endpoint. Some of them probably reviewed a product they didn't strictly need to. Under a purist reading, that credit was suspect.

I left it alone.

Because clawing back loyalty currency from someone who actually bought from you is a trust hazard, and that hazard costs more than the fraud ever could. Imagine the email. "We've removed points from your account." From a customer who paid you real money. You don't recover that relationship for $5 in store credit.

The whole point of a loyalty program is repeat revenue. I dug into whether the loyalty program actually lifts revenue separately, and the answer was the reason I run the program at all. You do not protect repeat revenue by punishing your best customers over a loophole you built.

That's the difference between a security engineer's instinct and an operator's instinct. The engineer optimizes for a clean ledger. The operator optimizes for the customer who's still going to be buying from you next quarter. Stop the farmers cold. Leave the real buyers alone, even when the rule says you technically could.

Why Incentive Systems Fail Quietly

Step back from this one program and the lesson generalizes fast.

Convenience vs Fraud Posture Tradeoff (Instant-Vest vs Vesting Window)

Every system that rewards an action is an attack surface. Review rewards. Referral bonuses. Sign-up credits. Points for completing your profile. Affiliate payouts. If money or credit flows out when someone takes an action, someone will eventually take that action just to get the money.

And the failure is almost always the same three holes I found in my open endpoint. No gate proving the action was legitimate. No dedup preventing the same person from repeating it. No cap bounding how much damage one account can do.

The damage is silent. That's what makes rewards program abuse so dangerous. Nobody files a bug report when free points get minted. The farmer isn't going to email you. Your honest customers don't see it. So it runs, quietly, until the day you go looking for something else and trip over it.

There's a real tension here between convenience and fraud posture. Instant-vest is great UX. Points show up the second you submit, the customer feels rewarded, the loop closes fast. It's also a terrible fraud posture, because there's no window to catch anything before the credit is spendable. A vesting window is slightly worse UX and dramatically better protection. That tradeoff is yours to make on purpose, not by accident.

The honest admission stands. I built this loophole myself. I'm the one who shipped instant-vest with no gate, no dedup, no cap. I caught it because I was auditing the redemption side and got curious about the earn side. That curiosity is the only reason I found it.

Most teams never get curious. They launch the incentive, watch the engagement numbers tick up, and never ask who's behind the engagement.

What This Looks Like When Someone Audits Your Rewards

I run a real DTC brand. That's not a credential, it's a method. I find these problems in my own systems, with my own money on the line, before I'd ever ship them to a client. The 94-second mint was my mistake to catch, and I caught it on my own infrastructure first.

The pattern transfers cleanly. Verified action gate. Per-action dedup. Velocity flag. Lifetime cap. Vest, then clawback. It applies to any incentive program you run, whether that's loyalty points, referral bonuses, or affiliate commissions. The attack surface is the same shape every time.

If you reward customers for actions and you've never stress-tested who can game it, that's exactly the kind of quiet money leak I go looking for. Not the dramatic breach. The slow one. The one that doesn't file a bug report.

I'd rather find your open mint before a stranger does. That's the honest pitch. If you want a second set of eyes on it, have me audit your incentive systems.

One limit, stated plainly: locks reduce abuse, they do not eliminate it. A motivated fraudster with enough real orders and enough patience can still work the edges. The realistic posture isn't a magic gate that ends all abuse. It's velocity flagging plus a human review queue, so the suspicious patterns surface fast and a person makes the final call. Anyone who promises you fraud-proof is selling you something. I'm offering you fraud-resistant, which is the thing that actually exists.

Want to explore what AI could do for your business?

Book a free 30-minute strategy call. No pitch deck, no sales team, just a real conversation about your operations and where AI fits.

Book a Discovery Call