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

May 2026 update: PrestaShop has now confirmed to partners that the native one page checkout will ship as a core module in PrestaShop 9.2, with 9.2 itself currently planned for the second half of 2026. We covered that announcement in a shorter news post: PrestaShop 9.2 native One Page Checkout.

Last updated: June 2026.

We've been shipping checkout modules since the PrestaShop 1.6 days, and we've also rebuilt the checkout from scratch on roughly half of our client shops at one point or another. So when PrestaShop's core team announced a native one page checkout at the Live Update on 30 July 2025, we paid attention. Development started in earnest in early 2026 and the first feature flag landed in core a few weeks later.

This is the page we send merchants who ask us: "Should I wait for native OPC, or fix my checkout now?" We sell Checkout Revolution, so we're not neutral. But we run shops too, and we'd rather you read an honest comparison than buy something you don't need.

Three checkout searches that sound the same, three different problems

Before anyone compares anything, untangle these three. We see them confused in support tickets every week.

Native PrestaShop OPC is a future core checkout layout — it doesn't exist in a stable release yet. Checkout Revolution is our full one-page checkout replacement for merchants who can't wait. Express Checkout is a separate, lighter module that adds Apple Pay / Google Pay / PayPal buttons to product and cart pages without touching the existing checkout. They are not the same product, and the comparison table below exists because people regularly buy the wrong one.

What PrestaShop has actually said

The July 2025 Live Update confirmed native OPC was on the roadmap. The February 2026 Core Monthly report confirmed development had started, and the first feature flag landed in pull request #40796.

Reading the PRs and the milestone tags rather than the marketing wording, here's what the public code currently tells us:

• Target release: PrestaShop 9.2 (the open PRs are milestoned for 9.2.0 — not 9.1).
• Theme: the visible work is tied to the modern 9.x checkout stack. Whether classic or custom themes will get a clean upgrade path is something we'll only know from the 9.2 release notes.
• Architecture: hybrid. AJAX for guest initialisation and address-form refresh; payment modules can still redirect or use hosted gateways, the way they do today.
• Guest flow: the current code attaches a valid guest customer to the cart before submit, which is sensible — final UX is not finalised.
• Fallback: the existing multi-step checkout stays as an option.
• Module impact: module authors will need to adapt anything that hooks the checkout flow. The core team has been clear about that.

As of writing, native OPC has not shipped in any stable release. It is behind feature flags, in active development.

Why the checkout layout actually matters

Baymard puts average cart abandonment at around 70%. Plenty of that is window-shopping that no checkout can save, but Baymard's own breakdown attributes 18% of abandonments specifically to a checkout that's too long or too complicated. That's the bucket a one-page layout can move.

The mechanism is simple: all the decisions in front of the customer at once, no inter-step page loads, no spinner between "I've entered my address" and "what shipping options do I have." On a desktop with a fast connection the saving is marginal — a second or two. On a 4G mobile connection, where over half our clients' traffic now lives, a five-step checkout can easily run three to four minutes of cumulative wait. A one-page flow brings that under a minute.

What we see in practice on shops we migrate: a 10–25% drop in cart abandonment, depending on category. Fashion and consumer electronics tend to be at the top of that range. B2B and high-AOV stores at the lower end, because their buyers were already more committed.

This is still what stock PrestaShop checkout looks like.

Screenshots from a real PS9 dev shop we run: personal info, address, shipping, payment — separate steps. Native OPC is interesting because it changes this structure, not because it changes how payment providers work underneath.

One page checkout puts every decision in one frame.

Side by side, the practical difference is obvious: the customer never has to commit to one step before they know what the next step will ask. That's why we discuss one-page checkout as a conversion feature, not as a theme tweak.

Our honest read on native OPC

From what the PRs, core monthlies, and Live Update show, here's the realistic picture.

Where native OPC is going to be great

• Free. Ships with core. No licence, no subscription, no per-shop key. For a lot of shops, that alone makes it the right answer.
• Built by the core team. It will sit inside the order pipeline, the hook system, and Hummingbird's component layer cleanly — no shimming required.
• Maintained with PrestaShop itself. Bug fixes and security patches arrive with every PS release. Anyone who has supported a third-party module across PS 1.7 → 8 → 9 migrations knows what that's worth.
• Modern architecture. Current work uses AJAX where it matters (guest init, address refresh) and leaves payment redirects/3DS/hosted gateways alone, which is the right call.
• Guest identification earlier in the flow. If the implementation lands as drafted, you won't get the late-stage "wait, no, fix your email" surprises that the current multi-step checkout still throws sometimes.

If you're starting a fresh shop on PrestaShop 9.2 with Hummingbird, standard shipping, standard payment methods and no B2B requirements — native OPC is probably the right tool, and we'll say so when clients ask. We don't want to sell modules to people who don't need them.

Where a v1 native feature will be a v1 native feature

