Blocking and Allowlisting

Blocking and allowlisting are TrustLens’s two primary moderation actions. Blocking prevents a customer from completing checkout; allowlisting locks a customer at score 100 and suppresses all negative signals. They’re opposite tools for opposite situations — one for customers you don’t want to transact with, one for customers you never want flagged. This page covers when to use each, exactly what each does, and how they interact with the rest of the system.

---

Blocking #

Blocking is the action you take on a customer whose behavior makes you decide not to transact with them anymore.

What It Does #

• Sets is_blocked = true on the customer’s record
• If the global checkout-blocking master toggle is on, the customer cannot complete checkout
• Both Classic and Blocks checkout are enforced
• The customer sees a generic error message (customizable in settings)
• The block is logged in the event timeline with admin attribution
• The customer’s score is not changed by blocking — it remains whatever the signals produced

What It Doesn’t Do #

• Doesn’t prevent the customer from browsing your store
• Doesn’t notify the customer that they’ve been blocked
• Doesn’t cancel existing orders or refunds
• Doesn’t prevent the customer from logging in to their WordPress account if they have one
• Doesn’t add them to a server-level firewall

The Master Toggle #

Blocking only enforces at checkout if the global Enable checkout blocking setting is on. This master toggle defaults to off in Free so you can mark customers as blocked, observe scoring, and choose your moment to actually enforce.

To enable enforcement: TrustLens → Settings → General → Enable checkout blocking.

The Block Message #

Customers attempting checkout while blocked see a generic, neutral message — by default: “We’re unable to process your order at this time. Please contact support.”

The wording is intentionally non-specific. It doesn’t tell the customer they’ve been blocked, what triggered it, or how to appeal. This is deliberate — revealing the block surface invites adversarial probing and gives bad actors information they can use.

You can customize the message in Settings → General → Block message. Keep it neutral.

When to Block #

• Critical-segment customers with confirmed multi-module abuse
• Customers with 2+ lost disputes
• Confirmed fraud-ring members (linked-account analysis confirms shared identity)
• Customers with explicit policy violations (terms-of-service breach)
• Pro: automated blocks via the automation engine

When Not to Block #

• Caution-segment customers — too early, observation is the right move
• Risk-segment customers with one signal — investigate first
• VIPs or long-tenured customers — even with negative signals, manual review is required
• Customers in active dispute resolution — let the process play out

---

Allowlisting #

Allowlisting is the action you take on a customer you never want flagged by TrustLens.

What It Does #

• Sets is_allowlisted = true on the customer’s record
• Locks the trust score at 100
• Locks the segment at VIP
• Short-circuits scoring entirely — no signals are computed
• Bypasses Card-Testing Defense velocity rules (if VIP bypass is on)
• The allowlist is logged in the event timeline with admin attribution

What It Doesn’t Do #

• Doesn’t unblock a blocked customer (you have to do that separately)
• Doesn’t grant the customer any special privileges in WooCommerce
• Doesn’t notify the customer

Allowlisting Locks the Score at 100 #

The allowlist is implemented as a short-circuit in the scoring engine. The first check the engine does is “is this customer allowlisted?” If yes, return score = 100, segment = VIP, and stop. No module signals are computed for allowlisted customers.

This means allowlisting is durable — future bad behavior won’t lower the score until you remove the allowlist. It’s the right tool for customers who matter enough that you want them protected from any signal, including ones you haven’t anticipated.

When to Allowlist #

• Top customers by lifetime value
• Strategic accounts (B2B, key partnerships)
• Customers you’ve personally vetted and want immune to false positives
• Family members, employees, friends shopping at your store
• QA test accounts you don’t want polluting your scoring metrics

When Not to Allowlist #

• Customers who are merely “good so far” — let them earn VIP organically
• Customers you don’t personally know — allowlist is a trust signal, use it accordingly
• Broad cohorts — allowlist is per-customer, not per-segment

---

Block + Allowlist Interaction #

The two flags are independent. A customer can technically be both blocked and allowlisted, though the combination is unusual:

Block	Allowlist	Effect
No	No	Normal — score computed from signals, normal checkout
Yes	No	Score from signals; checkout blocked if master toggle on
No	Yes	Score locked at 100, segment VIP; normal checkout
Yes	Yes	Score locked at 100, but checkout still blocked. Use only if you want score-locked but transactionally blocked.

The fourth case is rare. If you find yourself wanting it, consider whether you really want to allowlist someone you’ve also blocked — usually one or the other is correct.

---

Per-Customer vs Global #

Both blocking and allowlisting are per-customer actions. There’s no segment-wide “block all Critical” or “allowlist all VIP” toggle in Free. Pro adds automation rules that can effectively produce this behavior on incoming events (“if segment changes to Critical, set blocked”), but the state is still tracked per-customer.

---

Bulk Operations #

The Customers list supports bulk block / unblock / allowlist / remove-from-allowlist actions. Select rows with the checkbox column, choose an action from the bulk-action dropdown, and confirm. See Bulk Actions.

---

Undoing Actions #

Both actions are reversible. Unblock or remove-from-allowlist restore the customer to normal scoring. The event timeline preserves the historical state — you can see when the customer was blocked and unblocked.

Allowlisting then removing produces an immediate score recalculation — the score will drop back to whatever the underlying signals produce.

---

Customer-Facing UX #

Neither action produces customer-facing notifications. Customers don’t see when they’re blocked or allowlisted. The only customer-facing manifestation is the checkout error message during a block.

If you need to communicate with a blocked customer (e.g. for appeals), do so out-of-band — direct email, phone. Don’t try to communicate via the checkout error message.

---

The Admin Audit Trail #

Every block, unblock, allowlist, and remove-from-allowlist action is logged with:

• Timestamp
• Admin username who performed the action
• Customer affected
• Before/after state
• Optional reason (free-form text)

Audit log is visible per-customer (in the event timeline) and as a global audit page under Settings. Useful for accountability and for analyzing the team’s moderation patterns over time.