PrestaShop 9.2 Native One Page Checkout: What Merchants and Developers Should Know

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 launch currently planned for the second half of 2026.

I think this is genuinely good news for the ecosystem. Checkout has been one of the areas where PrestaShop often needed a third-party module, custom theme work, or both. But the useful question is not "is native OPC coming?" The useful question is: what does the public code actually show today, and what should a normal merchant or module developer do with that information?

Quick answer

Native OPC is real work, not just a roadmap bullet. PrestaShop core merged pull request #40796 to add core support for a native one-page checkout module, and the module itself is public in the ps_onepagecheckout GitHub repository.

At the same time, the module repository currently describes the project as under heavy development. That is useful planning context: merchants should treat it as something to watch and test, while developers should wait for stable technical contracts before making firm compatibility assumptions.

Where This Fits Next to Our Checkout Products

This update is about the upcoming native PrestaShop 9.2 OPC work. It should not be confused with our two existing checkout product pages: Checkout Revolution for a full one page checkout replacement, and Express Checkout for wallet buttons without replacing the checkout.

What GitHub shows right now

The current public module owns several important pieces:

• Checkout process injection: the module registers actionCheckoutBuildProcess, which lets it provide its own checkout process.
• A single checkout step: the implementation builds a one-page checkout step instead of the current multi-step flow.
• Guest initialization: the module has an AJAX endpoint that can create or reuse a guest customer when the email and required consents are valid.
• Address form refresh: the module has an AJAX endpoint used when the address form must be rebuilt, for example after a country change.
• Standard payment options: the checkout still uses PrestaShop payment option discovery, so existing payment modules remain part of the story.

That is a healthy architecture direction. It keeps the checkout inside PrestaShop rather than turning it into a completely separate app. It also means compatibility work will matter, because payment modules, carrier modules, checkout hooks and theme templates all meet on the same page.

The default checkout is still the baseline merchants know today.

This real PS9 development checkout capture shows the current multi-step flow. Native OPC matters because it aims to collapse those checkout decisions into a single-page flow while keeping PrestaShop payment and carrier logic involved.

Is everything fully AJAX?

No, and I would not describe it that way.

The public code shows AJAX for specific dynamic parts: guest initialization and address form refresh. That is different from saying the entire checkout is a fully AJAX, no-redirect flow. Payment modules can still redirect to a gateway, hosted payment page, 3D Secure step, wallet flow or bank confirmation page. That is normal for ecommerce and should not be treated as a flaw.

For a merchant, the practical meaning is simple: native OPC should reduce checkout friction, but it will not automatically make every payment method behave like Apple Pay or Google Pay. One Page Checkout and Express Checkout are related, but they are not the same feature.

What happens when the customer has no account?

The current GitHub code is built around guest checkout. If guest checkout is enabled and the customer enters a valid email plus required consents, the module can initialize a guest customer and attach that customer to the cart before final checkout submission.

There are a few important details here:

• If guest checkout is disabled, the guest initialization endpoint does not create a guest customer.
• If the cart already belongs to a registered customer, the handler does not simply overwrite that ownership.
• If a guest customer already exists, the implementation tries to reuse or update that guest context instead of blindly creating duplicates.
• Real address details are still validated and saved as part of the checkout form flow.

That is exactly the kind of boring checkout plumbing that matters in production. It is not flashy, but it decides whether carts, addresses, customers and payment modules stay coherent.

What ordinary PrestaShop merchants should do

If your checkout is currently weak, I would not wait months doing nothing. PrestaShop 9.2 is planned for the second half of 2026, and even after release many real stores will stay on PrestaShop 1.7, 8.x, 9.0 or 9.1 for a long time.

For a normal merchant, the reasonable plan is:

• keep your current checkout stable and fast;
• avoid custom core overrides that will make future checkout migration harder;
• keep payment and carrier modules updated;
• test native OPC on staging when PrestaShop publishes a testable release;
• do not assume every theme or checkout customization will work without changes.

Native OPC is promising, but it is not a reason to leave a broken checkout in place today.

What module and theme developers should prepare

Developers should watch this more closely than merchants. A one-page checkout changes where and when data is available. Address changes, carrier refreshes, terms and conditions, validation errors, cart totals, payment options and custom checkout fields can all appear in the same screen lifecycle.

The first things I would test when a usable package is available:

• payment option rendering and validation;
• carrier modules reacting to address changes;
• checkout hooks that assume separate steps;
• custom address fields and B2B fields;
• theme overrides of checkout templates;
• error handling after failed payment or failed address validation;
• guest checkout and logged-in customer checkout separately.

For developers, this is planning work. Reserve time for testing and compatibility notes, because checkout integrations deserve careful verification before they are shipped.

rg -n "actionCheckoutBuildProcess|paymentOptions|actionCarrierProcess|displayBeforeCarrier" modules themes
rg -n "checkout/_partials|payment.tpl|shipping.tpl|address-form.tpl" themes modules

Those searches are a quick staging check, not a compatibility guarantee. They show where your theme or modules touch checkout internals so you know what to retest when a stable native OPC package is available.

My take

I am optimistic about native OPC because it makes PrestaShop more competitive out of the box. I would still leave room for a normal real-world stabilization period after the first public release. The best outcome is not "native OPC kills checkout modules." The best outcome is that PrestaShop gets a better default checkout, while specialized modules keep solving advanced needs: express checkout, B2B workflows, custom payment rules, complex UX, older PrestaShop versions and merchant-specific flows.

For now, treat native OPC as something to prepare for and test, not something to blindly wait for.

Useful sources

• PrestaShop core pull request #40796 - native one-page checkout support
• PrestaShop ps_onepagecheckout module repository
• PrestaShop Monthly March 2026 - roadmap and new ownership context

If you need checkout improvements before PrestaShop 9.2 is stable, our Checkout Revolution module remains focused on today's stores: one-page checkout, payment integrations and compatibility across existing PrestaShop versions. If you only need wallet buttons and do not want to replace the checkout, use the separate Express Checkout product page.