Drupal Commerce implementation partner

Drupal Commerce implementation for teams choosing a framework-first store

If your business needs a store that shares content, product data and customer records with the rest of your Drupal site, the decision is usually whether to build on Drupal Commerce with your own team or bring in a partner. Drupal Commerce is a contributed commerce framework that runs on Drupal and is licensed under GPL-2.0-or-later like Drupal itself, so there is no license fee for the framework and no paid edition of Drupal to buy. Teams choose it when they want the store to be part of the same content and catalog model as their marketing site, and when they are willing to assemble checkout, payments, tax and shipping from modules rather than configure a packaged storefront. Its modules are published on Drupal.org, so the first technical step is to review which contributed modules your store needs and how actively each one is maintained.

A typical implementation covers product types and variations, catalog and content modeling, checkout flows, promotions, payment gateway integration, tax and VAT rules, shipping, order and customer data, and the integrations that move orders into finance, fulfillment or a CRM. It also includes theming the storefront, testing checkout across devices, and planning how the store is hosted, backed up and updated. The scope grows quickly when the catalog is large, when prices differ by market or customer group, or when the store must integrate with several existing systems. Ask any partner to describe the modules they propose, the custom code they expect to write, and which parts of the scope sit with your team after launch.

Before you commit, confirm three points with your own stakeholders and any candidate partner. First, check whether your product model fits Commerce's entity structure, since changing product types late is costly. Second, identify the payment, tax and shipping providers you must support and confirm each has a maintained connector. Third, decide who will own updates for Drupal core and the contributed modules after launch, because the store depends on all of them. If your requirements are mostly standard catalog and checkout with few integrations, a packaged platform may be the simpler route. A framework-first build tends to suit businesses that need deep control over content, catalog and checkout logic and can staff the ongoing maintenance.

What Drupal Commerce does out of the box and through contributed modules

Drupal Commerce gives you a set of core entities and workflows for selling, and leaves many commercial features to contributed modules. Knowing which pieces come from core and which come from add-ons is the first decision in any store build, because it sets your upgrade exposure and your testing scope.

Product types and variations

Products are split into a product entity and purchasable variations, such as a SKU per size or colour. Each product type defines the attributes and fields that variations carry. Model these before building the catalog, because changing attributes after launch means touching existing orders and carts. Ask your team which attributes drive pricing and stock, since those are the ones that need to be reliable on every variation.

Orders, carts and checkout flows

Carts become orders when a customer starts checkout, and checkout moves through configurable steps and panes such as billing, shipping and review. Checkout flows are configuration, so changes are testable, but custom panes or steps are custom code you must maintain. Map every step to a business rule, then test the payment return path, abandoned carts and failed payments before launch.

Promotions and price rules

Promotions apply discounts through offers and conditions, with coupons for customer-entered codes. Stacking, exclusions and usage limits interact in ways that are easy to misconfigure, so write the discount rules as a test matrix before configuring them. Confirm with your merchandising team which combinations are allowed, and check the promotion behavior of the Drupal Commerce version you plan to run.

Payment gateway plugins

Payment gateways are plugins that connect checkout to a processor, with onsite and offsite variants. The choice of gateway determines how card data flows through your systems and therefore how much of your environment falls under PCI DSS scope. Compare the gateway modules available for your Drupal version on Drupal.org, and confirm their maintenance status and the processor features they support.

Tax handling and customer profiles

Tax is handled through tax types and rates, and customer data is held in profiles attached to orders, which keeps billing and shipping addresses with the transaction. Tax rules for VAT or sales tax often need a dedicated tax service or module. Confirm with your finance team how rates are sourced, how they are updated, and how historical orders keep the rate that applied when they were placed.

Shipping, subscriptions and licensed products

Shipping methods, subscriptions and licensed products are not core features. They come from contributed modules that each need a check against your Drupal version, your payment gateway and your order data model. Treat each as a separate evaluation with its own maintenance and security review, and ask the module maintainers for their current support status before committing scope.

