We Tested PrestaShop 9.2's Native One Page Checkout: What Works, What Doesn't, and When You Still Need More

Tested July 2026 on PrestaShop 9.2.0 beta 1.

PrestaShop 9.2 ships a native One Page Checkout. For anyone running a store, that turns a long-standing assumption into a real question: if checkout is now built in, do you still need a checkout module at all?

We did not want to answer that from the release notes. So we installed the 9.2 beta on a clean container, switched the native one page checkout on, and drove the whole flow with a scripted browser, logging every page navigation, script, XHR and document request (static assets like images and fonts were excluded from the log) along with the timings. This post is what the instruments actually said.

The headline, before the detail: it is better than we expected. We went in with a specific suspicion, that adding an address would quietly force page refreshes and make it "one page" in name only. That suspicion was wrong, and we are saying so first because it was the thing we most expected to find.

It is not flawless, but the rough edges are smaller than we first reported. Two of our original findings turned out to be faults in our own test script, and we have withdrawn them below rather than leave them standing. What survives is a duplicated request, some missing form attributes, a mobile layout problem, and one deliberate design choice that takes away something the old checkout could do.

Before anything else: our conflict of interest

We sell PrestaShop checkout modules. A native checkout in the core is, commercially, competition for us, so you should read anything we say about it with that in mind.

Here is how we handled it, so you can check our work rather than trust our motives. Every claim below is a number we recorded or a screenshot we took, on an install anyone can reproduce from a public Docker image. Where we expected to find a fault and did not, we say so. Where our first reading was wrong, we corrected it in place rather than keeping the version that flattered us: we initially thought discount codes were missing from the new checkout, and they are not. The setup steps, the exact versions and the things we could not test are all listed. If a measurement here does not reproduce for you, tell us and we will chase it down.

What we tested, exactly

Every number below comes from this environment. If something does not reproduce for you, it could be your version, your configuration or our method, and we would rather hear about it than not.

Two setup notes matter for honesty. First, the default install had no carrier serving the shop's own country, because the UK sits in the "Europe (non-EU)" zone and the sample carriers only cover two other zones. We assigned the carriers to that zone, which is ordinary merchant configuration, not a checkout problem. Second, the timings are from a local network, so treat them as a comparison between the two checkouts on identical hardware rather than as numbers your shop will reproduce.

What native 9.2 OPC actually is

It ships as a module, ps_onepagecheckout, included in the 9.2 package. Two details we confirmed on the install are worth knowing before you plan anything:

• It is off by default. After a clean 9.2 install the module is present and enabled, but the setting PS_ONE_PAGE_CHECKOUT_ENABLED is 0. You opt in from Design > Checkout in the back office, and you can switch back to the classic four-page checkout whenever you want.
• It is 9.2 or nothing. The module declares ps_versions_compliancy with a minimum of 9.2.0. It is not something a 1.7, 8.x, 9.0 or 9.1 store can install.

Architecturally it does what the official announcement on the PrestaShop build blog describes. It injects its own checkout process through a core hook instead of overriding the order controller, and it replaces the four step classes with a single combined step. Login and account creation were deliberately moved out of the checkout onto their own pages. We covered the design before it shipped in what merchants and developers should know about 9.2 native OPC. This post replaces the guesswork in that one with measurements.

The benchmark

The native 9.2 one page checkout with the address filled in. Delivery method, payment method, terms and the pay button are all on the same screen, and the summary on the right updates live.

Same shop, same product, same address values, same carriers, each in a fresh cart. The two journeys were equivalent rather than action-for-action identical, because the two checkouts do not offer the same actions. "Full page loads" counts main-frame navigations from opening the checkout to landing on the order confirmation.

The same shop with one page checkout switched off. Three of the four steps are unreachable until the one above is completed, and each completed step costs a full page load.

