How to use an ecommerce platform requirements checklist before you choose a platform
A team that must pick or rebuild a store on open source usually starts with a platform name and works backward, which makes vendor and partner conversations hard to compare. An ecommerce platform requirements checklist reverses that order. It turns business needs, such as the number of products, the markets you sell into and the systems the store must talk to, into testable requirements that every candidate platform and implementation partner can answer in writing. Write the checklist before the first vendor call, and ask each party to show how their proposal meets each line.
Rank every item as must-have, should-have or later. A must-have is a condition the business cannot launch without, such as a payment provider that works in every target country or a checkout design that fits your card-data obligations. A should-have improves the store but has a workaround. A later item is useful after launch, such as personalized bundles or advanced loyalty rules. Keep the list short enough that stakeholders can agree on it in one review. The rest of this page groups requirements by function, security, integration, operations and compliance so each owner can check their own lines.
Scope drives effort more than the platform name does. A store with a few hundred products, one currency and a card processor that hosts the payment page is a different project from a multi-country B2B catalog with ERP stock feeds and negotiated price lists, even on the same software. Before you compare Magento Open Source, WooCommerce, Saleor, Medusa or Sylius, record the volume, channels, markets and integrations in numbers wherever you can. Confirm the current release status of any candidate with the vendor and its published release notes, because support windows change, and let those facts, not the brand, decide what the build costs.
Functional requirements every ecommerce platform must meet
This table lists the functional requirements a self-hosted ecommerce platform must meet, why each one matters, and a practical way to verify it before you commit. Use it as a shortlist filter and as the basis for a proof-of-concept. Where a platform capability is not confirmed by a supplied source, the verification step tells you what to confirm with the vendor or partner.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Catalog size and product data model | Variant counts, attributes and bundles drive import time, search indexing and admin usability. Some platforms model variants and attributes differently, which affects migration. | Run a proof-of-concept import of your largest real catalog file, including configurable products and variants, and time the import and admin search. |
| Channels, currencies and price lists | Per-market pricing, currencies and channel-specific stock decide whether one instance can serve several storefronts or markets. | Create two channels with different currencies and prices, then place a test order in each currency and confirm tax, rounding and stock deduction. |
| Multi-warehouse stock and fulfillment | Shared versus separate inventory across warehouses affects oversell risk and delivery promises. Saleor documents multi-warehouse fulfillment; Magento and Medusa stock models need confirmation for your layout. | Load stock for two warehouses, split one order across them, and confirm the fulfillment and inventory update in the admin and through the API. |
| Promotions, vouchers and gift cards | Promotion rules are a common source of checkout defects and margin leaks. Saleor documents sales, vouchers, cart rules and gift cards; confirm the equivalents on other platforms. | Build the ten most-used promotions from your marketing calendar and run them against a cart test matrix, including stacking and excluded products. |
| Returns and refunds | Returns logic affects order status, inventory and payment reversal. Saleor documents returns; the depth of return flows elsewhere varies and should be confirmed. | Process a partial return and a refund against a test payment, then check stock, order status and accounting export. |
| B2B features: customer-specific catalogs, price lists and quotes | Distributors and dealers need contract prices, restricted catalogs and approvals. Medusa lists B2B stores as a supported use, but B2B feature depth should be confirmed with the vendor or partner. | Ask the partner to demo a dealer account with its own price list, restricted catalog and quote approval using your real customer terms. |
| Checkout and payment provider support | Gateway choice sets PCI DSS scope and conversion. Saleor documents multi-gateway support and split payments; confirm your specific providers and their hosted-field or redirect options on each platform. | Run a sandbox transaction for each provider, including a declined card, a 3-D Secure challenge and a refund, and record which page handles card data. |
| Multi-store and multi-country setup | Brands and markets often need separate storefronts with shared customers or catalogs. How each platform models multiple stores differs and should be checked, not assumed. | Stand up two storefronts sharing one catalog and confirm customer login, price isolation and order routing as the design requires. |
| ERP and PIM integration hooks | Stock, order status and product data usually come from other systems. Saleor extends through webhooks, apps and metadata; Medusa and Magento use their own extension points. | Send a real order and a catalog update through the integration in staging and confirm idempotency and error handling when the ERP is unavailable. |
Which open-source platform fits which requirement profile
WooCommerce is a natural fit when the business already runs WordPress for its content, the catalog is modest, and the team is comfortable with WordPress plugins and themes. WooCommerce is licensed under GPL version 2 or later, and version 11.2.1 was published on October 9, 2026. Because the store shares a stack with the content site, the hosting, caching and plugin governance decisions usually sit with the same team.
- Licensing: GPL-2.0-or-later code, so review each paid extension's license terms separately.
- Stack fit: Strong when editorial content and the shop live in one WordPress estate.
- Plugin governance: Every extension is an upgrade and security dependency that needs an owner.
- Catalog and checkout: Confirm that the catalog size, variant counts and checkout flow stay within what your load tests show.
- Payment pages: Confirm how each payment plugin loads scripts, because that determines your PCI DSS scope.
Ask your implementation partner to confirm the WordPress and WooCommerce versions they will support, and to document how extensions will be kept upgradable in your written scope.
Magento Open Source suits catalogs with many SKUs, complex store views, and teams that want deep customization inside a PHP monolith. The code is licensed under OSL-3.0, and Adobe publishes system requirements and support windows for each 2.4.x release. Version 2.4.9 was released in May 2026, and its requirements list PHP 8.5, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30 on Linux x86-64. Adobe supports only the listed combinations, so the stack is more constrained than a plugin-based shop.
- Support windows: Adobe gives each 2.4.x release three years of standard support, with end of regular support on May 31, 2029 for 2.4.9.
- Infrastructure: Self-managed installations use Varnish as the full-page cache, plus search and message queue services.
- Security headers: Content Security Policy support is available from 2.3.5, and restrict mode is on by default for storefront and admin payment pages from 2.4.7.
- Operating model: Plan for an in-house or partner team that can run the upgrade path, not just install the platform.
- Distribution choice: Confirm whether you will use Adobe's distribution or a community distribution, and who supports it.
Confirm the exact version combinations, the support calendar and the upgrade owner with your partner before you commit to a scope.
Saleor and Medusa are API-first commerce platforms built for teams that will build their own storefront and integrate commerce into other systems. Saleor is licensed under BSD-3-Clause and runs on Python, Django, GraphQL and PostgreSQL. Medusa is MIT licensed for its core framework, but Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. Medusa v2.21.2 was released on September 28, 2026, and Saleor 3.23.42 on October 16, 2026.
- Saleor components: The API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers all need to run. The Docker Compose setup asks for at least 5 GB of memory for Docker.
- Saleor extension model: Extensions use webhooks, apps and metadata rather than in-process plugins.
- Medusa topology: A self-hosted deployment needs PostgreSQL, Redis, one server instance for the API and admin, and one worker instance for background tasks.
- Medusa operations: Database migrations run through a predeploy script before each startup, and the deployment is checked through the /health endpoint.
- Edition check: Confirm whether any required feature sits in Medusa's Enterprise Edition before you finalize the license plan.
Ask your partner to confirm the frontend framework, the license position for every feature you need, and who operates the worker and background processes.
Sylius suits organizations with an established PHP engineering team that wants commerce logic written as application code rather than configured through a plugin marketplace. Sylius is licensed under MIT, and v2.3.1 was published on October 14, 2026. Teams that already run Symfony services often find the domain model easier to extend, but the team carries more of the design, testing and upgrade work itself.
- Licensing: MIT, which places few obligations on how you use or modify the code.
- Domain customization: Pricing, promotions and checkout rules are implemented in your codebase, which suits unusual business logic.
- Staffing: Confirm that you have engineers who can maintain Symfony and Sylius upgrades over time.
- Ecosystem: Fewer off-the-shelf integrations than WooCommerce or Magento, so budget for custom connectors to ERP and PIM systems.
- Testing: Plan automated test coverage for commerce logic before go-live.
Ask your partner to show how custom domain logic will be documented and tested, and to confirm the version support path in your written scope. DeployOpen does not rank platforms, so confirm fit against your own requirements in a written scope.
Security requirements that decide the checkout design
Most of the security work on a self-hosted store traces back to one question: where the card data is captured. The cards below cover the decisions that follow from checkout design, the controls on the storefront and the ownership of patches, and they mark which items need confirmation from a qualified assessor or security firm before a build is locked.
PCI DSS scope and SAQ type
The checkout design sets how much of your environment is in scope for PCI DSS and which self-assessment questionnaire (SAQ) applies. A redirect or hosted payment page keeps card entry on the provider's side, while a self-built card form or direct post pulls your servers and scripts into scope. Ask your payment provider and an assessor to confirm the SAQ type for the exact checkout flow you plan to run, before hosting and scripts are designed.
Payment page script control
Requirement 6.4.3 of PCI DSS concerns how scripts loaded on payment pages are inventoried, authorized and kept in a known state. On a self-hosted store, every tag manager, analytics snippet and extension script on checkout is a decision you must record and justify. Confirm with your assessor which scripts are in scope and how they are approved and reviewed.
Payment page change detection
Requirement 11.6.1 of PCI DSS expects a mechanism that detects unauthorized changes to payment pages, such as injected scripts or altered form fields, and alerts staff. This is separate from script approval: it watches the live page for drift. Ask your security firm which tool, alert path and review owner will satisfy the requirement on your stack.
Content Security Policy in Magento
Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. Restrict mode blocks scripts that are not allowed, so themes and extensions can break at checkout. Test the policy on a staging copy of the live payment flow and confirm the allowed sources with your payment provider.
Secrets and session configuration
A self-hosted Medusa server and worker each need database credentials plus COOKIE_SECRET and JWT_SECRET values. Generate them per environment, store them in a secrets manager rather than in code, rotate them under a documented process and confirm that the server and worker use consistent values. Check the /health endpoint after each change so a misconfigured secret is caught early.
Patch ownership and security cadence
On Magento Open Source, Adobe ships security patches at least annually for all supported release lines, and 2.4.9 has regular support until May 31, 2029. Your team, or a contracted partner, owns applying patches, extensions and the underlying runtime such as PHP, the database and nginx. Write down who applies each class of patch, how fast, and who signs off on a regression test before go-live.
How ERP, PIM and payment integrations change the requirement list
ERP and PIM integrations are where most store projects overrun, so the requirement list should treat them as a separate workstream with its own acceptance tests. Start by naming the data flows the store depends on: stock levels, order status, product attributes, customer accounts and price lists. For each flow, record which system is the owner of record, how often the data must move (on each change, on a schedule, or in a nightly batch), and what the storefront does when the other system is unavailable. A flow nobody owns is the usual source of later disputes about which price or stock figure is correct.
Next, confirm what the platform exposes. Saleor and Medusa are API-first, so the integration question is which API surface, webhook events and app or module extension points your ERP and PIM will use. Saleor extends through webhooks, apps, metadata and API extensions rather than in-process plugins, and Medusa uses a module design with defined service boundaries. Both models keep custom code outside the core, which reduces upgrade friction. Magento is different: its extensions run inside the application, so every third-party connector needs a compatibility review against each 2.4.x patch and minor release before it is accepted into the upgrade plan. Ask each candidate partner to show the exact interfaces their integration uses and the test evidence for them.
Test integrations before go-live with a staged data set that includes edge cases: partial stock returns, price changes during a cart session, orders that fail at the ERP and retry, and attribute values that the PIM marks as optional. Run the same tests after each platform upgrade, because an extension or core change can break a mapping silently. Also confirm the payment integration path, since the payment provider's webhooks and the order record must agree on final status. Ask the implementation partner to document the test cases, the monitoring for failed syncs, and who on your side owns the reconciliation runbook. Connector licensing, middleware and any integration platform fees should be listed separately in the written scope, because they are recurring costs that a platform comparison often omits.
Integration requirements to write into the scope
Every ecommerce platform sits between systems that already hold stock, products, money and customer records. Each connection below should appear in the written scope with an owner, a data direction and a test that proves it works before cutover.
ERP order and stock sync
Ask which system owns stock levels, order status and price changes, and how often each direction runs. Write down the event that creates an ERP order, the retry rule when the ERP is offline, and how partial shipments are reported back. Test with a batch of orders that includes a refund, a split shipment and a cancelled line, then reconcile stock counts in both systems. Confirm the ERP vendor's API limits and whether it supports idempotent writes, since duplicate orders are the most common failure in this flow.
PIM product data
Ask which system is the master for product names, attributes, images and channel-specific descriptions, and whether the store may overwrite any field locally. Define the attribute schema the store will import, including units, variants and translated values. Test with a full import and a delta import, then check that removed products and changed variant codes behave as agreed. Confirm how media files are fetched and cached, because broken image links often surface only after launch.
Payment providers and fraud tools
Ask which payment providers must be live at launch, which payment methods each market needs, and whether fraud scoring runs before or after authorization. Confirm where the card data is entered, because that choice decides the PCI DSS scope of the store and which scripts must be managed on the checkout page. Test each provider with successful, declined, 3-D Secure challenged and refunded transactions, and test webhook replay after a timeout. Record which system stores the provider reference for each order.
Search service connection
Ask whether the search index is built from the catalog database, the PIM feed or the ERP stock feed, and how often it refreshes. Confirm who runs the search service, where the index lives, and how it behaves when the index is stale or unreachable. Test that a product removed from the catalog disappears from results, that stock status matches the ERP, and that search still returns results for the peak query volume agreed in the scope.
Shipping and tax engines
Ask which system calculates tax rates and shipping rates at checkout, which address data it needs and whether tax must be calculated on the storefront or in the ERP. Confirm rate tables, rounding rules and the handling of tax-exempt business customers. Test checkout for each destination market with domestic, cross-border and exempt addresses, and compare the totals on the order, the invoice and the carrier label.
Identity and customer data stores
Ask where customer accounts live, whether the store, the CRM or an external identity provider is the source of truth, and how login and account changes sync. Confirm which customer fields are shared, who may read them, and how a deletion or access request reaches every copy. Test single sign-on for staff and customers, password reset, account merge after a duplicate registration and a full customer export.
Operational requirements for performance, search and upgrades
This table compares the operational requirements a self-hosted store creates for Magento Open Source, Saleor and Medusa, and how to verify each one. Read each row as a question to answer before you select a platform, and use the verification column as the acceptance step in a staging rehearsal. The main takeaway is that the platform choice sets the service count you must run, patch and monitor for the life of the store.
| Requirement | What it asks for | How to verify it |
|---|---|---|
| Performance targets | Page speed, checkout response and peak order rates written by the business before platform choice, with the traffic pattern for normal and sale days | Load test the staging copy against the agreed targets and record results per release; ask the partner to show the test scripts and data volumes used |
| Full-page caching | Magento 2.4.9 self-managed installs use Varnish as the full-page cache accelerator; cloud-hosted Adobe Commerce uses Fastly instead | Confirm cache hit rates and bypass rules for carts, checkout and logged-in pages in staging, and test purge behavior after a catalog update |
| Search engine dependency | Magento 2.4.9 requires OpenSearch 3; Saleor and Medusa need a separate search choice for catalog queries | Index a full-size product export in staging, measure query latency under load, and rehearse a reindex and node failure |
| Queue and worker services | Magento 2.4.9 requires RabbitMQ 4.3; Saleor needs Celery workers; Medusa runs a separate worker-mode instance for background tasks | Confirm queues drain during a peak simulation, alert on backlog growth, and verify that failed jobs are retried or surfaced |
| Database and cache services | Magento 2.4.9 lists MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, and Redis or Valkey 9; Saleor needs PostgreSQL and Valkey or Redis; Medusa needs PostgreSQL and Redis | Confirm the exact versions against the platform's listed combinations, run failover tests, and review connection pool and memory settings under load |
| Backups and restore | Database, media, search index and configuration backups that match one point in time, plus documented restore steps | Perform a full restore into an isolated environment on a schedule and time the process against the recovery target the business sets |
| Monitoring and alerts | Health checks for the web tier, API, workers, queues, database, cache, search and cache hit rate, with alerts routed to a named owner | Trigger a controlled fault in staging, confirm the alert fires, and check that the runbook gives the on-call engineer the next step |
| Upgrade cadence and support windows | Magento 2.4.9 has standard support through May 31, 2029 (Adobe lifecycle policy); Saleor and Medusa release on their own schedules and need a planned minor-version path | Rehearse each upgrade on a production-sized copy, record the extension and theme results, and confirm the support end date for the chosen line before go-live |
| Extension compatibility | Every third-party module, theme and custom integration must support the target platform version and the required services | Keep a compatibility register with the target version, run automated tests on each extension, and block the upgrade until each item passes |
Accessibility and compliance requirements for the storefront
Accessibility is a requirement of the storefront you build, not a feature the platform ships with. Choosing Magento Open Source, WooCommerce, Saleor or Medusa does not make a store accessible. The theme, the product listing templates, the checkout steps, the account pages, the cart drawer and any third-party widgets all have to be tested against WCAG success criteria once they are in place. Write the requirement into the statement of work as a stated conformance level (for example, WCAG 2.1 Level AA), name the page templates in scope, and decide who fixes defects found in a custom theme versus an extension. Ask each candidate partner how they test keyboard navigation, form errors and focus order on checkout, and whether they run automated scans alongside manual review with assistive technology.
If the store is run by a public entity in the United States, the requirement is set by regulation. The US Department of Justice ADA Title II web rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA. An interim final rule published April 20, 2026 set compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Confirm your population category and whether any commerce function (for example, paying fees or buying licenses) falls within the rule with your counsel, and plan the theme remediation against the earlier date if you are in the larger group. Public entities that sell through an open source store should treat the checkout as in scope from the start.
If you sell to EU consumers, a separate set of obligations applies to e-commerce services, and the microenterprise position and the storefront remediation approach differ from the US rule. Read the dedicated guide on the European Accessibility Act for online shops before you fix the scope, because it covers the dates and exemptions that affect your build. For evidence, keep a dated accessibility statement, the test reports for each template, the remediation tickets with closure dates, and the list of extensions with their known gaps. DeployOpen prepares systems, controls and this evidence for assessments, but it does not issue audit reports, attestations or certifications. Those come from an independent auditor or certification body that you choose and pay directly.
What buyers ask before hiring an implementation partner for ecommerce
What drives the cost of a self-hosted open-source ecommerce build?
Cost follows the written scope: how many systems the store must connect to, how many extensions or custom modules are needed, how the checkout and payment pages are designed, and how much of the hosting and upgrade work is included. Each component has a different payer. Hosting is usually paid to your cloud or data center provider, while the platform software itself is open source, so the license line is zero. Implementation, integration, PCI DSS evidence work and upgrade support are the services you buy. Ask for a quote that separates one-time build work from recurring hosting, monitoring, patching and upgrade work, so you can see what continues after launch.
How long does an ecommerce platform implementation take?
No duration is given here. The timeline comes from the written scope, which should name the platform, the number of storefronts and channels, the catalog and order migration, the ERP and PIM connections, the payment providers and the testing before go-live. Each of those items adds planning and sign-off steps. Ask the partner to show the phases, the dependencies and which items depend on your team's availability, and treat any timeline without a written scope as a starting assumption rather than a commitment.
What does the work need from our own team?
Expect to supply people, not just access. Product data owners must confirm categories, attributes, prices and tax rules. ERP contacts must confirm stock, order status and customer record formats. Someone must hold the accounts and contracts for payment providers and must approve test payments and the checkout design. A business owner needs to sign off on each phase, including the cutover. Ask the partner to name these roles in the scope, with the hours or decision points they expect from each, so delays do not surface late in the project.
Can our team run an open-source ecommerce store without a partner?
Yes, many teams do, provided they have the skills to operate the chosen stack in their own environment. The platform's required components, such as the database, search, caching, queues and web server, must be deployed, patched and monitored. Upgrades must be planned against the vendor's support windows, and extensions must be kept compatible. For example, Adobe lists the supported combinations of PHP, MySQL or MariaDB, OpenSearch and other components for each Magento Open Source release, and only those combinations are supported. Compare that workload with your staff capacity before deciding to build in-house, partner, or buy a hosted service.
Is a SaaS commerce platform cheaper than self-hosting?
It depends on the volume, the features you need and what each model charges for. SaaS platforms typically charge subscription and often transaction fees, while self-hosting moves the cost to hosting, implementation, upgrades and your own operating staff. Neither option is automatically cheaper. The sibling topic on ecommerce platform cost compares build, partner and SaaS models in more detail. Ask any vendor or partner for a five-year view that includes all recurring fees, hosting, patching and PCI DSS work, not only the first year.
How should we compare two implementation quotes?
Compare the written scope before comparing totals. Check that both quotes cover the same platform version, the same integrations, the same number of storefronts, currencies and payment providers, and the same testing and cutover work. Then check what is excluded, such as extension licenses, third-party fees, hosting, monitoring, post-launch support and upgrades. Ask each bidder for the named roles, the acceptance criteria for each phase and how change requests are priced. A lower quote with a thinner scope often moves cost into change requests later.
What should we ask about PCI DSS and payment page scripts before signing?
Ask how the checkout design decides the self-assessment questionnaire that applies, and who manages the scripts that run on payment pages. Ask how script inventory and change detection are handled under the PCI DSS requirements for payment page scripts, and which evidence the partner produces for an assessor. The partner should prepare controls and evidence, but it does not issue the validation or attestation. Your acquirer or qualified assessor makes that determination, so confirm that role in writing.
How to score a platform against the checklist
This sequence turns the requirements list into evidence a buyer can defend, so each candidate platform is scored on the same tests against the same sample catalog, checkout and payment flow before a decision is made.
Write must-have requirements with named owners
Start by turning the checklist into a short list of must-have requirements, each with a named owner on the business or technical side. Cover catalog size, channels and currencies, B2B features, payment providers, PCI DSS scope, ERP and PIM integrations, search, performance, accessibility and upgrade cadence. Each requirement gets a pass condition written in plain words, such as which channels must be live at launch or which ERP order status must sync back to the storefront. The artifact is a requirements register signed off by commerce, finance, security and IT, so no later test can quietly change the bar.
Run a proof of concept on a sample catalog
Load a representative sample of your products, prices, stock levels, customer groups and tax rules into each shortlisted platform, then complete the core purchase journeys end to end. Include at least one B2B price list, one multi-currency order and one return if those are must-haves. The work is done by the implementation partner with your product and commerce staff reviewing results. It is complete when each requirement has a recorded pass, fail or gap, with notes on any extension or custom code needed to close a gap.
Test the payment flow and script inventory
Map every page where card data or payment-related scripts appear, including checkout, payment redirects, iframes and tag managers. Walk this map through with the payment provider and a QSA or internal assessor to confirm which self-assessment questionnaire the chosen checkout design implies and how script management under PCI DSS 6.4.3 and change detection under 11.6.1 would be met. The artifact is a payment page diagram, a script inventory with owners and a written note from the assessor on scope. Confirm the provider's exact responsibilities in writing before accepting the design.
Rehearse one platform upgrade and one extension update
Pick one core version upgrade and one update to a third-party extension or module, then run both in a staging copy of the proof-of-concept store. Record the steps, the commands or configuration changes used, the time the work took in your environment, and any conflicts with custom code. For Magento Open Source, confirm the target version against the published system requirements. The artifact is an upgrade runbook and a log of issues, which shows whether the platform's upgrade cadence and extension model fit your team's capacity to maintain it.
Load test the expected peak in staging
Build a load profile from your expected peak traffic, including browse, search, cart and checkout actions, and run it against a staging environment that matches production architecture, including cache, search, database and queue services. Watch response times, error rates and database behavior at the target load and at a stress level above it. The work is led by the partner and the platform team. It is complete when results are written up against the performance requirement, with any bottleneck and the fix assigned to an owner.
Record the evidence for each requirement
Consolidate the results into one scorecard that lists each requirement, the platform tested, the pass, fail or gap result, the evidence reference and the owner who accepted it. Evidence includes test logs, the payment page diagram, the script inventory, the upgrade runbook, load test reports and accessibility test results against WCAG 2.1 Level AA. Store the scorecard with the requirements register so auditors and internal reviewers can trace each decision to its evidence. The closing artifact is a signed scorecard that supports the platform decision and becomes the baseline for later upgrades and assessments.
How DeployOpen scopes, delivers and supports ecommerce selection and implementation
DeployOpen turns an ecommerce requirements checklist into a written scope for a self-hosted platform inside your own cloud accounts, data centers or air-gapped network. We plan, implement, customize, integrate, harden, back up, upgrade, document and support the platform you choose, and we prepare the controls and evidence that compliance assessments need.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists catalog size, channels, currencies, B2B needs, payment providers and ERP and PIM connections.
- Scope records which payment page design applies and which PCI DSS requirements your team must own.
How we build
- We implement the chosen platform in your environment and configure checkout, payment and tax flows to the agreed requirements.
- Integrations with ERP, PIM, search and marketing tools are built and tested against documented data contracts.
- Security testing of the storefront, APIs and checkout is run before go-live, with findings tracked to closure.
How we hand over
- Handover includes architecture notes, configuration records, runbooks and the test results that back each requirement.
- Your team receives the controls and evidence needed to support a compliance assessment, which an independent auditor performs.
- We confirm with you which upgrade cadence, patch ownership and extension policy will apply after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial delivery.
- Retainers can cover platform patching, backup verification and reviews when vendor releases change supported versions.
- Changes to requirements are handled through a new written scope so cost and timing stay visible to your team.
