Drupal Commerce: When It Beats Shopify

Drupal Commerce is the wrong answer for most online shops. That is not a criticism of the project, which is well engineered and has been for fifteen years. It is a statement about what most shops are: a few hundred SKUs, one currency, consumer customers, a card payment at the end. For that shape of business a hosted platform wins on every axis that matters and the argument is over before it starts.

There is a minority for which the calculation inverts completely, and it is a lucrative minority. Configurable products that cannot be expressed as a variant grid. Trade accounts with negotiated price lists. A catalogue that is also the editorial content. An ERP that owns stock and pricing and treats the website as a display surface. In those businesses the hosted platform is not cheaper, it is a permanent tax paid in apps, workarounds and things you are not allowed to change.

This piece sets out where that line actually falls, with the numbers on both sides. If you read the Shopify section and recognise your own business, stop there. You will save a great deal of money and this article will have done its job.

When does Drupal Commerce beat Shopify? When your products cannot be modelled as a simple variant grid, when different customers see different prices for the same SKU, when the catalogue and the editorial content are the same thing, or when an ERP is the source of truth and the shop is a view onto it. For a straightforward consumer catalogue in one or two currencies, Shopify is cheaper over three years and better at converting. The dividing line is product and pricing complexity, not traffic or turnover.

What Drupal Commerce Actually Is

Drupal Commerce is not a shop product. It is a set of entity types layered onto Drupal’s entity and field system, and everything that follows from this article follows from that sentence.

A product in Drupal Commerce is an entity with a bundle, exactly like a node. So is a product variation, an order, an order item, a payment, a promotion and a store. Every one of them accepts arbitrary fields, so a variation can carry a batch number, a certificate reference, a lead time in working days and a dimension used to compute its price. None of that is a custom field bolted to the side of a fixed schema. It is the schema.

The purchasable thing is the variation, not the product. A product is the presentational wrapper and the variation is the item with a SKU and a price, with attributes generating the selectable combinations. A product type decides which fields a product has, and a variation type decides which attributes its variations carry. Nothing in that arrangement assumes clothing, or physical goods, or a fixed number of choices.

The consequence is that Drupal Commerce imposes almost no opinion about what you sell. The cost of that freedom is that it also supplies almost no decisions, and somebody has to make all of them.

Where Drupal Commerce Sits Right Now

The current recommended release is Drupal Commerce 3.3.8, published on 17 July 2026, and it works with Drupal 10.3 or later and Drupal 11. Stable releases are covered by the Drupal security advisory policy, which matters more than it sounds: it means a disclosed vulnerability gets a coordinated release rather than a GitHub issue.

The Drupal Commerce project page reports 35,870 sites using the module. Commerce 3.0.0 was the first stable release of the 3.x line, in January 2025, and it dropped support for Drupal 9. Around it sits a small contributed ecosystem: Commerce Shipping is on 3.0.3 with roughly 15,200 installs, and the specialist modules discussed below sit in the low thousands.

Compare that with WooCommerce, which reports over seven million active installations and requires WordPress 6.9 and PHP 7.4 or higher. Drupal Commerce is roughly two hundred times smaller by install base.

That ratio is the single most important number in this article, and it is a warning, not a boast. It means the answer to “is there already a module for this” is frequently no.

The Honest Case for Shopify

Shopify solves the four problems that sink most self-hosted shops, and it solves them before you have written a line of code.

It is hosted, so uptime, scaling and patching stop being your budget line. It handles the card data, so the compliance surface you inherit is a fraction of what it would otherwise be. Its checkout is tested against a volume of real transactions no agency can reproduce, and small conversion differences at that scale are worth more than any architectural preference. And its app ecosystem means most requirements arrive as a subscription rather than a project.

For a consumer catalogue with a few thousand SKUs, one or two currencies and no negotiated pricing, none of the advantages described later in this article apply. You would be paying an agency to rebuild, worse, things you are currently getting for £65 a month.

Say it plainly, because the rest of the piece argues the other way: most shops should stop at Shopify. If yours is one of them, our comparison of Shopify against a custom ecommerce build covers the decision in more detail than this page does.

