Every store above a few thousand orders a month eventually has the conversation. Customer X has returned 60% of their orders over the past year. They've disputed two chargebacks and lost both, then opened three more. Support has received a dozen emails from them claiming damage, missing items, wrong sizes. The warehouse team has flagged three returns in the last six months for "signs of wear."
At some point the answer stops being "handle it on the ticket." The answer becomes: we're not selling to this customer anymore.
Blocking a customer is a legitimate operational tool. It's also one most stores handle poorly (too early, too casually, or too publicly) and end up with bad reviews, customer service complaints, or in a few cases legal threats they don't know how to respond to. Let's work through how to do it well.
When the threshold is actually met
Before talking about how to block, worth being honest about when. The instinct to block is often triggered by a single painful interaction, and the urge to act is strongest when it's least appropriate.
A pattern-based threshold looks like this, combining multiple signals:
- Return rate over 50% sustained over at least 10 orders
- At least one confirmed fraud pattern: chargeback filed and lost, return with clear wear signs, shared-address cluster with other flagged accounts, or documented abuse of a promotion
- Support interaction history that skews toward escalation: multiple tickets demanding exceptions, threats to dispute if refund not issued, repeated "I'll leave a bad review" pressure
- Aggregate refund spend disproportionate to purchase spend. The customer has cost you more in refunds, shipping, and support labor than they've generated in net revenue
Any one of these in isolation isn't enough. The right threshold is a pattern that hits at least three. A customer with a high return rate but clean chargeback history and reasonable support interactions is probably a bracketer or serial returner, not someone to block. That category needs different handling.
What doesn't meet the threshold, even though it feels like it does:
- A single heated support interaction, however unpleasant
- A single chargeback, even one you lost
- A return that came back in worse condition than expected, without a prior pattern
- A customer who left a scathing review
These feel personal. They're not patterns.
The three scenarios where blocking works well
Done right, blocking a customer is anticlimactic. No drama, no reviews, no escalation. Three scenarios reliably work out this way.
1. The high-return-rate customer whose pattern crosses the economic threshold
A customer whose net contribution over the last 12 months is negative, and whose return pattern looks like it's going to stay negative, is the clearest case. You're not making a moral judgment. You're a business deciding this individual customer isn't worth the operational cost.
These customers often know what they're doing. Blocking them rarely produces a surprise on their end. They've been optimizing your return policy for years. They tend to move on to the next store without much fuss.
2. The coordinated fraud ring member
When you've confirmed a fraud ring (shared address, shared payment method, new accounts created in coordinated bursts), blocking the ring members at once is both effective and defensible. The evidence is concrete. You have the addresses, the timing, the cross-account signals.
These customers rarely complain, for an obvious reason. A complaint would require them to explain to your support team why all their alternate accounts are shipping to the same address, and that conversation isn't one they want to have.
3. The customer who has escalated to threatening behavior
A customer who has sent harassing emails, threatened staff, or made explicit fraud threats ("I'll dispute every order I ever place") should be blocked on operational-safety grounds, regardless of their return history. About protecting your team and your processor relationship, not return economics.
The cleanest blocks to justify internally and the ones that produce the most relief on your support team.
The three scenarios where it backfires
Now the uncomfortable ones.
1. Blocking someone with a legitimate product-quality complaint
A customer who returned five of six orders from you because five of six arrived damaged is not an abuser. They're a victim of a fulfillment problem. Blocking them because their return rate is high produces a review that specifically calls out the fact that you blocked someone who was trying to tell you your packaging was inadequate.
The signal you want isn't return rate alone. It's return rate combined with return-reason consistency (abuse cases have scattered reasons, genuine complaints cluster), customer-service interaction tone (genuine complaints are frustrated but cooperative, abusive patterns often include demands or threats), and item-condition-on-return data (genuine complaints return items in the conditions they describe, abuse patterns return items in conditions that contradict the claim).
2. Blocking someone who has influence
"Influence" doesn't have to mean a social media following, though it can. It can mean they're a wholesale buyer who places small personal orders to try products. It can mean they're a journalist or reviewer covering your category. It can mean they work at a company that's a large business customer of yours.
These blocks don't backfire through a review. They backfire through a relationship you didn't realize you had. A pre-block check that takes 30 seconds ("is this customer associated with anything else in our records") prevents most of them.
3. Blocking publicly or with explanation
The most reliable way to turn a quiet block into a public incident is to tell the customer why they're being blocked, in writing, with specifics.
A customer who places an order that gets auto-declined, contacts support, and receives a response saying "your account has been blocked due to abusive return patterns" has just received a document they can screenshot. A subset of those screenshots end up on review sites with the customer's spin on the situation. You almost always come out worse in those stories, even when the block was fully justified, because the customer gets to tell the story first and you can't rebut without detailing their private purchase history.
The right communication is minimal. "We're unable to process this order at this time. For questions, contact [support email]." If the customer follows up, the escalated response is still minimal. "After review, we've determined we're unable to continue processing orders from this account. We've refunded any pending charges." No reasons, no history, no invitation to debate.
This feels cold. It's the correct temperature. The customer knows why, in most cases. You don't need to tell them.
The legal considerations nobody mentions
In the US, a private business generally has broad latitude to refuse service to specific customers, with a few specific exceptions. You can't refuse service based on protected-class membership (race, sex, religion, etc.). That legal baseline means most blocks are defensible if challenged.
Some jurisdictions have wrinkles worth knowing:
- California and some EU jurisdictions have stronger consumer protection rules, particularly around refunds and the conditions under which you can refuse to accept returns. Blocking the customer is usually fine. Refusing a return on a product they received but then retroactively blocking them mid-return is more complicated.
- The UK and EU "right to withdraw" gives consumers 14 days to return online purchases regardless of your store policy. Blocking someone after they've exercised this right is fine. Refusing the right itself is not.
- Class action exposure is minimal for normal blocking but rises if the blocking is algorithmic and applied at scale to a demographic pattern. If your scoring model correlates with a protected class (even accidentally, because of the features it uses) you have a problem that a single customer block can surface into a bigger one.
The practical mitigation is documentation. For every block, have a written record of the specific patterns that triggered it, stored somewhere discoverable. "Customer was blocked due to return rate exceeding 60% on 14 orders, with three confirmed fraud patterns including X, Y, Z" is a defensible record. "Customer was blocked because the algorithm said so" is not.
The communication template
Language that works across most situations, calibrated for minimal escalation.
On the automatic checkout failure (if your platform can customize the message):
"We're unable to process this order at this time. Please contact [email protected] if you have questions."
On the first support inquiry from a blocked customer:
"We've reviewed your account and determined that we're unable to continue processing orders at this time. Any pending charges have been refunded. We're sorry we can't accommodate further orders."
If the customer escalates or threatens legal action:
"We appreciate you reaching out. The decision has been reviewed at our end and stands. We wish you well."
That's the whole template. No explanation, no defense, no invitation to debate. The most important word across all three is "determined" rather than "decided." Signals finality without personal judgment.
The takeaway
Blocking a customer is a tool, not a statement. Used well, it's quiet. A small number of accounts per quarter, with documented patterns, minimal communication, no public fallout. Used badly, it produces reviews, legal threats, and escalations that take more time to manage than the customer would have cost if you'd just kept serving them.
The threshold that works is pattern-based, not incident-based. Multiple signals aligned over a sustained period. Single bad interactions don't meet it, no matter how tempting they feel.
The communication that works is minimal. The explanation that works is written down internally and never sent to the customer. The legal exposure that matters is mitigated by documentation of the specific pattern.
Most stores err in one of two directions. They never block, and they carry customers whose net contribution is deeply negative as a kind of implicit policy charity. Or they block reactively, individual by individual, in response to bad interactions, without a pattern threshold, and they pick up a slow trickle of negative reviews over time.
The better path is operational. A clear threshold, a documented process, a minimal communication protocol, and a willingness to hold the line when the blocked customer complains. Not fun work. The work.