---
title: Coupon Abuse Detection
description: "The Coupon Abuse Detection module watches how customers use discount codes and flags the patterns that turn promotional spend into a leak. The two patterns it catches most reliably are repeat first-order coupon usage (creating new accounts to grab a…"
url: "https://webstepper.io/docs/trustlens/detection-modules/coupon-abuse-detection/"
updated: "2026-10-18"
category: Detection Modules
---

# Coupon Abuse Detection

The Coupon Abuse Detection module watches how customers use discount codes and flags the patterns that turn promotional spend into a leak. The two patterns it catches most reliably are repeat first-order coupon usage (creating new accounts to grab a new-customer discount over and over) and coupon-then-refund cycles (applying a coupon, completing the order, refunding, repeating). It also coordinates with the Linked Accounts module to spot coupon abuse spread across a network of accounts.

Module ID: `coupons`. Default: enabled. Free tier (complete).

---

## What It Observes

The module hooks into order placement (classic and block checkout) and refund events. When an order that used one or more coupons is placed, the module:

1. Increments the customer's `total_coupons_used` count by the number of coupons on the order
2. If this is the customer's first order (no earlier counted or placed orders): increments `first_order_coupons` — whatever kind of coupon it is
3. Logs a `coupon_used` event with the coupon code(s)
4. Queues a score recalculation if it was a first order or several coupons were stacked

When a refund is processed on an order that used a coupon, the refund ledger recounts `coupon_then_refund` — the number of refunded orders that had used a coupon — and the module logs a `coupon_refund` event and queues a recalculation. This is the key signal for bad-faith coupon abuse — applying a discount to an order specifically to refund it later.

The module also subscribes to `trustlens/linked_accounts_detected`. When accounts are linked, it adds up first-order coupons across the customer and their linked accounts; if the total exceeds **Max first-order coupons** (default 2), it logs a `multi_account_coupon_abuse` event and queues a recalculation — a strong indicator of throwaway-account abuse, recorded as evidence rather than as a separate score penalty.

---

## What It Signals

### Coupon-Then-Refund Cycles (Primary)

The dominant signal. The Coupons module tracks the `coupon_then_refund` counter — the number of times the customer applied a coupon to an order and then refunded it. Mutually exclusive tiers:

| Coupon-Then-Refund Cycles | Score | Reason Shown on Profile |
| --- | --- | --- |
| 3+ | -25 | "3 coupon orders refunded (abuse pattern)" |
| 2 | -15 | "2 coupon orders refunded" |
| 1 | -5 | (no reason text) |
| 0 | 0 | (no signal) |

This is the strongest single coupon-abuse signal — applying a coupon, completing an order, then refunding is consistent with bad-faith use, and the cycle repeating reinforces the pattern.

### First-Order Coupon Abuse

An *additional* -10 penalty when both conditions hold:

| Trigger | Score | Reason Shown on Profile |
| --- | --- | --- |
| `first_order_coupons > 0` AND `coupon_then_refund > 0` | -10 | "First-order coupon abuse pattern" |

The logic: using a first-order coupon and then refunding the order combines two abuse patterns into one — the customer captured the new-customer discount value while returning the underlying purchase. This signal stacks on top of the coupon-then-refund tier above.

### High Coupon Usage Rate

| Trigger | Score | Reason Shown on Profile |
| --- | --- | --- |
| 5+ orders with coupon usage rate ≥ 80% | -10 | "High coupon usage: 85% of orders" |

Catches customers who only ever buy when a discount is on the table.

### Legitimate Coupon User (Positive)

| Trigger | Score | Reason Shown on Profile |
| --- | --- | --- |
| 3+ coupons used with 0 refund cycles | +5 | "Legitimate coupon user" |

Distinguishes deal-aware customers (good) from coupon abusers (bad).

Coupons stack — a customer with 3+ refund cycles, a first-order coupon among the refunded orders, and 80%+ coupon usage rate can see Coupons module penalties up to -45 before any other module contributes.

---

## How First-Order Coupons Are Detected

TrustLens uses "first-order coupon" in two places, with two different tests:

- **For scoring** (`first_order_coupons`), any coupon used on the customer's very first order counts — the coupon's settings don't matter.
- **For the Pro checkout block**, a coupon is treated as a first-order / new-customer coupon when its code contains *first*, *welcome*, *new*, *newcustomer*, *signup* or *register* (WELCOME10, NEWCUSTOMER, etc.), or when its usage limit per user is 1. Developers can force the answer for a specific coupon with the `trustlens/is_first_order_coupon` filter.

If your store uses a non-standard mechanism for new-customer coupons (e.g. a custom plugin), you can also tune the resulting risk with the `trustlens/score_signals` filter, where you can adjust or add the coupon-abuse signal from your own code:

```
add_filter( 'trustlens/score_signals', function( $signals, $email_hash ) {
    foreach ( $signals as &$signal ) {
        if ( isset( $signal['module'] ) && $signal['module'] === 'coupons' ) {
            // Soften or strengthen the coupon-abuse penalty for your store
            $signal['score'] = (int) round( $signal['score'] * 0.5 );
        }
    }
    return $signals;
}, 10, 2 );
```

---

## Settings

