How to Restrict Specific Payment Methods to Verified Business Customers Only

Managing payment options for different customer tiers is critical for high-volume B2B operations. In PrestaShop, offering credit terms or bank transfers to general retail visitors exposes your store to fraud and cash flow risks.

By default, PrestaShop allows basic payment restrictions by customer group, but enforcing strict verification requires a dedicated setup. Here is how to configure payment access so only fully verified B2B accounts can unlock special checkout methods.

Why Payment Gating Is A B2B Revenue-and-Risk Problem, Not A Checkbox

To restrict payment methods to verified business customers in PrestaShop, put approved trade accounts into a dedicated Customer Group, then gate the payment method to that group. PrestaShop's native Payment Restrictions page can hide methods per group, but it is brittle with multi-group customers and module logic. For reliable B2B payment gating, hiding invoice, PO and bank-transfer options until a business is verified, use the PrestaShop Restrict Customer Groups Module and assign payment methods granularly by group.

Picture a wholesale tile supplier in Leeds running a trade storefront. A consumer creates an account, adds several pallets to the basket, selects "Invoice, net terms" because it appears next to card at checkout, and pays nothing upfront. The order ships, and weeks later someone in accounts is chasing an invoice for a person who never had credit terms. Reversing that means a courier recall, restocking, and a soured customer relationship.

This is the real cost of an open payment list. Trade-only methods act as a credit promise, and letting anyone select them turns your checkout into a lender of last resort. Payment terms are something buyers actively expect, too: 67% of B2B buyers expect payment term options that match their accounting cycle, so you cannot simply delete invoice and PO options without losing genuine accounts.

Order sizes widen the exposure, because B2B retailers typically see orders of 15 to 25 items at once, so a single mis-selected payment method can tie up significant stock value. Card payments at least settle; deferred methods do not.

The fix is not to strip payment options from checkout, but to make visibility itself conditional:

• Verified trade accounts land in a Customer Group such as Wholesale Approved.
• That group alone sees invoice, purchase order and bank transfer at checkout.
• Unverified and retail visitors see card and other prepaid methods only.
• Group membership becomes the approval switch, so onboarding and payment rights stay in sync.

If a payment method is a credit decision, it does not belong in front of a customer who has not been approved for credit.

What You'll Need

Confirm you have the following in place before you start. Working through this list first saves you from stalling halfway through the setup.

• Access Level: a PrestaShop back-office account with permission to install modules, edit Customers and Groups, and change Payment settings. An employee profile limited to order viewing will not be enough.
• Platform Version: a PrestaShop 1.7.x or 8.x store with the standard Customers, Groups and Payment screens available in your back office.
• Module: the Restrict by Customer Groups module archive, ready to upload through Module Manager.
• Estimated Time: about 45 to 60 minutes to install, build the group rules, gate the payment method, and test three checkout scenarios.
• Difficulty: moderate. The interface work is straightforward, but the verification workflow and multi-group logic need a little care.
• Preparation: a database backup and at least one test customer account you can move between groups freely.

Prerequisites

These are the hard requirements. If any are missing, fix that first, because later steps will not behave predictably without them.

• Admin Access: full permissions on Modules, Payment and Customers, plus the ability to clear the shop cache.
• Plugin Installed and Active: Restrict by Customer Groups installed through Module Manager and showing a Configure button, not just an Install button.
• Existing Customer Groups: at least a default group plus one group you intend to use for verified trade accounts.
• A Payment Module To Gate: an invoice, purchase order, bank transfer or credit module already configured and working for the groups that should see it.
• A Staging or Low-traffic Window: payment visibility changes take effect immediately on save, so test before real buyers arrive.
• A VAT or Company Registration Check: some way to confirm a business is genuine before you approve it, whether that is a manual records check or a validation service.

Method 1: Gate Payments By Customer Group with the Restrict by Customer Groups Module

PrestaShop's native Customer groups feature lets you assign a payment module to a group, but it does not stop a self-registered visitor from being sorted into the wrong group in the first place. The module that closes that gap is PrestaShop Restrict Customer Groups by Products, Categories by FME Modules. It works alongside the group logic your shop already uses, so you keep native payment restrictions and add reliable group assignment on top.

