E-Commerce Platforms & Shop Systems
Shopware
EU-Made Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by shopware AG · www.shopware.com
Compare with JTL-Shop → Compare with Gambio → Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Shopware scores highest on extensibility and data control and exit, where scores cluster at 7-8: plugins are Symfony bundles and Composer packages with a dependency model, Store API routes are documented as decoratable services, and an open-source Community Edition at € 0 with self-hosting puts code and database under the merchant's control. It scores lowest on tax and legal at 2-4: the pages document a checkout-time tax-provider hook whose sums are used as given, and we found no public information on destination VAT, reverse charge, OSS or e-invoicing handled by the platform itself. Catalog and checkout at 4-6 and operations at 5-6 sit mid-table, with documented variant and state-machine machinery but unproven conversion features and no named carriers. On sovereignty the judges genuinely split, 3-6: the developer credited the imprint's shopware AG registration at Amtsgericht Coesfeld under HRB 11471, VAT ID DE261679493; others found no published subprocessor list and a European data-centre claim scoped to the Intelligence Copilot, with the independently sourced sovereignty attributes returning unknown. Pricing transparency sits at 4-5: tier prices are public, but both commercial tiers are from-prices.
Speaks for it
- Plugins are Symfony bundles and Composer packages that may declare dependencies, and Store API routes are documented as decoratable services for headless builds
- Three state machines cover order, transaction and delivery, natively modelling partial shipments, partial returns and partial refunds, with orders persisted independently of the catalogue
- The open-source Community Edition sits at € 0, with self-hosting offered alongside PaaS and SaaS
- The Migration Assistant is documented in depth — connections, profiles, delta detection by checksum and dedicated media handling
- Tier prices are published with VAT treatment stated exactly — Rise "Ab € 600 /Monat exkl. MwSt.", Evolve "Ab € 2.400 /Monat exkl. MwSt."
Held against it
- German tax work — destination VAT, reverse charge, OSS, e-invoicing — rests on whichever tax app the merchant connects, and we found no public information on the platform handling any of it
- PayPal is the only payment provider named, we found no public information on bundles, guest checkout, promotions or invoice and direct debit, and customer-specific prices appear only in the Beyond tier
- The documented Migration Assistant runs into Shopware; we found no public information on a documented exit path or a data-return commitment
- We found no public information on a subprocessor list or on where checkout data resides for the hosted offerings, and the European data-centre claim is scoped to the Intelligence Copilot
- Rise and Evolve are quoted as from-prices, Beyond is "Individuell", and we found no public information on transaction fees, order or revenue limits or minimum terms, so the annual invoice is not computable from the pages
Best for
- You have a development team and want a deeply customisable, headless-capable shop you can self-host on the open-source Community Edition
- Your order flow involves frequent partial shipments, partial returns and partial refunds that must live in the core state model
- You want structural ownership of code and data rather than a hosted-only platform
Avoid if
- You need maintained German tax correctness out of the box; the platform documents a checkout-time tax-provider hook and trusts the provider's returned sums
- You need customer-specific prices, multi-inventory or subscriptions without the top Beyond tier
- You need the annual invoice computable from published prices; both commercial tiers are quoted as from-prices and Beyond is individually quoted
- Your customisations are plugins and you plan to run on Shopware cloud; the documentation states plugins are not compatible with cloud stores, where apps are required
The scores
Catalogue & checkout
Show reasoningHide reasoning
How this is scored
Products, variants, pricing rules and the path to payment — the part that either converts or does not.
0 — Flat product list with one price and no variants; checkout is a form and one payment method.
3 — Variants and categories with a standard checkout and two or three payment methods, but no bundles, no tiered pricing and no guest checkout worth the name.
5 — Full variant matrix, product bundles, tiered and customer-group pricing, guest checkout, and the payment methods a German shop needs including invoice and direct debit.
8 — Configurable products, per-channel pricing, promotions and vouchers with rules, a checkout that can be customised without a rebuild, and payment via the major providers plus buy-now-pay-later where offered.
10 — Merchandising and checkout are the product: rule-driven pricing and promotions, A/B-testable checkout, multi-currency and multi-language as standard, and conversion features (abandoned cart, one-page checkout) shipped rather than bolted on.
The Merchant
The variant machinery is real — parent-child inheritance, a configurator object, unlimited property groups for filtering — and the payment architecture with synchronous and asynchronous handlers and the redirect URL returned in the API response means checkout can be reshaped without a rebuild. But we found no public information on invoice or direct debit as payment methods, on promotions or voucher rules, on guest checkout or bundles, and customer-specific prices appear only in the top Beyond tier. 1 2 5 6
The B2B Seller
The captured developer pages show a real variant model with parent-child inheritance and a configurator, hierarchical categories, multi-sales-channel availability, and a payment system built on extensible synchronous and asynchronous handlers — but customer-specific prices appear only in the top Beyond tier. I found no public information on bundles, tiered pricing, guest checkout, or invoice and direct debit as payment methods, which is the first thing a German trade buyer checks. 2 5 6
The Developer
The variant model is the real thing — self-referencing parent-child products with a configurator that assembles property groups and variants, hierarchical categories, unlimited property groups for filtering, and products addressable across multiple sales channels. Payment breadth is thin in the captures: PayPal is the only provider named, and I found no public information on bundles, promotions and vouchers with rules, guest checkout, or invoice and direct debit as payment methods. The checkout itself is documented as customisable without a rebuild via the Store API, payment handlers and the state machine, which is what lifts it above the standard tier. 5 6 1 12
The Operations Lead
The variant machinery is real — parent-child inheritance, a configurator assembled for storefront requests, unlimited property groups and multi-category products — and the checkout is documented down to payment handlers with synchronous and asynchronous gateway flows. What the captured pages do not show is bundles, tiered pricing, guest checkout, or German payment methods beyond PayPal; customer-specific prices appear only in the top Beyond tier. Checkout customisation without a rebuild is well evidenced through the plugin and Store API documentation. 2 5 6 12
The Data Protection Officer
Variants are properly modelled — parent-child inheritance, a configurator assembled for each variant product, hierarchical categories — and payments sit on a documented handler architecture with synchronous and asynchronous flows, PayPal the one provider named. We found no public information on bundles, tiered pricing, guest checkout, or German-standard payment methods such as invoice and direct debit; customer-specific prices appear only in the Beyond tier. The checkout is clearly extendable, but the conversion machinery itself is not evidenced. 1 2 5 6
The Skeptic
The variant machinery is genuinely worked — parent-child inheritance, a configurator object over property groups, unlimited properties with filtering — and the payment architecture with synchronous and asynchronous handlers plus a redirect URL returned in the headless API response shows a checkout built to be extended. But I found no public information on bundles, guest checkout, promotions or vouchers, the only payment provider named anywhere is PayPal, and customer-specific prices surface only on the top Beyond plan — good machinery with the conversion features unproven on the captured pages. 5 6 1 2
Tax & German legal correctness
Show reasoningHide reasoning
How this is scored
VAT determination, OSS, B2B reverse charge, and the checkout requirements German law actually imposes — judged on what the platform does, not on a plugin someone could buy.
0 — A single VAT rate applied everywhere; no B2B handling, no country logic, no legal-text handling in checkout.
3 — Per-country VAT rates configurable by hand, net prices for B2B possible with effort, and legal texts as free-form pages.
5 — Automatic VAT by destination and customer type, VAT-ID validation with reverse charge, gross and net display per customer group, and the mandatory checkout elements (order button wording, withdrawal policy, price indications) handled.
8 — OSS thresholds tracked and reported, correct invoicing per case including reverse-charge notes, small-business and third-country handling, and e-invoicing (XRechnung/ZUGFeRD) for B2B orders.
10 — Tax and legal correctness are maintained by the vendor rather than the merchant: rates and thresholds updated as the law moves, OSS reporting produced, every invoice case correct out of the box, and documented conformity a lawyer could review.
The Merchant
What the pages document is a pluggable tax-provider framework: apps registered via manifest are called during checkout in priority order with signed requests, adjusting tax at item, delivery or cart level while Shopware trusts the returned sums. We found no public information on destination-based VAT determination, VAT-ID validation with reverse charge, OSS reporting or e-invoicing handled by the platform itself — the automatic tax path runs through third-party apps rather than the shop system. 7 8
The B2B Seller
The only tax mechanism on the captured pages is an app-based tax provider invoked during checkout with a five-second timeout — a hook a merchant must build or buy, not determination the vendor maintains. I found no public information on VAT-ID validation, reverse charge, gross and net display per customer group, OSS, e-invoicing, or the checkout legal texts German law imposes. 7 8
The Developer
What the developer pages evidence is a tax framework, not maintained correctness: settings under Settings > Tax, and since version 6.5 an app interface where external tax providers are called by priority during checkout, with signed requests, a five-second timeout, and tax sums taken as given by the provider. That delegates German VAT correctness to whoever builds or buys the provider — I found no public information on automatic VAT by destination and customer type, VAT-ID validation with reverse charge, OSS tracking and reporting, e-invoicing, or the mandatory checkout elements on the captured pages. 7 8
The Operations Lead
Tax handling is documented as an app integration point: providers are registered in the administration under Settings > Tax, called by priority during checkout, and Shopware trusts the provider's calculated sums without recalculating them. That is plumbing for automatic VAT determination, not evidence the vendor maintains rates, OSS reporting, reverse charge, VAT-ID validation or e-invoicing. We found no public information on the mandatory German checkout elements such as order button wording, withdrawal policy or price indications. 7 8
The Data Protection Officer
What the platform itself does is expose tax settings in the administration and orchestrate external tax providers — since version 6.5 an app can be called during checkout with signed requests, priority ordering and a five-second timeout, its sums used as-is. The German-law work — destination VAT, OSS, reverse charge with VAT-ID validation, checkout legal texts, e-invoicing — rests on whichever tax app the merchant connects, and we found no public information on any of it being handled by the platform. That is configuration plus an extension point, not maintained correctness. 7 8
The Skeptic
What the developer pages document is a seam, not a service: an app can expose a tax endpoint that is called during checkout by priority with signed requests, and rates are configured by hand under Settings > Tax in the administration. Automatic VAT by destination and customer type, VAT-ID validation with reverse charge, OSS, and e-invoicing are all left to a provider the merchant must build or buy; I found no public information showing the platform handles any German legal case itself. 7 8
Extensibility & developer surface
Show reasoningHide reasoning
How this is scored
Themes, apps, APIs and headless — whether the shop can be shaped to the business, and at what cost in lock-in.
0 — Fixed templates, no app ecosystem, no API.
3 — Theme editing within limits and a small app store; a read-mostly API and no local development story.
5 — Custom themes with a template language, an app or plugin ecosystem, a documented REST API, and webhooks for the core order events.
8 — Full storefront API for headless builds, an extension framework with its own lifecycle, staging environments, version control for themes, and documented rate limits.
10 — A platform a team can own: headless-first APIs, open-source or source-available core, plugin architecture with a real dependency model, local development and CI supported, and upgrade paths that do not orphan customisations.
The Merchant
This is where my investment feels safe: plugins are Composer packages that can declare dependencies and behave as Symfony bundles with their own controllers, services and tests, and the Store API with service-based, decoratable routes gives headless builds a first-class surface, including the headless payment flow. The open-source Community Edition at "Kostenlos € 0" means the code is not hostage, though we found no public information on staging environments, theme version control or documented rate limits. 1 6 9 10
The B2B Seller
This is a platform a development team can work with: plugins are Composer packages extending Symfony bundles that declare dependencies, the Store API is documented down to naming conventions and decorator patterns, the headless payment flow returns the redirect URL inside the API response, and the core is open source with self-hosting. I found no public information on staging environments, theme version control or documented rate limits, and plugins cannot run on cloud stores where only apps are allowed. 1 6 9 10
The Developer
This is where I could live for five years: plugins are Symfony bundles shipped as Composer packages that can declare dependencies — a real dependency model — the Store API is documented down to route decorators and service conventions, the core is open-source with a free Community Edition and self-hosting on my own infrastructure, and even the Migration Assistant is extensible. Two reservations keep it short of the top: the plugin documentation states plugins are not compatible with cloud stores, so moving to cloud means rewriting that customisation path as apps, and I found no public information on version control for themes, CI support, or upgrade paths that carry existing plugins forward. 9 10 1 13
The Operations Lead
This is a developer platform: plugins are Symfony bundles shipped as Composer packages with a real dependency model, the Store API is documented with service-based decoratable routes and named routes, and headless payment flows return the redirect URL in the API response. An open-source core and a free Community Edition mean a team can shape and own the shop. We found no public information on staging environments, theme version control or documented rate limits, which keeps it off the top step. 1 6 9 10
The Data Protection Officer
The developer surface is real: plugins are Symfony bundles and Composer packages with a dependency model, the Store API is a documented service-based route system with decorators, and the payment flow is explicitly designed for headless use. The Community Edition is open source and self-hosted, so a team can run the whole thing. We found no public information on staging environments, theme version control or documented rate limits, and the documentation states plugins are not compatible with the cloud stores, where apps are required instead. 1 6 9 10
The Skeptic
Plugins are Symfony bundles delivered as Composer packages that may declare dependencies, the Store API is a documented headless surface with decorator patterns and naming conventions, and the open-source core can be self-hosted, run on PaaS or SaaS — a real dependency model rather than a walled app store. The pages state plainly that plugins do not run on cloud stores, only apps do, and I found no public information on staging environments, documented rate limits, or upgrade paths for customisations. 9 10 1 6
Order operations & back office
Show reasoningHide reasoning
How this is scored
What happens after checkout: order management, stock, returns, shipping, and the link to ERP or accounting.
0 — An order list and an email; stock is a number nobody trusts, returns are manual.
3 — Order statuses and basic stock, one shipping integration, and returns handled by hand.
5 — Order workflow with partial shipments, multi-warehouse stock, named carrier integrations with label printing, and a returns process in the system.
8 — Multi-channel order intake, automated fulfilment routing, supplier and dropshipping flows, and maintained interfaces to named ERP and accounting systems.
10 — The shop is the front of an operation: real-time stock across channels and warehouses, returns and refunds fully worked including partials, ERP integration the vendor maintains, and operational reporting a merchant runs the business from.
The Merchant
Three configurable state machines model the after-checkout reality properly — partial shipment, returns, partial refunds, chargebacks — and orders persist their own line items and calculated prices independent of the catalogue, with notifications and order history documented. But we found no public information on named carrier integrations with label printing or maintained interfaces to ERP and accounting systems, and the multi-inventory capability sits in the top Beyond tier only. 2 11 12
The B2B Seller
The order model is workflow-oriented with three state machines covering delivery states such as shipped partially and returned partially and transaction states through refunded partially, plus order management, notifications and history extendable via plugins, and Multi-Inventory in the Beyond tier. I found no public information on named carrier integrations with label printing, dropshipping, or maintained interfaces to named ERP and accounting systems — the integration claim covers CRM, payments and shipping only in general terms. 1 2 11 12
The Developer
The order model is workflow-oriented and denormalised so line items and calculated prices persist independently of the catalogue, with state machines that natively cover partial shipments, partial returns and partial refunds across three machines started per order. Multi-inventory appears only in the top Beyond tier, and beyond a generic integration surface for CRM, payments and shipping I found no public information on named carrier integrations with label printing, automated fulfilment routing, dropshipping flows, or maintained interfaces to ERP and accounting systems. 11 12 2 1
The Operations Lead
The order model is built for people who actually ship: three state machines with configurable, API-modifiable transitions, delivery states including shipped-partially and returned-partially, and transaction states including refunded-partially — the partials I need for December are in the core state model, and orders are denormalized with line items and calculated prices persisted independently of the catalogue. We found no public information on named carrier integrations with label printing, maintained ERP or accounting interfaces, dropshipping flows, or a returns workflow beyond the states; multi-inventory appears only in the top Beyond tier, and shipping is named only as an integration category. 1 2 11 12
The Data Protection Officer
The order model is workflow-built: three state machines for order, transaction and delivery with configurable, otherwise blocked transitions, and partial states throughout — shipped partially, returned partially, refunded partially — so partial shipments, returns and refunds are worked into the core. Multi-inventory arrives only with the Beyond tier, and shipping appears as an integration category without named carriers, label printing, or any named ERP or accounting system. We found no public information on fulfilment routing, dropshipping or operational reporting. 1 2 11 12
The Skeptic
The order model is the strongest evidence here: orders are denormalized and persisted independent of the catalogue, three state machines cover delivery states like Shipped partially and transaction states like Refunded partially and Chargeback, and a Documents module sits in the checkout guides. But states are not operations — no carrier is named, no label printing, no returns process beyond state names, no ERP or accounting interface is evidenced, and multi-inventory appears only as a Beyond-plan feature. 11 12 2 1
Data ownership & exit
Show reasoningHide reasoning
How this is scored
Whether the catalogue, customers and order history remain the merchant's: export completeness, hosting choice, and what leaving actually costs.
0 — Export is a partial CSV; order history and customer records cannot leave intact, and hosting is the vendor's alone.
3 — CSV export of products and customers, order history partial, no self-hosting, no documented migration path.
5 — Complete export of catalogue, customers and orders via API or dump, documented deletion, and a stated data-return commitment.
8 — Full-fidelity export including media and order documents, self-hosting or a choice of hosting partner, and no metering that prices a migration out of reach.
10 — Ownership is structural rather than promised: open-source or source-available platform the merchant can run anywhere, database-level access, documented migration in both directions, and contractual data return.
The Merchant
Ownership here is structural rather than promised: an open-source Community Edition and the option to deploy the shop on my own cloud infrastructure mean the data sits where I put it. The Migration Assistant is well documented with dedicated media processing, delta migration and error resolution, but it documents the way in — we found no public information on a comparable documented exit migration or a stated data-return commitment beyond GDPR portability tools. 1 13 14
The B2B Seller
Ownership is structural here: an open-source core with self-hosting as the stated default, and a documented, extensible Migration Assistant with connections, media processing, logging, error resolution and delta handling. That tooling migrates data into Shopware 6; I found no public information on export-out completeness including order documents, or on a contractual data-return commitment. 1 13 14
The Developer
Ownership here is structural rather than promised: the open-source Community Edition at € 0 with self-hosting on my own infrastructure means the shop and its data sit where I control them, and GDPR data-portability tools are claimed. The Migration Assistant is documented in one direction only — into Shopware 6 — and I found no public information on outbound export completeness including media and order documents, database-level export tooling, or a contractual data-return commitment. 1 2 13 14
The Operations Lead
Self-hosting is offered alongside PaaS and SaaS, the core is open source with a free Community Edition, and the Migration Assistant documents media processing, persistent mappings and delta detection by checksum. The documented migration path runs into Shopware rather than out of it; we found no public information on full-fidelity export of order documents or on a contractual data-return commitment when leaving. 1 13 14
The Data Protection Officer
Ownership is partly structural: the Community Edition is open source and self-hosted, orders are denormalised and persisted independently of the catalogue, and numerous data-portability and management tools are claimed. The Migration Assistant is documented in depth — connections, profiles, gateways, dedicated media handling, checksum-based deltas — but the captured pages describe migrating into Shopware; we found no public information on a documented export or exit path out, on deletion executing against order history, or on a data-return commitment. 1 11 14
The Skeptic
Self-hosting on an open-source core with a Community Edition at € 0 is structural ownership — the merchant can run the shop and its database themselves rather than trust a promise. But the documented Migration Assistant runs one way: connections, profiles, premapping, delta detection and media processing are all built to bring data into Shopware 6, and I found no public information on export completeness, documented deletion, or a migration path out. 1 2 14
European sovereignty
panel opinion
panel disagrees
Show reasoningHide reasoning
How this is scored
Where customer and order data live, who the contracting entity is, and which subprocessors sit in the checkout path. Independently sourced by the sovereignty pipeline.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — CDN, analytics, payment routing, support tooling — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, complete subprocessor list published, any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor European, certification published, and a self-hosted option that puts the shop entirely under the merchant's control.
The Merchant
The independent sovereignty review returned no confirmation for jurisdiction, ownership, data residency or subprocessors, and we found no published subprocessor list. The imprint does name a German stock corporation registered at Amtsgericht Coesfeld, and the homepage claims European data centres, but only as the basis for the AI Copilot architecture, which is no guarantee for the checkout path. 1 3 4
The B2B Seller
The captured imprint evidences shopware AG with a German register court, executive board and VAT ID, and self-hosting is the default posture, which is the strongest form of control. European datacentres are named only for the Intelligence Copilot product line, and the independently sourced attributes came back unknown; I found no public information on subprocessors, on data residency for the shop platform itself, or on ownership. 1 3 4
The Developer
The imprint is unambiguous about the contracting entity: shopware AG at Ebbinghoff 10 in Schöppingen, registered at Amtsgericht Coesfeld under HRB 11471, VAT ID DE261679493 — a German stock corporation — alongside a data processing agreement on the EU Standard Contract basis, published ISO 27001 and SOC 2 Type II, European datacenters named for the Copilot architecture, and a self-hosted option that puts the shop entirely under my control. For sovereign end to end, I found no public information on a published subprocessor list or named hosting infrastructure for shop data, and the captured pages leave data residency for the platform itself unconfirmed. 3 4 1
The Operations Lead
The captured pages establish a German contracting entity — shopware AG of Schöppingen, registered at Amtsgericht Coesfeld — with SOC 2 Type II and ISO 27001 claims, a data-processing agreement on the EU standard contractual basis, and self-hosting that puts the shop under the merchant's own control. The European data-centre claim is scoped to the Intelligence Copilot architecture rather than stated for the platform generally. We found no public information on a subprocessor list or on where customer and order data reside for the hosted shops, and the collected sovereignty attributes came back unconfirmed. 1 3 4
The Data Protection Officer
The contracting entity is solidly European — shopware AG, registered at the Amtsgericht Coesfeld, seat in Schöppingen, German VAT ID — and European data centres are claimed alongside self-hosting, PaaS and SaaS, with a data processing agreement on the EU Commission's standard contractual clauses plus ISO 27001 and SOC 2 Type II stated. We found no public information on a subprocessor list, on where the CDN, analytics or payment routing sit, or on confirmed data residence for the hosted offerings beyond a data-centre claim made in the context of the Copilot. A German entity with an unnamed processing chain — and a compliance statement that privacy standards in the USA and further markets are also met — leaves the checkout path unaccounted for. 1 3 4
The Skeptic
The imprint names shopware AG registered at Amtsgericht Coesfeld with a Schöppingen address — a German contracting entity with published DPA terms based on the EU standard contractual clauses. But the European-datacenter claim is scoped to the Intelligence Copilot architecture rather than shop hosting generally, and I found no public information on a subprocessor list, named hosting infrastructure, or vendor ownership; SOC 2 Type II alongside ISO 27001 evidences audits, not where checkout data sits. 3 1 4
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a merchant can compute the real annual cost — licence, transaction fees, apps, hosting — from public pages alone. The category where the headline price is least often the invoice.
0 — No public prices at all; every tier is a sales conversation.
3 — A monthly headline exists, but transaction fees, mandatory apps or hosting costs are unstated — the invoice is unknowable from the page.
5 — Tier prices public with billing period stated and transaction fees given, but at least one commonly needed piece (a required app, hosting, payment gateway rate) is unpriced.
8 — Every tier priced publicly including transaction or revenue-share rates, order or GMV limits, and the cost of the extensions most shops need; VAT treatment and minimum term stated.
10 — Complete price computability: annual cost derivable for a given order volume and GMV including licence, transaction fees, hosting and typical extensions — and for open-source platforms, an honest statement that the licence is free and where the money actually goes.
The Merchant
Every named tier is public with period and VAT treatment stated — Community Edition "Kostenlos € 0", Rise "Ab € 600 /Monat exkl. MwSt.", Evolve "Ab € 2.400 /Monat exkl. MwSt." — and the AI add-on carries a per-plan price. But the Beyond tier is "Individuell", and we found no public information on transaction or revenue-share fees, order or revenue limits, or minimum terms, so the true annual cost for a shop of my size cannot be worked out from the pages alone. 1 2
The B2B Seller
Tier prices are public with VAT treatment stated — "Ab € 600 /Monat exkl. MwSt.", "Ab € 2.400 /Monat exkl. MwSt.", Community Edition at €0 — and the Intelligence+ add-on carries plan-specific monthly figures. But both commercial tiers are quoted as floors, Beyond is "Individuell", and I found no public information on transaction fees, minimum terms, or order and revenue limits, so a real annual invoice cannot be computed from the page. 1 2
The Developer
More is public than with most: Community Edition at € 0, Rise ab € 600 /Monat exkl. MwSt., Evolve ab € 2.400 /Monat exkl. MwSt., add-on prices such as Shopware Intelligence+ at € 19 /Monat exkl. MwSt., and the VAT treatment stated outright. But Rise and Evolve are starting-from prices, Beyond is priced Individuell, the Nexus add-on sits in a free introductory phase running to 1 October 2026 with a non-binding review limit of 10,000 requests per customer month — and I found no public information on transaction or revenue-share fees, hosting costs, order or revenue limits, or minimum terms, so the real annual invoice is not computable from the page. 2 4 1
The Operations Lead
Tier prices are public with the billing period and VAT treatment stated exactly — "Ab € 600 /Monat exkl. MwSt.", "Ab € 2.400 /Monat exkl. MwSt.", Community Edition at € 0 — and the Intelligence+ add-on is priced per plan at € 29 or € 19 per month. But the tier prices are from-prices, the top Beyond tier is "Individuell", and we found no public information on transaction or revenue-share fees, order or GMV limits, minimum terms, or hosting costs, so the real annual invoice is not computable from the pages. 1 2 4
The Data Protection Officer
Tier prices are public with VAT treatment stated — Community Edition at € 0, Rise "Ab € 600 /Monat exkl. MwSt.", Evolve "Ab € 2.400 /Monat exkl. MwSt." — and the Intelligence+ add-on is priced per tier, with Nexus in a free introductory phase carrying a non-binding review limit of 10,000 requests per customer and calendar month. From-pricing and an individually quoted Beyond tier mean the annual invoice is not computable from the page, and we found no public information on transaction or revenue-share fees, order or revenue limits, minimum terms, or the cost of the extensions most shops need beyond that one add-on. 1 2
The Skeptic
The ladder is public and honest about VAT — Community Edition at € 0, Rise "Ab € 600 /Monat exkl. MwSt.", Evolve "Ab € 2.400 /Monat exkl. MwSt.", Beyond "Individuell" — but every number that decides the invoice is missing: no transaction or revenue-share fees, no order or GMV limits, no hosting costs, no minimum term, and no stated basis for what pushes a "from" price upward. Nexus carries a "Kostenlose Einführungsphase" planned until 1 October 2026 with a non-binding review limit of 10,000 requests per customer and calendar month — a price signal with no price attached. 2 1 4
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined ⚠ unverified | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined ⚠ unverified | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 31 Aug 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Data residency, Legal entity. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 28 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 21 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 10 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 8 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 5 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (14)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.shopware.com Checked 5 Oct 2026 Details →
- 2 Pricing www.shopware.com Checked 5 Oct 2026 +2 earlier captures: 15 Sep 2026, 31 Aug 2026 Details →
- 3 Imprint www.shopware.com Checked 5 Oct 2026 Details →
- 4 Privacy policy www.shopware.com Checked 5 Oct 2026 +2 earlier captures: 15 Sep 2026, 11 Sep 2026 Details →
- 5 Catalogue & checkout — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 6 Catalogue & checkout — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 7 Tax & German legal correctness — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 8 Tax & German legal correctness — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 9 Extensibility & developer surface — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 10 Extensibility & developer surface — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 11 Order operations & back office — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 12 Order operations & back office — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 13 Data ownership & exit — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →
- 14 Data ownership & exit — found from sitemap developer.shopware.com Checked 5 Oct 2026 Details →