E-Commerce Platforms & Shop Systems
OpenCart
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by OpenCart · www.opencart.com
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
OpenCart at a glance
- Vendor
- OpenCart
- Headquarters
- Not stated on the vendor’s pages as of 3 Nov 2026
- Data hosting
- Not stated on the vendor’s pages as of 3 Nov 2026
- Free plan
- Not stated on the vendor’s pages as of 3 Nov 2026
- Panel verdict
- The AI panel rates OpenCart 3/5, the mean of 6 judges. OpenCart is a free open-source e-commerce platform under GPLv3 (version 4.1.0.4). how scores are made
- As of
- Vendor pages captured 3 Nov 2026; evaluated by the panel 3 Nov 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
OpenCart is a free open-source e-commerce platform under GPLv3 (version 4.1.0.4). Its strongest criterion is data control and exit at 7 to 8, where judges call ownership structural rather than promised: the merchant runs the code on their own stack with a MariaDB database. Operations is uniform at 6 — a working order hub and a returns flow covering partial refunds, but no public information on carrier label printing, multi-location stock or ERP and accounting interfaces. Tax and legal is the weakest at a uniform 4: a configurable geo-zone VAT engine, yet no public information on VAT ID validation, reverse charge, OSS reporting or German checkout duties. The judges genuinely split on sovereignty, scores 0 to 3: five of six report every dimension as unknown on the captured pages, while the B2B seller scored 3 because self-hosting leaves data location to the merchant. Checkout coverage is thin — the default bundle ships bank transfer and checkout on delivery, with PayPal named only as an example extension.
Speaks for it
- Data control and exit scores 7 to 8, with GPLv3 code the merchant runs on their own MariaDB database
- Returns are documented end to end: configurable reasons and statuses, full and partial refunds, store credit, exchange and repair, plus return analytics
- The catalogue supports variants with their own pricing and stock, quantity-tier and customer-group discounts, special pricing, and multi-store, multi-language products
- Extensibility scores 6 to 7 on a documented developer surface: Twig templating, events hooks, OCMOD modifications, an admin extension installer and a Docker development environment
- Order handling covers editing existing orders, manual phone-order creation with a chosen payment method, status-change emails and bulk invoice printing
Held against it
- Tax and legal sits uniformly at 4: VAT rules are assembled by the merchant, and we found no public information on VAT ID validation, reverse charge, OSS reporting or German checkout requirements
- The bundled payment gateways are bank transfer and checkout on delivery, with PayPal named only as an example of an installable extension type
- We found no public information on legal entity jurisdiction, data residency, hosting options or a data processing agreement, and sovereignty scores range from 0 to 3
- Theme overrides live in the database with no built-in revert and no file locking between administrators, so concurrent edits resolve last save wins
- We found no public information on export tooling or a documented migration path in either direction, and the migration guidance warns to include the theme table in the backup
Best for
- You want structural ownership of your shop: GPLv3 code you run on your own infrastructure with a MariaDB database you hold
- Your team builds its own customisation on a documented surface of Twig themes, events hooks and OCMOD modifications, with a Docker development environment
- You sell through a complex catalogue of variants, per-option pricing, quantity tiers and customer-group pricing across multiple stores and languages
- Your back office depends on manual order creation and a complete returns flow covering full and partial refunds, store credit and return analytics
Avoid if
- You expect German-market legal duties handled for you: the tax engine is merchant-assembled and the captured pages give no public information on VAT ID validation, reverse charge, OSS reporting or German checkout requirements
- You need conversion-ready checkout on day one: the documented default bundle ships bank transfer and checkout on delivery, and the merchant judge found no public information on guest checkout, abandoned-cart recovery, buy-now-pay-later, invoice or direct debit
- Your team manages templates through version control: theme overrides live in the database with no built-in revert and no locking between administrators, so concurrent edits resolve last save wins
The scores
| Criterion | Panel median |
|---|---|
| Catalogue & checkout | 3 of 5 |
| Tax & German legal correctness | 2 of 5 |
| Extensibility & developer surface | 3.5 of 5 |
| Order operations & back office | 3 of 5 |
| Data ownership & exit | 3.5 of 5 |
| European sovereignty | 1.5 of 5 |
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 — Not a shop: no product catalogue and no checkout of its own.
3 — A product catalogue with categories and a checkout that takes payment through at least one provider.
5 — Products with variants, discounts or vouchers, guest checkout, and several payment methods including those German buyers expect (PayPal, invoice or direct debit) through named providers.
8 — Tiered and customer-group pricing, bundles or configurable products, rule-based promotions, per-channel or per-market pricing, abandoned-cart recovery, a checkout customisable without a rebuild, and 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 pricing core I sell on is there — variants with their own prices and stock, quantity-tier discounts with date ranges and customer-group targeting, special prices for seasonal and member-only sales, multi-language products across multiple stores — and the web-based theme editor means checkout templates can be changed from the admin without a rebuild. The conversion machinery is what I could not find: the captured pages say nothing about abandoned-cart recovery, buy-now-pay-later or guest checkout, and the only payment methods shown are bundled bank transfer and cash on delivery, with PayPal named merely as an example gateway — I found nothing on invoice or direct debit, which German customers ask for first. 2 3 6 7
The B2B Seller
Options with per-option pricing, true master-product variants, and discounts tiered by quantity and customer group with date ranges and store assignment are documented — the raw material for a customer-specific trade price list exists. The bundled payment gateways are bank transfer and checkout on delivery, with PayPal only named as an example of what an extension can integrate; we found no public information on guest checkout, abandoned-cart recovery, buy-now-pay-later, or the payment methods German buyers expect. 2 3 6
The Developer
Variants with per-variant pricing and inventory, quantity-tier and customer-group discounts with date ranges and store assignment, and per-option price and weight handling are all documented in the product form. Payment is evidenced mainly as bank transfer and checkout on delivery in the default bundle, with PayPal named only as an example of what a payment extension can integrate; we found no public information on guest checkout, vouchers, abandoned-cart recovery or buy-now-pay-later. That places it solidly above the mid-level definition but short of rule-driven merchandising and shipped conversion features. 2 3 6
The Operations Lead
Products carry variants and per-option pricing, multiple identifiers, quantity-tier and customer-group discounts, special pricing with date ranges, multi-store assignment and multi-language content — a genuinely solid catalogue. The payment gateways documented as shipped by default are bank transfer and checkout on delivery, with PayPal named only as an example of what an extension can integrate; we found no public information on guest checkout or German-expected methods such as invoice or direct debit. 2 3 6 8
The Data Protection Officer
The catalogue is richly documented: variants, per-option pricing, quantity-tier discounts, customer-group pricing, coupons, reward points and multi-store, multi-language assignment, with bank transfer and cash-on-delivery bundled and gateways such as PayPal documented as extension examples. The checkout path itself is thinly covered: we found no public information on guest checkout, abandoned-cart recovery or buy-now-pay-later, and with a checkout full of third-party gateways I would want far more about that path before trusting it with customer data. 2 3 6 8
The Skeptic
The catalogue side is genuinely strong: variants, per-option pricing, quantity tiers, customer-group pricing, special pricing and per-store discounts are all documented, and coupons appear in order handling. The checkout side is thin — the default bundle ships bank transfer and checkout on delivery, with PayPal named only as an example of an installable extension type, and we found no public information on guest checkout, German payment methods, abandoned-cart recovery or buy-now-pay-later in the captured pages. 2 3 6 8
Tax & German legal correctness
Show reasoningHide reasoning
How this is scored
VAT determination, OSS, B2B reverse charge, invoicing, and the checkout requirements German law imposes (Button-Lösung, Widerrufsrecht, Preisangabenverordnung) — judged on what the platform documents it does or ships as a maintained extension.
0 — No tax handling at all; prices carry no VAT logic and the merchant calculates tax outside the platform.
3 — VAT rates configurable per country or product, with prices shown gross or net and legal texts placed as pages in the checkout.
5 — VAT by destination country with gross and net display per customer group, B2B with VAT ID and reverse charge, and the German checkout requirements (order button wording, withdrawal policy, price indications) handled by the platform or a named official extension.
8 — VIES validation of VAT IDs, OSS thresholds tracked or OSS reporting data provided, invoices issued from orders with correct content 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
This is a serious VAT engine — rates tied to geo zones, tax classes with priority and cumulative combinations, a calculation basis of shipping, payment or store address, customer-group-restricted rates, and a payment-address rule for digital goods. But nothing in the captured pages covers VAT ID validation, reverse charge for B2B, OSS reporting, e-invoicing, or the German checkout duties of order-button wording, withdrawal policy and price indication — so the legal burden of a German shop stays on my desk rather than being lifted by the platform. 4 5 8
The B2B Seller
The tax machinery is solid and merchant-configured: geo-zone rates with a destination basis (shipping, payment or store address), priority-ordered cumulative rates, and tax rates restrictable by customer group with "Wholesale" and "Retail" given as examples — enough to separate trade from consumer treatment. But we found no public information on VAT-ID validation, reverse charge, OSS reporting data, or the German checkout requirements (order button wording, withdrawal policy, price indications); invoices can be generated from orders, yet their content per tax case is not documented. 4 5 8
The Developer
Tax is a proper engine: percentage or fixed rates tied to geo zones, restrictable per customer group, combined into tax classes that apply in priority order and can be based on shipping, payment or store address, with geo zones even suggested for EU VAT MOSS-style digital tax regions. We found no public information on VAT-ID validation, B2B reverse charge, OSS reporting, gross and net display per customer group, or the German checkout requirements such as order button wording, withdrawal policy and price indications; invoices can be generated and printed but their legally correct content per case is not documented. 4 5 8
The Operations Lead
VAT is properly configurable: rates per geo zone as percentage or fixed amounts, optionally restricted to customer groups, combined in tax classes with priority and cumulative behaviour, a tax basis of shipping, payment or store address, and explicit mention of geo zones for EU VAT MOSS. We found no public information on VAT ID validation with reverse charge, OSS reporting data, or the German checkout and invoicing requirements — invoice generation exists as a bulk action, but nothing documents whether the invoice content is legally complete. 3 4 5 8
The Data Protection Officer
VAT rates are configurable per geo zone with optional restriction to customer groups, the tax basis is selectable between shipping, payment and store address, geo zones are suggested for EU digital-tax regions, and invoices can be printed from orders. We found no public information on VIES validation of VAT IDs, B2B reverse charge, OSS reporting, e-invoicing or the German checkout requirements such as order-button wording and price indications, so the legal correctness rests on the merchant's own configuration. 3 4 5 8
The Skeptic
Tax rates by geo zone with priority ordering, customer-group restriction and a destination basis (shipping, payment or store address) are documented, and geo zones are even suggested for EU VAT MOSS — but that is the merchant assembling the rules themselves. We found no public information on VAT ID validation, reverse charge, OSS tracking or reporting, e-invoicing, or the German checkout requirements, and invoice generation is documented without any statement of legally correct content. 4 5 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 — A closed shop builder: no themes to edit, no apps or plugins and no API.
3 — Themes adjustable in an editor and a set of apps or plugins to add features.
5 — Custom themes with a template language or code access, an app or plugin ecosystem, and a documented API with webhooks for order events.
8 — A storefront API for headless builds, an extension framework with its own lifecycle, staging or development 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
A developer team can own this shop: GPLv3 source, custom themes in their own directory, a Twig theme editor in the admin with per-store overrides, an extension installer with packaging rules, events hooks and OCMOD for core modifications. The captured pages document no storefront API for headless builds, no webhooks for order events, no theme version control — the theme editor explicitly carries no revert button — and no rate limits. 1 6 7
The B2B Seller
This is a platform a team can get under: GPLv3 source, a Docker-based local environment with switchable PHP versions, Twig templating, an events system with hooks such as before-cart-add, OCMOD for core modifications, and packaged extensions with installer metadata and a contribution workflow gated by PHPStan and php-cs-fixer. We found no public information on a storefront or headless API, webhooks for order events, or documented rate limits. 1 6 7
The Developer
This is a platform a team can work in: GPLv3 source, a Docker local development environment with switchable PHP versions and optional Redis or PostgreSQL, Twig code access with custom theme directories, an MVC-L extension pattern, an events hook system (for example before cart add), OCMOD XML for modifications, an admin installer with packaging rules, and PHPStan plus code-style gates on contributions. We found no public information on a storefront API for headless builds, webhooks for order events, or a dependency model between extensions. And the upgrade story worries me: overrides live in the database, the theme editor has no revert button and no file locking (last save wins), admin templates cannot be overridden, and a store migration must remember to include the theme table in the backup — customisation debt waiting for a future migration. 1 6 7
The Operations Lead
A GPLv3 codebase with a Docker local development environment, switchable PHP version and optional Redis, Memcached or PostgreSQL is a platform a team can actually own, and the Twig template system, events hooks and OCMOD packaging form a real extension surface. We found no public information on a storefront or headless API, webhooks or documented rate limits, and the web theme editor keeps overrides in the database with no revert button and no file locking between administrators, which cuts against clean version control. 1 6 7
The Data Protection Officer
The GPLv3 open-source core, Twig templating with both a web-based editor and a custom theme directory, an events-and-OCMOD extension model that avoids core edits, a documented extension packaging and installer lifecycle, and a Docker development environment make this a platform a team can shape and run locally. We found no public information on a documented storefront API, webhooks for order events, headless operation or rate limits. 1 6 7
The Skeptic
GPLv3 source, Twig custom themes, a structured extension system with install.json, MVC-L, events and OCMOD, and a Docker development environment are real and documented. Nothing captures a storefront API or webhooks for external order events, and the theme editor actively works against version control: overrides live in the database, there is no built-in revert, and multiple administrators editing the same template means last save wins. 1 6 7
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 — No order handling in the product; orders leave as emails or exports to be processed elsewhere.
3 — An order list with statuses, stock counts per product, and shipping rates set up in the shop.
5 — Order management with status emails, stock tracking, named carrier integrations or label printing, and refunds or returns handled in the system.
8 — Partial shipments and partial refunds, multi-warehouse or multi-location stock, multi-channel or marketplace order intake, fulfilment routing, dropshipping, and maintained interfaces to named ERP and accounting systems (DATEV among them for German merchants).
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
After checkout this holds up well: status emails to customers, editing of customer details, products, totals and shipping after the sale, bulk invoice printing, manual phone orders, subscriptions, and a returns flow that goes as far as partial refunds, store credit, configurable reasons and return-rate analytics. I found no public information on partial shipments, multi-location stock, marketplace order intake, or maintained links to ERP and accounting systems such as DATEV, which is where my back office would need it. 3 8 9
The B2B Seller
Orders are a proper back office — filtering, bulk status updates and invoice printing, manual order creation with payment method choice, full editing of customer, products, totals and shipping, status-change emails, subscriptions and reward points — and returns are genuinely worked, with configurable reasons, refund, credit, exchange, repair and replacement actions including partial refunds, plus return analytics. We found no public information on partial shipments, multi-location stock, carrier label printing, or maintained ERP and accounting interfaces such as DATEV. 8 9 3
The Developer
The back office is real: eight order statuses with filtering, bulk status updates and invoice printing, editing of customer data, products, totals and shipping on existing orders, status-change emails, manual order creation with a payment method, subscription and reward-point tracking, and stock subtraction with out-of-stock status and backorder settings. Returns are unusually well worked — customer or admin initiated, configurable reasons, full and partial refunds, store credit, exchange and repair, plus return analytics. We found no public information on label printing or confirmed carrier integrations (UPS appears only as an example of extension types), partial shipments, multi-warehouse stock, or maintained ERP and accounting interfaces such as DATEV. 3 6 8 9
The Operations Lead
The back office is real: full order statuses, editing of customer, products, totals and shipping, manual phone orders with a chosen payment method, status-change emails, bulk invoice printing and subscription tracking, and the returns side is properly worked — configurable reasons, a status flow, automated notifications, analytics, and full or partial refunds, which is the first thing I check before December. We found no public information on partial shipments, multi-warehouse stock, carrier label printing, or maintained interfaces to ERP and accounting systems; shipping methods and UPS appear only as examples of extension types. 3 6 8 9
The Data Protection Officer
Order management is well evidenced: a central order hub with full statuses, editing of customer details, products, totals and shipping, manual order creation, bulk invoice printing, status-change emails and subscription handling, plus a returns system covering full and partial refunds, store credit, exchange and repair with return analytics. We found no public information on named carrier integrations or label printing, multi-warehouse stock, marketplace order intake or interfaces to ERP and accounting systems such as DATEV. 3 8 9
The Skeptic
Orders are documented as a full working hub — editing, manual creation, status-change emails, bulk invoice printing, subscription tracking — and returns are worked through completely with statuses, configurable reasons, full and partial refunds and return analytics. We found no public information on carrier integrations or label printing (UPS appears only as an example extension type), multi-location stock, marketplace intake, or interfaces to ERP or accounting systems such as DATEV. 3 6 8 9
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 — The terms state that the merchant's data cannot be exported or is not returned on cancellation.
3 — CSV export of products and customers, or of orders, from the admin.
5 — Export of catalogue, customers and orders documented (CSV, API or dump), with data deletion or return on cancellation stated in the terms or help centre.
8 — Full-fidelity export including media and order documents, a documented migration path in and out, 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 is structural rather than promised: GPLv3 code the merchant runs on their own MariaDB database, with template overrides stored in that database where they can be disabled at will. The captured pages show no export tooling and no documented migration path in or out — only a warning that a store migration must include the theme table in the backup — which keeps it short of the top. 1 7
The B2B Seller
Ownership is structural rather than promised: GPLv3 code the merchant runs on their own stack with a MariaDB service, so catalogue, customers and order history sit in the merchant's own database. The documentation warns that theme overrides live in the database and must be included in migration backups; we found no documented import or export tooling or migration guide in either direction on the captured pages. 1 7
The Developer
Ownership is structural rather than promised: GPLv3-licensed source the merchant runs on their own stack, a MariaDB database they hold, and migration handled at the database level, with the documented caveat that overrides are stored in the theme table and must be included in any migration backup. We found no public information on a documented migration path in and out or export tooling beyond the self-managed database, which keeps this short of the top definition. 1 7
The Operations Lead
Ownership is structural rather than promised: the GPLv3 licence makes the merchant's copy theirs to run anywhere, the data sits in the merchant's own MariaDB database, and the migration guidance speaks plainly of including the theme table in your database backup. We found no public information on export tooling for catalogue, customers and orders, or on contractual data return on cancellation. 1 7
The Data Protection Officer
Ownership is structural rather than promised: the platform is free under GPLv3, the merchant runs the database in the documented environment, and theme overrides and settings live in the database with explicit guidance to include them in migration backups. We found no public information on export tooling for catalogue, customers and order documents, or on contractual data return on cancellation, so an exit rests on the merchant's own database work. 1 7
The Skeptic
Ownership is structural rather than promised: GPLv3, free download, and a stack the merchant runs themselves with MariaDB, so the catalogue and order history sit in the merchant's own database. But the captured pages document no export tooling or migration path in either direction, and the warning that theme overrides live in a database table you must remember to include in a backup shows that leaving cleanly depends on the operator's diligence. 1 7
European sovereignty
panel opinion
n/r
n/r
n/r
n/r
n/r
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. Dimensions the evidence does not establish are unknown, not non-EU.
0 — Proven non-EU on every dimension the evidence covers: non-EU vendor and contracting entity and non-EU hosting, with no EU option stated.
3 — One European element proven — an EU hosting option, an EU contracting entity or EU representative, or a published DPA — with the rest of the chain unstated.
5 — EU hosting stated as standard or selectable and an EU contracting entity or EU representative, with a DPA offered; the subprocessor chain (CDN, analytics, payment routing, support tooling) is unstated or partly non-EU.
8 — EU hosting on named infrastructure, EU contracting entity, subprocessor list published with locations, 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 not rated — no public information
I found no public information on European sovereignty in the captured pages — nothing on the vendor's jurisdiction, where customer and order data would live, hosting options, or a data-processing agreement; the published source code settles nothing about who runs the infrastructure. 1 4 8
The B2B Seller
The captured repository shows a self-hosted platform running on the merchant's own infrastructure, with no vendor service sitting in the checkout path, so where customer data resides is the merchant's decision. We found no public information on the contracting entity's jurisdiction, data-residency commitments, a DPA, or any subprocessor locations. 1
The Developer not rated — no public information
We found no public information on the contracting entity's jurisdiction, data residency, hosting options, or a data-processing agreement in the captured pages, so no sovereignty dimension is established either way — unknown, not non-European. The repository page we read confirms the licence but not who sits behind the checkout path or where order data is processed. 1
The Operations Lead not rated — no public information
We found no public information on the vendor's jurisdiction, where customer and order data are hosted, a data processing agreement, or the subprocessor chain in the checkout path — every sovereignty dimension is unresolved on the captured pages. The repository page we read shows only a free open-source licence, which settles nothing about the vendor or hosting chain. 1
The Data Protection Officer not rated — no public information
We found no public information on the vendor's jurisdiction or contracting entity, hosting or data-residency options, a data-processing agreement, or the subprocessor chain behind CDN, analytics and payment routing; every sovereignty dimension is unknown in the captured pages. Unknown is not non-European, so I score nothing here and report it as unevidenced. 1
The Skeptic not rated — no public information
We found no public information on the vendor's legal jurisdiction, data residency, hosting arrangements, a data processing agreement or any subprocessor in the checkout path — every sovereignty dimension is unknown on the captured pages. The code repository confirms free open-source software, which speaks to who can run it but tells a buyer nothing about who processes data or where; I therefore report this criterion as unevidenced rather than score it. 1
Pricing transparency
not rated — the vendor publishes no price
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 public "from" price or one priced tier.
5 — Prices for the main tiers public with the billing period stated and the main inclusions per tier listed.
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
The licence is stated plainly as a free open-source platform under GPLv3, so licence cost is computable at zero, with no transaction or revenue-share fee appearing anywhere in the captures. What I could not compute is where the money actually goes — marketplace extension prices, hosting and support are absent from the captured pages, and those are the costs a real shop carries. 1 6
The B2B Seller
The licence is stated plainly — "a free open source ecommerce platform" — so the annual licence cost is zero and derivable from public pages, and no tiers hide behind a sales conversation. What the pages do not show is where the money actually goes: no extension marketplace prices, support tiers or hosting guidance, so the real annual cost of a live shop is not computable from what we read. 1 6
The Developer
The licence is honestly stated as free and open source, so the licence line of an annual budget is fully public. We found no public information on where the money actually goes — marketplace extension prices, commercial support or typical hosting costs are not priced on the captured pages — and for a shop built mainly from extensions that is the number a buyer still cannot compute. 1 6
The Operations Lead
The licence is publicly stated as free and open source, so the headline cost is honest: zero. We found no public information on where the money actually goes — extension marketplace pricing, paid support or hosting costs do not appear on the captured pages — so a merchant cannot compute a real annual total from these pages alone. 1
The Data Protection Officer
The captured pages state plainly that the platform is free and open source under GPLv3, which makes the licence cost transparent and, for an open-source platform, is the honest statement about where the licence money goes. We found no public information on the cost of typical extensions, themes, hosting or paid support, so the real annual cost of a running shop cannot be computed from these captures alone. 1 6
The Skeptic
The licence is stated honestly and publicly as free open source under GPLv3, so there are no headline games in the licence line itself. But we found no public information in the captured pages on hosting costs or marketplace extension prices, which is where the real annual invoice lives for a self-hosted platform, so a merchant cannot compute their true yearly cost from these pages alone. 1
European sovereignty — proven facts
0 of 6 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 | — | uncited Report an error |
|---|---|---|---|
| Hosting location | Not determined | — | uncited Report an error |
| Hosting options | Not determined ⚠ unverified | — | uncited Report an error |
| Open source | Not determined ⚠ unverified | — | uncited Report an error |
| Data processing agreement | Not determined | — | uncited Report an error |
| Transfer impact assessment | Not determined | — | uncited Report an error |
Questions about OpenCart
Is OpenCart European?
Not determined: the vendor’s pages as captured do not say where OpenCart is based.
Where does OpenCart store data?
Not stated on the vendor’s pages as of 3 Nov 2026.
Does OpenCart have a free plan?
Not stated on the vendor’s pages as of 3 Nov 2026.
What are the best alternatives to OpenCart?
As of 3 Nov 2026, the panel rates Shopify (3/5), Sylius (3/5) and OXID eSales (3/5) highest among the other 27 E-Commerce Platforms & Shop Systems products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is OXID eSales (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: OpenCart alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 3 Nov 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Hosting options, Open source. 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.
- We found no public information on pricing on the pages we read (github.com/opencart/opencart, docs.opencart.com/admin-interface/overview/products/adding-products, docs.opencart.com/admin-interface/overview/products/product-form-tabs, docs.opencart.com/admin-interface/system/localization/tax-rates, docs.opencart.com/admin-interface/system/localization/tax-classes, docs.opencart.com/developer-guide/extensions and 3 more). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- We found no public information on compliance on the pages we read (github.com/opencart/opencart, docs.opencart.com/admin-interface/overview/products/adding-products, docs.opencart.com/admin-interface/overview/products/product-form-tabs, docs.opencart.com/admin-interface/system/localization/tax-rates, docs.opencart.com/admin-interface/system/localization/tax-classes, docs.opencart.com/developer-guide/extensions and 3 more). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- 2 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
- 2 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
Sources (9)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Code repository (open-source licence) — found from the homepage github.com Checked 3 Nov 2026 Details →
- 2 Catalogue & checkout — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 3 Catalogue & checkout — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 4 Tax & German legal correctness — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 5 Tax & German legal correctness — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 6 Extensibility & developer surface — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 7 Extensibility & developer surface — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 8 Order operations & back office — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →
- 9 Order operations & back office — found from sitemap docs.opencart.com Checked 3 Nov 2026 Details →