Shopify B2B Customer Portal: What’s Native, What’s Not, and What It Takes to Close the Gap

Shopify’s B2B customer portal handles more than most people expect and less than most projects need. Merchants usually find out exactly where that line sits after launch, not before.

This article maps it.

Native B2B gives you company hierarchies, contract pricing, payment terms, order approval, and reordering. It does not give you buyer-managed teams, permission roles beyond two levels, quotes, CSV upload, or an invoice archive. It has no concept of a credit limit, and no view of what your ERP thinks is true.

Everything in the portal is therefore one of two things: configuration, or a build decision. Here’s which is which.

What a Shopify B2B customer portal actually is

Most definitions of “B2B customer portal” describe a wishlist — bulk ordering, custom pricing, self-service. 

On Shopify, the portal is a specific data model, and every constraint you’ll hit downstream traces back to it.

Three objects.

Company is the account. It’s a container. Practically speaking, it holds nothing that affects a transaction.

Company Location is the transacting entity, and this is the object that matters. Each location carries its own tax ID and tax exemptions, its own ship-to and bill-to addresses, its own assigned catalogs, its own payment terms, and its own checkout settings — including whether orders submit directly or land as drafts for review. Pricing is a property of the location, not the company. A single company can carry up to 10,000 locations, each with up to 25 catalogs.

Contact is the human buying on behalf of a location. When Shopify authenticates an email address, it checks whether that address is tied to a company location. If yes, the buyer gets the B2B experience — their catalog, their pricing, their terms. If no, they get the D2C storefront. A contact assigned to multiple locations is prompted to choose which one they’re purchasing for at login, and everything downstream changes accordingly.

The hard constraint sits at the login layer. B2B runs only on new customer accounts. Legacy customer accounts never supported it, and as of February 2026 they’re deprecated outright. That means passwordless authentication — the buyer enters an email, receives a six-digit code, and lands on Shopify-hosted account pages.No password field. No Liquid-templated account dashboard. If you need SSO against your own identity provider, that’s supported through OAuth 2.0 and OpenID Connect — but the account pages themselves stay Shopify’s. 

What you get out of the box in Shopify B2B Customer Portal

Before scoping any custom work, it’s worth being precise about where native B2B already ends. Shopify’s B2B suite is more capable than its reputation suggests, and a meaningful number of “we’ll need an app for that” conversations are unnecessary. The table below is the honest inventory.

Capability	Native?
Company → location → contact hierarchy	Yes — up to 10,000 locations per company, 25 catalogs per location
Custom catalogs and price lists	Yes — 3 across all B2B markets on Basic, Grow, Advanced; unlimited and location-assignable on Plus
Volume pricing and quantity rules	Yes — minimums, maximums, increments, quantity price breaks
Payment terms per location	Yes — Net 7 through Net 90, due on fulfillment, due on receipt
Order-as-draft for approval	Yes — set per company location
Price locking and inventory reservation on drafts	Yes
Purchase order numbers	Yes
Easy reorders from order history	Yes
Quick order list	Yes — multiple variants of one product, added from the product page
Self-serve returns	Yes — location admins submit and track return requests
Vaulted credit cards	Yes — saved at the company location level
Company account requests via Shopify Forms	Yes — but new companies only, never an existing one
D2C customer and order history migration into a company	Yes
Sales rep draft orders and send-invoice	Yes — some permission levels limited below Plus
SSO via your own identity provider	Yes — OAuth 2.0 / OpenID Connect
Deposits and partial payments	Plus only
Buyer-managed teammates	No
Roles beyond ordering-only and location admin	No
Approval thresholds by order value	No
Quote request and negotiation	No
CSV order upload	No
Self-serve invoice archive	No
Credit limit enforcement	No
Live ERP-driven pricing or stock	No

Three rows in that table deserve an asterisk, because they’re where most implementations discover the gap late.

Order-as-draft is binary. You enable review for a company location, and then every order from that location becomes a draft. There is no threshold, no “route to approval above $10,000,” no conditional logic. It’s on or it’s off, per location.

Quick order list is not bulk ordering. It lets a buyer add multiple variants of a single product to the cart from one page. A distributor pasting forty SKUs from a spreadsheet is not served by it.

Invoices exist, but only as outbound email. A merchant can send an invoice from a draft order. A buyer cannot log in and browse an archive of their open and paid invoices. If your AP department wants a statement, someone on your team is generating it manually.

Everything above the line is configuration. Everything below it is a build decision — and the next section explains why the two permission levels are where that decision usually starts.

 

Cart Approvals and Permissions Limitation in Shopify B2B Customer Portal

Shopify gives you two permission levels for B2B contacts. 

