Guide
Shopify wholesale applications: form, verification and approval workflow done right
A wholesale application workflow is the path a business buyer travels from "request B2B access" to placing a first order at wholesale terms: an application form, an identity and register verification, an approval decision, and the provisioning that actually unlocks buying. Most Shopify stores get one or two of those stages right and improvise the rest — a form that asks too much, checks done by hand in a browser tab, approvals that create a customer tag and hope for the best. This guide walks the full funnel and what "done right" looks like at each stage.
Stage 1: the application form
The form has one job: collect exactly what verification and provisioning will need, and nothing else. Every extra field costs conversions; every missing field costs a follow-up email.
Fields that matter
- Company name — as registered, because you will compare it against register data.
- Business address and country — the country routes the verification (EU → VIES, Switzerland → Zefix, UK → Companies House), and the address becomes the B2B company location on approval.
- VAT ID or company register number — the verifiable identifier. Which one applies depends on the country.
- Contact person and email — this person becomes the company contact who logs in and orders.
- Phone, website, expected order volume, free-text message — optional but cheap, and genuinely useful for manual review judgement calls.
Fields to skip
Resale certificates as upload requirements (a European register check is stronger and frictionless), bank details (never on an application form), multi-page questionnaires, and anything you can look up yourself from the register number. A wholesale application form is a qualification gate, not onboarding paperwork. This is why Anmelda ships a prebuilt B2B field library — company details, contact, business address, VAT number, register number, phone, website, expected volume, message — rather than a generic form builder: the field set is the product of what the downstream stages actually consume.
One more constraint shapes the form: it collects business data about real people, so it falls under the GDPR. Collect only what you will use, host it in the EU if your buyers are European, and delete rejected applications once a defined retention window passes — an applicant who never became a customer is not a marketing asset to keep forever. (Anmelda hosts applicant data in Frankfurt, eu-central-1, and erasure means true deletion, not anonymisation.)
Stage 2: verification before a human looks
The moment an application arrives, the verifiable claims in it should be checked against official registers — automatically, in the background, before anyone opens the application. An EU VAT ID goes to VIES; a Swiss UID goes to Zefix (status, registered seat, legal form); a UK company number goes to Companies House (status, incorporation date, officers). We cover the mechanics — including simple vs. qualified confirmation and why the VIES consultation ID must be stored — in the VAT ID verification guide.
Two properties make automated checks trustworthy. First, retries: registries go down routinely, and a temporary outage must never surface as a failed applicant. Second, honest states: a check can pass, fail, error, or simply not apply (a Norwegian applicant matches none of the three registers). The review UI should show which, per source — a traffic light, not a single boolean.
Stage 3: the decision — manual review vs. auto-approval
Manual review is the default and should stay available forever: a reviewer sees the application next to the register results — does the registered name match the form? is the company active? — and approves or rejects with one click.
Auto-approval is an optimisation for the unambiguous cases, and it is only safe with strict preconditions. A sane rule auto-approves an application only when all of the following hold:
- at least one register check applied and every applicable check passed — fully green, no ambers;
- an applicant that no register covers is never auto-approved — no evidence means a human decides;
- if a country allowlist is configured, the applicant's country is on it;
- the application is still untouched — a rule must never overrule a reviewer who already started.
This is precisely how Anmelda's auto-approval rules (a Pro-plan feature) are built: green-only, allowlist-aware, and never for applicants outside register coverage. The failure mode to avoid is the inverse workflow — auto-approve by default, verify later — which converts your wholesale channel into an honour system.
Stage 4: what approval must actually do
Approval is where most home-grown workflows quietly fall apart, because "approved" has to become real Shopify state. On a native B2B setup, one approval should produce all of this:
| Step | What is created | Why it matters |
|---|---|---|
| Company | A native Shopify B2B company | The buyer is an organisation with orders, terms and metadata — not a tagged retail customer |
| Location | A company location from the application's business address | Shipping, tax and catalog context attach to the location |
| Contact | The applicant linked as the company's main contact | This is who can log in and order at B2B terms |
| Catalog | Wholesale catalog assignment (plan-dependent, see below) | The buyer sees wholesale prices, everyone else does not |
| Unlock | Checkout lock and price hiding lift for the approved buyer | The gate that kept prices hidden opens automatically |
| A decision email to the applicant | The buyer learns they can now order — nobody checks a portal daily |
One plan nuance worth knowing: Shopify creates companies, locations and contacts on every plan, but assigning a catalog directly to a company location is a Shopify Plus feature. On non-Plus plans the equivalent is a B2B market catalog with a price list — capped by Shopify at three active catalogs. A well-built app detects what the store's plan supports and picks the right strategy automatically; the comparison guide covers this in depth in native B2B vs. tag workarounds.
Provisioning must also be resume-safe. It is a multi-step sequence of API calls, and any step can fail transiently. If step four fails, rerunning must continue from step four — not create a second company. Idempotent, resumable provisioning is the difference between an approval button you trust and one you click while watching the admin with your other eye.
Stage 5: decision emails
Both outcomes deserve an email. The approval email should say what changed ("your wholesale access is active"), where to log in, and what the buyer will see. The rejection email should be polite, brief and honest — and when the reason is fixable (a VAT ID typo, a missing register number), say so and invite a corrected application. A silent rejection costs you a buyer who might have been one digit away from legitimate.
Common mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Form asks for everything imaginable | Legitimate buyers abandon the application | Collect only what verification and provisioning consume |
| Manual register lookups in a browser tab | Slow approvals; no stored proof of the check | Automated checks on submission, results stored on the application |
| Registry downtime shown as "failed" | Legitimate applicants rejected for a maintenance window | Distinguish "source said no" from "source didn't answer"; retry the latter |
| Auto-approving unverifiable applicants | The gate stops gating exactly where evidence is weakest | Auto-approve only fully green, register-covered applications |
| Approval = adding a customer tag | No company, no locations, no B2B checkout, no payment terms | Provision a native B2B company, location, contact and catalog |
| Discarding the VIES consultation ID | No audit-proof record that you verified in good faith | Store the consultation ID with the application |
| No decision email | Approved buyers never notice; rejected ones apply again | Email both outcomes, with next steps |
The workflow, end to end
Form → automatic register checks → traffic-light review (or a strict auto-approval rule) → native B2B provisioning → decision email. Each stage feeds the next, which is why bolting them together from separate tools tends to leak: the form does not know what verification needs, verification does not write to the approval queue, approval does not provision. Anmelda was built as this funnel in one piece — application form (theme block or app proxy), VIES/Zefix/Companies House checks with stored proof, an approval inbox with auto-approval rules on Pro, resume-safe native B2B provisioning, and decision emails — so a wholesale applicant becomes an ordering B2B customer without a single manual copy-paste in between.
Verify your next wholesale application automatically
Anmelda checks every B2B application against VIES, Zefix and Companies House, then creates the native Shopify company for you.
Add to Shopify