Account and offer abuse in ecommerce: a merchant's playbook

Most of what an ecommerce store calls "fraud" is two different problems wearing one word. One is payment fraud: stolen cards, chargebacks, the things a payment-fraud tool and a card network handle. The other is account and offer abuse: real-looking accounts created to claim a discount, a coupon, or a referral more times than the rules allow. They need different answers, and this guide is about the second one.

Across online businesses, the share of "new customer" traffic that is really returning customers in disguise tends to follow the same pattern: the email and the card change, the device behind the account does not. This playbook maps the account-side abuse a store actually faces and shows how reading the device behind each signup stops it without forcing a login or an identity check on every shopper.

Key takeaways

• Account and offer abuse is one shopper presenting as many to claim an incentive again and again. It is distinct from payment fraud, and a payment-fraud tool does not catch it.
• An ecommerce store faces a handful of recognizable forms: fake signups, first-order-discount farming, promo and coupon abuse, reseller multi-accounting, referral self-dealing, loyalty farming, and the multi-account side of refund and fake-review abuse.
• The common thread under all of them is one device behind many "separate" accounts, which is what makes the whole family catchable at one layer.
• You read it at the device and network level, not the email or the card, and you score it at signup or checkout before the discount is granted.
• Detection produces evidence, not a verdict. Your own store rules decide what a risky account gets, so a real shopper checks out untouched.

What is account and offer abuse?

Account and offer abuse is when one shopper presents as many separate accounts to claim a store incentive, such as a first-order discount, a coupon, or a referral payout, more times than the rules intend. The payment is usually legitimate and the cards are the abuser's own, so the only thing fabricated is the "new customer" identity behind each redemption. It is distinct from payment fraud, which is about stolen cards and chargebacks, and a payment-fraud tool does not catch it. The shared mechanic is one person behind many look-alike accounts, which is what makes the whole family detectable at a single layer.

What account and offer abuse does an ecommerce store face?

The account-side abuse hitting an online store is not one thing, but the list is short and the forms repeat across every catalog. Naming them in one place helps, because they share a root and a fix even though they wear different offers. Each one has its own deeper guide; this is the map.

The forms differ, but read down the middle column and the same sentence keeps appearing: one shopper, many accounts. That is the whole reason these can be handled together instead of one campaign at a time. The last two carry a behavioral half as well, a single account that returns too much or posts one fake review, which lives in your order and review data; the device layer's job is the multi-account half, linking the accounts behind a return ring or a review cluster so the pattern stops hiding as unrelated shoppers.

The scale is not trivial. The National Retail Federation projects $849.9 billion in 2025 returns and puts 9 percent of them as fraudulent, which works out to roughly 76 billion dollars, and a slice of that is organized return rings running many accounts rather than one disappointed shopper. Discount and signup abuse rarely make a headline number because each instance is small, but they leak from the same place: accounts a store treats as new that are not.

This is not payment fraud, and the difference matters

The single most useful distinction a store can draw is between payment fraud and offer abuse, because they look similar in a dashboard and need opposite tools.

Payment fraud is about money that is not the buyer's

Payment fraud is the stolen card, the chargeback, the card-testing run. It is caught by the things a payment stack already does: address and card-verification checks, machine-screening of transactions, and a chargeback process with the card networks. The work happens at the card and the transaction.

Offer abuse is about an identity that is not real

Offer abuse is different. The cards are usually the abuser's own and the charges are real; the only thing fabricated is the identity claiming "new customer" again. No card check flags that, because nothing about the payment is wrong, and a returns-and-chargeback tool will not see it either, because the orders are legitimate purchases at an unfair discount.

That is why a store can run a capable payment-fraud platform and still bleed margin to discount farming: the two problems do not overlap. Offer abuse is read at the identity layer, by linking the accounts behind the redemptions, the same broad problem research presented at USENIX NSDI tackled when it showed fabricated accounts can be flagged at scale, though it worked from the social graph rather than the device. That is a different control set than the payment one.

ShieldLabs sits on the identity side of that line. It reads the device and network behind an account, scores that session on a 0 to 100 risk score, names the anonymity signals that fired, and hands you the score and signals through the API and webhooks so the offer-abuse slice stops being invisible and your own code decides the action. Naming the line keeps you from pointing a payment tool at an identity problem and wondering why the numbers do not move.

The one thread: one shopper, many accounts

Strip the offer away and every form on the list above is the same move: a single shopper produces a stream of accounts that each look like a first-time customer. It is the one-user-many-accounts pattern behind multi-accounting, where a fresh email and a rotated IP still fail to stop a determined shopper.

What ties the accounts back together is what the shopper cannot cheaply reissue per account. The email is disposable, the IP is rentable, the coupon code is shareable, but the device behind the checkout and the network it rides stay the same from one "separate" account to the next. So a store does not have to solve six problems; it has to answer one question at the moment an account acts: how new is this shopper, really. The same redemption-time signals and layered playbook that work against promo abuse apply across these account and offer-abuse cases.

How a store reads it without blocking shoppers

The reflex when abuse climbs is to add friction: force a login, demand a phone number, gate the first order behind a verification step. That tax falls on every honest shopper to catch a few abusers, and at an ecommerce checkout friction is measured directly in lost conversion. Reading the device first inverts the order.

Read the device, not the order

A JavaScript snippet identifies the visitor on the page, and your store reads a risk score for that session when an account signs up or a discount is redeemed. A device already seen behind a dozen first-order discounts scores high; a genuine first-time shopper on a normal connection scores clean and checks out with nothing added.

Because the score is separate from the action, your own store rules decide what a risky account gets, hold the discount for review, step up to a verification check, or let it through, while the real shopper never feels a thing. That separation, detect quietly and decide explicitly, is what lets a store cut abuse without turning checkout into an obstacle course. It works the same on a hosted platform like Shopify or BigCommerce as on a custom storefront, because it reads the browser and device rather than hooking into the payment flow.

The claim is easy to check, so we ran it directly. We sent the same shopper back through a store on a new email, an emptied cookie jar, and a different IP, and we measured that the device behind the checkout still tied back to an account we had already seen, even though every disposable layer had changed. That gap only widened after Safari began expiring script-set cookies within about a week in 2019, so a cleared browser now says even less about whether a shopper is genuinely new, and the device is the signal that holds.

Preventing ecommerce account abuse with ShieldLabs

ShieldLabs runs on your signup, checkout, or redemption page through one JavaScript snippet, and it risk-scores every visitor on the first visit, so you have a read on the shopper behind an account before a discount applies. At the center is persistent identification that ties a "fresh" account back to a device already seen, even after the shopper switches email, clears cookies, and rotates IP. It works in the background, with no login and no identity document required.

Each visit returns a risk score from 0 to 100 with the anonymity signals behind it, and across accounts the pre-built patterns surface which ones trace back to one device, so a discount farm reads as a trend in the dashboard rather than a pile of separate orders. You read the risk score and named anonymity signals through the API and webhooks and decide, by your own rules, what a risky account gets; it surfaces the evidence, so you set the threshold and can always say why an account was held. The same identity layer carries across the offer-abuse family, from promo abuse prevention to multi-accounting prevention, and it complements rather than replaces the payment-fraud tooling on the other side of the line.

Sources

1. Wikipedia: Disposable email address
2. Cao, Sirivianos, Yang, Pregueiro: Aiding the Detection of Fake Accounts in Large Scale Social Online Services (USENIX NSDI, 2012)
3. National Retail Federation: 2025 Retail Returns Landscape (2025)