When a framework-first store beats a packaged platform

When most of the value lives in editorial content, such as guides, reviews, magazines or brand sites, commerce often becomes one more section of an existing Drupal site rather than a separate system. Drupal Commerce keeps products, content, search and permissions in one installation, so editors and merchandisers work in the same place. The cost is that your team owns the store as part of the website. Someone must keep the commerce modules, payment connectors and tax configuration current alongside the rest of the site.

Shared ownership: Your Drupal developers must maintain both the content model and the store, including upgrades that touch both.
Editorial integration: Product pages can reuse Paragraphs or layout components, which suits teams that already publish a lot of content.
Upgrade coupling: A Drupal core upgrade also affects checkout, so schedule store testing into every release cycle.
Packaged alternative: If the store is a small addition to a brand site and the team has no Drupal capacity, a hosted store embedded through a link or widget may be simpler.

Confirm whether your editors need the store and content in one workflow, and whether you already have Drupal engineers who will own it after launch.

Configuration decisions that shape a Commerce build

This table compares the main Commerce configuration decisions, the options for each, the build effort they add and when each fits. Read it as a sequence: product modeling and payment scope set the boundaries that checkout, promotions and tax work then sit inside, so decide those first.

Decision	Options and build effort	When it fits
Product types and variations	Single product type with variations for simple catalogs. Several product types with distinct attributes and fields for mixed catalogs. Each added type adds templates, forms and checkout logic to test.	One type fits a narrow range. Several types fit when product families need different attributes, such as licensed software versus physical goods.
Checkout flow and panes	Default checkout flow with configured panes for a standard store. Custom checkout panes or a custom flow for added steps such as approvals or account types. Custom panes need code and ongoing upgrade testing.	Default flow fits most B2C and standard B2B stores. Custom panes fit when business rules must appear inside checkout, such as purchase order numbers.
Promotions and coupons	Core promotion offers and conditions for common discounts. Contributed or custom offers for stacking rules, customer-specific pricing or bundles. Each rule set needs test cases for overlaps.	Core offers fit simple percentage or fixed discounts. Custom logic fits negotiated pricing or complex stacking that finance teams must audit.
Payment gateway: off-site hosted fields	Gateway hosts the card form in a redirect or iframe, so card data does not reach your servers. Lower PCI DSS scope but gateway-specific integration and redirect testing.	Usually the lower-effort path for most stores that do not need to handle raw card data.
Payment gateway: on-site fields	Card fields are embedded in your own pages and submitted through the gateway API. Greater PCI DSS scope that follows your server, page and script controls, plus more security testing.	Fits when the checkout experience must be fully branded and the team can run the controls that the larger scope requires. Confirm scope with a qualified assessor.
Tax and VAT: built-in tax types	Commerce tax types and rates configured in the store for fixed, well-understood rules. Rate changes require manual maintenance and testing.	Fits a single jurisdiction or a small number of stable rates with low transaction volume.
Tax and VAT: external tax service	Calculation delegated to a tax service through an integration. Recurring subscription cost and an integration to build, monitor and version.	Fits multi-jurisdiction sales, frequent rate changes or invoices that must match a tax engine. Confirm which jurisdictions and invoice fields the service covers.
Order and customer data retention	Keep orders and profiles indefinitely, or define retention periods with anonymization or deletion jobs. Retention jobs need testing against accounting and refund records.	Set retention rules with your legal and finance owners before launch. Retention periods are set by your obligations, not by the platform.

How a Commerce implementation runs from discovery to launch

The sequence moves a store from a written scope to a tested, handed-over site in infrastructure the client controls. Each step produces an artifact that the next step depends on, so gaps surface early rather than at cutover.