Read that trade honestly, and mind the sample size. These are five runs on a local network, so treat them as descriptive. The first-paint gap in particular sits inside the run-to-run spread (one page checkout 152 to 180 ms, classic 148 to 188 ms) and we would not claim it as a real difference. The DOMContentLoaded gap and the byte counts were consistent across every run. The one page checkout is about 50 ms slower to reach DOMContentLoaded and carries roughly 28 KB more JavaScript, because it renders contact, address, delivery, payment and the summary in one document instead of one step at a time. In exchange it removes three full page loads from the journey. On any real connection, three fewer round trips to the server beats 50 ms of local render time comfortably.

Where the address hypothesis died

This was the specific thing we set out to catch, so here is the raw per-action breakdown. Every one of these was recorded with the browser's own network log.

Adding an address does not reload the page. Editing one does not reload the page. Changing country does not reload the page, it rebuilds the address form over AJAX because required fields and tax behaviour change. Switching carrier updated the order total live, from 19.12 EUR to 26.12 EUR, with no navigation at all.

The refresh logic is also more careful than we assumed. Editing the street line, which cannot change a shipping price, fired a single draft-save request and nothing else. Carriers and payment options were only refetched when something that genuinely affects them changed, such as the country or the completed address. That is sensible behaviour, with one caveat: our sample carriers were flat-rate, so a postcode change could not alter the price. A carrier that prices by postcode would need its own test, because a street edit and a postcode edit both produced only a draft save here.

What it does well

Crediting these properly matters, because they are the parts merchants will feel.

• It really is one screen. Contact, delivery address, delivery method, payment, order summary and the pay button are all in a single form on first paint. There is no step gating and nothing collapsed behind a "continue" button.
• The waiting states explain themselves. Before the address is complete, the delivery and payment blocks do not just sit empty. They say "Complete your delivery address above to see your delivery options" and then list exactly what is missing: "Still needed: First name, Last name, Address, City, Zip/Postal code". That is unusually clear microcopy for a default checkout.
• Inline validation blocks bad data without a reload. With France selected (which defines a postcode format), entering ABC marked the field invalid, showed "Invalid postcode - should look like "NNNNN"", replaced the carrier list with "Please correct the highlighted address fields", and refused to submit. Clicking Pay produced zero network requests and put focus back on the form. Nothing was lost and nothing reloaded. In the separate test where we cleared a required City field, the browser focused that exact field on submit.
• The pay button stays honest. It stays disabled while a required consent is outstanding, which we recorded with a returning customer whose carrier and payment were resolved but whose terms box was unticked, and it shows the live total on its face. It is not a complete readiness indicator: with a required City field emptied it stayed enabled, and the browser rather than the checkout blocked the submission ("Pay 19.12 EUR", then "Pay 26.12 EUR" after we picked the paid carrier).
• Saved addresses are managed without leaving the page. For a logged-in customer the address list offers "Use a different delivery address", and both that and the per-address edit menu open a modal on the same screen. Adding and editing an address mid-checkout never navigates away.
• Promo codes are supported and recalculate live. The summary carries a "Promo code" accordion with a "Paste your voucher here" field. Applying a code re-ran the discount, the carriers and the payment options over AJAX with no page reload at all. One thing to know: the field only appears once at least one cart rule exists in the shop, because PrestaShop turns the whole feature off when there are none.
• Returning customers get a genuinely fast path. Logging in with a saved address, the checkout form was up in 193 ms, and the saved address list, both carriers and all three payment methods resolved moments later over AJAX without a single interaction. Completing the order took two actions: tick the terms box, click pay. The email field is gone entirely for a logged-in customer, exactly as the announcement describes.
• Mobile layout holds up. At 375 px there was no horizontal overflow at all (document width 375 px, viewport 375 px), and first contentful paint was 152 ms. The carrier rows and the terms row have large tappable labels (351x136 px and 327x48 px).

An invalid French postcode. The field is flagged inline, the carrier list is replaced with a correction prompt, and clicking Pay produced no network requests at all.

