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 in Free so you can mark customers as blocked without immediate enforcement.

1. Go to TrustLens → Settings → General
2. Find Enable checkout blocking
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 indicators near the top
3. You should see a “Blocked” badge

If the customer shows blocked but checkout still proceeds, the enforcement layer is the problem. If they don’t show blocked, the block flag wasn’t actually set — go to the Customers list and explicitly block.

---

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, payment method, fingerprint), 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. Allowlist a test account (so it’s not affected)
2. Create a second test account
3. Mark the second test account as blocked
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, 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 POST to /checkout/
• Blocks Store API POST to /wc/store/checkout

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: Verify Add-to-Cart vs Checkout Enforcement #

If you’ve enabled the Block Add-to-Cart setting:

• The block engages at add-to-cart, not checkout
• Customers can’t even reach the checkout page
• Symptoms feel different — “can’t add items to cart”

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 by default — 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()
• Or use Pro automation rule on the renewal trigger to cancel

---

Step 10: Check the Audit Log #

Every blocked checkout attempt is logged. Open the customer’s profile and look at the event timeline for blocked_checkout_attempt entries.

• 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.
• Customer using a different email. Blocks are email-keyed; new email = new customer record.
• Subscription renewals. Not subject to the Request Gate by default.
• API-created orders. External integrations creating orders via REST bypass the Gate.
• Plugin conflict with custom checkout flows.