Should merchants add more friction to returns when abuse rises?

Why This Matters for Security Teams

Return abuse is usually discussed as a retail operations problem, but it quickly becomes a trust, fraud, and identity governance issue when the same buyer signals, device patterns, payment instruments, or account behaviours reappear across multiple transactions. The decision to add friction should therefore be treated as a control design question, not a blanket customer-service change. Current guidance from the NIST Cybersecurity Framework 2.0 supports risk-based governance and outcome-driven controls, which is the right lens here.

The main mistake is to equate more friction with more protection. Extra steps can deter serial abusers, but they can also increase abandonment, trigger support escalations, and create unfair outcomes for legitimate customers who happen to fit a suspicious pattern. That is especially true when teams rely on a single rule such as “too many returns” without considering product category, seasonal spikes, fraud linkage, or customer lifetime risk. A stronger model is to centralise return data, define thresholds by segment, and escalate only when the observed behaviour deviates from normal purchasing patterns.

In practice, many merchants only discover their return controls are too blunt after complaint volumes, chargeback disputes, or false-positive reviews have already damaged customer trust.

How It Works in Practice

Operationally, targeted friction means introducing graduated controls rather than one universal hurdle. Merchants can reserve stricter checks for higher-risk return scenarios, such as high-value goods, repeat serial returns, empty-box claims, or returns that correlate with account creation bursts and unusual payment behaviour. The objective is to add verification where the abuse signal is strongest, while keeping routine returns fast for low-risk customers.

A practical design usually starts with a central risk view that combines order history, return frequency, fraud signals, and policy exceptions. That view then feeds a decision layer that determines whether a return is approved automatically, routed for manual review, or sent through additional verification. If customer identity confidence is weak, merchants may ask for a receipt lookup, order confirmation, or proof of purchase. If product handling is the issue, they may tighten category-specific rules such as return windows or condition checks.

• Use segment-based thresholds rather than a single global limit.
• Separate abuse indicators from ordinary dissatisfaction or fit-related returns.
• Document when manual review is required and who can override it.
• Measure false positives, not just abuse rate, so friction does not drift upward unnoticed.
• Keep policy language clear enough that frontline teams can explain decisions consistently.

Where identity assurance matters, merchants should treat repeated return abuse as a trust signal, not proof of wrongdoing. That distinction matters because over-assertive controls can create avoidable privacy and fairness concerns, especially when they rely on behavioural inference rather than confirmed misuse. For broader control mapping, the OWASP guidance for application risk is not a direct returns framework, but its emphasis on abuse prevention and validation is useful when designing decision logic. These controls tend to break down in high-volume marketplaces with fragmented seller data because abuse patterns are distributed across many systems and cannot be scored consistently.

Common Variations and Edge Cases

Tighter return controls often increase operational overhead, requiring organisations to balance abuse reduction against customer experience, support load, and fairness review. That tradeoff becomes sharper when the merchant serves mixed-risk segments, because premium customers, gift buyers, and occasional shoppers can look similar to abuse actors on a narrow metric.

Best practice is evolving on how far to push automated restriction. Some merchants use soft friction, such as longer review times or more detailed return prompts, while others apply hard friction like account-level limits or refund method constraints. There is no universal standard for this yet, so policy should be tested against actual abuse patterns rather than copied from another retailer. The CISA Zero Trust Maturity Model is relevant as a design analogy: trust should be re-evaluated continuously, not granted or removed in one broad stroke.

Edge cases matter. Marketplace sellers may need different controls from first-party retail. Subscription goods and hygiene items often justify stricter rules because resale value and abuse potential are higher. International merchants also need to account for local consumer law, because a friction policy that is acceptable in one jurisdiction may be challenged in another. The most resilient approach is to define what triggers friction, what evidence is required, and when exceptions are allowed, then review those rules regularly against complaints, dispute rates, and repeat-offender patterns. For privacy-sensitive implementations, the ISO/IEC 27566 overview is a useful reference point for handling identity-related trust signals carefully.

Related resources from NHI Mgmt Group

• What does device intelligence add to subscription abuse and account sharing detection?
• How should teams detect free trial abuse without adding too much friction?
• How do teams balance friction and abuse prevention on AI free tiers?
• How should merchants reduce chargebacks caused by post-purchase friction?