PrestaShop in 2026: Strong Merchant Features, but What Does the Module Economy Cost?

PrestaShop earns a shortlist slot on the strength of a genuinely free multistore and multi-language back office, not on the strength of the phrase “open source” by itself — the module marketplace and an admittedly unfinished Symfony rewrite are where the real invoice shows up. This pass checked PrestaShop 9.1.4 (published 2026-06-04, alongside a parallel 8.2.7 maintenance line) against prestashop.com, devdocs.prestashop-project.org, the GitHub Advisory Database and the PrestaShop/PrestaShop repository, targeting PHP 8.1 on the documented 8.1-8.5 supported range with MySQL 5.7+ or MariaDB 10.2+.

Who should shortlist PrestaShop in 2026 (and who shouldn’t)

The hypothesis worth testing is specific: PrestaShop’s internationalised back office plus a large Addons marketplace add up to its strongest fit, on paper. The rest of this review checks that claim against pricing, architecture and API evidence rather than accepting it from the marketing page.

Current release: 9.1.4 stable, published 2026-06-04, alongside a parallel 8.2.7 maintenance release kept in step for merchants who haven’t moved onto the Symfony 6.4 (opens in a new tab) line yet.

Best fit: agencies and merchants, especially in Europe, who need native multi-store, multi-language and multi-currency management without a paid-plan gate on any of it. That’s a real, verifiable strength covered in full in section 5.

Weak fit sits at two ends of this series’ named alternatives. A team that wants WooCommerce’s larger, WordPress-native plugin pool gets more coverage per euro there. A team that wants a hosted cart with zero module-compatibility risk — no marketplace, no upgrade-breakage exposure — is asking for something PrestaShop’s architecture doesn’t offer at any price.

The failure boundary this review tests is module dependence and upgrade friction: how much of PrestaShop’s feature depth relies on third-party Addons code, and how safely that code survives a core upgrade. Sections 2 through 4 build the evidence for that boundary; section 6 shows what it costs in practice when patch stewardship on a bundled module fails.