A logged-in customer gets their saved addresses as selectable cards, with a per-address menu and an option to add a new one.

Adding an address opens a modal over the checkout. The page behind it is never reloaded and nothing already entered is lost.

The order confirmation page has been reworked too, and it is noticeably cleaner than the one it replaces.

The rough edges we actually measured

These are the things we can prove, not impressions.

1. The payment methods endpoint is fetched twice

Every time the address resolves, the checkout requests its payment options twice with a byte-identical URL:

GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17
GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17

We recorded it six times across four independent browser sessions: first address entry and a country change in the guest run, the mobile run, an invalid-postcode run, and both a first and a repeat checkout for a logged-in customer. The repeat-checkout case is the telling one, because it happens on a plain page load with no scripted interaction at all. It is a duplicate request, not two different states. On a shop where payment modules do real work per render (fee calculation, availability rules, remote calls), that is wasted server time on the single most conversion-critical page. It is exactly the kind of thing a 0.6.2 module still has left to tidy.

2. No autofill hints on any address field

We audited every field in the delivery address block. Not one carries an autocomplete attribute, and not one carries an inputmode:

Browser and phone address autofill relies on those tokens (given-name, address-line1, postal-code and so on). Without them, the one thing that removes the most typing on mobile works unreliably, which undercuts a checkout whose stated goal is mobile friction. We know this is an oversight rather than a decision, because the 9.2 registration page in the same theme sets the tokens properly: email, given-name, family-name, new-password and tel-national. The checkout address form, which needs them most, has none. Phone at least uses type="tel", so that keyboard is correct.

3. You cannot create an account while ordering, and this is a regression

Login and registration were deliberately moved out of the checkout, which the announcement states plainly. What that means in practice is worth spelling out, because it is a step backwards from the checkout it replaces.

We compared the two checkouts on the same shop. The classic four-step checkout renders a real <input type="password" name="password"> inside the checkout, so a buyer can create an account while ordering, and its "Sign in" control is an in-page tab. The one page checkout has no password field anywhere, and both controls are ordinary links that navigate away:

So a customer who wants to buy and keep an account has to leave the checkout, register on a separate page, and come back. For a guest-first checkout that is a coherent decision, and guest buyers never notice it. For a shop that depends on account signups at the point of purchase, it removes something the old checkout did. It also means the one moment a customer is most motivated to register, right after deciding to buy, is the one moment the checkout will not let them.

4. The pay button is a long scroll away on mobile

The one page checkout at 375 px. The layout holds up with no horizontal overflow, but the whole checkout is a single tall column.

Putting everything on one screen makes that screen tall. On a 375 px viewport the pay button sits 3337 px down the page, and it is not sticky: its computed position is static with no fixed or sticky ancestor. A returning customer with a saved address must still scroll past the whole form to reach it. A sticky summary or pay bar is the standard answer and it is not there yet.

5. It is a pre-1.0 module, and its own README says so

Not a defect, but the most important planning fact on the page. The beta package we tested bundles module version 0.6.2, while upstream had already tagged 0.6.5 a few days before our test, so treat specific version numbers as a moving target. And PrestaShop's own beta announcement is unambiguous: "this beta version is pre-release software. It is possible that you will encounter some issues. Do not use it in your production shop!" You also cannot upgrade a beta to the release candidate or stable through the normal update path.

The module's own repository is blunter still. The README of PrestaShop/ps_onepagecheckout states: "This module is under heavy development. It is not production-ready and should not be used in live environments." At the time of writing it carries a handful of open issues, and two of them line up exactly with things we hit independently: #94 reports duplicate field ids between the hidden address modal and the inline address form, which is why the same #field-postcode id appears more than once in the page we audited, and #102 describes the consent checkbox stack putting the heaviest block on the first screen, which is the friction we describe below. #132 covers the address form ignoring per-country field order, and #105 is an open request to expose an express checkout contract. That last one matters if you sell through wallet or express payment methods, because the surface they would hook into is still being designed.

