Customer Groups in PrestaShop: Showing Different Prices to Different Customers

Not every customer should see the same price. A wholesale buyer ordering 500 units expects a different number than a first-time retail shopper, and a long-standing reseller expects a different number again. The instinct most merchants have here is the wrong one: duplicate the product, build a second "trade" store, or hard-code discounts somewhere fragile. PrestaShop already solves this natively with customer groups — a built-in segmentation layer that lets one catalogue show different prices, different categories and different payment options to different people, all driven by which group a logged-in customer sits in. This guide is about that mechanism specifically: how groups decide the price a customer sees, how the discount-versus-specific-price logic actually resolves, and where groups stop being enough.

If you're standing further back and asking "how do I run B2B on PrestaShop at all," start with selling B2B on PrestaShop — this post assumes you've decided group-based pricing is the tool and want to get it right.

What a customer group actually controls

A customer group in PrestaShop is a segment you manage under Shop Parameters → Customer Settings → Groups. Every customer account is attached to at least one group, and the group — not the individual customer — is what most pricing and visibility rules attach to. Out of the box PrestaShop defines three groups, and it's worth knowing exactly what they mean because two of them are not "customers" in the way you'd assume:

• Visitor — anyone browsing who is not logged in. The price an anonymous visitor sees is the Visitor group's price. This catches people out: change Visitor's settings and you've changed what every passer-by and search-engine crawler sees.
• Guest — a customer who checked out without creating an account (guest checkout).
• Customer — the default for anyone who registers a normal account.

You then add as many custom groups as your business needs — Wholesale, VIP, Staff, Regional Distributor — each carrying its own discount, its own price-display rule and its own category access, and most payment modules can be restricted by group from the payment restrictions/preferences screen. The "So what?" here: one PrestaShop store, one product catalogue, one stock pool, but the experience reshapes itself per buyer. No second store to keep in sync, no duplicate SKUs drifting out of alignment.

The two ways a group changes a price — and how they resolve

PrestaShop gives a group two different levers over price, and the single biggest source of "why is this customer seeing the wrong number" confusion is not understanding that they stack in a defined order.

1. The group-wide discount (the broad brush)

In Shop Parameters → Customer Settings → Groups, open a group and you'll find a Discount % field. Set Wholesale to 20% and every product in the catalogue automatically shows 20% less to anyone in that group — no per-product work. This is the fast, store-wide tier: good for "all our trade customers get 15% off everything." It applies as a reduction off the base price and is recalculated live, so it follows price changes automatically.

2. Specific prices (the scalpel)

On any product, the Pricing tab has a Specific prices section (the underlying object is SpecificPrice, and the same engine powers catalogue price rules under Catalog → Discounts). Here you can say: for the Wholesale group, this product is €12.00 flat, or 30% off, optionally only above a quantity of 50, optionally only between two dates, optionally only for one currency or country. This is how you give wholesale 30% off electronics but only 10% off accessories — control the broad discount can't express.

How they combine

Here's the practical version: a group-wide discount and a product's specific prices are two separate mechanisms, and how they interact depends on the reduction type, quantity, the group/category reduction and your PrestaShop version. Specific prices have their own priority among matching specific-price rows — that priority decides which specific price applies, it doesn't universally cancel a group reduction. Because the final number depends on all of those factors, the safe rule is to test overlaps with a real cart rather than assume a fixed order. The reason this matters in practice:

The outcomes above are not guaranteed by a fixed formula: whenever a group discount and a quantity or per-product specific price overlap, confirm the final price with a test customer and cart on your own install before publishing it to buyers.

So what? Set the broad group discount once for the "everyone in this tier" baseline, and reach for specific prices only where a product needs to break the pattern. If you try to encode every contract as a per-product specific price, you'll be maintaining hundreds of rows by hand — and that's the wall this article ends on.

Category visibility by group — a quieter superpower

Groups don't only move prices; they decide what a customer can even see. Edit any category under Catalog → Categories, open its Group access checkboxes, and untick the groups that shouldn't see it. A "Wholesale Only" category holding bulk packs and pallet quantities then simply doesn't exist for retail shoppers — it's absent from the menu, and products that live only in hidden categories drop out of search results and listings for those groups too.