What Shopify Costs in the UK

Shopify publishes UK prices in pounds, so no conversion is needed. Read from the Shopify pricing page in September 2026, Basic is £25 a month billed monthly or £19 billed annually, Grow is £65 or £49, Advanced is £344 or £259, and Plus starts at £1,800 a month. POS Pro adds £69 a month per location.

The card rates matter more than the subscription. Online card rates through Shopify Payments are 2% plus 25p on Basic, 1.7% plus 25p on Grow and 1.5% plus 25p on Advanced. The figure most people miss is the third party payment provider fee, charged when you use a gateway other than Shopify Payments: 2% on Basic, 1% on Grow, 0.6% on Advanced and 0.2% on Plus.

That fee is on top of whatever your gateway charges. On a shop turning over one million pounds a year and using an external acquirer on Advanced, the third party fee alone is £6,000 a year, or £18,000 across three years, for the privilege of not using Shopify Payments.

Where Shopify Runs Out of Room

The limits are published and they are specific. Shopify’s documentation on adding variants states that each product can have up to three options and up to 2,048 variants, and that exceeding either requires a third party app or theme code that captures line item properties.

Three options is the ceiling that bites first. A window, a printed panel, a made-to-measure blind or a configured machine routinely has six or eight independent choices, and the moment you exceed three the platform stops modelling your product and starts approximating it.

The checkout is the second wall. Shopify’s checkout UI extensions for the information, shipping and payment steps are available only on the Plus plan. Below Plus you can brand the checkout but you cannot insert logic into it, which rules out delivery slot selection, trade credit checks and compliance gates at the point they need to happen.

The third is accumulation. Every gap is filled by an app, every app is a monthly fee and an upgrade dependency, and a shop with twenty apps has a maintenance problem that looks remarkably like the one it moved away from.

The Case for WooCommerce, and Where It Strains

WooCommerce deserves a fairer hearing than it usually gets. It is free, it runs on hosting that costs tens of pounds a month, the data is yours, and its extension catalogue is the largest in ecommerce by a wide margin. For a small to mid sized consumer shop where the team already knows WordPress, it is frequently the right answer and the cheapest one.

It strains in three predictable places. The first is the data model: products are a WordPress post type with attributes stored as serialised meta, so filtering a large attribute-heavy catalogue means querying a key and value table rather than real columns. That is survivable at a thousand products and painful at fifty thousand.

The second is performance under variation count, which is the single most common reason a WooCommerce store feels slow. We covered the mechanics of that in detail in our piece on why a WooCommerce store is slow, and the short version is that variable products multiply queries rather than rows.

The third is plugin sprawl. WooCommerce solves problems by installing things, and after four years the store is defined by thirty vendors’ release schedules rather than your own.

Complex Product Modelling: The First Real Dividing Line

The clearest case for Drupal Commerce is a product that is configured rather than chosen. Fabric sold by the metre with a cutting charge. Glazing priced by width multiplied by height with a minimum charge. A machine with eight option groups, some of which invalidate others. Print with a quantity break curve and a per-job setup fee.

None of these are variant grids. On a hosted platform they are approximated with an app and a set of line item properties, which means the price shown to the customer is computed outside the platform’s own pricing logic and has to be reconciled at some later point.

In Drupal Commerce the price is resolved by code you write. A price resolver receives the variation, the quantity and the current context, and returns a price. Nothing about that is exotic, and it means the configured price is the real price everywhere: in the cart, in the order, in the tax calculation and in the ERP export.

The test to apply is simple. If you can write your catalogue as a spreadsheet with one row per purchasable thing, you do not need this. If you cannot, everything else in this article becomes relevant.

B2B Pricing, Price Lists and Negotiated Terms

The second dividing line is whether two customers ever see different prices for the same SKU. Consumer shops answer no. Trade businesses answer yes, and the answer is usually the whole business.