flowchart TD
    A[Store requirements] --> B{Need native multi-store, multi-language, multi-currency, no paid gate?}
    B -- No --> C[Consider WooCommerce's larger plugin pool, or a hosted cart instead]
    B -- Yes --> D{Comfortable testing module compatibility on every core upgrade?}
    D -- No --> E[Look elsewhere - the Symfony migration is still incomplete]
    D -- Yes --> F{Priced the specific Addons modules you need?}
    F -- Not yet --> G[Price them first - the core is free, the modules are not]
    F -- Yes --> H[PrestaShop is a rational shortlist candidate]

What actually drives PrestaShop’s total cost of ownership

“Free and open source” undersells PrestaShop’s licensing, and overstates what it means for the invoice. The core is licensed under OSL-3.0 (opens in a new tab) with no fee attached, but PrestaShop’s own native modules and default themes carry a separate AFL-3.0 licence (opens in a new tab), per the project’s own maintainers’ guide. Two open licences on two different sets of files: “the core is free” and “everything PrestaShop ships is free” are not the same claim.

PrestaShop also sells hosting directly. Its own Hosted plan (opens in a new tab) runs EUR 24/month billed annually (EUR 290/year) or EUR 29/month with no commitment, with a 14-day free trial. It bundles Gandi-based hosting at 50GB, automatic VAT handling and support six days a week — a real alternative to self-hosting the Classic download, not a mandatory tier.

The bigger open question is the Addons marketplace (opens in a new tab), which PrestaShop’s own Hosted-offer page lists at over 3,200 modules and themes. What that page doesn’t give is individual module pricing or the seller commission split (opens in a new tab) — addons.prestashop.com returned HTTP 403 to every automated fetch attempt this pass, so both figures stay unconfirmed rather than invented.

Realistic total cost of ownership, then, breaks into three lines: a zero-cost OSL-3.0 core, hosting (self-managed, or the vendor’s EUR 24-29/month plan), and whatever paid Addons modules the store actually needs for payment gateways, SEO or B2B logic. That third line is the one this pass could not price directly — treat it as the biggest unknown in any PrestaShop budget until you check it in a browser yourself.

PrestaShop 9’s Symfony migration, and why it’s still not finished

PrestaShop 9 runs on Symfony 6.4 LTS (opens in a new tab), security-supported until November 2027, and requires PHP 8.1 as a floor, with 8.1 through 8.5 the currently documented supported range. That’s a current, well-supported foundation on paper.

Underneath it, PrestaShop’s own migration strategy documentation (opens in a new tab) describes something less finished: a deliberately partial, phased rewrite. Legacy ObjectModel business logic still powers much of the platform beneath the newer Symfony controllers, forms and CQRS handlers that a developer meets first.

The project states plainly that legacy code is removed only once a replacement handler is fully plugged in — an acknowledged, ongoing trade-off, not a modernisation the team claims to have finished. That’s the actual mechanism behind the upgrade friction this review’s hypothesis names in section 1, not an editorial guess about a mature codebase.

The consequence lands on module authors and the merchants who depend on them. A third-party module that hooks into a legacy code path can lose that hook without warning once PrestaShop 9 replaces the path underneath it — a module’s version number climbing to “9-compatible” doesn’t guarantee the specific hook it uses survived the swap.

Mitigate it the way you’d mitigate any framework migration seam: check a candidate module’s changelog for an explicit PrestaShop 9 compatibility statement, not just a bumped version number, and test the actual upgrade against a staging clone of the store before trusting either one.

flowchart TB
    subgraph PS9[PrestaShop 9 request]
        SC[Symfony controller / form / CQRS handler]
        LOM[Legacy ObjectModel business logic]
        SC --> LOM
    end
    MOD[Third-party module hook] -.->|targets a legacy code path| LOM
    LOM -.->|replaced once a Symfony handler is fully plugged in| GONE[Hook silently stops firing]

Does PrestaShop have a REST API? Two systems, one still incomplete

Yes, but as two separate systems, not one. The older Webservice API (opens in a new tab) is a Basic-Auth CRUD REST surface over /api/, covering products, orders, customers, carts and stock. The newer Admin API (opens in a new tab), introduced with PrestaShop 9, is built on API Platform 3 with a materially different design: OAuth2 Client Credentials Grant authentication and CQRS-style commands, instead of Basic Auth and direct resource CRUD.

PrestaShop’s own documentation is direct about where the newer API stands: its “essential foundations are operational”, with more endpoints and improvements still planned. That’s a vendor statement of an incomplete resource surface, not a complete one dressed up in cautious language.

The consequence: an integration scoped as “PrestaShop has a REST API” stalls the moment a team assumes full CRUD parity with a platform that ships one mature API, when PrestaShop ships two and the newer, better-authenticated one admits it isn’t finished. Decide explicitly which generation an integration targets, then check the exact resources and actions needed against that API’s current documentation — not the other one’s.

Confirm token issuance and one documented endpoint against a disposable 9.1.4 install before committing an integration timeline to either API:

# Admin API: request an OAuth2 access token (Client Credentials Grant).
# Confirm the exact token route, scope names and endpoint paths against
# the current Admin API docs before running this in a real project -
# the API surface is still partial and documented as evolving.
curl -X POST "https://<YOUR_DOMAIN>/admin-api/access_token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "grant_type=client_credentials" \
  --data "client_id=<YOUR_CLIENT_ID>" \
  --data "client_secret=<YOUR_CLIENT_SECRET>" \
  --data "scope=hook_read"

# Then call one documented resource endpoint with the returned bearer token.
curl "https://<YOUR_DOMAIN>/admin-api/hooks" \
  -H "Authorization: Bearer <ACCESS_TOKEN>"

Expected output:

You should now see: a bearer token from the first call and a JSON response from the second, confirming which Admin API resources actually respond on a real 9.1.4 install rather than assuming coverage from the documentation index alone.

Multistore and internationalisation: PrestaShop’s real free-core strength

PrestaShop’s own multistore documentation (opens in a new tab) confirms native multi-shop management from a single installation: settings and inventory can be shared or overridden per-store, per-group or globally, switched through a context selector in the back office. No plugin, no upsell screen in the way.

That’s a genuine, unpaid differentiator. Elsewhere in this series, equivalent multi-store capability sits behind a paid plan tier on more than one competing platform — PrestaShop ships it in the free core, full stop.

The B2B question is where this section has to hedge rather than assert. PrestaShop publishes its own B2B guide (opens in a new tab) on its blog, but this pass could not confirm from primary product documentation which specific B2B features — tax-exempt accounts, tiered pricing — ship in the free core versus needing a paid Addons module. A blog post describing a capability and a back office shipping it by default are different claims, and the gap between them belongs in your budget, not your assumptions.

Test both claims yourself before committing to either. Spin up a proof-of-concept install, configure two stores sharing one catalogue, and check the exact data-sharing behaviour against what you actually need — then do the same for any specific B2B requirement, rather than taking the marketing page’s word for what’s included.

PrestaShop’s production concern: an RCE in a module it bundles by default

CVE-2026-54159 (opens in a new tab) (GHSA-m5f5-28qr-9g9r, CVSS 10.0) is about as bad as an advisory gets: a critical, unauthenticated PHP object-injection vulnerability in PrestaShop’s own bundled ps_facetedsearch module, versions 3.0.0 through 4.0.3. An attacker exploits it with a crafted front-office filter request, no login required, and can write a webshell to the server.

It’s patched in ps_facetedsearch 4.0.4 — which is why PrestaShop shipped 9.1.4 and 8.2.7 the same week (opens in a new tab) as no-core-change maintenance releases built around exactly this fix.

It isn’t the only recent example of the back office itself being in scope. CVE-2026-44212 (opens in a new tab) (CVSS 9.3) was a stored XSS in the back-office customer-service view, triggered by a crafted public contact-form submission and executed the moment a staff member opened the thread. It’s patched, in 8.2.6 and 9.1.1, and it’s history now — but it establishes that staff-facing surfaces are part of the attack surface too, not only the storefront.

The consequence for a merchant’s threat model: real risk includes PrestaShop’s own bundled first-party modules, not only the paid third-party ones bought from Addons. Confirm ps_facetedsearch is at 4.0.4 or later and core is at 8.2.6/9.1.1 or later, and don’t assume a module that shipped “by default” carries less risk than one you paid for.

sequenceDiagram
    participant Attacker
    participant Storefront as Front-office filter request
    participant Module as ps_facetedsearch (<= 4.0.3)
    participant Server
    Attacker->>Storefront: Crafted filter-block request, no login required
    Storefront->>Module: PHP object deserialized into filter-block cache
    Module->>Server: Object injection triggers arbitrary write
    Server-->>Attacker: Webshell written, RCE achieved
    Note over Module: Patched in ps_facetedsearch 4.0.4, shipped in 9.1.4 / 8.2.7

PrestaShop’s modernity and AI/agent-readiness scores, with the working shown

Modernity score, component by component

Weighted total: (8×0.20) + (4×0.20) + (4×0.15) + (5×0.15) + (5×0.15) + (6×0.10) + (7×0.05) = 5.45, rounding to 5.5/10.

AI/agent readiness score, component by component

Weighted total: (5×0.30) + (6×0.20) + (6×0.15) + (3×0.15) + (6×0.10) + (4×0.05) + (7×0.05) = 5.20, rounding to 5.2/10.

The PrestaShop MCP Server (opens in a new tab) listing, read on 28 July 2026, settles most of what the blog post leaves vague. Version 1.0.3, published November 2025 and last updated 26 June 2026, developed by PrestaShop’s own verified account, compatible with 8.2 to 9.1, and free. Its write surface is real rather than read-only: updating product descriptions and multi-language SEO fields, adding, replacing and reordering product images, setting the cover image, alongside order and customer retrieval.

Three details on that page deserve more weight than the marketing copy around them.

It is not multistore-compatible — the listing’s compatibility block says so outright. Multistore is one of PrestaShop’s headline differentiators, covered earlier in this review, so the official AI integration not supporting it is a genuine gap rather than a footnote.

It is proprietary. PrestaShop’s own listing states the module “is distributed under a proprietary license” and “may not be modified, shared, reused, or distributed without PrestaShop’s written permission”. On a platform whose appeal is open source, the official agent bridge is the one component you cannot fork or audit freely.

And it wants admin access: the listing notes your AI application may require it, on top of requiring ps_mbo, ps_accounts and ps_eventbus. An agent with catalogue and image write permissions through an admin-scoped connection is a real blast radius, and nothing on the page describes narrower scopes.

Reception is muted so far — 3,169 downloads and a 3.1 average across 10 ratings. Ten ratings is far too few to conclude anything about quality, but it does say this is early-stage tooling rather than a proven integration path.

The score moves from 6 to 7 on confirmed first-party status and zero cost, held back from higher by the multistore gap and the licence.

The Admin API’s live endpoint coverage still needs a hands-on test before the API rows above are settled, consistent with this series’ evidence-box requirement. The series’ own caution applies here too: a mature platform mid-migration can still score reasonably on modernity if its boundaries and release discipline are sound, independent of how old parts of the stack are — PrestaShop’s release clarity and runtime currency carry its modernity score further than its still-splitting API surface would suggest on its own.

Run the five-question proof-of-concept before you commit to PrestaShop

Run these five questions against your own project before signing off on PrestaShop, not after:

1. Feature fit. Does your store genuinely need PrestaShop’s native multi-language, multi-currency, multi-store back office, or would a simpler cart or WooCommerce’s larger plugin pool serve the same need at lower module spend?
2. Module cost. Have you priced the specific Addons modules — payment, SEO, B2B — your store needs directly on addons.prestashop.com in a browser, since automated pricing checks were blocked this pass?
3. Upgrade safety. Have you tested a staging-clone upgrade path for your critical third-party modules against PrestaShop 9, given the acknowledged incomplete Symfony migration?
4. API scope. Have you decided which API generation — Webservice or Admin API — your integration needs, and confirmed the specific endpoints exist today rather than assuming full coverage?
5. Patch status. Is ps_facetedsearch patched to 4.0.4 or later, is core at 8.2.6/9.1.1 or later, and who owns tracking PrestaShop/PrestaShop (opens in a new tab)’s security advisories going forward?

You should now see: a completed checklist with a documented answer against your own project for each of the five questions, ready to bring into a platform-selection decision.

Limitations

This review doesn’t include a hands-on Admin API integration test, a live multistore data-sharing test or a sampled set of real Addons module prices. Sections 2 and 4 describe procedures to run, not completed runs, and their outputs are marked as pending.

The adoption figures split by how they were obtained. PrestaShop’s W3Techs share (opens in a new tab) — 0.7% of CMS-known websites and 2.9% of ecommerce systems as of July 2026 — was read directly from the source page. The Europe-weighted claim that France, Spain and Italy are its largest national markets, sourced to 6sense (opens in a new tab), came from a search summary rather than a page load, and needs reconfirmation before it counts as fact.

The MCP module details above were read in a browser, because addons.prestashop.com returns 403 to automated fetch. Module prices and the seller commission split were not, and remain open. Re-check that host yourself rather than assuming its block still applies by the time you read this.