Agree the written scope and business rules
The partner and the client's commerce, finance, and operations leads document the sales channels, currencies, countries served, shipping and returns rules, tax obligations, payment methods, and integrations with ERP, inventory, or CRM. Discovery ends with a written scope that names what is in and out, who signs off each decision, and what the client must supply. Done means the scope is signed and every open question has an owner and a due point in the plan.
Model products, variations, and catalog data
Product types, variation axes such as size or color, attributes, taxonomy, and pricing structures are designed from the business rules, then checked against sample real product records supplied by the client. The output is a product data model and a field-mapping sheet that shows which source system owns each attribute. Done means the client's merchandising team has reviewed sample products in a staging site and confirmed that variations and prices behave as they expect.
Provision hosting and environments
The Drupal application, database, cache, search, and file storage are deployed on infrastructure the client owns or contracts directly, such as its cloud accounts or data centers. Development, staging, and production environments are created with separate credentials and secrets, and the build is driven from version-controlled Composer and configuration. Done means a deployment from the repository reproduces the staging site, and the client's operations team can access and redeploy it without the partner.
Configure payments and tax in sandbox
Each payment gateway is connected to its sandbox account, and tax rules for each jurisdiction are configured from the agreed rules, including VAT or sales tax treatment of shipping and digital goods where applicable. Test transactions cover successful payments, declines, refunds, partial captures, and currency handling, and the results are recorded. Done means a payment and tax test report lists each scenario, the expected and actual outcome, and the tax calculation for each sample order, reviewed by the client's finance lead. Tax treatment should be confirmed with the client's tax advisor.
Build checkout flows and promotions
Checkout steps, address and shipping handling, order states, and customer account flows are built and configured, along with promotions such as coupons, order-level and product-level discounts, and their stacking rules. Custom code is limited to what the agreed scope requires and is kept in custom modules with automated tests. Done means a test matrix of checkout and promotion cases has passed in staging, and the outputs are a checkout specification and the list of custom code paths with their owners.
Migrate data and reconcile results
Customers, orders, product records, and stock levels are extracted from the source systems, transformed, and loaded with repeatable migration scripts. Totals, order counts, tax amounts, and inventory levels are reconciled between source and target, and mismatches are logged with a decision for each. Done means a reconciliation report shows agreed tolerances and signed exceptions, and the migration can be rerun from a clean copy of the source data.
Test security and rehearse the launch
Security testing covers the storefront, checkout, account, and administrative interfaces, along with the hosting and secrets configuration. A full launch rehearsal then runs the cutover steps in a production-like environment, timing each step, and recording rollback points. Done means the security findings are fixed or accepted in writing, and a cutover runbook lists each action, its owner, the go or no-go checks, and the rollback procedure.
Hand over and transfer operations
Administrators and operations staff are trained on product management, orders, refunds, promotions, and gateway settings, and the update, backup, and monitoring routines are transferred to the client's team or an agreed support arrangement. Architecture notes, runbooks, configuration exports, and credential ownership records are delivered. Done means the client's team has run the operational routines themselves in staging, and the handover package is signed off against the original scope.

What drives Commerce effort and cost up or down

This table lists the main drivers of Drupal Commerce scope, why each one adds work, and how to keep it contained in a written scope. Read it before requesting a quote, because most of the variance in effort comes from the decisions in the first column rather than from the code itself.