Shopify does have B2B, and its B2B plan features documentation confirms it is available on Basic, Grow, Advanced and Plus. The limits are where the detail sits: below Plus you get up to three active catalogues across all B2B markets, direct company catalogues are Plus only, and deposits, partial payments and per fulfilment payment requests are Plus only. Three catalogues is fine for three price tiers and useless for forty negotiated accounts.

On Drupal the equivalent is the Commerce Price List module, currently 8.x-2.16 with roughly 1,662 reported installs and security team coverage. It sets prices per user or per role, supports quantity tiers and date ranges, and imports from CSV.

That last point is the practical one. A wholesaler with forty accounts, each on its own agreed list, refreshed quarterly from the ERP, is a CSV import job rather than a platform migration.

Multi-Store, Multi-Currency and Multi-Language From One Codebase

A store is a first-class entity in Drupal Commerce, and products are assigned to the stores that may sell them. That is a small design decision with a large consequence: several storefronts can share one catalogue, one order pipeline and one admin, while carrying different currencies, tax configuration, payment gateways and shipping rules.

The usual shape is a UK site, an EU site and a trade portal, all running from one deployment. Product data is entered once. A price list applies to the trade store only. Tax resolves per store because the store carries its own billing country and registrations.

Drupal core also brings a genuinely strong multilingual layer, with per language URL aliases, translated entities and alternate language links, which is why Drupal has such a heavy presence in higher education and the public sector.

Shopify Markets covers a good deal of this now, but contextual checkout and storefront customisation through Markets are limited to the Advanced and Plus plans, so the comparison is against £259 a month at minimum rather than against £25.

When the Catalogue Is Editorial

Some catalogues are content. A specialist retailer whose product pages carry buying guides, comparison tables, technical explainers and a reviewer’s notes is running a publication that happens to take payment.

On a hosted platform that is two systems. The CMS holds the article, the shop holds the SKU, and they are joined by a link and a nightly export. Editors work in two places, search indexes twice, and the URL structure grows a seam down the middle.

In Drupal Commerce a product is an entity in the same system as every article, so it shares the editorial workflow, the revision history, the taxonomy vocabularies, the media library, the search index and the access model. A product page can reference three articles and an article can reference nine products, both as real entity references rather than as pasted links.

This is the argument that most often justifies Drupal for a business that would otherwise sit comfortably on Shopify, and it is the one most often dismissed as a nice-to-have until an editorial team has spent a year working in two admin interfaces.

Regulated and Highly Attributed Products

Products that carry compliance data are the fourth case. Chemicals with safety data sheets. Medical devices with certificate numbers and expiry dates. Food with allergen matrices. Electrical goods with declarations of conformity. Anything with batch traceability or a restricted-sale flag.

The requirement is not simply to store those values. It is to validate them, to version them, to show the right one for the batch a customer actually received, and to prove afterwards what was published on a given date. Drupal’s Field API and revision system do this because they were built for content governance rather than for merchandising.

The enforcement side matters equally. An order processor can refuse a checkout that would ship an age-restricted item to a country that prohibits it, or that would combine two items which must not travel together, and it can do so inside the order pipeline rather than in a theme template.

On a hosted platform each of those checks is an app, and apps do not compose. Two apps that both modify the cart are two apps that will eventually disagree.

When the ERP Is the Source of Truth

The fifth case is structural. In a distribution or manufacturing business the ERP owns stock, pricing, customer credit and order status, and the website is a display surface with a shopping basket attached. The question is not what the shop can do, it is how cheaply it can be kept in agreement with the system that is actually in charge.

Drupal Commerce is comfortable here because the integration runs in your own process. The queue API handles asynchronous work, the migrate API handles repeatable idempotent imports, and there is no intermediary charging per record or throttling your sync window. A nightly price and stock import of two hundred thousand rows is a cron job.

On a hosted platform the same integration is either an app subscription or a middleware subscription, and the platform’s API rate limits become an architectural constraint you design around rather than a detail. That is workable, and for many businesses it is the correct trade. It stops being correct when the sync is large, frequent and business-critical at the same time.

