Open trade pricing to anyone who ticks a "business" box and you've built a discount coupon, not a trade channel. Within a week, private buyers will have found the form, claimed to be a company, and started paying wholesale for single-unit orders. A trade account application is the gate that stops that: it makes the customer prove they're a real business before PrestaShop ever shows them a lower price or a restricted category. This guide is about building and running that gate on PrestaShop specifically, what to collect, how to verify it without burning a day per applicant, and exactly where in the back office you flip the switch that grants or removes access.
This is one piece of a larger B2B setup. If you're still deciding whether to run B2B on PrestaShop at all and how the moving parts fit together, start with selling B2B on PrestaShop; this article assumes you've decided to, and focuses purely on the application-and-approval workflow.
Turn on B2B mode first. It changes what the form can ask
Before you design an application, enable PrestaShop's native B2B mode under Shop Parameters → Customer Settings, the Enable B2B mode toggle (the PS_B2B_ENABLE configuration value). So what does that actually do for you? It exposes the business-account fields PrestaShop already knows how to store, SIRET, APE and other B2B customer data, so you're collecting verifiable data into proper database columns instead of scribbling it into a free-text comment box you can never query later. The company name and the VAT number aren't conjured into existence by B2B mode: company is a normal customer/address field and the VAT number is stored on the Address object, shown according to your country/address configuration. What B2B mode does is expand the set of business-account fields and surface them cleanly when you review the account in the back office.
It also surfaces fields like outstanding allowance and maximum payment days on the customer record. Those belong to invoicing, not onboarding, if you plan to let approved trade accounts pay later, that's its own decision covered in deferred payment terms. For the application itself, ignore them.
What a trade application should actually collect
The temptation is to ask for everything. Resist it. Every field you add is a percentage of legitimate buyers who give up halfway. The job of the form is to collect exactly what lets you verify the business and decide, nothing more. A defensible baseline:
- Company name and registration / SIRET number, the spine of the whole check. Everything else verifies against this. PrestaShop's B2B mode gives you the SIRET field natively; for other countries you'll repurpose it or add a company-number field.
- VAT number, the single highest-value field, because for EU businesses it's machine-checkable in seconds against VIES (more on that below).
- Business address. Should match the registration record. A trading company operating from a residential flat isn't disqualifying, but a mismatch is a flag worth a glance.
- Industry / what they sell, your fastest filter for relevance. An electronics wholesaler doesn't need to ship to a hairdresser at trade price.
- Website or social proof, a thirty-second sanity check that there's a real operating business behind the name.
Resist adding "estimated monthly volume" and similar tiering questions to the application. Self-reported volume is unreliable and it's the wrong moment, you tier customers on real purchase history after they're approved, which is a customer-groups job covered in customer groups in PrestaShop, not an onboarding question.
Getting those fields onto the registration form
PrestaShop's B2B mode enables business-account fields such as SIRET and APE once turned on; the company field already exists as a customer/address field, and the VAT number is stored on the address and displayed according to country/address configuration rather than as a blanket form addition, so for an EU/French-style setup you may not need to build anything. The gap appears when your trade gate needs information PrestaShop doesn't model: a "what do you sell" dropdown, a trade-reference field, a checkbox confirming they'll resell rather than personally consume, or a file upload for a registration certificate.
That's where a purpose-built trade-application module earns its place. Our Trade Account module adds the business fields and the approval workflow as a back-office feature instead of a CustomerFormatter override. Out of the box, adding a field to the sign-up form means overriding the CustomerFormatter class (or implementing the additionalCustomerFormFields hook) and adding a matching column to the customer table, workable, but developer territory. A good registration-fields module lets you add exactly those fields from the back office instead, so applicants declare their business details in one pass during account creation rather than you chasing them by email afterward. The practical payoff: the application is the registration, the data lands on the account, and you review one complete record instead of stitching together a half-finished signup and a separate form submission.
The verification step. Fast where you can, human where you must
Collecting data is the easy half. The gate only works if you actually check it, and the trick is splitting the work into the part a machine does instantly and the part a person does in under a minute.
The instant check is the VAT number. For EU businesses, a valid VAT number validated against the EU VIES service (the checkVat SOAP endpoint at ec.europa.eu) tells you in seconds that this is a registered, active business and confirms the legal name. PrestaShop core does not validate VAT numbers against VIES on its own. The stock field is a text input with no live lookup. Automating that check (and using a valid VAT number to drive tax exemption at the same time) is a topic in its own right; we cover the mechanics in automating tax exemption with an EU VAT checker, and our Automatic EU VAT Checker module runs the live VIES lookup that PrestaShop core doesn't. For the trade gate, the relevant point is simply this: a VAT number that passes VIES is your strongest single signal, and it costs you nothing.
The human check is everything VIES can't tell you. Does the website match the company? Is the industry one you actually sell to at trade price? Does the address look like a business? For most applications this is a 30-to-60-second glance, not a 5-minute investigation, you're confirming, not auditing. Reserve real digging for the ones that smell wrong: a brand-new VAT registration, a free email domain instead of a company one, a "wholesaler" with no web presence.
Speed is part of the product here. A three-day verification quietly hands legitimate buyers to whichever competitor approved them the same afternoon. Treat same-business-day approval as the target, and design your form to give you everything you need to decide in one sitting so you're never waiting on a follow-up email.
The grant: where in PrestaShop you actually open the gate
This is the mechanical heart of the whole process, and it's worth being precise because the back-office path is unobvious the first time. Access in PrestaShop is governed by customer groups, and trade access means moving an approved applicant out of the default group into your trade group.
- New registrants land in the default group. By default that's Customer (group id 3), set by the PS_CUSTOMER_GROUP configuration value. They see retail prices and no restricted categories. Which is exactly right while their application is pending. They can shop immediately; they just can't see trade pricing yet.
- Create your trade group(s) under Shop Parameters → Customer Settings → Groups → Add new group (older installs may place this menu differently). This is where you attach the actual benefit, a price reduction, tax display behaviour, restricted-category visibility. The pricing mechanics live in customer groups, and whether trade buyers see net or gross prices is its own switch covered in net vs gross tax display.
- On approval, edit the customer under Customers → Customers, open the account, and under Group access tick the trade group and set it as the Default group. Saving this is the moment the gate opens: the group's price reduction, the unlocked categories, and the tax-included vs tax-excluded display all apply on their very next page load. (Group membership drives reductions, category access and net/gross display. Actual VAT exemption is a separate matter that depends on tax rules and address/country logic or a dedicated module, not on group assignment alone.) Nothing else to publish.
The one detail people miss: the Default group field, not just the Group access checkboxes, is what drives default pricing and tax display for that customer. Tick the box but leave the default as "Customer" and you'll get support tickets asking why the trade price isn't showing. Set the default group to the trade group.
Don't let approvals pile up, get notified
A gate nobody is watching becomes a backlog, and a backlog becomes lost customers. You want to know the moment a business account is created so you can verify and approve while the applicant is still warm. PrestaShop fires a actionCustomerAccountAdd hook on every registration, and B2B-relevant data (company, VAT) is on the record, so a notification on new business signups is a natural fit for either a small custom module hooking that event or a registration module that flags business applicants for you. The goal is simple: turn "I should check the admin panel sometime" into "an email told me there's an application waiting," which is the difference between same-day approval and a three-day delay you didn't notice you had.
Handling rejection without burning the bridge
Not every application clears, and how you say no matters more than merchants expect. A rejected applicant today can be a legitimate reapplication next week. The common, defensible rejection reasons:
- VAT number fails VIES, or the registered name doesn't match the application.
- A private individual claiming business status purely to reach lower prices, the most common case, and exactly the one the gate exists to catch.
- A business in an industry you don't sell to at trade terms.
- Information you simply can't verify, no traceable company, no web presence, free email and a vague description.
Reject with a specific, reopenable reason rather than silence: "We couldn't verify your business registration against the details provided, send us your VAT number or registration certificate and we'll review again." Mechanically, a rejection is the absence of an action: you leave the account in the default Customer group. They keep a working retail account, which is the right outcome. A real business that buys at retail today might qualify for trade next quarter.
Closing the gate again: revocation and review
Granting access is a one-time act; keeping the trade list honest is ongoing, and it's the step most stores skip. A trade account isn't a lifetime grant. Businesses close, change industry, or quietly stop ordering while still holding the discount. The same back-office control that opens the gate closes it: edit the customer, remove the trade group from Group access, reset the Default group to Customer, and their next visit shows retail pricing again. No data is lost; you've simply revoked the benefit.
- Periodic re-verification. Once a year, spot-check that long-standing trade accounts are still active, registered businesses. A dissolved company shouldn't keep wholesale pricing.
- Watch for misuse. A trade account placing small, one-of-each, gift-wrapped-looking orders is often a private buyer who got through the gate. PrestaShop's order history per customer (Customers → Customers → view) is enough to spot the pattern.
- Re-tier on real history, not promises. The volume question you didn't ask on the form gets answered by actual orders. Promote, or demote, between trade tiers based on what they've genuinely bought, which is again a customer-groups operation: showing different prices to different customers.
Done properly, the trade application stops being a form and becomes a control surface: you decide who sees wholesale pricing, you can see why each account got it, and you can take it back in two clicks when the reason no longer holds. That's the whole point of the gate. Not to make business customers jump through hoops, but to make sure the lower price you give away only ever lands with the buyers it was meant for.
Two adjacent decisions round out the B2B setup: whether approved trade accounts see net or gross prices, and whether they can pay on invoice rather than upfront. Both are separate switches from the trade gate itself. (Disclosure: Trade Account, Automatic EU VAT Checker, Tax Display Switcher and B2B Deferred Payment Terms are modules we build and sell.)
Frequently asked questions
What does enabling PrestaShop B2B mode actually change?
Turning on Enable B2B mode under Shop Parameters → Customer Settings (the PS_B2B_ENABLE value) exposes business-account fields like SIRET and APE so you collect verifiable data into proper database columns instead of a free-text comment box. It does not conjure the company name or VAT number into existence. Company is a normal customer/address field and the VAT number is stored on the Address object, but it surfaces the business fields cleanly when you review the account.
Where in PrestaShop do I actually grant trade pricing?
Through customer groups. New registrants land in the default Customer group (id 3, set by PS_CUSTOMER_GROUP). On approval, edit the customer under Customers → Customers, tick your trade group under Group access, and, the step people miss, set it as the Default group. The Default group, not just the checkbox, drives pricing and tax display; tick the box but leave the default as "Customer" and you'll get tickets asking why the trade price isn't showing.
How do I verify a business customer quickly?
Split the work. The instant check is the VAT number validated against the EU VIES service (the checkVat endpoint at ec.europa.eu). It confirms in seconds that this is a registered, active business and returns the legal name. PrestaShop core doesn't run that lookup, so it needs a module or external check. The human check is everything VIES can't tell you: does the website match, is the industry one you sell to at trade price, does the address look like a business, a 30-to-60-second glance, not a five-minute audit. Treat same-business-day approval as the target.
How do I revoke trade access later?
The same control that opens the gate closes it: edit the customer, remove the trade group from Group access, reset the Default group to Customer, and their next visit shows retail pricing again. No data is lost, you've simply revoked the benefit. Re-verify long-standing trade accounts about once a year, since businesses close or change industry while still holding the discount.
How should I reject an application without losing the customer?
Reject with a specific, reopenable reason rather than silence: "We couldn't verify your business registration, send your VAT number or registration certificate and we'll review again." Mechanically a rejection is the absence of an action. You leave the account in the default Customer group, so they keep a working retail account. A real business that buys at retail today might qualify for trade next quarter.