Driver	Why it changes effort	How to keep it down
Catalog size and variation complexity	Each product type, attribute and variation combination adds configuration, pricing rules, stock handling and test cases.	Limit variations to attributes that change price or stock, use one product type per distinct buying model, and load a representative sample before the full catalog.
Number of payment gateways	Every gateway needs its own configuration, sandbox testing, webhook handling, refund and failure paths, and reconciliation checks.	Start with one gateway per region, prefer hosted payment fields or redirect flows so card data stays out of your application, and add gateways in later phases.
Regions, currencies and tax jurisdictions	Each country or currency adds tax rules, rounding behavior, address formats, shipping zones and legal copy to verify.	Launch with the markets you actually sell in, confirm with your tax adviser which VAT or sales tax rules apply, and treat each new jurisdiction as a separate change request.
VAT rules and tax calculation source	Reverse charge, OSS-style cross-border rules and exemptions need explicit logic, while an external tax service adds an integration to test and maintain.	Decide early whether tax comes from Commerce tax modules or an external service, and document which rules the business owns and which the service owns.
Custom checkout steps	Each added pane or step changes validation, session handling, accessibility testing and the order states that downstream systems depend on.	Keep the default checkout where possible, use configuration before code, and limit custom steps to data the business must collect at a specific moment.
Promotion rule complexity	Stacked offers, coupon limits, customer-specific pricing and exclusions interact, so each combination needs its own test case.	Agree a short list of promotion types for launch, avoid stacking rules unless the business requires them, and write expected totals for worked examples before build.
ERP and accounting integration	Order, stock, invoice and customer sync needs field mapping, error queues, retry logic and reconciliation rules agreed with the ERP owner.	Confirm which system is the master for stock and pricing, send only the fields the ERP needs, and plan a one-way sync first unless two-way updates are required.
Shipping carriers and rate sources	Each carrier adds an API contract, label handling, tracking updates and returns logic.	Start with flat or table rates, add one carrier at a time, and confirm which carrier APIs your account can access before scoping.
Data migration volume	Orders, customers, product history and legacy carts each need mapping, cleaning, reruns and sign-off, and volume increases rehearsal time.	Migrate only active products and recent orders where legal and finance allow, archive older records, and agree the record counts that define a successful trial run.
Drupal versions and contributed modules to validate	Each Commerce, core or contributed module update must be tested against your custom code, payment flows and tax logic before release.	Keep the contributed module list short, pin versions in Composer, and ask the partner to state how upgrade testing is run for each release.

How payment gateways and VAT affect scope and compliance

The gateway choice decides how card data moves through your store, and that movement sets your PCI DSS scope more than any other decision in the Commerce build. If the Commerce checkout posts card numbers to your own servers, your environment falls inside the cardholder data environment and needs the full set of controls. If the gateway collects card details in a hosted payment page or through an iframe or tokenization script served by the provider, your servers handle fewer or no card elements, and the assessment shrinks accordingly. Confirm with your acquirer and gateway which integration method they support, what they will attest for you, and which responsibilities remain with your team. Describe the scope in terms of control areas such as network segmentation, access control, logging, vulnerability management and secure configuration, and have your qualified assessor confirm the boundary before the build is locked. We do not quote the standard's requirements here. Refer to the current PCI DSS document and your assessor for the exact control IDs that apply.

VAT and sales tax rules differ by country, state, province and sometimes by product type or customer status, and they change over time. Commerce provides tax handling through contributed modules and its tax configuration, so the build can calculate, display and report tax according to the rules you give it. The rules themselves must come from your tax advisor, who should confirm the rate tables, registration thresholds, place-of-supply logic, invoice wording and treatment of digital or licensed products before we configure anything. Ask for that rule set in writing as part of the scope. DeployOpen configures the tax logic against those rules, tests representative orders for each jurisdiction and documents the results, but we do not give tax advice and do not decide what is taxable or how it must be reported.

Gateway and tax work recur after launch. Gateway APIs and payment methods change, card scheme rules are updated, and tax rates move, so plan an owner for periodic review of the gateway integration, the scope boundary and the tax tables. When you request a quote, ask who is responsible for each control area, which items the gateway provider covers, and how tax rule changes will be delivered and tested after go-live.

How Commerce connects to the rest of the platform

How does Drupal Commerce product search work with Search API?

Drupal Commerce stores products as entities, so product search is usually built with the Search API module, which indexes product and variation fields into a search server and exposes facets and sorting to shoppers. The index design decides what a shopper can filter on, such as brand, size or availability, and each index field must map to a field that the product type actually carries. Search API can use the database backend for small catalogs or an Apache Solr backend for larger ones, and the choice affects hosting and reindexing time. Confirm which Search API and Solr module versions support your Drupal core version before you commit to an index design, because compatibility is set per release line.

