Skip to content

For Shopify agencies

Native Shopify B2B, a quote app, a custom build or CPQ: a decision guide

By Jahangir Alam · September 20, 2026 · 15 min read

Last verified
Shopify API
2026-07
Audience
Shopify agencies and solution architects recommending a B2B quoting stack
Scope
The four ways to run B2B quoting on Shopify, scored by requirement, with the conditions where each fits

There is no winner among the four ways to run B2B quoting on Shopify, only fit.

Native Shopify B2B fits when prices are standing and the buyer orders against them. A quote app fits when the price is decided per deal on standard products and the deal has to become a Shopify order with its history. A custom build fits when the workflow itself is the product and the merchant has engineers who will keep pace with Shopify's quarterly API releases for as long as the store exists. CPQ fits when the product is configured from rules and the sales team already lives in a CRM opportunity. Most B2B stores end up with native B2B for standing prices plus one of the other three for the exceptions; the mistake is picking two that both want to own pricing.

This guide is for the agency or architect who has to recommend one. It defines the four options, scores them against eighteen requirements, and gives a five-question decision tree. The architecture post explains why the ownership rule matters; when you shouldn't use a quote app is the longer version of the native leaf; the evaluation checklist is what to run against any app or build you shortlist, and the launch test plan is what to run before whichever one you choose goes live.

The four options, defined

Native Shopify B2B. Companies, company locations and contacts; catalogs with price lists, quantity rules and volume pricing; net terms, vaulted cards and PO numbers at checkout; "submit for approval" to turn a checkout into a draft order; custom prices, locked prices and reserved stock on that draft; deposits and partial payments on Plus. On every plan since 2 April 2026. It has no object for a price request, a proposal, a counter-offer, an approval or a negotiation history. What you run: Shopify.

A quote app. A public app that adds the request, proposal versions, counter-offers, approvals and audit trail on top of the native objects, reads the buyer's catalog price as the starting point and creates the draft order when the price is agreed. Installed and removed by the merchant; the vendor carries API upgrades, compliance webhooks and storefront extensions. What you run: a subscription and the vendor's roadmap.

A custom build. The same quote layer written for one merchant, as a custom app on the Admin API with its own database, theme app extension, customer account extension and webhooks. Every behaviour can be exactly what the merchant wants. What you run: an application, for as long as the store trades - the obligations are listed below, and they do not shrink after launch.

CPQ. Configure-price-quote software, defined by one vendor as "software that helps sales teams configure products, apply pricing rules, manage discounts and approvals, and generate accurate quotes" - product configuration from rules, pricing governance, guided selling, approvals, documents and contracts, usually created from a CRM opportunity. Shopify is not its home: the storefront, the customer account and the draft order are an integration a CPQ project has to build or buy. What you run: a per-seat platform and its integration.

The fit matrix

Fit is scored for the requirement as a B2B store on Shopify meets it, not in the abstract. "Partial" means the option can do it with a workaround or a second tool.

Requirement Native B2B Quote app Custom build CPQ
Company price lists, per location Yes - catalogs Reads them; never owns them Reads them; never owns them Partial - its own price book, synced to catalogs
Volume tiers Yes - up to 10 breaks per product Reads them Reads them Yes - own rules
Buyer orders and pays on terms Yes Yes - via the converted draft order Yes - via the draft order you create Partial - order capture is the integration
One review round before the order Yes - submit for approval Yes Yes Partial
Price request from a guest No - prices need a company contact Yes Yes No - quotes start from a CRM record
Deal-specific price, negotiated No object Yes Yes Yes
Buyer counter-offer No Yes Yes Partial - usually rep-driven
Approval on a discount, enforced No - staff permissions scope accounts, not prices Yes Yes, if you build the enforcement Yes
Custom or service lines with their own tax and shipping flags Yes - on a draft order, by hand Yes Yes Yes
Product configured from options and rules No No - holds a custom line, does not compute it Possible Yes - this is what CPQ is for
Complex engineered product, BOM-driven No No Possible, at real cost Yes
Freight priced per deal Draft order, by hand Yes Yes Yes
Multi-currency presentment Yes - Markets Yes, if the app quotes in the presentment currency Yes, if built Partial - CPQ currency vs Shopify currency
Deposit on the order On Plus On Plus, via the draft order On Plus On Plus, once it reaches Shopify
Quote inside the customer account Draft orders only Customer account UI extension Customer account UI extension No - CPQ portals are their own
ERP owns prices Sync into catalogs Reads catalogs Reads catalogs Own sync to CPQ and to catalogs
Quote created from a CRM opportunity No Partial - events via Flow Possible Yes - native
Time to first quote Hours Days Months Months
Ongoing engineering None Vendor's Yours Vendor's, plus your integration
Data ownership and exit Shopify Shopify + export Yours Vendor + Shopify