If the integration work is the bulk of the project rather than the shop itself, that is a software development engagement with a storefront attached, and it should be scoped that way from the start.

Tax Is Where Hosted Platforms Stop Being Cheap

Tax is the quiet cost centre in cross-border ecommerce, and it is where the monthly subscription comparison starts to mislead. Two thresholds decide most of it.

The UK VAT registration line

GOV.UK guidance on when to register for VAT sets the threshold at £90,000 of total taxable turnover. Two separate tests trigger registration: a rolling twelve month test, where you must register within 30 days of the end of the month in which turnover passed £90,000, and a forward-looking test, where you must register as soon as you realise turnover will exceed £90,000 within the next 30 days.

The forward-looking test is the one that catches growing shops, because the registration date is the day you realised, not the day the money arrived.

EU VAT and the One Stop Shop

The European Commission’s guidance on place of taxation sets a combined annual threshold of EUR 10,000 covering intra-Community distance sales of goods and telecommunications, broadcasting and electronic services together. Below it, the place of taxation is where dispatch or transport begins. Above it, taxation moves to where the transport ends, which means the customer’s rate in the customer’s country.

The One Stop Shop lets you declare all of that in a single return in one member state, filed quarterly with deadlines at the end of April, July, October and January. The Import One Stop Shop covers goods imported from outside the EU in consignments not exceeding EUR 150.

What Drupal Commerce does about it natively

Commerce ships an European Union VAT tax plugin in core rather than as an add-on. It carries rates for all 27 member states plus Monaco, distinguishes standard, reduced, intermediate, super-reduced and zero rates, and handles the special territories that trip up flat rate tables, including Corsica, the Azores, Madeira, the Greek islands and the Austrian enclave of Jungholz.

It also applies the rules rather than just the rates: destination taxation for digital goods, and intra-Community business to business supplies zero-rated where a valid tax number is supplied. On a hosted platform that behaviour is typically an app with a per-transaction cost.

Payments, PCI DSS and How You Take the Card

How you collect the card number decides your compliance burden, and the rules changed recently in a way that is widely misunderstood.

The PCI Security Standards Council’s clarification of the SAQ A eligibility criteria explains a criterion that became effective on 1 April 2025. Merchants must confirm their site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”, satisfied either by implementing the techniques in PCI DSS requirements 6.4.3 and 11.6.1 or by obtaining confirmation from the payment provider that its embedded solution includes those protections.

The precise scoping is the part people get wrong. That criterion applies only to merchants whose page embeds the provider’s payment form, typically in an iframe. The Council states it does not apply to merchants who redirect the customer away to the provider, whether by an HTTP redirect, a meta refresh or JavaScript, nor to merchants who fully outsource payment functions.

So a hosted redirect keeps the surface small. Embedded fields, which convert better and are what almost everyone actually wants, put the integrity of every script on your checkout page inside your compliance conversation.

This is where Shopify’s real advantage sits, because the checkout is theirs and the scripts on it are theirs. On Drupal Commerce the checkout is yours, so the answer has to be engineered: a strict content security policy, subresource integrity, an inventory of every script that runs on the payment page, and change detection when one of them moves. That work is neither difficult nor optional, and it needs to be in the budget rather than discovered during an audit.

Accessibility Is a Legal and Commercial Risk

Ecommerce accessibility failures cluster in the checkout, which is also where every failure costs money directly.

The relevant reference is WCAG 2.2, a W3C Recommendation published on 12 December 2024. The criteria that bite in a shop are specific. 1.3.5 Identify Input Purpose at level AA covers autofill on address and card fields. 3.3.7 Redundant Entry at level A is the one violated every time a checkout makes a customer retype the delivery address at the payment step. 3.3.8 Accessible Authentication at level AA governs account creation and sign-in. 2.5.8 Target Size at level AA catches quantity steppers and remove-from-basket controls, and 1.4.3 Contrast at level AA catches the greyed-out disabled button that is in fact enabled.

Two more sit around the order itself: 3.3.1 Error Identification at level A, and 3.3.4 Error Prevention for legal, financial and data transactions at level AA, which is squarely about placing an order.