Can Webform or Paragraphs build Commerce landing pages and forms?

Yes, both are used alongside Commerce for different jobs. Paragraphs lets editors assemble category landing pages from reusable blocks such as product grids, promotional banners and comparison tables, while Webform handles pre-order requests, quote forms, returns and contact forms that sit next to the store. Keep the product data itself in Commerce so that prices, stock and cart behavior stay in one system of record. Ask for a list of every form and landing page type during scoping, since each one adds content types, permissions and testing effort.

What is the best way to add SSO for Commerce customer or staff accounts?

Use a contributed module that matches the identity provider in your environment. The OpenID Connect module lets external OpenID Connect providers authenticate Drupal users and can create accounts on first sign-in, with built-in clients for generic OAuth 2.0 and several named providers. The SAML Authentication module (samlauth) lets the site act as a SAML service provider, and its latest stable release 8.x-3.14 supports Drupal 10.3 and later and Drupal 11. Decide early whether customers and staff share one identity provider, because staff roles and customer roles behave differently in Commerce checkout and administration. Confirm the module release against your exact Drupal version before design starts.

How do CRM and ERP connectors fit into a Drupal Commerce build?

Commerce is usually the storefront and order capture point, and the CRM or ERP receives customers, orders, invoices and stock levels through a defined integration. Most projects use custom code or a dedicated integration module built on Drupal's event and plugin system, with a queue for retries so that a failed ERP call does not lose an order. The cost is driven by the number of objects that move, the direction of each flow, whether the ERP exposes an API or only file exchange, and how often master data changes. Ask any partner to document field mappings, error handling and reconciliation reports in the written scope.

Where should Commerce product media be stored?

Store product images and downloadable files on object storage such as S3-compatible storage, and serve them through a CDN, rather than on the web server's local disk. Drupal's file system and media handling can be configured with a contributed storage module for S3-compatible buckets, which keeps multiple web nodes consistent and simplifies backups. Plan image styles and derivative generation, because a large catalog creates many derivatives that increase storage and cache purging work. Confirm the storage module's support for your Drupal core version, and confirm where private files such as licensed downloads will live and who can access them.

Does the Drupal version change how these integrations are built?

Yes. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so the PHP version of your hosting stack can limit which module releases you can run. Contributed modules for search, SSO and storage each declare the core versions they support, and a module that is current for Drupal 11 may not yet support the release you plan to adopt. Drupal 12 is scheduled for the week of December 7, 2026, according to the core release schedule, so integrations chosen today should be checked against that timeline. Ask for a compatibility matrix for each integration as part of scoping.

Who maintains these integration modules after launch?

Contributed modules are maintained by their projects and maintainers, and security releases are published by the Drupal Security Team, which uses Wednesday security release windows. Your team or a support partner must monitor these releases, test them against your Commerce build and deploy updates, because an unpatched search, SSO or storage module is a risk to customer data. Custom integration code is your responsibility after handover, so ask for coding standards, tests and documentation to be part of the deliverables. Ongoing support and upgrades are available as retainers.

Migrating products and orders from an existing store

Moving products and orders from an existing store is a migration project in its own right, and it runs through the core Migrate API with the migration modules for the source platform. If the source is a Drupal 6 or Drupal 7 store, plan for a new site rather than an in-place upgrade: the Drupal documentation states that these sites cannot simply be updated to Drupal 10 or later, they are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. Budget the theme work as new front-end development, not as a data step. Ask your partner to show the mapping file for each entity type before any build starts, because it is the document your team will review line by line.

