Checkout Blocking Not Working

If you’ve marked customers as blocked but they’re still completing checkout, the enforcement layer isn’t actually engaging. This page walks through the diagnostic chain — there are several reasons enforcement can be off, and each has a specific fix.

---

Step 1: Verify the Master Toggle #

The most common cause. By default, the master toggle is off so you can mark customers as blocked without immediate enforcement.

1. Go to TrustLens → Settings → General
2. Under Blocking Settings, find Enable Blocking (“Allow blocking customers from checkout”)
3. If it’s off, turn it on
4. Save

With the toggle off, blocks are recorded but not enforced — the customer’s is_blocked flag is true, but checkout proceeds anyway. Turning the toggle on starts enforcement immediately on the next checkout request.

---

Step 2: Verify the Customer Is Actually Blocked #

The blocked-state flag is per-customer. Confirm:

1. Open the customer’s detail page
2. Look at the status chips near the top
3. You should see a “Blocked” chip — and no “Allowlisted” chip

Allowlisted customers skip checkout enforcement even when they’re also blocked. If you see both, remove the customer from the allowlist, then block them again (allowlisting clears the block).

If the customer shows blocked (and not allowlisted) but checkout still proceeds, the enforcement layer is the problem. If they don’t show blocked, the block flag wasn’t actually set — block them from their profile or with the Customers list’s bulk Block action.

---

Step 3: Verify the Email at Checkout Matches #

Enforcement is keyed by email hash. If the customer is using a different email at checkout than the one on their TrustLens record:

• They won’t match the block lookup
• Enforcement won’t apply
• They appear as a new, unblocked customer

This is a known limitation. Customers determined to evade blocks can register with a new email. Linked-accounts detection can sometimes catch this (shared address, phone or payment token), but the block won’t auto-propagate.

If you suspect block evasion, check the Linked accounts panel on the original blocked customer — are there new accounts linked? If so, block those too.

---

Step 4: Test With a Known Blocked Account #

Sanity check the enforcement:

1. Create a test customer (place a test order with a test email)
2. Block that customer from their profile
3. Log out of WordPress — store admins and shop managers are never blocked, so testing while logged in always gets through
4. From an incognito browser, attempt checkout with the blocked email
5. You should see the block message

If the test blocked account also gets through while you’re logged out, enforcement is fundamentally broken — not a per-customer issue.

---

Step 5: Check for Plugin Conflicts #

The Request Gate registers WooCommerce hooks. Other plugins that:

• Replace or override the checkout flow
• Implement custom checkout endpoints
• Aggressively cache the checkout page

…can bypass the Request Gate. To diagnose:

1. Deactivate all non-essential plugins
2. Switch to a default theme
3. Test blocking again
4. Reactivate plugins one by one until the issue returns
5. The plugin reintroducing the issue is the conflict

Common conflicts:

• Custom checkout plugins that replace WooCommerce’s checkout
• Direct checkout / one-click buying plugins
• Caching plugins caching the checkout page (rare but possible)

---

Step 6: Check Classic vs Blocks Checkout #

TrustLens’s Request Gate handles both Classic and Blocks checkout, but some WooCommerce versions or extensions add additional checkout paths. If you’ve added a custom checkout block, verify it goes through the standard Store API endpoint.

The Gate intercepts:

• Classic checkout submissions to /checkout/
• Blocks Store API writes to /wc/store/v1/checkout and /wc/store/v1/cart/…
• The pay-for-order page (/checkout/order-pay/…)
• Classic add-to-cart (blocks only when a logged-in customer’s account email is blocked)

Custom routes bypass these. If you have a custom route, your custom code needs to call wstl_is_blocked() and reject.

---

Step 7: Check the Block Message #

Sometimes “checkout not blocked” turns out to be “block is working but customer not seeing the message clearly.” Verify:

1. The Block Message in Settings → General is set
2. The message displays in standard WooCommerce notice format
3. If your theme heavily customizes notices, the block message may be hidden by CSS

Test by viewing source on the checkout error — is the block message in the DOM but hidden?

---

Step 8: Add-to-Cart vs Checkout Enforcement #

There’s no separate add-to-cart setting. With Enable Blocking on:

• A logged-in blocked customer is refused by classic add-to-cart buttons — symptoms feel different (“can’t add items to cart”)
• Blocks cart updates are refused once they carry the blocked billing email
• Guests can usually fill their cart and are stopped at checkout, once they enter their email

Both add-to-cart blocking and checkout blocking depend on the master toggle being on.

---

Step 9: Subscription Renewals #

WooCommerce Subscriptions renewal orders bypass the Request Gate — they’re created via Action Scheduler, not standard checkout. If your “blocked” customer keeps getting renewal orders processed, this is why.

Fix:

• Cancel the subscription in WooCommerce
• Or write a custom hook on wcs_renewal_order_created that checks wstl_is_blocked()

Pro automation rules can’t help here — there’s no renewal trigger, and renewal orders don’t fire Order Placed.

---

Step 10: Check the Audit Log #

Every blocked checkout attempt is logged. Open the customer’s profile and look in Recent activity for checkout_blocked entries (“Checkout blocked”).

• If you see these entries, enforcement is working — the customer is being blocked, they’re just retrying
• If you don’t see these entries despite the customer placing orders, enforcement isn’t engaging — back to earlier steps

---

Common Pitfalls #

• Forgot to turn on the master toggle. By far the most common.
• Testing while logged in as an admin. Store admins and shop managers are never blocked.
• Customer is also allowlisted. Allowlisted customers skip enforcement.
• Customer using a different email. Blocks are email-keyed; new email = new customer record.
• Subscription renewals. Not subject to the Request Gate.
• API-created orders. External integrations creating orders via REST bypass the Gate.
• Plugin conflict with custom checkout flows.