Every "1.0" of a core feature ships narrow. This isn't a complaint — it's how every framework we've ever worked on has shipped its first take. The honest limitations to plan around:

• Theme compatibility is genuinely unknown. The public work is tied to the modern 9.x checkout stack. Whether your existing classic/custom theme will need a non-trivial rebuild is something we'll only learn from the final 9.2 migration notes. Budget for the rebuild as a possibility.
• It's 9.2-only. Anything running 1.6, 1.7, 8.x, 9.0 or 9.1 is out. If you're not upgrading before the second half of 2026, native OPC is not on your menu this year.
• No express checkout. Native OPC is a one-page form. Apple Pay / Google Pay / PayPal buttons on product pages and in carts are a different feature entirely — see the express section below. The core team has not announced this as part of the OPC scope.
• Module ecosystem lag. Payment modules, shipping modules, carrier customisations, checkout-step modules — they will all need updates. There's always a transition period after a major UX change in core. Plan for it.
• V1 covers the common path. Custom field management, conditional logic ("hide shipping method X if customer is in country Y"), advanced validation, B2B-style payment restrictions — these aren't day-one features in any first-generation core checkout. They take years to mature.

If you maintain modules or a custom theme, run these greps first

"It loads" is not a compatibility check. Before you commit to migrating to native OPC, find every place your modules or theme touch the checkout. The cheap version is two ripgreps:

rg -n "paymentOptions|displayPayment|actionValidateOrder|actionCarrierProcess|displayBeforeCarrier" modules themes
rg -n "checkout/_partials|order-confirmation|cart-summary|payment.tpl|shipping.tpl" themes modules

Every hit is a candidate for breakage. We've seen payment modules that pass the visible smoke test on the new checkout but quietly fail on a real order because they hooked old markup, listened for old JS events, or relied on a theme override that no longer exists. Always run this on staging first — never on the live shop's first day with the new checkout.

What a mature checkout module gives you today

This is the part where we have to be careful, because Checkout Revolution is ours. We'll keep it factual.

What you actually get from a mature, in-production checkout module today — using Checkout Revolution as the reference because that's what we run on our own client shops:

• Works on every PS version we still support. 1.6 through 9.1, every theme we've tried it on. Your checkout stops being a function of which PrestaShop release you happened to install.
• 30+ payment methods in one module. Apple Pay, Google Pay, PayPal, Klarna, Afterpay, BLIK, Przelewy24, iDEAL, SEPA, Amazon Pay, Link by Stripe, and a long tail of local methods. One module to configure, not 30.
• Express checkout in three places. Apple Pay and Google Pay buttons on product pages, in the cart, and inside the mini-cart drawer — with biometric authentication. The customer never has to see the checkout page at all.
• Shipping inside the Apple Pay / Google Pay sheet. When the customer picks an address in the wallet UI, we calculate shipping rates in real time and feed them back into the sheet. No "next step" for shipping.
• Address auto-creation. Wallet addresses (Apple Pay, Google Pay) are saved straight to the customer's account. No address form for those buyers.
• B2B features. Credit accounts, quote/RFQ workflows with PDF output, company-level management, payment-method restrictions per customer group.
• Risk analysis. Stripe Radar integration for transaction scoring.
• Cart recovery. Webhook-synced abandoned-cart tracking, so you can recover sales rather than just count them.

This isn't a roadmap. It runs today on shops we operate ourselves (modernedusche.de, douchemoderne.fr, blackdeblacks.de) and processes real transactions. We'd rather you know that and decide than have us pretend the comparison is between equals.

Express checkout: the thing native OPC is not

This is the distinction that gets lost in every "should I wait for native OPC?" conversation we have. One page checkout and express checkout are not the same feature.

A one page checkout puts the address, shipping, and payment fields on a single page. The customer still types their address, picks a shipping method, and enters payment details. It's faster than five steps, but it's still a form.

Express checkout skips the form. The customer taps an Apple Pay, Google Pay or PayPal button, authenticates with a fingerprint or Face ID, and the address / payment / shipping preference are pulled straight out of their digital wallet. End-to-end purchase, no characters typed. We see this complete in three to five seconds on real devices.

Checkout Revolution bundles express checkout into the full checkout replacement. Express Checkout is the lighter, separate module if all you want is wallet buttons without touching the checkout page itself. They are different products solving different problems — that's not a marketing line, it's why we kept them as two SKUs.

Express checkout is a separate conversion lever entirely.

Real PrestaShop product page, express checkout button next to Add to cart. This isn't "one page checkout on a product page" — it's a different flow where some customers skip the checkout form completely.

• Product page: tap Apple Pay, authenticate with Face ID, order placed. No cart, no checkout, no forms.
• Cart page: express buttons above the summary. Tap, authenticate, done.
• Mini-cart: the slide-out cart panel has express buttons too — the customer never leaves the page they were browsing.

Native OPC, on every public artefact we've seen, doesn't include any of this. It's a better form. Express on product and cart pages is a module-level feature, and we don't expect it to land in core in the 9.x line.