6. Three required consent boxes stand between the customer and the options

On a default 9.2 install a first-time guest meets three required ticks: customer data privacy, the GDPR module's own box, and the terms and conditions. For a guest the first two gate the delivery and payment options, which stay behind a "please accept the required terms" message until they are ticked. For a returning customer it is milder, and we measured the options resolving normally with only the terms box left unticked, which gates the pay button rather than the options. That stack is your shop's configuration rather than the checkout's fault, and it is removable, but it is what a fresh 9.2 install presents to a first-time buyer. PrestaShop has an open issue on exactly this, #102.

A correction: two findings we withdrew

An earlier version of this article carried two more findings. Both were wrong, and both were our fault rather than the checkout's. We are leaving the record here instead of quietly deleting it.

We reported that applying a discount code reset the customer's delivery method, and separately that the checkout could display one carrier and total while the saved cart held another. Both came from the same mistake: our script selected the carrier programmatically rather than clicking it, so the choice never reached the server, and every later render simply showed the server's version of the truth.

The test that settled it was completing a real order and then reading the database row rather than trusting the screen:

Clicked like a human, the order matches the screen every time, with and without a voucher. Discount codes work correctly: the field appears once the shop actually has a cart rule, and applying one recalculates the discount, the carriers and the payment options over AJAX without a reload. We had no business publishing either claim, and we are recording the correction because a benchmark you cannot trust to correct itself is not worth reading.

What we could not test

Stating these plainly is the difference between a benchmark and an opinion.

• Real payment gateways. We tested with offline methods only. A card gateway, a wallet flow or a 3D Secure step will each add their own handoff, which may be a redirect, a popup or an embedded frame. The final navigation we measured was the check module handing off to its validation page.
• The classic theme. We tested on hummingbird, the theme 9.2 installs. The official announcement warns that classic themes are not supported by default and that you "may need to override some of the One Page Checkout module's templates to make it work". We did not complete a clean, properly migrated classic-theme install, so we are quoting PrestaShop on that point rather than our own result.
• Load and concurrency. Single-browser measurements on a local network. Nothing here says how the extra AJAX endpoints behave under real traffic.
• Third-party checkout modules. We did not test how existing carrier, fee or upsell modules render inside the one page flow. That is the single biggest thing to check on your own staging copy.

Reproduce this yourself

None of this is worth much if you cannot check it. The whole test bed is a public image and about ten minutes of setup. This is an abridged version of the compose file we used (add the usual MYSQL_* and matching DB_* credentials, and point the domain at wherever you run it):

services:
  prestashop:
    image: prestashop/prestashop:9.2.0-6.0-beta.1-classic-apache
    ports: ["8088:80"]
    environment:
      DB_SERVER: ps92-db
      PS_INSTALL_AUTO: 1
      PS_DEV_MODE: 0          # leave this OFF or every timing is inflated
      PS_DOMAIN: localhost:8088
  ps92-db:
    image: mysql:8.0

Then four things that will otherwise waste your afternoon, because they cost us ours:

• Turn the checkout on. It ships installed but disabled. Design > Checkout, or set PS_ONE_PAGE_CHECKOUT_ENABLED to 1.
• Give your carriers the right zone. A default install puts the United Kingdom in "Europe (non-EU)" while the sample carriers only serve two other zones, so a UK address legitimately shows no carriers at all. That is sample data, not a checkout fault, and we nearly reported it as one.
• Test postcode validation with France, not the UK. PrestaShop ships an empty zip_code_format for GB, so any nonsense passes and the checkout looks broken when it is not. France defines NNNNN and validates properly.
• To reproduce the voucher bug you need more than the default shop. The core benchmark ran on the two sample carriers, but the voucher test needs a carrier worth losing: we added Standard Delivery at 4.90, Economy at 6.90 (free over 100) and Express 24h at 12.90, each covering every zone, then created a 10% cart rule with the code TEST10 and free shipping switched off. Pick the most expensive carrier, apply the code, then complete the order and compare the delivery method on the finished order against the one you chose. One gotcha: the promo field is invisible until at least one cart rule exists, because PrestaShop flips PS_CART_RULE_FEATURE_ACTIVE to 0 on a shop with none.