Ordering only. The contact can place orders for the company location and review the orders they personally placed. Nothing else.

Location admin. The contact can place orders, view every order placed for that location by anyone, and edit the location’s shipping and billing addresses.

That’s the complete set. There is no approver role that reviews orders above a threshold. No AP clerk who can pull invoices and payment status but cannot purchase. No read-only controller who needs visibility for budget reconciliation and nothing more. No procurement manager who can add users but not spend. 

The two roles exist, they apply per location, and paying for Plus does not unlock a third.

Every contact record in your B2B portal is created in your Shopify admin, by your team. Buyers cannot add their own colleagues. 

So consider a distributor running four hundred active accounts, each averaging four contacts. That’s sixteen hundred records whose entire lifecycle you own.

The problem is not that the work is hard. It’s that the work sits on the wrong side of the account boundary. Your customer knows who joined their team. You don’t, until they email to tell you. You have built a self-service portal whose most basic administrative function requires a human on your payroll.

Portal adoption depends on the portal being complete, and the moment a buyer has to email you to do something they could do in every other SaaS tool they use, the phone and the PDF start winning again.

Fixing this is not a platform limitation you have to accept. It’s a build — and it’s a small one.

How to let buyers manage their own teams

Native Shopify has no path for this. But the gap sits inside customer accounts, which means it’s reachable through Customer Account UI Extensions — and that’s exactly where the fix lives. Onboard B2B is one implementation, and walking through it is useful because the mechanics reveal what you’re actually installing.

Enabling buyer-side contact management

Setup runs through the theme editor, not the Shopify admin.

1. Open the Onboard B2B app, select the Installation tab, and launch the editor.
2. The theme editor opens directly on your store’s profile page. Confirm that the Manage contact page is enabled.
3. Save.

That’s the entire merchant-side configuration.

One constraint governs everything downstream: only contacts holding the Location admin permission can add or manage teammates. Ordering-only contacts never see the interface. This isn’t the app’s choice — it inherits Shopify’s two-role model, and it inherits the boundary that comes with it.

Which means the provisioning problem doesn’t disappear. It moves. You still designate the first Location admin at each account manually, in your admin. What you’ve delegated is everything after that.

What the buyer experiences

From the customer’s side the flow is unremarkable, which is the point.

An approved B2B contact with the Location admin role signs into your store and opens their account portal. A dropdown selector labeled Manage now appears. From there they enter a new team member’s details, choose that person’s permission level, and send an invitation.

The invitee receives an email with a sign-in link. They authenticate, and on landing they have access to your B2B catalog with the company’s pricing, payment terms, and checkout settings already applied. Nobody on your team touched a record.

The AP clerk who was previously a support ticket is now a two-minute task for the person who actually knows she was hired.

The app-vs-build decision

A handful of apps solve this — Onboard B2B, Roleify, B2B Company Controls, B2B User/Location Admin Portal — and for the common case, one of them will do it this week.

Understand precisely what you’re getting. These are interfaces layered over Shopify’s permission model, not replacements for it. The two roles remain two roles. A Location admin can invite an ordering-only contact or another Location admin, and that exhausts the possibilities. The app makes the boundary self-serve; it does not move the boundary.

So the question isn’t whether an app is good enough. It’s whether your customers’ buying organizations actually fit inside two roles.

Most don’t, past a certain size. A buyer with a $10,000 spend limit and a manager who approves anything above it is two roles Shopify doesn’t have. An AP user who needs invoice visibility and no purchasing rights is a third. Cost-center routing, where a contact’s orders must be tagged and reported against a budget line their controller owns, is a fourth — and it requires data that lives in your customer’s ERP, not yours.

None of that is available from the app store, because none of it is available from the platform. Approval thresholds, budget caps, and cost-center routing are custom work by definition.

The good news is that “custom” here doesn’t mean rebuilding the portal. Shopify exposes a specific, well-bounded extensibility surface for exactly this — and knowing its limits before you scope is the difference between a four-week build and a four-month one.

The extensibility model — what you can and can’t build

Every custom B2B portal decision on Shopify comes down to one question: does the work fit inside a Customer Account UI Extension, or does it not? Answer that before you write a line of code, because the two paths differ by an order of magnitude in cost.

What a UI extension actually is

Extensions render at defined targets inside Shopify’s hosted account pages — the order index, the order status page, and the profile page. You can also build full-page extensions, which add entirely new pages to the account navigation. That’s the surface.

The constraints are firm, and they’re enforced, not advisory:

It runs in a sandboxed Web Worker. No DOM access. No window. Your extension cannot see or touch the page it renders inside, and it never will — the isolation is a security property, not a gap waiting to be closed.

