💻 computer science

Refunded but Rewarded: The Double Dip Attack on Cashback Reward Engines

This paper identifies and analyzes a class of "double dip" vulnerabilities in cashback reward systems where flaws in handling transaction refunds allow users to exploit timing gaps or missing adjustments to illegitimately retain rewards, proposing a formal state-machine model, a vulnerability taxonomy, and defensive algorithms to ensure reward integrity.

Original authors: S M Zia Ur Rashid, Suman Rath

Published 2026-04-21

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: S M Zia Ur Rashid, Suman Rath

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a magical piggy bank that gives you a little bit of extra money every time you buy something. Let's say you buy a $100 jacket, and the bank gives you $5 back as a "thank you" reward. You can take that $5 and spend it on candy immediately.

Now, imagine you decide you don't want the jacket anymore. You take it back to the store, and the store gives you your full $100 back.

The Big Question: What happens to your $5 reward?

In a perfect world, the bank would say, "Oh, you got your money back, so you don't get to keep the $5 reward. We'll take that back from your piggy bank."

But this paper reveals that for some banks, the answer is: "You keep the $5. We forgot to take it back."

This is the "Double Dip Attack." It's a loophole where a person can buy something, get the reward, return the item for a full refund, and walk away with free money (the reward) and no cost (the refund).

Here is a simple breakdown of how the researchers found this, the different ways it happens, and how to fix it.

1. The Three Types of "Forgetful" Banks

The researchers tested six different banks (which they kept anonymous) and found three distinct ways these systems fail. Think of them as three levels of "clumsiness."

Level 1: The "Blank Slate" Bank (Issuer A)

The Metaphor: Imagine a waiter who takes your order, gives you a free appetizer, and then you tell him you don't want the main course. He returns your money for the main course but completely forgets that you even ordered the appetizer. He never asks for it back.
What happens: You buy a $50 item, get $2.50 cashback, and redeem it instantly. Then you return the item. The bank refunds your $50 but leaves the $2.50 in your pocket.
The Result: You made $2.50 for doing nothing but buying and returning an item. You can do this every month until you hit the limit.

Level 2: The "Calendar Confused" Bank (Issuer B)

The Metaphor: Imagine a club that counts your points at the end of the month. You buy a gift in the last week of January. The club says, "Great! You have points," and immediately gives you a gift card. But you return the gift in the first week of February.
What happens: Because the club's "point counting" happens on a strict monthly schedule, they already gave you the reward in January. When the return happens in February, the system doesn't look back to January to say, "Wait, that transaction is gone." The reward is already yours.
The Result: You get the reward because you were fast, and you get the refund because the store is slow. The bank's calendar got in the way of the truth.

Level 3: The "Slow to React" Bank (Issuer F)

The Metaphor: This bank is smarter but still has a gap. They say, "Okay, you bought a TV, here are 100 points. You can spend them right now." But if you return the TV, they don't take the points back until the end of the month.
What happens: You buy the TV, get the points, spend them on pizza, and then return the TV. You now have a "negative balance" of points (you owe the bank 100 points). But you've already eaten the pizza!
The Result: You get to enjoy the pizza for free for a few weeks. If you stop using the card after that, the bank is stuck with a debt you never pay back. It's like borrowing money interest-free for a month.

2. The "Good" Banks (Issuers C, D, and E)

The researchers also found three banks that did it right.

The Metaphor: These banks are like a strict accountant. If you buy a TV and get points, and then return the TV, they immediately take the points back.
The Twist: If you had already spent those points on pizza, your point balance goes negative. You now owe the bank points. You can't get any new points until you earn enough to pay off that debt.
Why it works: You can't "double dip" because the moment you return the item, the reward disappears, and you are in debt.

3. How to Fix the Leaks

The paper suggests a simple set of rules (algorithms) to fix these banks:

Track Every Item: Don't just count total spending. Keep a tiny receipt for every single item bought and the reward it earned.
The "Clawback" Rule: If an item is returned, immediately calculate how much reward was attached to that specific item and take it back.
Allow Negative Balances: If a user spends their reward before returning the item, let their balance go negative. Don't let them withdraw more money until they earn enough to fix the debt.
The "Wait and See" Period: For banks that calculate rewards once a month, they should put a "hold" on the rewards for a few days after the month ends, just in case a return happens late.

4. Why Should You Care?

You might think, "I'm a good person; I won't try to scam the bank."

But the paper argues that these aren't just "hacks" for criminals. They are logic errors in the software.

It's not about stealing: The researchers used their own real credit cards and bought real items. They didn't hack the bank; they just followed the rules the bank wrote, which happened to have a loophole.
It costs everyone money: When banks lose money to these loopholes, they might raise fees for everyone or stop offering rewards.
It's easy to fix: The solution isn't a super-complex AI. It's just making sure the software checks the math when a return happens.

The Bottom Line