Product mapping is where most errors start. Map each source product to a Commerce product type, then map each sellable item to a product variation with its own SKU, price and stock reference, and confirm how option combinations, attributes and images carry over. Customer accounts need a decision on password handling: most legacy hashes cannot be carried into a new site without a validation step, so agree whether users log in once and have their hash rehashed, or whether they reset passwords at first sign-in. Keep the customer address book and tax identifiers in scope, since they feed checkout and invoicing. Order history should be imported as read-only records linked to the new customer and product IDs, so that support teams can answer questions about past purchases without the old system running.

Reconciliation at cutover is the step that protects revenue. Freeze or drain the source store for a defined window, run the final delta migration, and then compare counts and totals for orders, line items, prices and stock levels between the two systems. Check currency, rounding and tax-inclusive price fields, because a mismatch there will show up as a mispriced cart on launch day. Agree with your team and your payment gateway how open carts, pending payments and refunds are handled during the switch. Ask any partner to quote migration as its own line item, with the source platform version, the number of entity types and the number of rebuilt themes listed as the drivers, and to include a rehearsal run on a copy of production data before cutover.

Questions buyers ask before hiring a Drupal Commerce partner

What drives the cost of a Drupal Commerce build, and can it be quoted as a fixed price?

Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and the quote follows from that written scope. The main cost drivers are the number of product types and variations, the checkout flows and promotions you need, the number of payment gateways and shipping or tax integrations, the volume and quality of product data to import, and the custom code required beyond contributed modules. Ask any partner to split the quote into discovery, build, integration, testing and launch, and to state which items are one-time and which recur, such as hosting, module updates and support retainers. Ongoing support, upgrades and continuous testing are available as retainers, so those costs should be quoted separately.

How long does a Drupal Commerce implementation take?

The timeline depends on scope more than on the platform itself. Duration is set by the number of product types, the complexity of checkout and promotion rules, how many gateways and tax or ERP connections must be tested, and how quickly your team confirms decisions and returns product data. Gateway sandbox approvals, tax rule sign-off and data cleansing are common sources of delay, so plan those as early tasks rather than launch-week tasks. Ask for a written timeline with named milestones and the client dependencies behind each one. We do not publish a fixed duration because it would not reflect your scope.

What must our team provide before a Drupal Commerce build starts?

A store build depends on decisions and data that only your organization can supply. Expect to provide:

Product data in a usable format, including SKUs, attributes, variations, images and stock sources
Tax rules and the jurisdictions you sell into, with a named person who approves tax logic
Payment gateway accounts, sandbox access and the merchant details each gateway requires
Shipping rates, carrier accounts and fulfillment rules
Decision owners for pricing, promotions, checkout and returns, with authority to sign off

Also name a technical contact for hosting and identity, and agree who will own the store after launch. Missing decision owners are one of the most common causes of rework.

Can our in-house team build and run a Drupal Commerce store without a partner?

Yes, an experienced in-house team can build a Drupal Commerce store, since the framework and its contributed modules are open source and licensed under GPL-2.0-or-later. The questions to answer honestly are whether you have engineers who know Drupal's entity and configuration systems, whether they can own payment, tax and PCI DSS scoping decisions, and whether they can keep the store patched on the Drupal release schedule. Many teams split the work, keeping product and content ownership in-house while a partner handles architecture, integrations and testing. A partner is most useful when the team has no Commerce experience or when the launch date is fixed.

How do Drupal major versions and upgrades affect a live store?

A store must be planned for upgrades from day one. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, so your operations plan needs a standing patch window. Contributed Commerce modules must also support the target core version before you upgrade. Drupal 6 and 7 sites cannot be updated in place, so older stores require a migration into a new site. Ask any partner how they test upgrades against checkout, payments and tax before they reach production.

What does Drupal Commerce need from the hosting environment?

Drupal runs on Apache, Nginx and other web servers, with MariaDB, MySQL, PostgreSQL or SQLite as the database, according to the Drupal.org system requirements page. Supported versions depend on PHP: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, per the Drupal.org PHP requirements page. Your payment, tax and ERP integrations also need outbound network access, secrets storage and a tested backup routine. Confirm these requirements with your hosting team before the build, since they affect cost and the upgrade path.

