When the store is part of a Drupal site

Build integrated content-commerce experiences withprofessional Drupal Commerce development services

Drupal Commerce makes sense when content is the heart of the business and the store has to live inside it, sharing its users, permissions and pages. We build it as Drupal modules and configuration, and plan core and Commerce upgrades together, because each depends on the other.

Versions and deadlines, as of October 2026

Drupal's schedule is published in advance, and for anyone still on Drupal 10 the next date is close.

Drupal 10 ends on 9 December 2026

After that date, it gets no more security support. Commerce 2.x works with Drupal 9.3 or later and Drupal 10, while Commerce 3.x works with 10.3 or later and Drupal 11. So a store on 2.x has to move to 3.x as part of leaving Drupal 10.

Commerce 3.x today

The current stable release is 3.3.13, from 28 October 2026, and it is covered by Drupal's security advisory policy. Centarro sponsors and maintains Commerce Core.

Drupal 11 and PHP

Drupal 11.3 and 11.4 support PHP 8.3, 8.4 and 8.5. A store coming from Drupal 10 on PHP 8.1 or 8.2 needs a PHP upgrade too, so the hosting belongs in the plan.

Drupal 12, not yet

Drupal 12 is due in the week of 7 December 2026, and 12.0 requires PHP 8.5. Commerce's project page lists 3.x for Drupal 10 and 11 as we write this, so we would aim a store at Drupal 11 for now.

Drupal Commerce development work

Commerce provides data objects, interfaces and subsystems, and you add configuration and code on top. It is closer to a toolkit than a finished store.

Checkout flows

A checkout flow is a plugin assigned to an order type, and its steps are defined in code. So a subscription order and a physical order can follow different checkouts, each with the steps it needs.

Custom checkout panes

Panes are annotated plugins with a default step, optional configuration and a visibility check. They suit extra order data, such as a delivery note or an account field, shown only to the buyers who need it.

Contributed modules

Shipping, stock, recurring billing, PayPal and AvaTax are separate projects that extend Commerce. We check that each has a release for your target version before relying on it, and write only what is left over.

Older stores

Commerce 1.x is a Drupal 7 product, built on a different architecture of hooks and Rules. Moving from it is a rebuild with a data migration, not an upgrade, so we scope it that way from the start.

When Drupal Commerce is the right choice, and when it is not

Drupal Commerce is an unusual choice for a plain store, and a sensible one where Drupal is already there.

A good fit when

  • You already run Drupal, and want the store to share its content, users and permissions.
  • Your products are tied closely to content, such as publishing, membership or education.
  • You have, or will pay for, Drupal skills over the long term.

A poor fit when

  • You just need an online store, and have no other reason to use Drupal.
  • You want ready-made themes and apps to do most of the work.
  • You have no one to keep Drupal core, Commerce and its contributed modules updated.

How Drupal Commerce projects run

On Drupal, the module versions decide what is possible, so we check them before designing anything.

  1. Module and version review

    Core version, Commerce version, PHP, every contributed module and any custom code, compared with what your target release needs.

  2. Model the store

    Product types, order types and checkout flows are agreed in writing with a price, since these decisions are expensive to change later.

  3. Build as code and config

    Custom modules and exported configuration live in version control and move through environments, so that a change can be reviewed and repeated.

  4. Upgrade and release

    We run updates on a copy first, then test orders through each checkout flow and payment gateway. Only then do we repeat it on the live site.

Named projects and how we engage

No Drupal Commerce projects are named on this page. Most of our work is delivered under NDA, so many projects cannot be named.

A Drupal 10 deadline upgrade suits a fixed scope, once we have reviewed the modules, and ongoing Commerce development can run as a monthly arrangement. Tell us early if you are on 2.x, because the date is close. We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment.

Drupal Commerce questions

We are on Drupal 10 and Commerce 2. What must we do?

Plan a move to Commerce 3 and Drupal 11. Drupal 10 stops receiving security support on 9 December 2026. Commerce 3 runs on Drupal 10.3 or later as well as 11, so the Commerce upgrade can come first, followed by core once your contributed modules are ready.

Should we wait for Drupal 12?

No, not if you are on Drupal 10. Drupal 12 is due in December 2026 and needs PHP 8.5, and Commerce's project page does not yet list it. Drupal 11 is the practical target today, and from there the next move should be much smaller.

Can you add recurring billing or subscriptions?

Usually. Commerce Recurring is a separate contributed project, and the Commerce docs cover recurring in their developer guide. We check that it fits your billing rules and gateway before committing to it, because recurring logic depends heavily on the payment provider.

Is Drupal Commerce right for a new store with no Drupal site?

Probably not. If content is not central to your business, you would be paying to run Drupal for little return. We would compare a hosted or simpler platform first, and say so.

Tell us about your Drupal Commerce site

Send your Drupal and Commerce versions and a list of contributed modules if you have one. We will tell you what stands between you and a supported version.

We reply within one business day (IST).