Compiled bundles cannot exceed 64 KB. Shopify rejects the deploy. This is the constraint that surprises teams most, because it rules out shipping a component library, a state manager, and a charting package inside an extension.

You render Polaris components. Shopify’s UI kit, Shopify’s typography, Shopify’s spacing. You choose which components and how they compose. You do not choose what they look like.

Talking to your own backend requires configuration. Set network_access = true in the extension’s capabilities and request access in the Partner Dashboard. Because extensions run with a null origin, your server must return Access-Control-Allow-Origin: *. Authenticate the call with the session token Shopify provides. For reads against Shopify’s own data — orders, profile, addresses, company context — use the Customer Account API directly and skip the round trip.

What that means in practice

You can add a quote request page. An open-invoice list with balances pulled from your ERP. A reorder-from-history block on the order index. A credit-limit widget on the profile page showing available balance against terms.

You cannot rebuild the portal’s chrome. The navigation, the layout, the login screen, the visual system — those stay Shopify’s. If a buyer opens your portal and it looks like Shopify’s portal with your logo on it, that’s the ceiling of the extension model, and for most B2B businesses it’s a perfectly acceptable one.

If it isn’t — if the buying experience has to look and behave like your product, not like a commerce platform — then you’re going headless. Storefront API for the catalog, Customer Account API for authentication and account data, Hydrogen or Next.js on top. Note that Multipass is retired; the replacement is a proper OAuth flow, which is more work to implement and solves the double-login problem that made headless B2B miserable for years.

Choosing the path

Requirement	Path
Add a self-serve feature to Shopify’s hosted account pages	Customer Account UI Extension
Buyer team management, quote requests, CSV order upload	App from the store, or a custom extension if the app’s model doesn’t fit
Fully branded portal, ERP-driven pricing and stock, custom authentication	Headless on the Customer Account API

Most merchants belong on row one or two and talk themselves into row three. The tell is whether the requirement is about capability or appearance. Capability gaps are almost always extension-shaped. Appearance gaps are the only honest reason to go headless — and they’re expensive.

The exception is row three’s middle clause, and it’s the one that actually forces the decision for manufacturers and distributors: ERP-driven pricing and stock. That’s the next section.

Where the portal meets your back office

Shopify put two fields in the B2B object model specifically for this problem, and most implementations leave them empty.

When you create a company, there’s a company ID field. When you create a company location, there’s a location ID field. Neither is Shopify’s identifier. Both exist so you can store the external ID that your ERP already uses for that account and that ship-to. Populate them at creation and every subsequent reconciliation is a lookup. 

Skip them — because the launch was rushed and nobody asked — and you’re matching on company name six months later, discovering that your ERP says “Harding Supply Co.” and Shopify says “Harding Supply,” and that two of your customers share a billing address.

This is not a detail. It’s the join key for everything below.

What actually has to move

Five flows, in rough order of how badly they hurt when they break.

Contract pricing. Negotiated pricing lives in your ERP and has to land in Shopify as a catalog assigned to a company location. Price changes must propagate before a buyer sees the old number.

Credit limits and payment terms. Terms map cleanly to the location’s payment terms field. Credit limits don’t map anywhere — Shopify has no credit limit primitive — so this becomes an extension reading live balance data from your system.

Available-to-promise inventory. Not on-hand quantity. What a distributor can actually commit to, net of allocations and inbound POs.

Invoices and open balances. The data your customer’s AP department opens the portal to see.

Order writeback. Orders flowing into the ERP with the PO number attached, so the invoice your customer receives matches the order they placed.

The failure mode

The portal shows one price. The ERP invoices another.

Your customer calls. Your CSR investigates, apologizes, issues a credit. The buyer learns that the portal is not authoritative, and reverts to emailing the rep — who they trust, because the rep quotes from the ERP.

You have now spent six figures building a system that made your phone ring more.

Batch or event-driven

Nightly batch is defensible for data that changes slowly and where a stale value is embarrassing rather than expensive: product attributes, catalog membership, address updates.

Event-driven sync is mandatory for anything a buyer transacts against. Pricing, inventory, credit availability. If a price changed at 9 a.m. and your job runs at 2 a.m., you have a nine-hour window in which every order placed is wrong.

Most implementations run both, and the discipline is knowing which field belongs in which pipeline. That decision is architecture, and it’s made before the first webhook fires — not after.

A Realistic Implementation Sequence

This is not a five-step launch plan. It’s a phasing model, and the ordering matters more than the contents — because two of these phases are cheap to do early and ruinous to do late.