The benefit is a clean shopfront without running parallel stores: your retail visitors never see the 24-unit case packs that would confuse them, and your trade buyers land straight in the catalogue built for them. The watch-out: a product still needs to be visible to some group the customer belongs to, or it vanishes — so when a product mysteriously won't show, the Visitor group's category access is the first thing to check.

Payment methods by group

Most PrestaShop payment modules expose a group restriction under Payment → Preferences (the "Group restrictions" matrix), letting you decide which groups may use which method. The common B2B move: allow Wholesale to pay by bank-wire or on account, and hide card payment from them so you're not absorbing card fees on five-figure orders — while retail keeps every fast option. Letting trade customers buy now and settle later is a topic of its own; we cover the mechanics in deferred payment terms for business customers.

How a customer ends up in the right group

A single customer can belong to several groups but has exactly one default group, set on their profile under Customers → Customers, which determines their base price display. When a customer belongs to more than one group, specific-price priority decides among the matching specific-price rows, while the default group drives their price display and baseline group behaviour. That makes multi-group membership worth testing explicitly: assign the extra group, then log in as a test customer and confirm the price you intended is the one they actually see.

Assigning groups by hand is fine for a handful of trade accounts. It stops being fine the moment you're approving business customers at any volume — at which point you want the application, the vetting and the group assignment to be one workflow rather than three manual steps. That's a sibling topic with its own depth: see trade account applications for verifying a business before you hand it wholesale pricing.

One thing groups do NOT decide on their own: tax display

It's tempting to treat "show net prices to wholesale" as just another group setting — and PrestaShop does expose a Price display method (tax included / tax excluded) per group. But getting net-versus-gross right for B2B is more than flipping that toggle: it interacts with your country tax rules, the displayed-price logic across product pages and cart, and VAT-exemption handling. Rather than half-cover it here and contradict the dedicated guide, the full treatment lives in net prices vs gross prices: tax display switching, and the automated VAT-number side in the EU VAT checker. Set the group's display method, then follow those for the parts that bite.

A practical setup checklist

• Keep the group count low — 3 to 5. Every group multiplies the surface you have to test (price, visibility, payment, tax display). Most stores need Retail, one or two trade tiers, and maybe Staff. Resist a group per customer.
• Use the group discount for the tier, specific prices for the exceptions. Broad brush first, scalpel second — not hundreds of hand-built rows.
• Reserve cart rules for time-boxed promotions. Groups are permanent pricing structure; a seasonal sale belongs in Catalog → Discounts → Cart rules, not baked into a group discount you'll forget to remove.
• Test as a real account in that group. Create a test customer, assign the group, log in normally, and verify the price, the visible categories and the payment options. If you have a trusted impersonation module installed it makes this a few clicks, but a plain test account works everywhere.
• Write down the structure. Once specific prices overlap across groups it gets genuinely hard to predict a number from memory — keep a short map of group → discount → notable specific prices.

Where customer groups stop being enough

Groups are built for tiers: bands of customers who share a price. They are a poor fit for per-customer pricing — the classic B2B situation where every reseller has individually negotiated rates on different product ranges. You can express that with customer-level specific prices, but you'd be maintaining one SpecificPrice row per customer per product, by hand, forever. At a few dozen contracts that's tedious; at hundreds it's a part-time job and a source of pricing errors that cost real money.

That's the honest boundary of the native system: groups give you clean, low-maintenance pricing tiers and they're the right answer for most stores — but if your model is genuinely "every account has its own price list," you've outgrown what groups alone manage comfortably, and the maintenance overhead becomes the deciding factor. Before you build that, it's worth pressure-testing whether a smaller number of well-designed groups plus a handful of specific prices gets you 90% of the way with a tenth of the upkeep. Most stores discover it does.

Customer groups are one of PrestaShop's most quietly capable features: one catalogue, one stock pool, and a shopfront that reshapes its prices, its categories and its payment options around who's logged in. Get the group-discount-versus-specific-price logic straight, keep the group count disciplined, and hand the tax-display and trade-vetting parts to the guides built for them — and you have a B2B pricing layer that runs itself instead of running you.