Read the columns, not the rows. Native has the most "yes" cells for a store that never negotiates and the most "no" cells the moment it does. A quote app and a custom build share a column shape; the difference is who runs it. CPQ's column is strongest exactly where the others are weakest - configuration and CRM - and weakest where they are strongest - the Shopify storefront and order.

Decision tree: native, quote app, custom build or CPQ Five questions in sequence. One: is the price known before the buyer asks? Yes leads to native Shopify B2B. No leads to question two: is the price computed from product options and rules? Yes leads to question three: do reps quote from a CRM opportunity? Yes leads to CPQ; no leads to a configurator plus a quote app or a custom build. From question two, no leads to question four: is there a workflow no app models, plus engineers to run an app for years? Yes leads to a custom build; no leads to a quote app. A note under the tree: most stores combine native for standing prices with one other option for exceptions. 1. Is the price known before the buyer asks? for every buyer, every order yes Native Shopify B2B catalogs, terms, draft review no 2. Is the price computed from options and rules? configuration decides the number, not a conversation yes 3. Do reps quote from a CRM opportunity? contracts, renewals, guided selling yes CPQ Shopify as order capture no Configurator + quote layer options tool, then app or custom no 4. A workflow no app models, and engineers to run it? API versions, webhooks, compliance - for years yes Custom build your app, your obligations no Quote app reads catalogs, creates the draft Most stores keep native B2B for standing prices and add exactly one of the other three for the exceptions. Two options that both want to own pricing is the failure mode; the catalog stays the price list in every branch.
Five questions, four leaves. The tree is the short form of the sections below.

Native Shopify B2B: when it is enough

Native is the answer when question 1 is yes for every buyer and every order: the price is on the location's catalog before anyone asks, tiers are quantity breaks that apply to everyone on that catalog, and the only review the merchant wants is a look at the draft order before it becomes an order. Since 2 April 2026 that is available on Basic, Grow and Advanced; Plus adds unlimited catalogs, direct catalog assignment to a company or location, deposits and partial payments. The eight situations native covers, each mapped to the feature that covers it, are in when you shouldn't use a Shopify quote app.

Native stops being enough at the first reply. A draft order can carry a custom price, but it has no state for "the buyer asked for less", no version, no approval and no record of the exchange. Merchants who try to run negotiation on draft orders end up with the conversation in email and the draft order out of date - which is the point at which one of the other three options is being chosen, whether or not anyone has said so.

A quote app: when it fits

A quote app fits when the price is decided per deal on products Shopify already knows: the buyer asks, the seller proposes from the catalog price, one or both sides move, someone approves the discount, and the accepted version becomes a draft order at the agreed prices. It also fits the buyer native cannot serve - the guest who wants a number before they have a company account.

The conditions that make it the right choice rather than a custom build are practical. The workflow the merchant needs is the workflow the app models; the merchant has no engineering team, or has one with better things to do than track Shopify's quarterly API releases; time to first quote matters; and the app passes the evaluation checklist - above all the native-fit questions, because an app that keeps its own price list has recreated the problem it was bought to solve. What it costs is the subscription and a dependency on the vendor's roadmap: a behaviour the app does not model is a feature request, not a ticket.

QuotWay is one such app and is the example this site can speak for: its company-aware quoting starts a proposal from the buyer's company-location catalog price, versions every proposal and counter, enforces approvals on the server, and converts the accepted lines to a native draft order with the location's payment terms; the Lite plan runs that whole loop free at ten quotes a month, which is a cheaper way to find out whether a store has quoting volume than any of the other three columns. Run the checklist against it the way you would against anyone else.

A custom build: when it is justified, and what it must keep running

A custom build is justified when both halves of question 4 are true: there is a workflow no app models - a procurement rule, an industry document, a pricing negotiation that follows a contract's own logic - and the merchant will fund engineers to run an application for as long as the store trades. The first half is more common than the second, and agencies are usually asked to price only the first.

What a custom quote layer on Shopify has to keep running, from Shopify's own obligations pages:

  • An Admin API version, upgraded on Shopify's quarterly cadence. Each version is supported for at least 12 months; a request to an unsupported version "falls forward" silently to the oldest supported one, which is how a build that nobody touched breaks in month thirteen. New apps are GraphQL only; the REST Admin API has been legacy since 1 October 2024.
  • The three compliance webhooks - customers/data_request, customers/redact, shop/redact - and the protected-customer-data safeguards for any name, email, address or phone the build stores. A custom app is not reviewed for that access the way a public app is, but the requirements are the same.
  • Webhook handling that survives Shopify's delivery model: verified signatures, duplicates ignored by X-Shopify-Webhook-Id, retries (8 over 4 hours, then the subscription is deleted), and a reconciliation job because delivery "isn't always guaranteed".
  • Rate-limit-aware API use: 100 points a second on Standard, 200 on Advanced, 1,000 on Plus, with a 1,000-point cap per query.
  • A theme app extension for the storefront and a customer account UI extension for the buyer's account, each with its own size limits and its own upgrade path; a headless storefront needs a third path.
  • An idempotent conversion to the draft order, with the negotiated price on each line as a priceOverride, the company as the purchasingEntity, and drift checks against draftOrderCalculate.
  • If checkout behaviour is part of the workflow - a PO-number rule, a validation - Shopify Functions; and "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs".