Phase 0 — Decide blended or dedicated. Do B2B and D2C share one store, or does B2B get its own? This choice constrains your theme, your access restrictions, your Markets configuration, and your migration path. It is the one decision that cannot be quietly reversed later.

Phase 1 — Model the account structure. Companies, locations, catalogs, and the external ID on both company and location. Get the mapping right before a single order flows through the system. Rework here is the expensive kind — you are not renaming a field, you are reconciling transaction history.

Phase 2 — Move to new customer accounts and test both cohorts. If you run a blended store, restricting access can redirect D2C traffic to authentication on pages you didn’t expect. Test the storefront as a B2B contact and as an anonymous D2C shopper before you touch production.

Phase 3 — Ship native, and only native. Price lists, payment terms, draft-order approval, PO numbers. Nothing custom. Put it in front of ten real accounts and find out whether they use it. Adoption data from this phase determines what you build next — and frequently kills a feature someone was certain was essential.

Phase 4 — Layer self-service. Team management, quotes, CSV upload, invoice visibility. Now you’re building against demonstrated demand rather than a requirements document.

Phase 5 — Integrate. ERP, OMS, WMS. Event-driven for anything a buyer transacts against. Batch for the rest.

Phase 6 — Instrument. Portal-attributed share of order volume. CSR hours reclaimed from order entry. Reorder frequency per location. Days from invitation to a contact’s first order.

Most failed B2B portal projects invert phases three and four — they build the custom experience first, launch it complete, and discover their customers wanted reordering and a PDF invoice. The sequence above costs less and tells you more.

How to know it’s working

Most B2B portal case studies report conversion rate. Conversion rate is a D2C metric, and in B2B it measures almost nothing — your buyers were going to place the order regardless. The only question is which channel absorbed it.

Five numbers survive a conversation with a CFO.

Share of order volume through the portal. Not sessions, not logins. Revenue. If sixty percent of orders still arrive by email and phone, the portal is a brochure with a login screen.

CSR hours reclaimed from order entry. Baseline it before launch. This is the line item that funds everything else, and it’s the only one your operations lead already tracks in some form.

Order-error rate, before and after. Rekeyed orders carry errors. Errors carry credits, reships, and calls. Measure the credit memos.

Days from invitation to a contact’s first order. The cleanest diagnostic in the set. If a newly invited buyer takes eleven days to place an order, something in onboarding is broken — and you’ll find it in the login flow, the catalog assignment, or the fact that nobody told them the portal exists.

Reorder frequency per location. The compounding metric. A portal that works pulls the routine reorder out of the sales rep’s inbox and makes it weekly instead of monthly.

Track these for a quarter before you decide the portal succeeded.

Also read: How to Integrate B2B eCommerce with ERP Systems

Frequently Asked Questions

Does a Shopify B2B customer portal require Shopify Plus?

No. B2B works on Basic, Grow, Advanced, and Plus. But direct company catalogs — assigning pricing to a specific company or location — are Plus-only. Lower plans cap at three market-level catalogs. If every account has its own negotiated pricing, you need Plus.

Can B2B customers add their own users in Shopify?

Not natively. Contacts are created by the merchant in the Shopify admin. Buyers cannot invite colleagues on their own. Customer Account UI Extensions close this gap — apps like Onboard B2B let a Location admin add teammates and assign permissions directly from their account portal.

What’s the difference between Ordering only and Location admin?

Ordering only lets a contact place orders and view the orders they personally placed. Location admin adds visibility into every order placed for that location, plus the ability to edit the location’s shipping and billing addresses. These are the only two permission levels Shopify offers, on every plan.

Can I customize the Shopify B2B customer account pages?

Partially. Account pages are Shopify-hosted, so you cannot rebuild them in Liquid. Customer Account UI Extensions let you add blocks and full pages to the profile, order index, and order status screens. For full control over the buying experience, you go headless via the Customer Account API.

How does a Shopify B2B portal connect to an ERP?

Through the external ID fields on companies and company locations, which store your ERP’s own account and ship-to identifiers. Populate them at creation. Contract pricing, payment terms, and inventory sync in; orders write back with the PO number attached. Use event-driven sync for anything buyers transact against.

Where that leaves you

Map your requirements against the table in this article before you talk to anyone — including us.

If native B2B covers what you need, build it in-house. Shopify’s documentation is genuinely good, most of the configuration is admin-side, and an agency adds cost without adding capability. Plenty of merchants launch a working portal in six weeks with no external help.

The gap tends to appear in three places. Permission roles your buying organizations actually require. ERP integration, where the portal has to be as authoritative as your system of record. Or a buying experience that has to carry your brand rather than Shopify’s.

That’s the engineering we do. If that’s where you are, get in touch.

Visit Us For: B2B Portal Development