Short answer
RaftLabs built the coupon distribution and fraud-prevention system behind a Power NI promotion, delivered through BrandFire, in about 30 days. Each customer received a unique redemption URL, and an IP-based eligibility check stopped multiple people at the same address from claiming separate coupons. All 250 coupons were redeemed within a week of launch, with zero duplicate redemptions recorded.
Engagement
The Power NI engagement
- Client
- Power NI
- Sector
- Utilities and energy services in Northern Ireland
- Delivery
- Fixed-scope project, about 30 days, delivered through BrandFire
- Team
- One project manager, two developers, and QA
- Scope
- Unique-URL coupon distribution and IP-based redemption fraud prevention
- Outcome
- All 250 coupons redeemed within a week of launch
The situation
A limited-quantity coupon giveaway has one failure mode that ruins it for everyone: the same household claims several codes while genuine customers get nothing. Coupon fraud is rarely crime. It is design exploitation: smart users finding the weak logic in a campaign and walking through it.
Power NI's original setup could only enforce one coupon per IP address total. The first visitor from a shared connection, a household, an office, a block of flats, locked out every other real customer behind it. Meanwhile, someone who simply switched browsers sailed past the control entirely.
The founder running the promotion wanted something sharper: a unique redemption URL for every customer and every coupon, with fraud protection that could tell genuine multi-person households apart from someone gaming the system. RaftLabs took on the build through BrandFire, on a fixed scope, with a two-developer, one-QA team over roughly 30 days. All 250 coupons were redeemed within a week of launch, with zero duplicate redemptions recorded.
Before and after
From one-IP-one-coupon to fair, fraud-resistant distribution
- One IP address could redeem only one coupon, full stop, no matter how many real customers shared that connection
- Every customer used the same generic redemption link, so there was no way to trace a code back to a specific person
- The founder faced pressure to get a workable fraud control live before the limited coupon stock ran out
- With no way to tell one household's five members from one person running five browsers, the team had no better option than a blunt total block
- Each customer received their own unique coupon URL, tying a code to a person rather than a shared link
- An IP-based eligibility check ran per redemption attempt, catching rapid multi-claim patterns from the same address without a blanket one-per-IP rule
- Genuine multi-person households could still redeem legitimately, since eligibility was evaluated per coupon claim rather than as a lifetime IP block
- The admin view showed redeemed versus unredeemed coupons in real time, so the team could watch the giveaway run down without guessing
The decisions that made the fraud control work
Telling a real household apart from a repeat claim
The brief sounded simple: block coupon fraud. The harder problem showed up once the team modeled real usage. Multiple genuine people (family members, flatmates, colleagues on the same office network) could easily share a single IP address. A flat one-per-IP rule, which was the original setup, punished those legitimate cases as collateral damage while doing nothing to stop someone who just switched browsers or used a VPN.
The edge case that confirmed it arrived early: several different, real people redeeming from the same address, not because anyone was gaming the system, but because they lived or worked together.
The team's answer was to check IP address and eligibility per redemption attempt rather than applying a single lifetime block per address. That distinction, evaluating each claim rather than locking out the address permanently, was the decision that let real multi-person households through while still catching the rapid repeat-claim pattern that signaled abuse.
Generating a unique URL for every coupon, not just every user
Sending the same coupon code to lots of people is the most common pitfall in coupon campaigns. Within hours, the code leaks, and people it was never meant for are cashing in. Power NI wanted unique URLs for both users and coupons, a two-layer identity problem rather than the usual single-token link. Each generated URL had to resolve to exactly one coupon and be traceable to the customer it was issued to. A code could be redeemed once and only once, and any dispute could be traced back to the original send.
The core discipline is the same regardless of the campaign mechanic: generate the identifier before any redemption logic runs, and never let two coupons resolve to the same link.
the build
What the coupon system changed
The redemption experience and the fraud control had to work together. A unique URL means nothing if the eligibility check behind it still blocks legitimate customers, and a smart fraud check is pointless if the underlying link can be duplicated or guessed.
Every customer redeemed through their own coupon link
Each customer received a unique URL tied to their specific coupon. A code could not be redeemed from a link that was not issued to that customer, closing off the simplest form of code-sharing abuse before the IP check even ran.
IP eligibility ran per claim, not as a lifetime address block
Instead of banning an IP address after its first redemption, the system evaluated each new claim from that address against the pattern of prior claims. Genuine households kept working; rapid, repeated claims that looked like abuse got stopped.
The admin view tracked redeemed against unredeemed in real time
A simple admin panel let the team see how many of the 250 coupons had been claimed against how many remained, without needing to query the database directly.
Proof
What changed after launch, and what supports each claim
These figures come from the retained PM questionnaire responses. Exact redemption timestamps and any cost figures are not part of the public record.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Redemption completion | All 250 coupons redeemed | Within one week of launch | PM-reported project record |
| Fraud incidents | Zero duplicate redemptions from the same household | Across the full 250-coupon run | PM-reported project record; measured via the admin redeemed/unredeemed view |
| Delivery time | About 30 days, fixed scope | From kickoff to launch | PM-reported project record |
The lesson
For limited-quantity giveaways, fraud prevention is a per-claim decision, not a per-address rule
The instinct with coupon fraud is to write a rule that blocks the address. That rule also blocks every legitimate person who happens to share it, which is exactly what was happening to Power NI's real customers before this rebuild.
If you are running a limited-quantity coupon, voucher, or ticket giveaway, treat eligibility as a judgment made on each redemption attempt: look at the pattern behind an IP address, not just its presence on a list. A rule that only counts addresses will always trade fraud prevention for false positives against your own genuine customers.
Why we chose this approach
- Unique URL generation
- Each coupon needed its own traceable, non-guessable redemption link tied to one customer and one code, generated before any eligibility logic ran.
- IP-based eligibility checks
- Redemption eligibility was evaluated per claim against the pattern of prior claims from that address, rather than as a single lifetime block, so legitimate multi-person households were not locked out.
Common questions
Power NI's original system allowed only one coupon redemption per IP address in total, which blocked genuine multi-person households sharing a connection while doing little against someone who simply switched browsers. RaftLabs built unique per-user, per-coupon URLs and a per-claim IP eligibility check so real customers could redeem while abusive claim patterns were still caught.
That is the most common pitfall in coupon campaigns. A shared code leaks within hours, and people it was never meant for start cashing in. Power NI's generic redemption link had the same weakness at a smaller scale: with no way to trace a code back to a specific person, there was no way to tell a legitimate claim from a shared one. Unique per-customer URLs closed off code-sharing before the fraud check even ran.
The build was a fixed-scope project delivered in about 30 days, with a team of one project manager, two developers, and QA. The project was delivered through BrandFire, which held the client relationship.
Given the fixed scope and short timeline, the admin panel did not include a self-serve editor for terms and conditions or FAQ content; those pages stayed as manual edits rather than becoming admin-configurable fields. This was a deliberate trade-off disclosed to the client, not an oversight.
The same unique-URL-plus-per-claim-eligibility pattern applies to any limited-quantity coupon, voucher, or ticket giveaway where a business needs to stop the same household or address from claiming multiple codes without blocking genuine repeat visitors. See our loyalty program development and utilities loyalty program development services for how we scope similar builds.
RaftLabs continues to take on engineering work sourced through BrandFire, which brought the Power NI engagement to RaftLabs in the first place. BrandFire manages the client relationship and campaign strategy; RaftLabs builds the platform engineering behind qualifying programs.
Related work
Related loyalty and campaign work
Energia Rewards utility loyalty platform
A 10-12 week Energia Rewards rebuild that migrated roughly 500,000 users and cut support tickets by 80% (client-reported).
AldiFest receipt-based loyalty campaign
AldiFest recorded 2,000+ signups and processed 5,000 receipts in its first week, delivered through BrandFire.
GrowViral referral and campaign platform
A white-label campaign platform using unique URL tracking and fraud-pattern detection across referral, sweepstakes, and affiliate campaigns.