| Setting | Default | Description |
| --- | --- | --- |
| **Max first-order coupons** | 2 | When accounts are linked and the first-order coupons used across the customer and their linked accounts exceed this number (1–20), TrustLens logs a multi-account coupon abuse event. It does not change the score by itself — the -10 first-order pattern above doesn't depend on it. |
| **Block checkout when a linked account has used first-order coupons** (Pro) | Off | If on, a first-order-type coupon is refused at checkout when an account linked to the shopper has already used a coupon on its first order |
| **Module enabled** | On | Master toggle |

To adjust, go to the **Coupon Abuse Detection** card in **TrustLens → Settings → Detection**.

---

## Common Patterns

### The Throwaway-Account Coupon Hunter

**Signature:** One person creates multiple accounts using slight email variations (john+1@, john+2@, john.smith@gmail vs johnsmith@gmail) to grab the new-customer discount repeatedly.

**Detection:** Linked Accounts module catches the link via a shared shipping or billing address, phone number or payment method (a shared device or IP alone is not enough). Coupons module logs the multi-account coupon abuse event once their combined first-order coupons exceed the limit.

**Score impact:** Linked Accounts -5 to -15 per account, plus 5 for each linked account already in Risk/Critical; Coupons penalties of -5 to -35 as soon as coupon orders are refunded. With the Pro blocking setting on, the next first-order coupon on a linked checkout is refused.

### The Refund-Cycle Abuser

**Signature:** Customer applies a coupon, completes the order, refunds. Repeats. The coupon may be a percentage off (extracting a free or near-free item that they refund).

**Detection:** `coupon_then_refund` counter increments; the signal starts at the first cycle (-5) and steps up at 2 and 3+.

**Score impact:** Coupons -5 to -25 (another -10 if a first-order coupon was involved), plus Returns signals for the underlying refund rate.

### The Deal-Site Coupon Leak

**Signature:** A single coupon code is shared on a coupon-aggregator site. Suddenly hundreds of customers (mostly first-time) use it.

**Detection:** Not a per-customer signal, and TrustLens has no per-coupon report. Watch the coupon's usage count in WooCommerce's own coupon list, and the first-time customers it brings in — those who refund their coupon orders pick up Coupons signals individually.

**Action:** Tighten the coupon's per-user usage limit, restrict to specific products, or expire it.

### The Legitimate Returning Customer

**Signature:** Customer has used one welcome coupon, then placed orders without coupons since.

**Detection:** No Coupons signals fire. The one welcome coupon doesn't penalize.

**Score impact:** None from Coupons. Earns +5 "Legitimate coupon user" once they've used 3+ coupons with no refunded coupon orders.

---

## False-Positive Watch List

- **Family-shared addresses.** A spouse and partner using separate accounts at the same shipping address will be linked — and, with the Pro blocking setting on, the second one's welcome coupon will be refused — even though they're legitimately separate customers. Allowlist or use the linked-accounts manual review.
- **Roommates.** Same as above — shared address but separate finances.
- **Office addresses.** Multiple coworkers ordering to the same office, each using a new-customer discount, look identical to abuse. Consider whether your shipping data deduplicates by suite/unit number.
- **Email-typo customers.** Some customers create a new account after forgetting their first credentials. Looks like a duplicate-account-with-new-customer-coupon pattern. The Linked Accounts module's fingerprint detection helps disambiguate.

---

## Blocking Linked-Account Coupon Abuse at Checkout

The Pro "Block checkout when a linked account has used first-order coupons" setting (it works as described from 1.3.23) is an aggressive option that enforces at the checkout-time level. When on:

1. At checkout, when a first-order-type coupon is applied, the module gathers the accounts already linked to the shopper's billing email *plus* any account matching the shipping address, billing address or phone number being entered at checkout — so a brand-new shopper with no history is covered too
2. If any of those accounts used a coupon on its first order, the coupon is rejected with the message "This coupon cannot be used. Please contact support if you believe this is an error."
3. The customer can still complete checkout without the coupon

This is a Pro setting and off by default because it can produce false positives on shared-address households. Turn it on only after you've observed the linked-accounts data for a few weeks and confirmed the pattern is real abuse, not legitimate shared addresses.

---

## Coupon Abuse Beyond the Profile

The Dashboard has no separate coupon-abuse card. Coupon abuse surfaces at the store level through:

- **Priority Targets** — customers whose coupon signals helped push them into Risk or Critical
- **Live Activity** — recent events, including `coupon_used`, `coupon_refund` and `multi_account_coupon_abuse`
- **Automation conditions (Pro)** — rules can test `total_coupons_used`, `first_order_coupons`, `coupon_then_refund` and the order's `coupon_total`

If a single coupon code is behind a burst of new accounts and refunds, that's the leak indicator — investigate where the code is being shared.

---

## Disabling the Module

Reasonable to disable if your store doesn't run coupons or new-customer discounts. When off, no coupon signals fire and no coupon events are recorded, so `total_coupons_used` and `first_order_coupons` stop updating (the refund ledger still keeps `coupon_then_refund` current). Automation rule conditions that use those coupon counters will work from stale values.

---

## Reading the Coupons Section of a Profile

- **Signal breakdown** shows one Coupons signal combining every coupon rule that fired
- **Stats panel** shows `total_coupons_used`, `first_order_coupons`, `coupon_then_refund`
- **Event timeline** lists each `coupon_used` event with the coupon code, order ID, and date

The timeline is the best evidence for justifying actions — you can see exactly which coupons the customer used and when, in case the customer disputes the block.
