Struggling to verify if the Unique Customer Pricing (UCP) plugin for WooCommerce is working with your caching layer? This guide dives into the root cause and provides three real-world solutions, from quick code fixes to permanent architectural changes, to ensure your customers always see the right price.

Is Your WooCommerce Pricing Lying? Taming UCP and That Pesky Cache

I still remember the pager alert. 2:17 AM on the Tuesday before Black Friday. A high-priority ticket floods in: “Wholesale prices not showing!!!” I log in, and my heart sinks. Our biggest B2B client, who was supposed to see a 40% discount, was seeing full retail price on every single product. We were hours away from losing a massive holiday order. The culprit wasn’t a database failure or a broken deployment; it was a single, stubborn, misconfigured line in a Varnish cache config. That night taught me a lesson I’ll never forget: user-specific content and aggressive caching are natural enemies, and if you don’t force them to play nice, they will burn your house down.

So, What’s Actually Breaking? The “Why” Behind the Pain

Let’s get one thing straight: this isn’t really UCP’s fault, nor is it WooCommerce’s. The problem is a fundamental conflict of interest. Your caching layer (be it Varnish, Redis, NGINX FastCGI Cache, or a plugin like WP Rocket) has one simple, beautiful goal: serve a pre-built, static HTML page to as many people as possible, as fast as possible. It grabs a copy of the page requested by the *first* visitor and serves that same copy to visitors 2, 3, and 500.

But a plugin like “Unique Customer Pricing” has the opposite goal: serve a *different*, dynamically generated page based on who is asking. A retail user sees one price, a “Gold Tier” wholesale user sees another. When the cache botches this, it usually caches the version for the very first visitor—typically an anonymous, logged-out user—and then serves that retail-priced page to everyone, including your logged-in wholesale partners. Ouch.

Three Ways to Fix This Mess

Alright, enough theory. You’re here because things are broken and you need to fix them. I’ve got three approaches for you, ranging from a quick tactical fix to a more permanent, architectural solution.

Solution 1: The Quick Fix (The ‘DONOTCACHEPAGE’ Hammer)

This is the “stop the bleeding” approach. We’re going to tell WordPress, in no uncertain terms, not to cache pages for logged-in users. It’s a blunt instrument and impacts performance for those users, but it guarantees they see the correct, dynamically generated price. You do this by adding a snippet to your theme’s functions.php file.

add_action('wp', 'ucp_no_cache_for_logged_in_users');
function ucp_no_cache_for_logged_in_users() {
    // We only care about logged-in users
    if ( is_user_logged_in() ) {
        // This is a WordPress constant that many caching plugins respect.
        if ( ! defined('DONOTCACHEPAGE') ) {
            define('DONOTCACHEPAGE', true);
        }
        
        // As a backup, send no-cache headers directly.
        // Some caching layers (like Varnish) can be configured to obey these.
        nocache_headers();
    }
}

When to use this: Use this when you’re in a panic, you can’t easily configure your upstream cache (e.g., on managed hosting), and you’d rather have slower pages for logged-in users than wrong prices.

Solution 2: The Permanent Fix (Vary The Cache)

This is the “right” way to do it. Instead of disabling the cache, we’re going to teach it to be smarter. We’ll tell our caching layer, “Hey, I know you love caching, but you need to maintain a *separate* cached version of the page for each different type of user.” This is typically done by varying the cache based on a specific cookie.

Most pricing and membership plugins, including UCP, set a cookie to track the user’s group or status. Your first job is to find it. Use your browser’s developer tools, log in as a wholesale user, and look for a relevant cookie. It might be named something like wp_ucp_customer_group or similar.

Once you have the cookie name, you configure your cache. Here’s a conceptual example for a Varnish (VCL) configuration:

# This goes inside your vcl_hash subroutine
sub vcl_hash {
    # Default hash behavior
    hash_data(req.url);
    if (req.http.host) {
        hash_data(req.http.host);
    } else {
        hash_data(server.ip);
    }

    # Our magic line: If the UCP cookie is present, add it to the cache hash.
    # This creates a unique cache object for each value of the cookie.
    if (req.http.Cookie ~ "wp_ucp_customer_group") {
        hash_data(regsub(req.http.Cookie, ".*wp_ucp_customer_group=([^;]+);.*", "\1"));
    }

    return (hash);
}

This tells Varnish: “Create a different cached version of this URL for every unique value of the wp_ucp_customer_group cookie.” Now, retail users (with no cookie) get one cache, and wholesale users get another. Problem solved, and you keep your performance.

Warning: Be careful with this! If you vary the cache on a cookie that has too many unique values (like a session ID), you will destroy your cache hit rate and effectively have no cache at all. Only vary on cookies with a low number of possible values, like user roles or pricing tiers.

Solution 3: The ‘Nuclear’ Option (Client-Side AJAX)

What if you can’t modify your server’s caching config? Maybe your hands are tied by a managed hosting provider. In this case, we bypass the cache for the price itself. The strategy is to serve the entire page from cache with a placeholder (like a loading spinner or even the retail price), and then use JavaScript to make a separate, non-cached AJAX call to the server to fetch the *correct* price for the current user and update the page.

This is complex. You’d need to:

1. Create a custom WordPress REST API or admin-ajax.php endpoint that returns a product’s price for the current user. This endpoint must be explicitly excluded from caching.
2. Write JavaScript that, on page load, hits this endpoint, gets the price, and injects it into the correct spot on the page.

When to use this: Only when solutions 1 and 2 are impossible. The big downside is “price flicker,” where a user briefly sees one price before it updates to another. It can feel clunky and adds extra requests to your server, but it’s a valid last resort.

How Do You Actually Verify It’s Working?

Don’t just deploy and pray. You need to verify. Here’s my go-to checklist:

My Pro Tip: Never, ever debug caching issues on a live production server during business hours. Clone your site to a staging environment (e.g., staging-ecom-cluster) that has an identical caching setup. Break things there. Fixing a bug under pressure at 2 AM is ten times harder than fixing it on a staging server on a quiet Wednesday afternoon.

Caching is a powerful tool, but it demands respect. When you mix it with dynamic, user-specific content, you have to be deliberate and methodical. Hopefully, these approaches give you a clear path to getting your prices right and your sleep back.

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