Shopify B2B 2026: How to Verify a Wholesale Catalog Before Launch?

Shopify B2B 2026 launch checks should start with the current plan and the B2B features actually available in the store, then verify company locations, catalog assignment, buyer login, and the order path. Some native B2B capabilities are available beyond Plus, but catalog assignment and market customization can still vary by plan; confirm each item in the current official documentation and the store admin before launch.

This guide is for merchants setting up wholesale on Shopify and operators checking buyer-specific products, prices, and payment terms.
It also helps project leads decide whether the current plan meets requirements and what evidence to save before launch.

Last updated September 25, 2026. We checked Shopify’s current B2B feature, catalog, login, checkout, and payment-term documentation, and recommend confirming the relevant settings in the live store before relying on them. Shopify’s B2B feature overview

Start by separating a feature Shopify offers from a feature enabled for this store and plan. Shopify announced that B2B functionality would be available beyond Plus, but the announcement is not proof that every plan includes every catalog or market assignment option. The current B2B feature overview and Plus plan documentation are the references for plan-specific limits. Check them alongside the actual admin rather than relying on a past announcement or a setup guide written for another store.

Use this comparison to decide what to verify next. It is not a substitute for checking the current plan row and controls in the store.

Pass condition: every required B2B function is both documented for the plan and visible in the store’s own admin. If those sources disagree, do not infer access from a menu label or announcement. Resolve the discrepancy with current Shopify support documentation or the store’s plan details before configuring buyer-facing rules.

This check matters because a plan mismatch can appear late: the catalog may exist, while a desired way to assign it or customize the B2B experience is unavailable. That can mean reworking the catalog, changing the plan, or postponing launch. Record the exact capability needed in business terms—such as “assign this assortment to these wholesale buyers”—instead of recording only a feature name.

In Shopify B2B, a company represents the business customer, while a company location represents a particular business location with its own purchasing context. Contacts are the people associated with the business who access the store and place orders. Confirm how these records relate in the company and customer setup documentation.

The company location deserves its own acceptance check. A wholesale customer can be associated with a company but still have the wrong location, contact, address, or payment arrangement for the order being tested. A correct company name on a record is not enough to prove that the buyer sees the intended terms.

Use this checklist with a test account that is authorized for the relevant company:

• [ ] The company record identifies the intended wholesale customer.
• [ ] The test contact is associated with that company and can access the B2B storefront.
• [ ] The selected company location is the one covered by the commercial agreement.
• [ ] The billing address and shipping address match the intended purchasing setup.
• [ ] The payment terms shown for that location match the agreed terms.
• [ ] The test evidence connects the buyer contact, company, and location without exposing unnecessary personal or financial information.

Keep the distinction between identity and entitlement clear. A contact’s successful login proves that the account can access the storefront; it does not, by itself, prove that the contact is assigned to the correct company location or entitled to a particular catalog. Save a redacted screenshot of the company-location relationship in the admin, then compare it with the buyer-side result.

If the customer has multiple locations, test each location that uses different products, pricing, shipping arrangements, or payment terms. Do not use one location’s successful order as evidence for another location’s setup.

The main catalog question is not simply whether the wholesale catalog exists. It is whether the intended buyers receive the intended assortment and final prices. Shopify’s catalog documentation describes catalog configuration and assignment. Check the current documentation for the store’s plan and assignment method before treating a setting as supported.

For each catalog, record:

• [ ] Which B2B market, company, or company location it is intended to cover.
• [ ] Which products and variants should be available to that audience.
• [ ] Which products or variants must remain unavailable.
• [ ] The wholesale price or price adjustment expected for each representative product.
• [ ] Any quantity rules or discounts that apply to the buyer.
• [ ] The expected result when more than one catalog may apply.

Do not sign off based only on the catalog name or its assignment label. Open the storefront as the authorized test buyer and compare the actual product selection and displayed price with the business rule. If multiple catalogs or rules apply, the final buyer-side result is the useful acceptance evidence—not an assumption based on the order in which settings appear in the admin.

Keep consumer-facing and wholesale testing separate. A product page viewed while logged out may show the D2C experience, not the B2B price or availability. Conversely, a logged-in test account may belong to the wrong company location and display a valid but irrelevant wholesale result.

Important: Save evidence of the assigned buyer, selected company location, product, and displayed price together. A price screenshot without the account context cannot establish which catalog produced it.

If the intended catalog behavior depends on a feature that is absent from the current plan or admin, stop before building a workaround around unverified assumptions. Confirm whether a plan change or a different assignment design is required, then repeat the buyer-side check after the setting changes.

A catalog can be configured correctly and still fail the buyer’s actual test because the login path, account association, or location selection is wrong. Shopify’s B2B customer login documentation explains the supported login and account behavior. Use an authorized test contact rather than a staff member’s personal account or credentials shared with a customer.

For the buyer-side review, capture the steps and results:

• [ ] Open the storefront in a clean browser session and record whether the intended login route is available.
• [ ] Sign in using an authorized B2B test contact.
• [ ] Confirm that the expected company and company location are associated with the session.
• [ ] Check that intended products are visible and excluded products are not presented as purchasable.
• [ ] Compare the displayed price with the approved catalog rule.
• [ ] Repeat the comparison while logged out or using a separate D2C test session, so the two experiences are not confused.
• [ ] Save redacted screenshots that show enough context to identify the test state without disclosing credentials or customer data.

How should we check prices and products after wholesale login?

Check the buyer session, company location, product visibility, and displayed price as one test record. Then compare that record with the relevant admin configuration. If the results differ, first verify that the test contact is linked to the expected company location and that the session has not retained another account’s state. Only then investigate the catalog assignment or price rule.

A screenshot is useful but limited. It records what appeared in a particular browser session; it does not prove that all customer accounts, locations, markets, or devices will receive the same result. Pair screenshots with admin records and a short note describing the account type and selected location. Redact email addresses, order details, and other customer information before sharing evidence internally.

Do not stop the acceptance test at the product page. Continue through checkout with the authorized test buyer and compare the buyer’s selections with the resulting admin record. Shopify’s B2B checkout and orders documentation describes the checkout and order workflow, while its payment terms documentation explains payment-term behavior. Use those references to interpret the status and terms shown in the live store.

• [ ] Add a representative wholesale product to the cart and confirm that the cart retains the expected product and price.
• [ ] Proceed through checkout using the intended company location.
• [ ] Check that the billing and shipping information reflect the intended business arrangement.
• [ ] Confirm that the available payment method and any payment terms match the agreement.
• [ ] Submit the test order only through an approved test procedure.
• [ ] Find the resulting record in the admin and compare its customer, company, location, products, price, and payment terms with the buyer-side evidence.
• [ ] Record whether the result is a draft order, a submitted order, or an order with payment completed; do not describe these states as interchangeable.

A draft, an order submission, and a completed payment are different operational outcomes. Use Shopify’s current order documentation to interpret the record instead of assuming that reaching checkout or saving a draft means a buyer has placed and paid for an order. If the test’s purpose is to verify payment collection, define that success condition before testing and use a permitted method that does not accidentally charge a real buyer.

For the acceptance record, note the point where any mismatch occurs: cart, checkout details, payment terms, order submission, or admin record. This makes it easier to distinguish a catalog issue from a company-location issue or a payment setup issue, and prevents a broad “B2B checkout failed” report from hiding the actual cause.

Use the following pass, hold, and recheck rules rather than treating setup completion as approval:

• Pass when the required feature is documented for the active plan, the store admin supports the intended configuration, and the authorized buyer sees the expected products and terms through the order flow.
• Hold when plan documentation and admin controls conflict, the buyer is linked to the wrong location, or a required payment or catalog rule cannot be confirmed.
• Recheck after changing a plan, company relationship, catalog assignment, price rule, or payment setting. Evidence from before the change does not establish the new result.

Store a compact acceptance record containing the plan checked, relevant official documentation, company and location tested, catalog assignment, buyer-side screenshots, and order outcome. Keep the record redacted and limit access to staff who need it. This creates a traceable basis for launch approval without collecting more customer data than the review requires.

Also record the environment used for the buyer-side review. A test on one operating system and browser can reveal presentation issues in that environment, but it cannot establish identical behavior on every buyer’s device. That distinction is particularly important when a wholesale team relies on macOS Safari for storefront review.

A remote Mac can help reproduce the macOS browser view when the team does not have a suitable Mac available. It can be useful for checking layout, navigation, and the visible buyer experience in a macOS browser. It cannot grant B2B eligibility, create Shopify permissions, bypass a plan limit, prove the correct company-location relationship, or guarantee that a catalog price or order will appear the same for every buyer.

Our decision rule is straightforward: if the unresolved issue is the store’s plan, account setup, catalog rule, or order status, resolve it in Shopify first. If those checks pass and the remaining question is how the storefront appears in a macOS browser, a remote Mac may be an appropriate additional test environment. Review the JEXCLOUD remote Mac options to determine whether that kind of browser review fits the team’s workflow.

A common alternative is to rely on a staff member’s local computer and forwarded screenshots. That can leave the team with an inconsistent browser environment, limited ability to repeat the same test, and screenshots that omit the account or location context. A remote Mac can make the macOS browser review more repeatable, but it still does not replace an authorized buyer account or the store-admin evidence.

Before launch, complete the checklist with a real authorized test buyer and keep the result tied to the correct company location. If the remaining acceptance gap is macOS browser presentation for overseas buyers, compare that requirement with the available JEXCLOUD US East remote Mac option; if the gap is in Shopify configuration or buyer authorization, fix that in the store rather than expecting a different test machine to resolve it.

• Use a controlled checklist to verify storefront pricing, delivery details, and buyer-side browser behavior.