A merchant-focused review of PrestaShop’s new one-page checkout, its upgrade methodology, and the widening divide between development priorities and ecommerce reality.
By Fred, PrestaHeroes — El Patrón on the PrestaShop forum
I may be one of the last remaining U.S.-based PrestaShop agencies. I have worked with the platform for many years and watched PrestaShop repeatedly damage its own position—not only by losing market share, but by making existing merchants pay for technical decisions that provide them with very little direct business value.
PrestaShop announced its native one-page checkout for PrestaShop 9.2 using the word “finally.” That word is revealing. It effectively admits that checkout—arguably the most important part of an ecommerce platform—has been inadequate for years.
Betas are expected to have defects. The more serious issue is that the product vision itself still falls short. Moving contact information, addresses, delivery, carriers, and payment onto one continuously updated URL is an architectural improvement. It does not automatically produce a modern checkout.
A modern checkout should immediately answer the customer’s most important questions: What am I buying? What is the total? Where is it being delivered? When will it arrive? How can I pay? What is the minimum information required to complete the purchase?
Instead, PrestaShop’s published design remains a long, vertically sequential form. The final payment action sits well below the initial viewport, while legal text, optional fields, and account-related details occupy valuable space earlier in the journey.
The more accurate description is a single-URL checkout. “Conversion-first” should be a measured commercial outcome supported by usability testing, mobile completion times, abandonment data, and controlled conversion comparisons. It should not be a marketing synonym for AJAX.
PrestaShop frequently refers to “the community,” but in practice there are two largely separate communities.
Its priorities are code architecture, Symfony versions, APIs, pull requests, automated tests, deprecations, and technical compatibility.
Its priorities are orders, checkout, shipping, payments, promotions, reporting, affordable upgrades, and keeping the store operational.
These groups rarely cross. GitHub contributors generally are not following merchant forum discussions closely enough to see the operational cost of their decisions. Most merchants cannot reproduce an issue in a development environment, identify the responsible component, create a clean test case, or debate the architecture that caused the problem.
Open-source software should involve community testing. But open source is normally vetted by an informed development community before ordinary end users are expected to depend on it.
A development community can test code quality, APIs, upgrade scripts, and controlled compatibility scenarios. It cannot replace structured commercial validation across:
In the current model, a technical change is approved and released. Merchants encounter the real-world consequences. They report problems in the forum, where volunteers usually cannot change the core product. The original developers may never see the discussion. The merchant must then pay an agency or developer to diagnose, override, replace, or work around the released software.
Merchants see an upgrade notice in the Back Office and reasonably assume the newer release is safer, more capable, and commercially better. Many do not know that the first question should be:
A major PrestaShop upgrade can require replacement themes, updated modules, rewritten overrides, integration work, and complete regression testing. The merchant may spend thousands and accept meaningful production risk.
At the end, the visible return may be little more than:
Technical modernization is necessary, but it is not the same as ecommerce innovation. A newer framework does not automatically reduce checkout abandonment, improve merchandising, simplify order management, or help the merchant retain customers.
Compatibility resets also create another market for updated modules, themes, subscriptions, and services. I am not claiming this is the deliberate purpose of the upgrade strategy, but it is unquestionably one of its economic consequences.
The move from PrestaShop 1.6 to 1.7 was especially damaging. For many established merchants, it was not a routine software upgrade. It was a partial rebuild that devalued prior investment in themes, modules, overrides, integrations, and agency knowledge.
When staying requires nearly the same budget, disruption, and risk as changing platforms, the merchant eventually asks:
That is how a platform loses loyal merchants. It makes remaining almost as expensive and uncertain as leaving.
PrestaShop continues to confuse three different achievements:
A cleaner checkout architecture is welcome. Newer PHP support is necessary. Better APIs may help future developers. But merchants do not operate Symfony projects. They operate businesses.
They need checkout, shipping, payments, promotions, merchandising, reporting, and upgrades that produce measurable commercial value without putting the store at unnecessary risk.
PrestaShop continues to externalize the cost of connecting development decisions to ecommerce reality. The merchant pays for the upgrade, pays for compatibility, pays to discover the problems, and then pays again to make the released software commercially usable.
PrestaShop announcement: Introducing One Page Checkout in PrestaShop 9.2
About the author
Fred is the founder of PrestaHeroes and is known as “El Patrón” on the PrestaShop forum. He has supported PrestaShop merchants, upgrades, performance projects, and custom development since 2010.
This is an independent opinion based on long-term agency experience supporting PrestaShop merchants. PrestaShop is a trademark of its respective owner.