PrestaShop Is Building a Native One Page Checkout — Should You Wait or Act Now?

There is a question every PrestaShop merchant with a leaky checkout is now asking: PrestaShop is building a native one-page checkout into the core — so should you wait for it, or fix your checkout now? This post is a decision framework, not a feature list. It assumes you already know what a one-page checkout is and why it converts better than a stepped flow (if you don't, start with one-page checkout for PrestaShop). The only thing we're settling here is timing: wait, or act.

We've shipped checkout modules since the PrestaShop 1.6 days and we sell a one-page checkout module ourselves, so we're not neutral. But we run shops too, and we'd rather hand you an honest framework than sell you something you don't need. By the end of this you should be able to put your own store in one of three buckets and stop agonising over the announcement.

First, what's actually been announced

PrestaShop confirmed native one-page checkout (OPC) on the roadmap at its July 2025 Live Update, and the February 2026 Core Monthly report confirmed development had started, with the first work landing behind a feature flag. The target release is PrestaShop 9.2 — the open work is milestoned for 9.2, not 9.1 — and 9.2 itself is currently planned for the second half of 2026. As of writing, native OPC has not shipped in any stable release; it lives behind feature flags in active development. For the announcement details and what the public pull requests reveal about architecture and theme impact, we keep a dedicated news post: PrestaShop 9.2 native one-page checkout.

That single fact — "not in a stable release, targeted for late 2026" — is the hinge the whole decision turns on. Everything below is about what that timeline means for your store specifically.

The decision in one screen

Run your store through these three filters in order. The first one that fits is your answer.

The rest of this post is the reasoning behind those three rows, so you can defend the call to yourself (or a client) rather than take our word for it.

The hidden cost of "wait" is the waiting itself

"Wait for the free native feature" sounds obviously correct until you price the wait. The checkout is the one page where every visitor has already decided to buy — friction there leaks orders that were yours to lose. So the real comparison isn't "free native OPC vs a paid module." It's "free native OPC in late 2026, after you upgrade, after your modules catch up vs orders recovered every week between now and then."

For a shop with meaningful checkout abandonment, several months of leaked orders usually dwarfs the price of a module. That's not a pitch — it's arithmetic you can do with your own numbers. Pull your cart-to-order conversion rate, estimate the share of drop-off that's checkout friction rather than window-shopping (for the full taxonomy of why people leave, see the 12 reasons people abandon carts), and multiply by your average order value and your monthly checkout starts. If that number over six to nine months is larger than a one-off module licence, "wait" is the expensive option, not the cheap one.

If you're not sure how much of your drop-off is fixable checkout friction versus pricing or trust issues, diagnose before you decide: why your checkout page is losing you sales walks through isolating the real leak.

What "wait" actually gets you — honestly

We want native OPC to be good; it raises the floor for every shop that would never pay for a checkout module. So here's the genuinely strong case for waiting, not a strawman.

• It's free and ships with core. No licence, no per-shop key. For a standard shop, that alone can make it the right answer.
• It's built by the core team. It will sit inside the order pipeline and the hook system cleanly, with no third-party shimming, and security patches arrive with every PrestaShop release. Anyone who has carried a checkout module across the 1.7 to 8 to 9 migrations knows what that maintenance guarantee is worth.
• The architecture choices look right. The public work uses AJAX where it matters (guest initialisation, address-form refresh) and leaves payment redirects, 3DS and hosted gateways alone — which is the correct call, because that's the part you don't want a checkout rewrite touching.

If you're spinning up a fresh 9.2 shop later this year with a standard theme, standard shipping and common payment methods, native OPC is probably the right tool and we'll say so. We don't want to sell modules to people who don't need them.

What "wait" won't get you — the v1 reality

Every "1.0" of a core feature ships narrow. That's not a criticism; it's how every framework ships its first take. The honest limitations to plan around:

• It's 9.2-only. Anything on 1.6, 1.7, 8.x, 9.0 or 9.1 is excluded. If you're not upgrading before the second half of 2026, native OPC simply isn't on your menu this year.
• Theme compatibility is unknown. The visible work is tied to the modern 9.x checkout stack. Whether your existing classic or custom theme needs a non-trivial rebuild is something we'll only learn from the final 9.2 migration notes — budget for that rebuild as a possibility, not a certainty.
• Module ecosystem lag. Payment modules, carriers, checkout-step modules — they'll all need updates for the new structure, and there's always a transition window after a major UX change in core. Plan for it.
• It's a one-page form, not express checkout. Wallet buttons (Apple Pay, Google Pay, PayPal) on product and cart pages are a different feature the core team has not announced as part of OPC scope. If that's what you actually want, see express checkout — it's not the same thing as a one-page form, and confusing the two is the single most common mistake we see in this decision.
• V1 covers the common B2C path. Conditional logic, advanced validation, B2B payment restrictions and quote workflows aren't day-one features in any first-generation core checkout. They take years to mature.

If you maintain modules or a custom theme, test before you trust

"It loads" is not a compatibility check. Before you bet a migration on native OPC, find every place your modules or theme touch the checkout. On a staging copy, search your modules and themes directories for the checkout hooks and templates that a UX rewrite is most likely to disturb — payment-option and carrier hooks (paymentOptions, displayPayment — the legacy 1.6-only payment hook replaced by paymentOptions in 1.7+ — actionValidateOrder, actionCarrierUpdate and displayCarrierExtraContent, plus displayCarrierList on 1.6) and the checkout partial templates (the checkout/_partials tree, payment.tpl and shipping.tpl — the core name, which some themes rename). Every hit is a candidate for breakage. We've seen payment modules pass a visible smoke test on a new checkout yet quietly fail on a real order because they hooked old markup or listened for old JS events. Always exercise this on staging with a real test order — never discover it on the live shop's first day.

Why "act now" is a real option, not just impatience

The reason "act now" is even on the table is that getting a genuine one-page checkout onto a current PrestaShop store no longer requires waiting for core or paying for custom development that breaks at the next upgrade. A maintained checkout module turns the stepped native flow into a true single-page flow across the versions you're actually running — no theme surgery, no core edits, so it survives upgrades.

This is where we have to be careful, because our Checkout Revolution module is one of those modules and we built it for exactly this "can't wait, won't fork the theme" situation. We rebuilt it from the ground up for the single-page flow — the story is in Checkout Revolution 3.0. So what does the module route get you that "wait" can't? It works today, on the version you're on, and it covers the ground a v1 core feature won't: wallet/express buttons on product and cart pages, broad payment-method coverage, and B2B checkout logic. For a side-by-side of how a module compares to the platform's own checkout and to other paid options, see PrestaShop checkout process modules and alternatives.

Crucially, choosing a module now is not a marriage. If 9.2's native OPC later covers your needs cleanly, you switch. What you avoid by acting is leaving conversion on the table for six to nine months while you wait for a feature that hasn't shipped — and the express, payment-coverage and B2B capabilities you'd be buying don't evaporate when 9.2 lands anyway.

The pragmatic middle path most live shops land on

For the majority of live shops we work with, the answer to "wait or act" is neither purely one nor the other: act now with a module, then re-evaluate native OPC when 9.2 is actually out. You stop the bleeding this quarter, you keep the capabilities core won't have at v1, and you reserve the right to migrate to free native OPC later if it turns out to cover you. The only shops for whom "pure wait" clearly wins are greenfield builds that genuinely won't launch until 9.2 is stable.

Whichever you choose, the other levers still apply

The wait-or-act question is only about the one-page structure. Several decisions affect conversion no matter which route you take, and each has its own home in this cluster rather than a rushed paragraph here:

• Guest checkout vs forced registration — make guest the default and offer the account after the order: what the data says about forced registration.
• Mobile — a one-page layout lives or dies on tap targets and input types on a phone: mobile checkout optimization.
• Recovering the ones who still leave — even a perfect checkout loses some carts; an email sequence wins a share back: abandoned-cart emails and the automation that runs them.
• The wider playbook — for the full, ordered checklist of checkout fixes beyond layout, see the PrestaShop checkout optimization guide and proven strategies for reducing cart abandonment.

Measure the call you make

Whichever bucket you land in, decide with numbers, not vibes — and don't trust three days of data. Before changing anything, record four figures from your analytics: cart-to-order conversion rate, checkout abandonment rate (started checkout but didn't finish), average time to complete checkout, and mobile-versus-desktop conversion. After you act — or after you upgrade to native OPC — compare the same four over at least 30 days and a few hundred orders, enough volume to see a real trend rather than the week-to-week noise that fools merchants into reverting a change that was actually working.

The bottom line, said plainly

Native OPC arriving in core is genuinely good for PrestaShop, and we're not here to badmouth it. But "we're working on it for next year's release" is not a plan for a shop bleeding carts today. If your checkout is standard and you're starting fresh on 9.2 later this year, wait — you'll likely get a perfectly good one-page checkout for free. If your shop is live now, on a version that won't see native OPC this year, and the leaked orders are adding up, act: the tools to fix it already exist, support the version you're actually running, and cover ground no v1 core feature can touch yet. That's the trade-off, laid out as honestly as we know how — now put your store in one of the three buckets and stop waiting on a release date.