Medusa.js Customer Groups: Building B2B and Loyalty Segmentation Logic

Most storefronts treat every customer the same way, one product catalogue, one price list, one checkout flow for everyone. That works fine until a business needs to sell to wholesale buyers at negotiated rates, reward loyal customers with tiered pricing, or restrict certain products to specific accounts. Medusa.js handles this through customer groups, and once you understand how the pieces fit together, building B2B and loyalty logic on top of it becomes far less complicated than it first appears.

The official Medusa B2B recipe documents the core building blocks well, but most teams still need to think through how those pieces map onto their actual business rules before writing any code.

What Customer Groups Actually Do

A customer group in Medusa.js is simply a way to bucket customers together so you can apply rules to the whole bucket instead of individual accounts. You might create one group for wholesale buyers, another for VIP loyalty members, and another for a specific partner organisation with its own negotiated terms. Once a customer sits inside a group, price lists, product visibility, and even checkout behaviour can be scoped to that group without touching the rest of your catalogue.

Pairing Groups With Price Lists

The real power shows up when customer groups are combined with price lists. A price list can be scoped to one or more customer groups, meaning a wholesale group might see a flat twenty percent discount across an entire category, while a loyalty group sees smaller, targeted discounts on specific products. Because price lists sit as a separate layer above your base pricing, you can run several of these rule sets at once without duplicating your product catalogue for each customer type.

Handling Product Visibility for B2B Accounts

Some B2B setups need entire product ranges hidden from regular retail customers, which is where sales channels come in alongside customer groups. Creating a dedicated B2B sales channel and restricting certain products to it means wholesale buyers see a catalogue tailored to their contract terms, while your regular storefront stays unaffected. This separation also makes it easier to run different checkout rules, such as purchase order based ordering instead of card payments, for the B2B channel specifically.

Where Teams Usually Get Stuck

The most common mistake is creating one giant customer group for everything B2B related, which quickly becomes unmanageable once different partners need different terms. Splitting groups by organisation, even when the initial rule set looks similar, saves a lot of rework later. Our developers at Askan's Medusa.js development practice generally recommend mapping out every distinct pricing or access rule before creating groups, rather than adjusting group structure after the storefront is already live.

Comparing This Against Other Headless Options

Teams evaluating headless frameworks sometimes weigh Medusa against alternatives before committing, and our breakdown on Medusa.js versus Shopify Hydrogen covers how customer segmentation and B2B flexibility differ across the two. For teams that specifically need deep B2B customisation without vendor lock in, the customer group and price list combination in Medusa tends to require less custom engineering than building equivalent logic on more opinionated platforms.

Getting this right early matters more than it seems, because customer segmentation touches pricing, checkout, and reporting all at once. A clean group structure from the start means new partner accounts or loyalty tiers can be added later without restructuring the storefront each time.