Does DeployOpen guarantee payment acceptance or tax outcomes for our store?

DeployOpen plans, builds, integrates, tests and documents the store inside your infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and independent auditors and certification bodies perform those reviews. Tax obligations depend on your jurisdictions and your tax advisers, and gateway approvals depend on each payment provider. What DeployOpen can do is configure tax logic to the rules you supply, test checkout and refunds against the sandboxes you provide, and document how the store behaves so your advisers and assessors can review it.

What the client receives at handover

Handover is the point where the store moves from the project team to your operations team. Each item below is a document, record or piece of configuration your team keeps, so the store can be changed, tested and recovered without the original builders. Ongoing support, upgrades and continuous testing are available as retainers, and all scope is agreed in writing before work starts.

Configuration exported to version control

Store configuration is exported into your repository: product types, order types, checkout flows, promotions, tax settings, payment gateway definitions and stores. Secrets such as gateway keys stay out of the export and live in your secrets store. Confirm with your team which environment is the source of truth and how changes move from staging to production, so a config export is never overwritten by an editor on the live site.

Product and checkout documentation

A written record of how the catalog and checkout are built: each product type and its variations, attribute and price rules, the checkout pane order, and which promotions and coupons interact. Editors and support staff use it to answer questions without reading module code. Ask for it to name the Commerce modules and versions in use, because upgrade planning depends on them.

Payment and tax test records

Recorded test results for each payment gateway in sandbox and live modes, covering successful payments, declines, refunds, partial captures and failed webhooks. Tax tests show how rates apply to each country, product class and shipping charge, including VAT where it applies. Ask for the expected results to be signed off by your finance team, since tax rules change and the record shows what was checked and when.

Migration reconciliation reports

If orders, customers or products came from an earlier store, reconciliation reports compare record counts, totals, tax amounts and open balances between the source and the new site. Each difference is listed with its cause and the decision taken. Ask for these reports before cutover, because they are the evidence that historical orders and stock levels are complete.

Runbooks for updates and backups

Step-by-step runbooks cover applying Drupal core and Commerce updates, restoring the database and file store, rotating gateway credentials and recovering from a failed deployment. Each runbook names the person or team responsible and the test that confirms it worked. Rehearse at least one restore before go-live so the backup is known to work, not assumed.

Operations plan

The operations plan sets out who monitors the store, how payment and order errors are triaged, how cron and queues are watched, and which Drupal security advisories are checked and applied. It also records the review cadence for tax rules and gateway changes. Agree the plan with your operations and security owners before handover, so the store has a named owner from the first day after launch.

How DeployOpen scopes and delivers Drupal Commerce work

DeployOpen plans, builds, documents and supports Drupal Commerce stores inside infrastructure you control, from the first product model to the handover and ongoing maintenance. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

The written scope lists product types, variations, checkout steps, promotions and the payment gateways in use.
Tax and VAT rules, shipping methods and stock handling are named in the scope so the quote reflects them.
Scope states which contributed Commerce modules are used, which custom modules are built and what stays out of scope.

How we build

Product and order data models are designed and reviewed before checkout flows, promotions and gateway connections are configured.
Custom modules are built with automated tests covering pricing, tax calculation, promotions and checkout transitions.
Payment, tax and order integrations are tested in a staging environment with sandbox gateway credentials before go-live.

How we hand over

Deliverables include configuration exports, custom code in your repository, and documentation of product, tax and checkout decisions.
Runbooks cover order and payment reconciliation, failed-payment handling, and how to add a product type or tax rate.
Handover sessions walk your team through the store, the admin workflows and the deployment process before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainers can cover Drupal core and Commerce module updates, tested against your gateway and tax integrations.
Ask for the support scope, response expectations and upgrade testing approach in writing before you sign.

Drupal Commerce implementation