The legal position in the UK is often overstated. A private retailer is not bound by a statute naming a WCAG conformance level. What applies is the duty in section 20 of the Equality Act 2010 to take reasonable steps to avoid a substantial disadvantage to disabled people, including the provision of auxiliary aids. The regulations that do name a conformance level, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, apply to public sector bodies rather than to shops.

The commercial point is sharper than the legal one. On a hosted theme you cannot always fix what an app injects into your checkout. On a platform you control, you can.

What Three Years Actually Costs

The comparison people run is monthly subscription against monthly hosting, which is the least significant line in the table. Build cost and maintenance dominate, and transaction percentages dominate at volume.

The bands below are Mecanik house estimates for a UK mid-market shop, except the Shopify subscription and fee figures, which are quoted in pounds exactly as Shopify publishes them. Everything else is what we would expect to quote, and the spread within each row is wider than the gap between platforms at the low end.

What each line in that table actually buys

In prose: Shopify Advanced costs between £9,324 and £12,384 in subscription over three years depending on whether you commit annually, and includes hosting, but adds app subscriptions that realistically run from £5,400 to £14,400 over the same period. WooCommerce pays nothing for the platform and between £3,600 and £14,400 for hosting, with extensions at £3,000 to £9,000 across the three years. Drupal Commerce pays nothing for the licence, spends the most on hosting at £5,400 to £21,600 because it is the heaviest application of the three, and spends the least on add-ons, between nothing and about £3,000, because the equivalents are contributed modules rather than commercial ones.

Build cost is where the platforms separate. A Shopify build of £8,000 to £25,000 buys a themed store with the standard integrations, against £10,000 to £35,000 on WooCommerce. The same brief on Drupal Commerce is £35,000 to £120,000, because the checkout, the pricing logic and the integrations are all being written rather than configured. Maintenance follows the same shape, at £3,000 to £9,000 a year for Shopify, £4,000 to £12,000 for WooCommerce and £12,000 to £30,000 for Drupal Commerce, reflecting UK agency day rates of roughly £600 to £900 covered in our guide to Drupal developer rates.

Where the three year totals land

Three year totals land at roughly £32,000 to £79,000 for Shopify, £29,000 to £94,000 for WooCommerce and £76,000 to £235,000 for Drupal Commerce. Card and gateway fees sit on top of all three and scale with turnover, which is why the Shopify third party gateway fee of 0.6% on Advanced is worth £18,000 over three years on a million pound shop.

Read the table honestly and Drupal Commerce is two to three times the cost. It is justified only when the alternative is not actually available, which is the entire point of the five preceding sections.

Headless and Decoupled Drupal Commerce

Decoupling Drupal Commerce is a real requirement in a narrow set of cases and a fashion in most of the rest. The honest test is whether something other than a website needs the same catalogue.

It is a real requirement when a native mobile app and a website must share one product and pricing model, when an existing front end built by another team is not being replaced, when point of sale terminals or kiosks consume the same cart, or when a design system is owned outside the project and cannot be expressed in Twig. In those cases the API is the product and the CMS is deliberately invisible.

It is fashion when the reason offered is performance. A well cached traditional Drupal front end serves anonymous product pages from the edge, and the rendering approach is rarely what makes a slow shop slow.

The cost is concentrated in one place. Drupal core exposes content over JSON:API without configuration, and the Commerce Cart API module puts carts behind a REST interface, so reading a catalogue and building a basket are close to free. Checkout is not. Address handling, tax display, shipping selection, promotions, payment element integration and order confirmation all have to be rebuilt in the front end, and that is usually 40% or more of the total build.

The Five Minute Decision Rule

Answer six questions about your own catalogue. Each yes counts as one point.

Do any of your products need more than three options, or more than 2,048 purchasable combinations? Do two different customers ever pay different prices for the same SKU? Do you sell into more than one country with different VAT treatment, or expect to file an OSS return? Is the catalogue also editorial content that the same team writes and maintains? Is an ERP or a PIM the authority for price and stock, with the shop downstream of it? Do you need to insert your own logic into the checkout, rather than only branding it?

