Struggling with WooCommerce blocking your legitimate hemp or CBD products? This guide dives into the real reason behind the block—it’s not what you think—and provides three practical, in-the-trenches solutions for DevOps and developers to fix it for good.

Decoding the “WooCommerce Not Accepting Hemp” Mystery: A DevOps Perspective

I got the call at 1:47 AM. It was a frantic project manager from one of our e-commerce clients. “Darian, the site’s broken! No one can check out. The cart says ‘prohibited item’ for our best-selling CBD dog treats.” My first thought was a security breach or a botched deployment from the junior dev. But after 20 minutes of digging through logs on our `prod-web-cluster-01` and finding nothing, the real, much more annoying culprit emerged: a silent, third-party “feature” update. This wasn’t a bug; it was a policy decision, forced on my client’s store without their consent. It’s a classic case of platform overreach, and if you’re in the hemp or CBD space, you’ve likely hit this wall yourself.

First, Let’s Get This Straight: It’s Not Really “WooCommerce”

Before we start blaming the entire WooCommerce ecosystem, let’s pinpoint the real issue. WooCommerce itself doesn’t inherently block hemp products. The problem comes from a service bundled with Jetpack and the official WooCommerce Payments plugin: Automattic’s country validation service. This service maintains a list of products and services it considers “restricted,” which often includes hemp, CBD, and other high-risk (in their view) categories. When a customer tries to check out, the plugin phones home to this service, which replies with a hard “no,” blocking the transaction. It’s a well-intentioned feature meant to help with compliance, but its implementation is a blunt instrument that causes chaos for legitimate businesses.

The Fixes: From a Band-Aid to a Permanent Solution

Alright, enough complaining. Let’s get our hands dirty. I’ve got three ways to tackle this, ranging from a quick fix to a more robust, architectural solution. We’ll weigh the pros and cons of each.

Solution 1: The Quick Fix (The Functions.php Snippet)

This is the most common solution you’ll find on forums, and for good reason: it’s fast and easy. We’re basically telling WordPress to ignore the “restricted product” check by using a filter. You can add this code to your child theme’s functions.php file or a custom snippets plugin.

Here’s the magic snippet:

// Disable WooCommerce Payments server-side country/state validation.
// This prevents it from blocking products like Hemp/CBD.
add_filter( 'wcpay_is_product_supported', '__return_true' );

Warning: This is a “hacky” fix. While effective, it’s brittle. A major update to the WooCommerce Payments plugin could change the filter name or remove it entirely, and you’ll be right back where you started, probably at 2 AM again. Use this for immediate relief, but consider a more permanent solution.

Solution 2: The Permanent Fix (The Server-Level Block)

Now we’re talking my language. Instead of trying to patch the application, let’s cut off its ability to talk to the service causing the problem in the first place. We can block the specific API endpoint at the server level. The plugin will try to make the call, it will fail to connect, and in most cases, it will gracefully fail-open, allowing the transaction to proceed without the external validation.

The endpoint to block is public-api.wordpress.com.

For a single server environment, you can do this with a simple hosts file edit. SSH into your server (e.g., `ssh admin@prod-web-01`) and edit the file:

sudo nano /etc/hosts

Then add this line to the bottom, which redirects any requests for that domain back to the server itself, where they will go nowhere:

127.0.0.1 public-api.wordpress.com

For a scalable cloud environment, you would implement this at the network level using a firewall, a WAF (Web Application Firewall), or your cloud provider’s DNS routing policies. This is far more robust and survives plugin updates, server rebuilds, and scaling events.

Solution 3: The ‘Nuclear’ Option (Ditch the Offending Service)

Sometimes, the best move is to remove the problem piece from the board entirely. If your business depends on selling these products, you can’t afford to be at the mercy of Automattic’s policy decisions. This means re-evaluating your stack.

The primary culprit is often WooCommerce Payments. The solution? Replace it. Find a payment gateway that explicitly supports your industry (e.g., Square, or specialized high-risk processors) and has a solid WooCommerce integration plugin. This removes the dependency on the validation service altogether.

This is the most disruptive option, as it involves changing your payment processor, but it’s also the only one that guarantees you won’t be fighting this battle again in six months.

Comparing the Solutions

To make it easier, here’s a quick breakdown of the approaches:

Ultimately, the right choice depends on your situation. If you need to get your site back online right now, use the code snippet. But while you’re doing that, start planning for a move to the server-level block or a different payment gateway. Don’t let a third-party policy dictate whether your business can operate.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions