Checkout Revolution 3.0: One-Page Checkout rebuilt from the ground up

Last updated: June 2026.

We rebuilt Checkout Revolution from the ground up, not a feature bump on the old codebase, but a fresh architecture. The short version: the previous express-checkout module and the wider checkout module have been merged into one, the whole flow now lives in a single modal built on Stripe's Payment Intents API, and it runs on PrestaShop 1.6 through 9. This post is the honest engineering story, what actually changed, why it changed, and what that means for your store. If you're still deciding whether a one-page checkout is even the right move, start with one-page checkout for PrestaShop and come back.

Why rebuild instead of patch

The original module was written against PrestaShop 1.6 patterns and then progressively adapted for 1.7, 8.x and 9.x. Every adaptation layered another conditional on top of the last, the AJAX handling, the form validation, the payment-method switching all carried decisions made for a platform version that's now years old. At some point the cost of working around the old structure exceeds the cost of replacing it. We hit that point, so we replaced it.

We also folded our separate express-checkout module into this one. Maintaining two overlapping checkout products meant two sets of payment integrations, two carts, two places for a Stripe API change to break something. Now there is one module, one cart pipeline, one set of front controllers to keep compatible across PrestaShop releases. So what does that mean for you? Fewer moving parts that can conflict at upgrade time, and one place to configure instead of two.

What "rebuilt" actually changed

One modal instead of a page sequence

PrestaShop's default checkout. Even on 1.7 and later, where it lives on a single URL, reveals itself one gate at a time: personal information, then addresses, then delivery, then payment, each section unfolding only after the last is complete. (We unpack exactly how that native flow works, and the order controller and step classes behind it, in PrestaShop native one-page checkout.) Checkout Revolution replaces that sequence with a single modal: registration or guest details, address, shipping selection and payment all in one surface, reachable from a product page, the cart, or any page on the store. The customer never navigates away from what they were looking at to pay.

Built on Stripe Payment Intents

The payment layer is built on Stripe's Payment Intents API rather than the older charge-based flow. That's the part of the rebuild that took the longest, because it's the part that has to be exactly right, it's what handles 3D Secure / Strong Customer Authentication, asynchronous payment confirmation, and the regional methods that settle after the customer leaves the page. On the merchant side it means support for digital wallets (Apple Pay, Google Pay), cards with saved-card reuse for repeat buyers, bank transfers, and Buy Now Pay Later. A broad set of methods through a single Stripe connection rather than a separate module per provider.

Address entry that fights less

Address forms are the most tedious thing in any checkout, so the rebuild attacks them directly:

• Google Places autocomplete. Start typing a street and the rest of the address fills from the suggestion, instead of tabbing through five fields by hand.
• EU VAT validation via VIES, B2B customers enter a VAT number and it's checked against the European Commission's VIES service, so a valid intra-community number applies correctly at the point of entry rather than failing silently later.
• Guest checkout as the default path, with an opt-in to save details and create an account after the order is placed. The customer is never blocked behind a registration wall. The data on why that matters is in guest checkout vs account creation.

Social login, where it helps

Returning customers can sign in with Google, Facebook, Apple or Microsoft instead of recalling a store password, useful for the shopper who bought once eight months ago and won't remember they ever made an account. It's optional and off by default; turn it on only if it fits your audience.

Live recalculation and validation

Because everything is in one modal, the running total recalculates as the customer acts: pick a country and shipping options update, choose a carrier and the total moves with it, enter a voucher and it's validated in real time against your cart rules rather than after a page reload. That immediacy is the difference between a checkout that feels responsive and one that feels like submitting a form and hoping.

How it sits next to PrestaShop's native checkout

A fair question for any checkout module: why not just use what PrestaShop ships? The honest answer depends on your version and your appetite for waiting.

PrestaShop building a native one-page checkout into 9.2 is genuinely good for the ecosystem. It is in development, not yet released, and we cover what the public code includes today in PrestaShop 9.2 native one-page checkout. The module exists for the stores that can't or won't wait for that release, are running an older version that will never get it, or want the Stripe-wallet and B2B pieces the core won't ship. If you're weighing the broader trade-offs of a stepped versus single-screen checkout, that's the subject of our PrestaShop checkout optimization guide, and the module-versus-alternatives question is laid out in checkout process modules and alternatives.

Compatibility and upgrading

Checkout Revolution targets PrestaShop 1.6 through 9. It detects your version and adapts its integration, on 1.7.7+ it hooks the Symfony-era admin order panel (displayAdminOrderSide), and on older stores it falls back to the legacy hook (displayAdminOrderLeft), so the same module behaves correctly on a 1.6 store and a current 9.x store without you choosing a build.

That version-adaptive hooking is the kind of detail that decides whether a module survives a PrestaShop upgrade or quietly stops rendering. In practice it looks like picking the hook at install time from the running version rather than hard-coding one:

// Register the admin-order panel on the hook the running PS version exposes.
$adminOrderHook = version_compare(_PS_VERSION_, '1.7.7', '>=')
    ? 'displayAdminOrderSide'   // Symfony-era order page (1.7.7+, 8.x, 9.x)
    : 'displayAdminOrderLeft';  // legacy order page (1.6–1.7.6)

$this->registerHook($adminOrderHook);

The point is not the two hook names. It is that the module reads _PS_VERSION_ and adapts, so you never have to match a build to your platform by hand. The same principle runs through the front controllers and templates.

If you ran the previous express-checkout module, note that it has been deprecated and merged into this one; the database table prefixes are now unified under mprcheckoutrevolution_. Existing Checkout Revolution users update through the standard module-update process and configuration is preserved. The checkout's appearance changes. The new design is cleaner, but the settings are a superset of what the older version exposed, so nothing needs reconfiguring from scratch.

What it deliberately doesn't do

Being honest about scope matters more than a feature list. Checkout Revolution's express-payment features are Stripe-centric: without Stripe, the wallet and BNPL benefits won't apply, but the one-page flow, guest-first checkout and address tooling remain gateway-independent. It also doesn't, by itself, recover the carts that abandon before reaching checkout; that's a different job, handled by an email sequence. See abandoned-cart emails and the automation that runs them. And no checkout, however good, fixes a deeper conversion problem upstream; if you're not sure where your leak is, diagnose it first with why your checkout page is losing you sales.

Measure it on your own store

We won't hand you a conversion-uplift number, because the honest one depends entirely on how rough your current checkout is, a store with forced registration and a four-step native flow has far more to gain than one that's already lean. So measure it yourself. Before you switch, record four numbers from your analytics: cart-to-order conversion rate, checkout abandonment rate, average time to complete checkout, and mobile-versus-desktop conversion. After enabling the single-modal flow, compare the same four over at least 30 days and a few hundred orders, enough volume to separate a real trend from week-to-week noise. For the wider playbook on cutting abandonment across the whole funnel, see reducing cart abandonment in PrestaShop.

That's the rebuild: one module instead of two, one modal instead of a step sequence, a Stripe payment layer that handles the methods customers actually reach for on a phone, and the same behaviour from PrestaShop 1.6 to 9. The principle hasn't changed, fewer gates, less typing, a total that's honest from the first screen. The architecture under it finally has.

FAQ

I'm already on the old Checkout Revolution. Will updating break my configuration?

No. Existing Checkout Revolution installs update through the standard module-update process, and your configuration is preserved. The new settings are a superset of the old ones, so nothing needs setting up from scratch, but the checkout's appearance does change to the cleaner new design, so preview it on a staging copy before pushing to live so the look isn't a surprise.

I used your separate express-checkout module. What happens to it?

It's been deprecated and merged into Checkout Revolution. Express checkout is now part of this one module, not a second product. The database tables are unified under the mprcheckoutrevolution_ prefix. Running two overlapping checkout modules was a source of upgrade conflicts and double payment integrations, which is exactly what the merge removes.

Do I have to use Stripe?

The wallet, saved-card and Buy Now Pay Later features are built on Stripe's Payment Intents API, so those specific benefits need a Stripe connection. If your store runs entirely on a provider with no Stripe path, the express-payment side won't apply and the module may not be the right fit, we'd rather say that plainly than oversell it. The one-page flow, guest-first checkout and address tooling don't depend on which gateway renders, but the headline payment methods do.

It runs on PrestaShop 1.6 through 9. Do I pick a different build for my version?

No. It's one module that reads your PrestaShop version at install and adapts, for example choosing displayAdminOrderSide on 1.7.7+ and the legacy displayAdminOrderLeft on older stores. You install the same package regardless of whether you're on 1.6 or a current 9.x release.

PrestaShop 9.2 is getting a native one-page checkout. Should I just wait for that?

That depends on your version and timeline. Native OPC is in development for 9.2, not shipped, and it will need a stabilization period plus an upgrade to 9.2 to use it. If your checkout converts badly today and you're on 1.6–9.1, waiting one or more release cycles is itself a cost in lost orders. We cover the honest scope of the native build in PrestaShop 9.2 native one-page checkout so you can decide with the real facts rather than the roadmap.