Score zero or one and choose Shopify. The advantages described in this article do not apply to you and you would be paying to rebuild what you are currently renting.

Score two and the decision is genuinely open, with WooCommerce often the better middle path, particularly if the team already runs WordPress.

Score three or more and Drupal Commerce is worth pricing properly, because the workarounds required elsewhere will cost more than the platform does over three years. Score five or six and the hosted platform is not a cheaper option, it is a different product that does not do the job.

Where Drupal Commerce Projects Usually Go Wrong

The most common failure is choosing it for the wrong reason. “We already run Drupal” is not a commerce requirement. A content site and a transactional site have different uptime, different testing and different consequences when a deployment goes wrong, and treating the shop as another section of the existing site is how a small ecommerce project acquires an unplanned platform team.

The second is under-resourcing maintenance. With 35,870 installs the ecosystem is small enough that you will use modules with a handful of maintainers, and somebody on your side has to watch security advisories and schedule the updates. A Drupal Commerce site with nobody responsible for that is a security incident on a delay, which we cover in more detail alongside the hosting requirements that Drupal actually has.

The third is assuming a module exists. Check before scoping. If it does not, the work is a bespoke website development task and needs a real estimate rather than a line item.

The fourth is major version discipline. Commerce 3 requires Drupal 10.3 or later, and a site that falls behind core eventually finds its commerce modules have moved on without it. Our guide to Drupal development in 2026 and the piece on migration costs and deadlines both go into that cycle.

Getting the Decision Right

The choice is decided by product and pricing complexity, not by traffic, turnover or preference. Model your catalogue first, on paper, including every option, every negotiated price and every integration that has to stay in agreement with something else. If that model fits in a variant grid, buy the hosted platform and spend the saved budget on merchandising.

Mecanik builds and maintains both kinds of store, and we will tell you which side of the line you are on before quoting anything. If the answer is Drupal Commerce, the work is a website development engagement with a substantial integration component; if the ERP work outweighs the storefront, it belongs under software development instead. If the answer is Shopify, we will say so, and we would rather say so now than eighteen months into a rebuild.

Frequently Asked Questions

Is Drupal Commerce better than Shopify? Not for most shops. Shopify is cheaper over three years, handles PCI compliance and hosting, and has a checkout tested at a scale no agency can match. Drupal Commerce wins in a narrow set of cases: products with more than three options or 2,048 variants, customer-specific negotiated pricing, catalogues that are also editorial content, and shops where an ERP owns price and stock.

What does a Drupal Commerce build cost in the UK? Expect £35,000 to £120,000 for the initial build and £12,000 to £30,000 a year for maintenance, at UK agency day rates of roughly £600 to £900. Over three years a Drupal Commerce shop typically lands between £76,000 and £235,000 including hosting, against roughly £32,000 to £79,000 for Shopify Advanced. These are house estimates, not quotes.

Which version of Drupal Commerce should I use? Drupal Commerce 3, currently at 3.3.8, released on 17 July 2026. It works with Drupal 10.3 or later and Drupal 11, and its stable releases are covered by the Drupal security advisory policy. Commerce 2 supported Drupal 9 and 10 and is the previous release cycle, so new projects should start on 3.x.

Does Drupal Commerce handle EU VAT and OSS? The tax rules are built into Commerce core rather than sold as an add-on. The European Union VAT plugin carries rates for all 27 member states plus Monaco, distinguishes standard, reduced, intermediate, super-reduced and zero rates, handles special territories, applies destination taxation to digital goods and zero-rates intra-Community B2B supplies against a valid tax number. Filing an OSS return remains an accounting task.

When is headless Drupal Commerce worth it? When something other than a website consumes the same catalogue, such as a native app, a point of sale terminal or a front end owned by another team. It is not worth it purely for speed, since a cached traditional front end is already fast. Budget for rebuilding checkout, which is typically 40% or more of a decoupled build.