For the reload counts, open the Network panel, filter to Doc, and watch how many main-frame navigations you get between opening the checkout and the confirmation page. For the duplicate request, filter to paymentmethods.

Is native 9.2 OPC enough for you?

Based on what we measured, here is the honest split.

Native OPC is genuinely enough if

• You are moving to 9.2 anyway and run the hummingbird theme or a child of it.
• Your checkout is a standard one: a few carriers, standard payment methods, no custom fields.
• You sell business to consumer with guest checkout as the norm.
• You want the four-step flow collapsed and a live-updating total, which is precisely what it delivers, with zero reloads.
• You are content to wait for the stable 9.2 release before switching it on.

For that shop, the answer is straightforward: the platform now covers it, and you should not buy a module to do what the core does. If your checkout is currently leaking orders and you want to know whether it is even the problem, start with why your checkout page is losing you sales and the reasons people leave before paying.

You will still hit a wall if

• You are not on 9.2. This is the hard one. The module refuses to install below 9.2.0, and checkout-touching upgrades are exactly the ones merchants postpone. A shop on 1.7, 8.x, 9.0 or 9.1 gets nothing from this release.
• You need the payment step itself to be one tap. One page checkout removes the friction before payment. It does not turn a gateway into a wallet button. That is a different feature, covered in express checkout and in is one-click checkout possible in PrestaShop.
• Mobile is most of your revenue and you need a sticky pay bar, or you need the address form to cooperate with phone autofill. Both are measured gaps above.
• You want customers to register at the moment of purchase. There is no password field in the checkout, so account creation means leaving it.
• You need rules like "this payment method only between X and Y order value". That kind of conditional payment and carrier logic is not part of the native module.
• You need custom checkout fields, B2B rules, order-level upsells or delivery-date pickers. None of that is in scope for the native module.

Where a module still earns its place

We sell checkout modules, so treat this paragraph with the scepticism it deserves and check it against the table above. The gaps we actually measured are narrower than they were a year ago, and on a standard 9.2 shop the native checkout now does the core job well.

The one gap that is not a matter of taste is version reach. Native OPC starts at 9.2, verified in the module's own compliancy declaration. Our Checkout Revolution exists to put a single-page checkout on the PrestaShop versions most live shops are actually running today, without core edits. Check the product page for the exact supported range, and note we have not certified it against 9.2 itself yet. Its story is in Checkout Revolution 3.0. Separately, if what you want is the payment tap itself compressed rather than the form above it, that is Express Checkout, and it stays relevant whichever checkout renders the page. If you are weighing the routes against each other, the checkout optimization guide and the checkout process and alternatives overview lay them out.

If you are on 9.2 with a standard catalogue and a standard checkout, we would tell you to use the native one. That is what the measurements support.

FAQ

Is PrestaShop 9.2 one page checkout stable enough for production?

Not yet, and PrestaShop says so twice. The 9.2 beta announcement states it is pre-release software and tells merchants not to use it on a production shop, and the module's own README says "This module is under heavy development. It is not production-ready and should not be used in live environments." The checkout module itself is at version 0.6.2. Every order we placed came out matching what the checkout had displayed, but a pre-1.0 module on a beta platform still belongs on staging until 9.2 reaches stable. You also cannot upgrade from the beta to the release candidate or stable through the standard update path, so test on a throwaway copy.

Does it work on my theme?

It is built for hummingbird, which is the theme the 9.2 package installs and the one we tested on, where it worked without any modification. PrestaShop's own announcement warns that classic themes are not supported by default and that you may need to override some of the module's templates to make it work. We did not verify the classic-theme case ourselves, so treat your theme as the first thing to test on staging, especially if it overrides any checkout templates.