The steps below build one clear outcome: a trade-only payment method that only verified businesses can reach, and a default group that never sees it.

Step 1: Install & Configure the Module

Installation comes first because every later step depends on the module being active and reading your existing groups correctly.

Navigate to Modules and Module Manager, search for the module, and install it. Open Configure once installation finishes.

• Currency: choose the currency the restriction rules apply to, from EUR, GBP or USD.
• Language: select the back-office and front-office language from English, Deutsch, Español, Français or Português BR.

You should now see the module's configuration screen with your currency and language applied, ready for group rules.

Step 2: Create a Verified B2B Customer Group

You need a group that exists purely to mark an account as trade-approved, separate from any general "Wholesale" group you may already run.

Go to Customers and Groups, then select Add new. A customer can belong to several groups at once, so this new group adds a verification flag rather than replacing the customer's existing group.

• Name: give it an unmistakable internal label, such as Verified B2B.
• Discount and Price display method: set these to match your trade terms, or leave them at the default if you apply trade pricing at product level.

You should now see the new group listed under Customers and Groups, available to assign to any account.

Step 3: Restrict Access to Products, Categories and CMS Pages

Restricting content matters because a payment rule means little if anonymous visitors can still browse trade-only catalogue pages and prices. The module handles this in the same place you build the payment gate.

Open the module's configuration and locate the restriction options for Products, Categories, and CMS pages. For each item you want to protect, choose the customer groups allowed to see it.

• Products: select the trade-only items and allow only the Verified B2B group.
• Categories: apply the same rule at the category level, which is faster for large catalogues.
• CMS: restrict wholesale terms, price lists or account pages to approved groups only.

You should now see restricted products, categories and CMS pages hidden from groups that are not on the allowed list.

Step 4: Gate the Payment Method by Group

This is the step that stops a retail shopper from selecting an invoice or trade-credit payment option they should never see.

Go to Payment and Preferences. PrestaShop lets you limit each payment module to specific customer groups here, so set the trade-only module to the Verified B2B group only, and leave card and wallet modules open to all groups.

• Currency Restrictions: Align the payment module's currency limit with the currency you set in Step 1.
• Group Restrictions: Tick Verified B2B for net-terms and invoice modules, and untick every other group.
• Country Restrictions: Add a country limit if you only extend trade terms to businesses registered in specific markets.

You should now see the restricted payment method appear at checkout for Verified B2B accounts, and stay hidden for everyone else.

Step 5: Approve Business Accounts into the Group

Approval is the verification workflow, and it is what makes the whole setup trustworthy rather than merely restrictive. Build the process around your registration form and order back office rather than a single toggle.

1. Require a company name and VAT or registration number on the registration form.
2. Check the submitted details against your business records or a VAT validation service.
3. Open Customers and Customers, edit the approved account, and tick Verified B2B under its groups.
4. Reject or leave unapproved accounts in the default customer group, so they stay on retail terms.

You should now see approved businesses flagged with the Verified B2B group, and unverified registrations left on retail pricing and payment options.

Step 6: Confirm B2C Buyers Never See Trade-Only Options

Final verification protects your margin and prevents a retail buyer from ordering on terms you never granted.

Log out, then repeat the checkout three times: once as a guest, once as a new unapproved registration, and once as an approved Verified B2B account.

• A guest should see only card and wallet payment methods, with no invoice or net-terms tile.
• A new registration should land in the default group and see the same restricted set.
• The approved account should see the trade payment method and any restricted catalogue content.

You should now see a clean split between retail and trade checkout, with no overlap between the two.

Method 2: What PrestaShop's Native Tools Can (and Can't) Do

PrestaShop does ship with payment restrictions, and they are genuinely useful. They are also narrower than most B2B merchants assume. Before you install anything, it is worth understanding exactly where the native setup stops working, because the gap is what justifies the module approach.