Decision matrix — Native OPC, Checkout Revolution, or Express Checkout?

Who should wait, who should act now

The honest answer depends on where you are. We try to tell clients exactly this before they buy anything.

Wait for native OPC if:

• You're building a brand-new shop and you won't launch until PrestaShop 9.2 is stable
• You're planning to use Hummingbird v2 from day one
• Your checkout is genuinely standard — basic shipping, common payment methods, no B2B
• You don't need express checkout on product pages
• You're fine waiting for payment, shipping and checkout modules to be updated for the new structure

If most of those are true, save your money. Native OPC is going to be a perfectly good answer for you.

Act now if:

• Your shop is live and losing carts to checkout friction today
• You're on any PS version from 1.6 to 9.1 — and probably won't upgrade in the next six months
• You run any theme other than Hummingbird v2 — classic, custom, 1.7, 8.x
• You want Apple Pay / Google Pay / PayPal on product and cart pages
• You need wide payment coverage beyond cards and PayPal
• You sell B2B and need credit accounts, quotes, or payment restrictions by customer group
• Conversion matters to your P&L this quarter, not in 2027

The pragmatic middle path

For most live shops we work with, the answer is: use a module now, re-evaluate native OPC when 9.2 is actually out. A checkout module isn't a marriage. If 9.2's native OPC covers your needs cleanly, you can switch. What you don't do is leave conversion on the table for six to nine months while you wait for a feature that hasn't shipped.

And even once native OPC is in the wild, the things our module does on top of "form on one page" (express checkout, the long tail of payment methods, B2B flows, cross-version support) don't disappear when 9.2 lands.

The bottom line — said plainly

Native OPC arriving in core is genuinely good for PrestaShop. It raises the floor for every shop that wouldn't otherwise pay for a checkout module, and that's a win we want. We're not here to badmouth it.

But the checkout is the page where money is made or lost on every order, and "we're working on it for next year's release" is not a plan for a shop that's bleeding carts today. If your current checkout is costing you sales, the tools to fix it already exist, they support the PrestaShop version you're actually running, and they cover ground that no v1 core feature can touch yet. That's the trade-off, laid out as honestly as we know how.

FAQ

When is native one page checkout shipping in PrestaShop?

PrestaShop has confirmed to partners that native OPC will ship as a core module in PrestaShop 9.2, which is currently planned for the second half of 2026. As of writing it has not shipped in any stable release — it's behind feature flags and in active development, with the open PRs milestoned for 9.2.0, not 9.1. Roadmap timing is a plan, not a release date, so treat the second-half-of-2026 window as movable.

Should I wait for native OPC or fix my checkout now?

If you're building a brand-new shop, won't launch until 9.2 is stable, plan to use Hummingbird from day one, and your checkout is genuinely standard with no B2B and no need for express buttons — wait, and save your money. If your shop is live and losing carts to checkout friction today, you're on any version from 1.6 to 9.1, you run a classic or custom theme, or conversion matters to your P&L this quarter — act now. For most live shops the pragmatic answer is: use a module now and re-evaluate native OPC once 9.2 is actually out. A checkout module isn't a marriage.

Will native OPC include Apple Pay and Google Pay buttons on product pages?

No, not on every public artefact we've seen. Native OPC is a one-page form — a better checkout layout. Express checkout (wallet buttons on product and cart pages that let a customer skip the form entirely) is a separate feature the core team has not announced as part of OPC scope, and we don't expect it in the 9.x line. If you want express buttons, that stays a module-level feature — Express Checkout on its own, or bundled into Checkout Revolution.

Will native OPC work on my current theme?

Genuinely unknown until the 9.2 release notes land. The public work is tied to the modern 9.x checkout stack, so whether a classic or custom theme gets a clean upgrade path — or needs a non-trivial rebuild — isn't something anyone can promise yet. If you're planning around it, budget for the rebuild as a possibility rather than assuming a drop-in.

How do I check whether native OPC will break my modules?

Don't rely on "it loads." Before migrating, find every place your modules or theme touch the checkout — the cheap version is the two ripgreps in the section above, run on a staging copy. Every hit for paymentOptions, actionValidateOrder, actionCarrierProcess or a theme override of checkout/_partials is a candidate for breakage. We've seen payment modules pass the visible smoke test on a new checkout but quietly fail on a real order because they hooked old markup or listened for old JS events. Never test it for the first time on the live shop.

Related reading

• Checkout Revolution — our full one-page checkout module
• Express Checkout — wallet buttons without replacing the checkout
• PrestaShop 9.2 native One Page Checkout — what the 9.2 version specifically means for merchants and developers
• PrestaShop Checkout Optimization Guide — the concrete changes that move completion rate while you decide
• Why Your Checkout Page Is Losing You Sales — diagnose the leak before you choose a fix
• PrestaShop 9.1 release notes — Hummingbird and multi-carrier changes