Do I still need a checkout module?

If you are on 9.2, run hummingbird or a child theme, and have a conventional checkout, then honestly no. The native module collapses the four steps into one screen, updates totals live, validates inline and completes an order in two actions for a returning customer. You would still want a dedicated module for the things we found it does not do: running on PrestaShop 1.6 to 9.1, one-tap wallet payment, custom or B2B checkout fields, order-level upsells, and mobile refinements such as a sticky pay bar.

How do I enable it?

Go to Design > Checkout in the back office and select the one-page checkout layout. The module ships installed with 9.2 but the setting is off by default, so a fresh install gives you the classic four-step checkout until you opt in. You can switch back at any time, and in a multistore setup the choice is made per store rather than globally.

Can customers use discount codes in the one page checkout?

Yes. The order summary includes a "Promo code" accordion with a voucher field, and applying a code recalculates the discount, the carriers and the payment options over AJAX without reloading the page. We originally reported that applying a code resets the customer's carrier. That was our test script selecting the carrier programmatically instead of clicking it, and we have withdrawn the claim: driven by real clicks, the finished order matched the chosen delivery method every time, with and without a voucher. The one genuine quirk is that the promo field stays hidden until the shop has at least one cart rule, because PrestaShop disables the feature entirely when none exist.

Does one page checkout mean no redirects at all?

No, and this is the most common misunderstanding. We measured two full page loads across the whole journey: opening the checkout, and the payment module handing off after submit. Everything in between, including entering an address, editing it, changing country, switching carrier and choosing a payment method, happened without a single reload. But a real payment method can still hand off to a hosted page, a 3D Secure challenge, a popup or an embedded frame. We only measured the offline check module handoff, and that kind of step is normal e-commerce behaviour rather than a flaw in the checkout.

Will my existing payment and carrier modules keep working?

By design they should, because the native checkout uses PrestaShop's standard payment-option discovery rather than bypassing it, and our three offline payment methods appeared and worked without modification. The caveat is that everything now renders on one screen at once, so carrier modules reacting to live address changes and payment modules rendering in a single-page context are exactly where assumptions from the stepped flow can break. Note also that the payment options endpoint is currently requested twice per address change, which is worth knowing if your payment modules do expensive work on each render.

Sources and how this was tested

Primary sources, all public:

• Introducing One Page Checkout in PrestaShop 9.2, the official announcement on the PrestaShop build blog.
• PrestaShop 9.2 Beta is open for feedback, which carries the pre-release warning quoted above.
• PrestaShop/ps_onepagecheckout on GitHub, the module source, its README and its open issue list.

Method. A clean PrestaShop 9.2.0 beta 1 install from the official Docker image, hummingbird theme, debug mode off and the production cache warm. The guest journey, the returning-customer journey and the classic four-step comparison were each driven by a scripted browser that logged navigations, XHR, fetch and document requests, excluding static assets, with main-frame navigations counted separately from AJAX calls. Load timings are the median of five runs with the HTTP cache cleared before each. Two findings in an earlier version of this article were withdrawn after we traced them to our own script selecting the carrier programmatically rather than clicking it; every order placed with real clicks matched the checkout display, verified against the order row in the database. Automated captures used 1440 px and 375 px CSS viewports; published images were cropped or resized for presentation but their content is unretouched.

Dated and provisional. These measurements describe PrestaShop 9.2.0 beta 1 with ps_onepagecheckout 0.6.2, tested on 27 July 2026. It is pre-release software under active development, so the faults we describe may well be fixed by the time 9.2 reaches stable, and new ones may appear. We intend to re-run this exact benchmark at the release candidate and again at stable, and to update this article with the new numbers rather than quietly leave the old ones standing. If you reproduce something different, tell us and we will correct it.