WooCommerce: What Actually Happens After You Block a Customer (And Why They Come Back Anyway)

Blocking a customer feels like a definitive action. You have found someone abusing your return policy, or committing coupon fraud, or placing orders you suspect are fraudulent — and you want them gone. You take action. You remove their access. And then they come back.

This is not a rare edge case. It is the default outcome for native WooCommerce blocking, because the block mechanism in WooCommerce core ties enforcement to a single identifier — the WordPress user account — and a determined bad actor has at least four other routes back in. Understanding those routes is the starting point for any enforcement that actually holds.

What Native WooCommerce “Blocking” Actually Does

WooCommerce does not have a dedicated customer blocking feature built into core. What most store owners call “blocking” is actually one of two things: either revoking the customer’s WordPress user account access (by changing their role to something that cannot complete purchases, or by deleting the account entirely), or cancelling their outstanding orders manually and refunding where required. Neither of these is a checkout-level enforcement mechanism.

When you change a user’s WordPress role — for example, to a subscriber with no WooCommerce purchase capability — they may be prevented from checking out as a registered user. Some stores achieve a harder version of this by disabling their account entirely. But the checkout enforcement in native WooCommerce is role-based, not identity-based. It has no concept of “this email address should never complete a purchase.” It controls access for logged-in user accounts, not for people.

The practical result: if a customer you have “blocked” simply logs out and places their next order as a guest, or creates a new email address, or borrows an account, the block does not apply. There is nothing in native WooCommerce that connects “this person” across those identity variations.

The Four Ways a Blocked Customer Comes Back Anyway

Once you understand that native WooCommerce blocks are tied to a specific user account rather than to a person’s identity, the bypass routes become obvious. They do not require technical sophistication. They are available to any customer who is motivated enough to try again.

1. Guest checkout with the same email

If you have disabled a customer’s user account but your store still allows guest checkout, they can complete a purchase simply by using the same email address without logging in. Their account is blocked; the guest checkout path is not. WooCommerce treats the guest order as a separate entity — no user ID means no role check, no account-level block. The order goes through.

This is the most common bypass and the easiest to execute. It requires no technical knowledge. The customer just unchecks “create account” at checkout and the restriction disappears.

2. Guest checkout with a different email

Email addresses are free. A customer who understands — or guesses — that your block is tied to their email simply creates a new one. They do not need to verify it in advance; most WooCommerce checkout flows only validate email format, not deliverability. A new email address creates a completely fresh identity from WooCommerce’s perspective: no order history, no blocks, no flags.

This is harder to catch because the new identity genuinely looks like a new customer. Nothing on the individual order connects it to the blocked account unless you check manually — and most stores process enough orders that manual review of every new email is not realistic.

3. A new registered account

If you blocked the customer by disabling their existing account, they can create a new WordPress account with a different email address. The new account starts clean. It passes all the same registration checks their original account passed. You are back to the beginning.

Some stores attempt to mitigate this by manually reviewing new account registrations, or by requiring email verification with tighter delivery checks. Neither is reliable at scale, and both add friction for legitimate new customers.

4. A shared address or payment method via someone else

A blocked customer who lives with someone else — a family member, a roommate, a partner — can use that person’s account or create an account in their name. The shipping address may be the same. The payment method may be the same card, held by a different family member. The order looks like it comes from a different customer entirely.

This is the hardest bypass to identify because the signals are shared with a legitimate person. Acting on this requires connecting multiple customer records through shared fingerprints — something no purely account-level block can do.

Why Each Bypass Works — and the Technical Reason It’s Hard to Close

The common thread across all four bypasses is the same: WooCommerce’s native checkout validation framework has no identity model beyond the logged-in user account. The security question it answers is “does this account have permission to purchase?” — not “does this person have a history that should prevent them from purchasing?”

This is a design choice, not an oversight. WooCommerce’s core job is to process e-commerce transactions. Identity enforcement at the level of “stop this specific person, regardless of what account they use” is a fundamentally different problem — one that requires storing behavioral history, linking it across multiple identity signals, and intercepting checkout before the transaction completes.

This is also why IP blocking addresses a different problem than behavioral enforcement. An IP block stops traffic from a specific IP address — useful against certain automated threats, but trivially bypassed by any customer who changes their home network, uses a mobile connection, or uses a VPN. For the human customer who placed several fraudulent return orders from their home, an IP block provides essentially no enforcement. The comparison between IP blocking and behavioral fraud scoring explores this methodological difference in detail.

What Real Enforcement Actually Requires

Closing these bypass routes requires two things that native WooCommerce does not provide: an identity model that persists across accounts, and checkout interception that runs against that identity model before the transaction processes.

The identity model has to work at the level of behavioral signals rather than account identifiers. The signals that remain stable across different email addresses and different accounts include: shipping addresses, billing addresses, phone numbers, payment method tokens, IP addresses, and device fingerprints. A customer who creates three new accounts all shipping to the same address is identifiable through the address signal even when every email address is different.

The checkout interception has to run before the order is created — not as a post-order review step. A block that triggers after a payment has been processed puts you in the position of issuing a refund and reopening the conversation with the customer. A block that triggers at the cart or checkout stage, before any payment is attempted, prevents the transaction from reaching the payment gateway at all.

Both of these requirements — cross-account identity and pre-payment checkout interception — are outside what WooCommerce core provides. They require a plugin layer that is purpose-built for enforcement rather than transaction processing.

How TrustLens Checkout Enforcement Works — and Where It Reaches