You can find the relevant controls in two places. Go to Payment -> Preferences to set currency and country restrictions, plus a minimum order value, per payment method. Then open each individual payment module and use its own Customer groups and Carrier restrictions. That is the whole native toolkit.

What the Native Restrictions Actually Do Well

• Currency & Country Limits let you hide, for example, a BACS transfer method from buyers outside your invoicing markets.
• Customer Group Limits hide a method from the Guest group, which is the simplest way to stop a walk-in shopper selecting "Pay on account".
• Carrier Limits prevent a freight-only payment method from appearing for a click-and-collect order.
• Minimum Order Value keeps expensive payment methods off very small baskets.

Combine group restrictions with a guest-checkout policy and manual account validation, and you get a workable first line of defence. Disable Guest checkout under Customer Settings, approve new B2B accounts by hand, and check a VAT number before you flip an account into your wholesale group. For a store with a handful of trade customers, that is often enough.

Where The Native Approach Breaks Down

The first crack appears with multi-group membership. A customer can belong to several groups at once, and PrestaShop evaluates payment visibility against that combination. A buyer who is both "Retail" and "Wholesale" can inherit access to a method you only meant for verified accounts, and there is no straightforward way to make one group's restriction take precedence.

Second, group restrictions are site-wide, not catalogue-wide. They gate the payment step, not the products that lead to it. If a payment method is tied to a product line or category rather than to a customer type, the native settings cannot express that rule at all.

Third, behaviour varies between payment modules. Not every module exposes the same Customer groups and Carriers fields, and third-party modules may ignore them entirely. The result is an inconsistent checkout where one payment method respects your gating and another quietly does not.

The native settings tell PrestaShop who can see a payment method, but they never verify that the buyer is a legitimate business, which is the part that actually protects your margin.

That is the limitation PrestaShop Restrict Customer Groups by Products, Categories closes. It ties access rules to the customer group itself, including product- and category-level gating, so an unverified visitor cannot even reach the checkout stage where an invoice payment method lives.

If you have only a few manually approved trade accounts, the native route is honestly fine. Once you are onboarding B2B buyers at any volume, the manual checks become a queue, and the queue is where unverified orders slip through.

Troubleshooting: When Restricted Payment Methods Still Show Up

Payment gating usually works the first time you test it. The problems appear later, when a real buyer checks out in a way you did not test, or when PrestaShop serves a cached version of the checkout page. Below are the failure patterns we see most often, with the fix for each.

If a trade-only tile still shows to a guest, start with guest checkout. PrestaShop lets visitors check out without an account by default, and a guest is not a verified business. Either turn off guest checkout entirely in Customer Settings or remove the trade payment method from the group that visitors inherit. A payment method is only as private as the weakest group a buyer can belong to.

When one customer sees everything, the cause is almost always overlapping group membership. If you have assigned a wholesale buyer to a second group for a promotion, a newsletter segment, or a regional discount, that second group may still have the trade method enabled. Access rules combine across groups, so the buyer keeps the tile. Review the customer's group list and remove the stray group, or switch that group's payment access off.

Cache is the next suspect. After you change group payment access, clear PrestaShop's cache and any page cache or CDN layer sitting in front of the shop. If your theme overrides payment templates, that override can also bypass the restriction, so check for custom templates in your child theme before assuming the module failed.

Sometimes the payment module itself is the problem. Some payment modules apply their own validation and ignore group context entirely, which means no group rule can hide them. Test by disabling the module temporarily; if the tile disappears and the restriction behaves, the module needs a compatibility check with its vendor.

Finally, watch for clashes between group rules and country or currency restrictions. If a payment module only allows certain currencies, a buyer paying in an unsupported currency may see the tile disappear, or a buyer in an unsupported country may lose access to a method you expected to offer. Test checkout with a real buyer account from each target country before you go live.

Why Restricting Payment Methods to Verified B2B Buyers Matters

B2B payment methods carry real financial exposure. Net terms, purchase orders, and invoice-based checkout all assume the buyer is a legitimate business with an accounting department on the other end, not a consumer who ticked a box at registration.