Two shortcuts look like custom builds and are not. Modelling the quote as metaobjects gives you a custom record type in the admin and on the Storefront API, but a record, not a workflow: no states, no versions, no approvals, no enforcement. And a Flow-and-draft-orders build - Flow automations moving a draft order through tags - is one review round with extra steps, and stops at the same reply native stops at.

A custom build stops being justified when the workflow it was built for turns out to be the one every quote app models. That happens more often than the reverse, and it is worth asking before the build, not after; the architecture post is the specification either route should meet, and the evaluation checklist is the test of whether an existing app already meets it.

CPQ: when it is justified, and when it is overkill

CPQ is justified when question 2 is yes and question 3 is yes: the price comes out of product configuration rules rather than a conversation, and the people quoting work from CRM opportunities with contracts, renewals and guided selling around them. In that world Shopify is the order-capture and fulfilment surface, the CPQ is the quoting surface, and the integration between them - configured product to Shopify line, CPQ quote to draft order, Shopify order back to the opportunity - is a project of its own that the CPQ does not ship.

Full CPQ is overkill for the store whose products are standard, whose prices are negotiated rather than computed, and whose reps live in Shopify rather than a CRM. That is most Shopify B2B stores. The tell is the configuration rules: if a proposal's lines are variants at negotiated prices plus the occasional custom line, there is nothing for a configurator to configure, and the store is paying per seat for the two components it needs - approvals and documents - packaged with several it does not. The Shopify CPQ post separates the two jobs; QuotWay versus enterprise CPQ is the side-by-side for a store deciding between them.

The middle case - configured products, no CRM - is the dashed leaf on the tree: a product-options tool computes the configured price, and a quote layer (app or custom) negotiates and converts it. It is two tools because it is two jobs.

Combining them

Every combination that works has one owner of the standing price, and it is Shopify's catalog.

  • Native plus a quote app: the default for a store with standing prices and negotiated exceptions. Catalogs price the storefront and the reorders; the app quotes from the catalog price and hands back a draft order.
  • Native plus a custom build: the same shape, for the store whose exceptions follow rules no app has.
  • Native plus CPQ: CPQ owns configuration and the CRM-side quote; the ERP or CPQ syncs standing prices into catalogs; Shopify captures the order. The quote itself does not live in the customer account unless someone builds that.
  • The combination that fails: any two options that both keep a price list. A quote app with its own prices next to catalogs, or a CPQ price book and catalogs both edited by hand, produces two numbers for one buyer within weeks.

FAQ

Can Shopify B2B handle negotiated pricing without an app?

For one round, yes: set the location to submit orders as drafts, adjust the prices on the draft order, lock them, and send the invoice. There is no object for the buyer's reply, a second version, or an approval, so a negotiation with more than one exchange needs a quote layer of some kind - app or custom.

Can we implement request-a-quote without Shopify Plus?

Yes. Companies, catalogs, quantity rules, payment terms and draft orders are on every plan since April 2026, and a quote app or a custom app on the Admin API works on all of them. The Plus dependencies are Shopify's: deposits and partial payments, unlimited and directly assigned catalogs, and - for a custom build - Shopify Functions, which need a Plus store when they ship in a custom app.

Does Shopify have a CPQ?

No. It has catalogs, quantity rules, draft orders and the B2B checkout; configuration rules, guided selling and CRM-native quoting come from CPQ platforms that integrate with Shopify, and negotiation on standard products comes from quote apps. Which one a store needs is question 2 on the tree.

How do we estimate the cost of a custom build?

Price the obligations, not the launch: the API upgrade every quarter, the compliance webhooks and data safeguards, the webhook and rate-limit handling, the two extensions and their upgrades, and the conversion logic - each for the life of the store. A build estimate that ends at go-live is an estimate of the cheaper half.

Which option keeps the data in Shopify?

Native keeps everything there. A quote app or a custom build keeps the negotiation - request, versions, approvals, audit trail - in its own store and everything else in Shopify, which is the correct split; the order is always Shopify's. CPQ keeps the quote in the CPQ and the order in Shopify, with the link between them as good as the integration.

Can a quote app and a CPQ coexist?

Only with a clear border: one of them owns the proposal for a given product line. Two systems that can both propose a price to the same buyer is the two-price-lists failure in a different form.

Sources

Shopify pages, all read on 20 September 2026:

Related articles

See how QuotWay handles this on your store.

We’d like to set analytics cookies to understand how the site is used. They’re not required — declining changes nothing about how the site works, and you can change your mind any time on our privacy page.