TrustLens implements checkout enforcement through a Request_Gate — a rules dispatcher that intercepts checkout attempts before WooCommerce processes the transaction. The gate hooks into three points: woocommerce_add_to_cart_validation (Classic, fires when the customer adds an item to cart), woocommerce_checkout_process (Classic checkout submission), and the WooCommerce Store API’s cart and checkout routes via rest_pre_dispatch (covering the WooCommerce Blocks checkout).

When a checkout attempt comes in, the gate builds a context object containing the billing email, the IP address, a device fingerprint, and the customer’s WordPress user ID if they are logged in. It then runs registered rules against that context. The email blocklist rule — which handles explicit blocks you have set on a customer — checks whether the billing email hash from the incoming request matches any blocked customer record in TrustLens’s database.

The practical effect: a blocked customer cannot add items to their cart or complete checkout, whether they are logged in or checking out as a guest. The block applies to the email address they provide at checkout, not to their WordPress account. A customer who was blocked under their original account email is still blocked if they use that same email as a guest. They receive a customizable message (“We are unable to process your order at this time. Please contact support for assistance.” by default, editable in TrustLens Settings). The blocked attempt is logged in the customer’s event timeline.

This closes bypass route 1 directly: a customer blocked in TrustLens who uses the same email at guest checkout will be stopped at the cart level. Bypass routes 2, 3, and 4 — where the customer uses a genuinely different email — require the linked accounts layer.

Linked Accounts Detection: Connecting the Dots Across Identities

TrustLens’s Linked Accounts Detection module runs on every order, regardless of whether the customer is a guest or a registered user. When an order is created, the module extracts six types of fingerprint data from the order: shipping address hash, billing address hash, phone number hash, IP address, payment method token, and device user-agent hash. These are stored in TrustLens’s fingerprint table against the customer’s email hash.

After storing the fingerprints, the module searches for other customer records sharing any of those values. When it finds matches — a different customer record that previously placed an order with the same shipping address, for example — it flags the accounts as linked. The linkage appears on both customer profiles in the TrustLens admin.

This is how TrustLens can surface the relationship between a blocked customer and a new account they create to evade the block. The new account does not start out blocked. But when the first order from the new account arrives, the linked accounts module checks the fingerprints against existing records. If the new account ships to the same address as the blocked customer, or uses the same payment method, or checks out from the same device, TrustLens flags the connection.

The flag does not automatically block the new account — that decision remains with you. But the linked account data appears on the customer profile, and the scoring model applies a negative signal when a customer is linked to already-risky accounts. In TrustLens Free, you review that information and decide whether to block the new account manually. With TrustLens Pro’s Automation Rules, you can configure a rule that fires when linked accounts are detected and takes an action automatically — such as holding the order for review, or blocking the new account if the linked account’s segment is Risk or Critical.

For a deeper look at the specific signals the linked accounts module uses and how the fingerprint matching works across guests and registered customers, the post on guest checkout fraud and TrustLens covers the mechanics in detail, including what happens when a guest later creates a registered account.

What linked accounts detection does not do

Be honest about the limits here. Linked accounts detection is useful, but it is not a perfect catch mechanism for all evasion. A customer who uses a genuinely different shipping address, a different payment method, and a different device — as well as a different email — will not produce any overlapping fingerprints. Their new order will look entirely unrelated to the blocked account. There is no behavioral scoring tool that can reliably connect two customer records when every identifying signal is different. What TrustLens does is raise the cost and complexity of successful evasion significantly, because most determined abusers will reuse at least one signal.

Free vs Pro: What Each Tier Does When Blocking

TrustLens Free includes email-hash checkout blocking, the linked accounts detection module, and the full eight-module scoring pipeline — all at no cost. You can block a customer explicitly from their profile page, and that block enforces at the cart and checkout level across both Classic and Blocks checkout. Linked account data is surfaced on the customer profile. All blocked checkout attempts are logged.

What TrustLens Free does not do is act automatically on what it finds. You review the risk signals and make the enforcement decisions. The one exception is the 90-second card-testing lockout, which fires automatically when a device crosses the decline-velocity threshold during an attack — but that is device-level enforcement against bots, not customer-level blocking based on behavioral history.

TrustLens Pro adds automation rules that can take enforcement actions automatically when behavioral conditions are met. This includes rules that fire when linked accounts are detected, when a customer’s trust score drops below a configured threshold, when a customer’s segment changes to Risk or Critical, or when a new order arrives from a customer with a chargeback history. Pro’s Advanced Chargeback Monitor also adds an auto-block setting that fires after a configured number of lost disputes — useful for customers who dispute every order and require no further manual review decision.

For most stores dealing with one or two blocked customers per month, Free enforcement — review signals, block manually — is sufficient. Stores dealing with higher-volume abuse patterns, or those that want enforcement to run without requiring daily manual review, will find the automation layer in Pro meaningfully reduces the operational overhead of staying ahead of evasion attempts.

Frequently Asked Questions

Blocking is a decision, not a mechanism

The gap between “I have blocked this customer” and “this customer can no longer order from my store” is wider than it looks. Native WooCommerce gives you the tools to make a blocking decision — but the enforcement of that decision across all the ways a person can identify themselves at checkout requires a layer that WooCommerce core was not designed to provide.

The most useful reframe is this: blocking is not a wall you build once. It is an ongoing position you maintain as the customer’s behavior unfolds. Each bypass attempt produces signals — a shared shipping address, a familiar device fingerprint, a payment method you have seen before. Those signals, collected and linked across multiple identity attempts, are what make enforcement durable rather than cosmetic.

If you are finding that customers you have blocked return under new identities, the first useful step is not to add more manual review. It is to look at the fingerprint signals available from the orders you already have. The connections are often there — they just require a tool that is designed to look for them.