This paper is a wake-up call for banks and payment apps. They spend millions of dollars securing the actual money transfer (so hackers can't steal your cash), but they often forget to secure the reward system.

It's like building a fortress with a giant iron gate (the payment system) but leaving the back door (the reward system) wide open with a "Welcome" sign. The researchers showed us that the back door is open, explained exactly how to walk through it, and gave the blueprints to lock it.

1. Problem Statement

The paper addresses a critical class of business logic vulnerabilities in cashback and loyalty reward engines used by credit card issuers, debit card providers, and digital wallets. While payment authorization and settlement systems are heavily secured, the reward engines sitting atop them often lack rigorous security modeling.

The core problem is the Double Dip Reward Abuse (DDRA) attack. This occurs when a user:

Makes a legitimate purchase and earns a cashback reward.
Redeems the reward for cash or statement credit.
Returns the merchandise for a full refund.
Fails to have the reward clawed back because the reward engine does not properly adjust the ledger when the underlying transaction is reversed.

This allows an attacker to achieve zero net spend while retaining positive net reward, creating a deterministic profit loop. The paper argues that these vulnerabilities arise not from technical exploits (like SQL injection) but from flawed state transitions in the reward engine's business logic.

2. Methodology

The authors employed a combination of empirical case studies and formal modeling:

Empirical Case Studies: The researchers conducted controlled, small-scale experiments on six legitimate issuer accounts they personally held (covering both debit and credit cards from major U.S. financial institutions). They performed low-value transactions, redeemed rewards, and initiated standard merchant returns to observe how different reward engines handled the reversal of funds.
Adversary Model: They defined an "honest but opportunistic" adversary. This attacker uses legitimate accounts, makes real purchases, and follows standard return policies but strategically times redemption and refunds to exploit logic gaps. They do not use stolen identities or forged data.
Formal Modeling: The reward engine was abstracted as a state machine. The authors defined transaction states (Pending, Settled, Refunded, etc.) and reward ledger states to mathematically model the flow of rewards and refunds.
Defensive Design: Based on the findings, they developed a suite of pseudo-algorithms and a semi-formal correctness argument to propose a secure architecture.

3. Key Contributions

A. Vulnerability Taxonomy

The paper identifies three distinct classes of vulnerabilities (V1, V2, V3) mapped to CWE-841 (Improper Enforcement of Behavioral Workflow) and the OWASP Business Logic Abuse Top 10:

V1: Refund Insensitive Rewards (Case I - Issuer A):
- Mechanism: The reward engine grants rewards upon settlement but has no handler for refund events.
- Result: When a refund occurs, the principal is returned, but the reward remains in the user's account. This is a complete violation of integrity.
V2: Temporally Scoped Adjustment (Case II - Issuer B):
- Mechanism: Rewards are computed and finalized at the statement cycle close. If a refund occurs in the next billing cycle (but within the merchant's return window), the system treats the reward as finalized and does not claw it back.
- Result: A timing gap allows users to redeem rewards before the refund is processed in the subsequent cycle.
V3: Inconsistent Negative Balance Handling (Case III - Issuer F):
- Mechanism: The system creates a negative reward balance upon refund, but there is a timing asymmetry. Rewards are available for immediate redemption upon settlement, but the clawback (negative balance creation) is batched until statement close.
- Result: Users can redeem rewards and refund the purchase within the same cycle, extracting value before the negative balance is applied. Recovery depends on the user continuing to use the card; if they stop, the debt is never recovered.

B. Formal Invariants

The authors define two critical security properties that reward engines must satisfy:

Reward Integrity: The total reward value a user extracts must never exceed the value generated by their net legitimate spending.
Refund Reward Consistency: When a purchase is reversed, the reward state must be updated within a bounded time to reflect the new economic reality.

C. Defensive Algorithms

The paper proposes four algorithms to close these loopholes:

Algorithm 1 (RewardOnSettlement): Computes rewards based on category rates and caps, storing an immutable Rorig (original reward) for each transaction.
Algorithm 2 (RewardOnRefund): Triggers proportional clawback based on the refund fraction ( $x/a$ ) applied to the immutable Rorig. It allows the user's balance ( $B[u]$ ) to go negative, creating a debt that must be repaid by future earnings before further redemption is allowed.
Algorithm 3 (CanRedeem): A gatekeeper that blocks redemption if the user's balance would drop below a minimum threshold (e.g., 0) or if they are within a "grace period" after statement close.
Algorithm 4 (StatementCycleReconcile): For batched systems, this reconciles pending refunds against the current cycle's rewards and applies retroactive clawbacks for cross-cycle refunds.

4. Results

Spectrum of Robustness: The study revealed a three-tier spectrum among the six issuers:
- Fully Vulnerable: Issuers A (V1) and B (V2) allowed deterministic profit extraction.
- Partially Robust: Issuer F (V3) allowed a timing-based extraction (interest-free float) but eventually corrected the balance if the user remained active.
- Fully Robust: Issuers C, D, and E implemented indefinite negative balance enforcement with immediate or cycle-corrected clawbacks, preventing any net profit from the attack.
Economic Impact: The authors provide a sensitivity analysis estimating that if even 1% of users on a platform with 1 million users exploited a $50/month cap vulnerability, the annual leakage could reach $60 million.
Disclosure:
- Issuer A: Reported via a private bug bounty; acknowledged as a known vulnerability.
- Issuer B: No disclosure channel found; authors proceeded with anonymized publication.
- Issuer F: Characterized as a design trade-off rather than a critical vulnerability; no formal disclosure pursued.

5. Significance

Shift in Security Focus: The paper elevates reward engines from "marketing logic" to "security-critical state machines," arguing they require the same rigor as payment authorization logic.
New Threat Vector: It defines a new class of fraud that does not require identity theft or stolen cards, making it accessible to any legitimate user with a basic understanding of the system's timing.
Actionable Defense: Unlike many security papers that only identify problems, this work provides a constructive, algorithmic solution (per-transaction tracking, negative balance enforcement, and grace periods) that is technically feasible to implement.
Regulatory Implications: The findings highlight potential compliance risks (UDAAP) for issuers who fail to maintain consistent and fair reward accounting, potentially affecting consumer trust and regulatory standing.

In conclusion, the paper demonstrates that the integrity of the incentive ledger is just as critical as the payment ledger. By treating refunds as first-class events that trigger proportional clawbacks and enforcing negative balances, issuers can eliminate the "Double Dip" attack vector entirely.