PrestaShop 9.2 native One Page Checkout: what merchants and developers should know

Last updated: June 2026.

Update, May 2026: PrestaShop has told partners that a native One Page Checkout (OPC) module is planned for PrestaShop 9.2, with the official 9.2 release currently slated for the second half of 2026. For the first time, a genuine single-page checkout is being built into the platform itself rather than bolted on by a module or a theme rebuild.

That is good news for the ecosystem. Checkout has long been the one area where PrestaShop merchants reached for a third-party module, custom theme work, or both. But "is native OPC coming?" is the wrong question to plan around. The useful questions are concrete: what does the public code actually do today, what are its limits, and what should a merchant or a module developer change now because of it? This post answers those from the source, not the marketing roadmap.

If you want the broader picture of how to get a one-page checkout onto PrestaShop today across every available route, start with one-page checkout for PrestaShop and the wider checkout optimization guide. This article is narrower on purpose: it is about the 9.2 native build specifically.

The short version

Native OPC is real engineering, not a roadmap bullet. PrestaShop core merged a pull request (#40796) that adds the OPC feature flag, and the module itself ships as a separate public repository, ps_onepagecheckout. So there are two moving parts: a hook/contract in core (the actionCheckoutBuildProcess hook) and a module that consumes it.

The catch: the module repository currently describes the project as under heavy development. That is the single most important planning fact in this post. Merchants should treat 9.2 native OPC as something to watch and test on staging, not a stable feature to wait for with a broken checkout still live. Developers should hold off on firm compatibility assumptions until the technical contracts settle.

How the native checkout differs from today's default

Today's default checkout, the same architecture across PrestaShop 1.7, 8.x and 9.0–9.1. Already lives on a single URL through the order controller, but it reveals itself one step at a time. Each step is its own class: CheckoutPersonalInformationStep, CheckoutAddressesStep, CheckoutDeliveryStep and CheckoutPaymentStep. A step stays collapsed until the one before it is complete. One page, four gates. We unpacked why those gates leak orders in PrestaShop native one-page checkout (OPC).

The 9.2 native module replaces that step sequence with a single combined step. Instead of personal info, then addresses, then delivery, then payment unfolding in turn, the customer sees the checkout as one screen. Crucially, it does this from inside PrestaShop's own checkout process rather than as a separate front-end app. Which is what makes the compatibility questions below matter.

What the public code actually does

Reading the current ps_onepagecheckout module, a handful of concrete capabilities stand out. These are the pieces a merchant or developer should understand before forming an opinion:

• Checkout-process injection. The module registers the actionCheckoutBuildProcess hook, which is the core contract for checkout-process injection. That hook lets the module supply its own checkout process in place of the default stepped one, cleanly, without overriding the order controller.
• A single checkout step. Rather than four step classes, the implementation builds one combined one-page step. That is the actual mechanism behind "one page", not CSS hiding steps, but a different process definition.
• Guest initialization over AJAX. There is an AJAX endpoint that can create or reuse a guest customer once the email and required consents are valid, attaching that customer to the cart before final submission.
• Address-form refresh over AJAX. A second AJAX endpoint rebuilds the address form when it needs to change, for example after the customer picks a different country, which can change required fields and tax behaviour.
• Standard payment-option discovery. The checkout still uses PrestaShop's normal payment-option mechanism, so existing payment modules remain part of the flow rather than being bypassed.

That last point is the architectural reassurance. Native OPC keeps the checkout inside PrestaShop instead of forking it into a standalone app. The trade-off is that compatibility work genuinely matters: payment modules, carrier modules, checkout hooks and theme templates all now meet on the same screen at the same time.

Capabilities vs limits: what native OPC is and isn't

The most common misconception is that "one-page checkout" means "fully AJAX, no redirects, pay like Apple Pay." It does not. Here is the honest scope, side by side.

On payments specifically: a payment module can still redirect to a gateway, a hosted payment page, a 3D Secure step, a wallet flow or a bank confirmation page. That is normal for e-commerce and not a flaw. One-page checkout reduces the friction before payment; it does not replace the payment redirect. Making the payment itself a one-tap action is a different feature. That is express/wallet checkout, covered in express checkout.

The guest-checkout plumbing (why the boring details matter)

Guest handling is where a one-page checkout quietly succeeds or breaks, because everything now happens in one screen lifecycle instead of a tidy sequence of pages. The current code gets several of these edge cases right:

• If guest checkout is disabled, the guest-initialization endpoint does not silently create a guest customer.
• If the cart already belongs to a registered, logged-in customer, the handler does not overwrite that ownership.
• If a guest customer already exists, it tries to reuse or update that guest context rather than blindly creating duplicates.
• Real address details are still validated and saved as part of the form flow, the single page doesn't skip validation.

None of that is flashy, but it is exactly the plumbing that decides whether carts, addresses, customers and payment modules stay coherent in production. Whether guest is even the right default for your store is a business decision with surprisingly clear data behind it, see guest checkout vs account creation.

Migration timing: when should you actually move?

This is the decision most posts skip. Three timing realities should shape it:

• 9.2 is second-half-2026 at the earliest, and "planned" is not "shipped." Treat the date as directional.
• The module is under heavy development now, so even at 9.2 launch there will likely be a real-world stabilization period before it's safe on a revenue-critical checkout.
• Most stores won't be on 9.2 for a long time. Plenty of live shops will stay on 1.7, 8.x, 9.0 or 9.1 well past the 9.2 release, because checkout-touching upgrades are exactly the ones merchants delay.

Put those together and the conclusion is simple: native OPC is a reason to prepare, not a reason to leave a leaking checkout in place. If your checkout is converting badly today, waiting one or more release cycles is itself a cost in lost orders. If you're not sure your checkout is the leak, diagnose first: why your checkout page is losing you sales and the broader reasons people abandon carts are the place to start.

What ordinary merchants should do now

For current stores, one-page checkout remains a module decision until native OPC is stable on your target version.

If your checkout is currently weak, don't spend months waiting. A reasonable plan that costs you nothing on the native-OPC bet:

• Keep your current checkout stable and fast.
• Avoid custom core overrides on the order controller. They make any future checkout migration harder.
• Keep payment and carrier modules updated, so they're ready for whatever the new contract expects.
• Test native OPC on a staging copy the moment PrestaShop publishes a testable release.
• Don't assume every theme tweak or checkout customization will survive the move unchanged.

If you want the one-page conversion benefit on your current version rather than waiting, that's the module route. Our Checkout Revolution module turns the stepped native checkout into a true single-page flow on PrestaShop 1.6 through 9, configured from the back office, with no core edits or theme surgery, so it survives upgrades. So what does that buy you? Every section on one screen, a live-updating total the moment an address is entered, guest checkout as the default, and inline validation that catches a bad email as the customer types. We rebuilt it from the ground up for exactly this job. The story is in Checkout Revolution 3.0, and it sits alongside our checkout process module and alternatives overview if you're comparing options.

What module and theme developers should prepare

Developers should watch this more closely than merchants, because a one-page checkout changes where and when data is available. Address changes, carrier refreshes, terms acceptance, validation errors, cart totals, payment options and custom fields can now all surface in the same screen lifecycle rather than across separate step pages.

The first things worth testing once a usable package exists:

• Payment-option rendering and validation in a single-page context.
• Carrier modules reacting to live address changes (a classic place for stepped-flow assumptions to break).
• Any checkout hook that assumes discrete steps exist.
• Custom address fields and B2B fields.
• Theme overrides of checkout templates.
• Error handling after a failed payment or failed address validation.
• Guest checkout and logged-in checkout, tested separately.

A fast way to find your exposure today is to grep your theme and modules for the checkout hooks and templates they touch, for example searching for actionCheckoutBuildProcess, paymentOptions and carrier-process hooks across your modules and themes directories, plus any overrides of checkout/_partials, payment.tpl, shipping.tpl or address-form.tpl. That tells you what to retest when a stable native OPC build lands. It is a staging checklist, not a compatibility guarantee.

rg -n "actionCheckoutBuildProcess|paymentOptions|PaymentOptionsFinder|displayPaymentReturn" modules themes
find themes \( -path "*/checkout/_partials/*" -o -name "payment.tpl" -o -name "shipping.tpl" -o -name "address-form.tpl" \) -print

Our take

Native OPC makes PrestaShop more competitive out of the box, and that is worth being optimistic about. The realistic outcome is not "native OPC kills checkout modules." It's that PrestaShop gets a better default checkout, while specialized modules keep solving the advanced needs the default won't cover: express/wallet checkout, B2B workflows, custom payment rules, complex UX, older PrestaShop versions, and merchant-specific flows. Even a perfect checkout loses some carts, which is why abandoned-cart emails and broader cart-abandonment strategies stay relevant whatever checkout you run.

For now, treat PrestaShop 9.2 native OPC as something to prepare for and test on staging, not something to blindly wait for while orders leak from the checkout you have today.

FAQ

Has PrestaShop 9.2 native one-page checkout actually shipped yet?

No. As of mid-2026 it is in active development. The OPC feature flag was merged into core (PR #40796) and the ps_onepagecheckout module exists publicly, but the module's own repository describes it as under heavy development. The 9.2 release is currently planned for the second half of 2026, and "planned" is not "released." Treat the date as directional and test on staging when a usable build appears, rather than waiting for it with a broken checkout live.

Will my existing payment and carrier modules work with native OPC?

They should, by design, native OPC uses PrestaShop's standard payment-option discovery, so existing payment modules stay part of the flow instead of being bypassed. The catch is that everything now meets on one screen at once, so carrier modules reacting to live address changes and payment modules rendering in a single-page context are exactly the spots where stepped-flow assumptions can break. Plan to retest them on staging rather than assume they carry over untouched.

Does native one-page checkout mean a no-redirect, one-tap payment?

No, and this is the most common misconception. Native OPC collapses the four pre-payment gates into one screen, but a payment module can still redirect to a gateway, a hosted page, a 3D Secure step or a bank confirmation. That is normal e-commerce behaviour, not a flaw. Turning the payment itself into a one-tap action is a different feature, express/wallet checkout, covered in express checkout.

I'm on PrestaShop 1.7 or 8.x. Will I get native OPC?

Not without upgrading. Native OPC is being built for 9.2, so stores on 1.7, 8.x, 9.0 or 9.1 won't get it until they move to that release, and checkout-touching upgrades are exactly the ones most merchants delay. If you want a single-page checkout on your current version now, that's the module route, such as Checkout Revolution, which runs on 1.6 through 9.

As a developer, what one thing should I avoid doing today?

Avoid custom core overrides on the order controller. They are the changes most likely to make a future checkout migration painful, because native OPC injects its process through the actionCheckoutBuildProcess hook rather than the controller. Keeping your customizations in modules and hooks, and grepping your theme and modules for the checkout hooks and templates they touch, leaves you far better placed when a stable build lands.