When every visitor sees every payment option, you are effectively extending supplier credit to strangers. A wrong selection means chasing an invoice, absorbing a chargeback, or cancelling an order after stock has already been picked.

Restricting payment methods by PrestaShop customer group keeps those options visible only to accounts you have reviewed and approved.

Quick Answer

In PrestaShop, payment method visibility is tied to customer groups rather than individual accounts. PrestaShop Restrict Customer Groups by Products, Categories lets you gate CMS pages, products, and categories by group, while your payment module's group restrictions control which checkout options appear to verified trade accounts.

How To Restrict Payment Methods To Verified B2B Buyers in PrestaShop?

Two routes exist: pairing a group-restriction module with your payment module's own group settings, or editing the theme template manually. The module approach is safer and reversible.

Method 1: Restrict By Customer Groups

PrestaShop Restrict Customer Groups by Products, Categories is a module that limits access to CMS pages, products, and categories based on the customer group a visitor belongs to. It gives you one place to manage what each trade tier can see, instead of editing theme files every time your wholesale terms change.

Step 1: Install & Open the Module

Installation is the foundation, because nothing else in this workflow functions until PrestaShop recognises the module as active in your back office.

• Navigate to Modules and then Module Manager.
• Use Upload a module to add the downloaded archive, or search the marketplace listing for Restrict by Customer Groups.
• Select Install, then choose Configure once the install finishes.

You should now see the module's configuration screen listed under your installed modules.

Step 2: Set Up Your Customer Groups

Groups are the unit everything else depends on. If your wholesale tier, retail tier, and pending-approval accounts are not separated into distinct groups, no restriction rule can target them correctly.

• Navigate to Customers and then Groups.
• Select Add new customer group to create a tier such as Verified Wholesale.
• Assign a name, and review the discount and display settings that apply to that group only.

You should now see your new group appear in the customer groups list.

Step 3: Restrict Content By Group

A group with no restrictions attached changes nothing. This step defines which products, categories, and CMS pages each trade tier can actually open.

• Open the module's Configuration page.
• Select the content types to manage: Products, Categories, or CMS Pages.
• Apply groups to each entry, choosing Allowed Groups from the available list.
• Pick a behaviour for blocked visitors, such as redirecting them or showing a restricted message.
• Select Save to store the rules.

You should now see your selected groups stored against each product, category, or CMS page.

Step 4: Restrict Payment Options By Group in Your Payment Module

Group access alone does not hide a payment method. PrestaShop's core separates payment availability by currency, country, and group, so the final gate belongs to the payment module itself.

• Navigate to Payment and then Payment Methods.
• Open the settings for the method you want to limit, such as a bank transfer or cheque module used for invoice terms.
• Locate the Customer Groups restriction field within that module's configuration.
• Untick Visitor and Guest and leave only your verified trade groups selected.

You should now see the restricted payment method listed with only your approved trade groups attached.

Method 2: Restricting Payment Methods in Your Theme

If your payment module has no group setting, you can suppress its display in the checkout template. This approach edits your theme directly, so treat it with care.

• Duplicate your active theme folder so you have a restorable copy.
• Open the checkout payment template in your active theme, typically order-payment.tpl or the equivalent file in your theme's template directory.
• Wrap the payment option's output in a condition that checks the current customer's group before rendering it.
• Save the file, clear the PrestaShop cache, and test the checkout page with both a verified trade account and a guest.

You should now see the payment method rendered only for the group you allowed in the template condition.

Conclusion

You now have a PrestaShop storefront where invoice, purchase order and bank transfer options appear only to accounts you have reviewed and moved into a verified trade group, while guests and unapproved registrations see prepaid methods alone. Catalogue and CMS gating reinforce that split, so an unverified visitor cannot even reach the pages that lead to a trade checkout.

The native restrictions in PrestaShop get you part of the way, but the verification step and the multi-group edge cases are where they fall short. If you are onboarding B2B buyers at any real volume, close that gap with the module that puts group assignment and payment visibility in one place: PrestaShop Restrict Customer Groups by Products, Categories, and set your first trade group restriction today.

Frequently Asked Questions