PrestaShop Checkout Optimization: One Page, Express, Embedded and One-Click Compared

We've shipped Checkout Revolution since 2016 and watched it run on shops doing everything from €15 phone cases to €5,000 industrial orders. The one thing we can say with confidence: there is no single "best" PrestaShop checkout. One-page, express, embedded and one-click are not competitors fighting for the same crown — they solve different problems, and the right answer depends on your average order value, your device split, and whether your customers come back. This is the decision guide: what each approach is, the trade-offs PrestaShop specifically imposes on it, and how to tell which one (or which combination) fits your shop.

If you just want the deep dive on a single pattern, we've written those separately — one-page checkout and express checkout each get a full post. This one is about choosing between them.

Start with the default, because everything is measured against it

Out of the box, PrestaShop 1.7, 8 and 9.0/9.1 ship a stepped checkout on a single controller (the order controller) — PrestaShop 9.2 adds a native one-page checkout option, but on every version before it the stepped flow is what you get. It runs a fixed sequence of step classes — CheckoutPersonalInformationStep, CheckoutAddressesStep, CheckoutDeliveryStep, CheckoutPaymentStep — where each step stays collapsed until the previous one is complete. It lives on one URL, but the customer still passes through gates, and changing an earlier choice re-validates the steps after it.

That stepped default is your baseline. Every option below is a bet that removing, reordering or skipping those gates wins you more completed orders than it costs. Whether it does depends entirely on who's checking out. For the wider symptoms of a leaking checkout — and how to diagnose which step is the problem — start with why your checkout page is losing you sales.

The four approaches, at a glance

Here's the whole landscape on one screen. The detail follows, but if you read nothing else, read this:

Notice that only one-page and embedded actually touch the page layout. Express and one-click are accelerators you layer on top — which is exactly why the realistic answer for most shops is a combination, not a single pick.

One-page checkout: the default base layer

One-page checkout collapses the stepped flow onto a single screen. Address, shipping and payment are all visible, the order total updates live via AJAX when the customer changes country or carrier, and there are no page reloads. For a typical B2C cart it's the single biggest conversion lever we know of, because it kills the friction the default flow builds in: the customer sees the whole finish line at once and the shipping total appears while they're still typing their address, not as a surprise three steps in.

The trade-off: the simplicity is on the surface. Underneath, every field change can trigger PrestaShop's full carrier and tax recalculation — change country, the shipping options change, totals recalculate, the tax display can flip, and the payment-method list re-evaluates. A well-built one-page checkout sequences those AJAX calls cleanly with loading states; a bad one flickers and occasionally loses the customer's selection. That's the real engineering difficulty, and it's covered in depth in our one-page checkout guide and the rebuild story behind Checkout Revolution 3.0.

When it's the wrong call: high-value orders (€500+) where customers want to slow down and verify, complex B2B with VAT numbers and split addresses, or shops with 15+ shipping options where a focused shipping step is genuinely easier to navigate than one long list. More on that boundary below.

Express checkout: skip the form entirely

Express checkout doesn't optimise the form — it removes it. The customer taps Apple Pay, Google Pay or PayPal, authenticates with Face ID or a fingerprint, and the order is placed in seconds. Name, address and card all come from the wallet; your shop never collects them through a form. Mechanically, the button is driven by the gateway's own SDK — Stripe's Express Checkout Element or PayPal's JS SDK — the provider returns a token plus a shipping address, and your module creates the cart, assigns the address, calculates shipping and validates the order.

The trade-offs are sharp and worth being honest about:

• It needs a gateway with an express SDK. Stripe (Express Checkout Element) and PayPal (JS SDK) do. Bank transfer, cheque and most older custom gateways can't participate — a bank-transfer-only shop simply can't offer express until it adds a card processor.
• Availability is device- and country-gated. Apple Pay needs Safari, Google Pay needs Chrome/Android. A heavily desktop-Firefox audience (common in B2B) won't see the buttons, and that's by design, not a bug.
• Many express integrations simplify shipping to a single default carrier, even though capable wallet APIs can present shipping options through callbacks. If pickup points, gift messages or split billing matter to your buyers, check whether your module exposes carrier choice — many don't, and express alone isn't enough.

So express is an accelerator, not a replacement: you layer it on top of a normal checkout for the customers whose device and order are simple enough to use it. The full mechanics and placement options are in express checkout: when customers just want to buy fast.

Embedded checkout: bring the checkout to the customer

Embedded checkout puts the checkout form on pages that aren't the checkout page — in the footer, on the product page, or in a slide-out panel triggered by "Add to Cart." The point is to remove the "commit" moment: traditional checkout has a deliberate "Proceed to Checkout" action that signals "you are spending money now," and that transition is where doubt creeps in. Embedded checkout dissolves it — the customer is just filling fields on a page they were already looking at.

This is the hardest pattern to build correctly in PrestaShop, and the trade-off is technical. The carrier-calculation and payment-method hooks were designed to run on the order controller. Embedding them in the footer or on a product page means initialising that logic outside its intended context — including Stripe Elements or PayPal's button scripts, which must mount cleanly regardless of what else the page is doing. Most "embed checkout" attempts we've audited fail the same test: they don't recalculate shipping when the customer changes country in the footer form. There's a UX balance too — the form has to be compact enough not to dominate every page but complete enough to actually take an order, which on mobile usually means a sticky bottom bar that expands into a full-screen overlay.

Best fit: single-product stores, digital goods, landing pages and subscription signups — anywhere the product page itself is doing the heavy lifting and a separate checkout page is just an obstacle.

One-click checkout: a feature, not a layout

One-click is the odd one out: it isn't a layout you choose, it's a feature that sits on top of whichever checkout pattern you've already picked. For a logged-in returning customer whose card token and address are already saved, the cart page shows a summary and a single "Place Order" button instead of a form. The completion numbers on repeat orders are dramatic because there's almost nothing left to abandon.

The PrestaShop-specific catch: one-click needs PCI-compliant tokenisation, which means Stripe, Adyen or another tokenising provider. The card data never lives on your server — only a token referencing it at the gateway. Cash on delivery, bank transfer and cheque can't be one-clicked, because there's nothing to tokenise. And it only applies to returning customers who've paid before, so it supplements your checkout rather than replacing it — it does nothing for a first-time buyer.

Best fit: stores with high repeat-purchase rates, subscription products and consumables, where most revenue is reorders.

The trap every approach shares: nothing on a PrestaShop checkout is static

Before you choose, understand the constraint that decides how well each option actually performs: on a PrestaShop checkout, the carrier list, the prices and the payment options all change in real time based on what's in the cart, where the customer lives, and sometimes who they are.

Carriers resolve from a matrix of delivery country and zone, total cart weight and price, product dimensions, and the merchant's carrier rules. A French customer with a 500g item sees Colissimo, DPD and Mondial Relay; add a 25kg item and the carriers with weight caps drop off; switch the country to Switzerland and the EU-only carriers vanish entirely. Payment methods shift just as much — Klarna may only appear in a price band, iDEAL is NL-only, Bancontact BE-only, BLIK PL-only, and wallet buttons depend on the device. Two customers on the same shop routinely see different lists.

This is precisely where the four approaches diverge, and it's the most important line in the whole decision:

• One-page handles it best — every variable lives on one screen, so a country change updates the carrier list and the payment list together and the customer always sees the full picture.
• Multi-step can hide problems — a payment method chosen on the payment step can become invalid after the customer goes back and changes the address, and weaker checkouts don't catch it until submit.
• Express sidesteps most of it (payment comes from the device, address from the wallet) but that's also why many implementations fall back to a single default carrier rather than surfacing shipping options.
• Embedded faces the hardest version — it has to run carrier and payment resolution on pages the order controller never touches, which is why so many implementations quietly skip the recalculation.

The more dynamic your shipping and payment setup, the more this matters — so test every option with realistic carts (mixed weights, multiple countries), not a single lightweight product.

The decision: three questions, in order

You don't need to agonise. Answer these three and the shortlist falls out:

• 1. What's your average order value? Under €100, optimise for speed — one-page plus express. Over €500, optimise for trust — a structured flow with a clear summary and visible security cues, because rushing an expensive purchase increases anxiety rather than reducing it. €100–€500 is one-page territory with a strong order summary.
• 2. What devices do they use? Pull mobile share from your analytics. Past roughly 60% mobile (most B2C today) express buttons stop being optional, and a one-page layout has to be built thumb-first. The device split is the whole game on mobile — mobile checkout optimization covers tap targets, input types and wallet payments.
• 3. Repeat or one-off? A high repeat rate makes one-click the biggest single lever you have. Under ~10% repeat, nail the first-time flow first and add one-click later.

By shop type

• Fashion / apparel: one-page + express + guest. Small carts, heavy mobile, speed wins.
• Electronics / high-value: one-page with a prominent order summary and visible security cues; express as an option, not the focus.
• B2B / wholesale: multi-step, or one-page with expandable B2B fields; skip express — company buyers don't use Apple Pay for purchase orders.
• Single-product / landing page: embedded checkout on the product page or footer, express buttons alongside, no separate checkout page at all.
• Subscription / consumables: one-click reorder is your highest-leverage feature — most revenue is repeat, so invest there.

For most PrestaShop B2C shops the answer is the same: one-page checkout as the base, with express buttons layered on top, guest checkout on, and one-click added once you have returning customers. That serves both the careful filler and the buyer who just wants to pay and leave.

When the stepped default actually beats one-page

We sell one-page checkout for a living — take this with that in mind. There are genuine cases where the structured flow wins, and pretending otherwise would be dishonest:

• Luxury and high-ticket. Someone spending €1,000 wants to feel in control; a deliberate step-by-step flow lowers anxiety rather than raising it.
• Complex B2B. VAT validation, PO numbers, net terms and multi-stage approval are overwhelming on one screen.
• Configurable products. Engraving, colour and size customisation each earn a step because the customer expects to be guided.
• Regulated products. Age verification, licence checks and mandatory disclaimers shouldn't be buried in a single dense form.

Match the checkout to the customer's mental model. A teenager buying a phone case wants speed; a procurement manager placing €5,000 against a PO wants control and a paper trail. The same shop can serve both if you build for both — and the cross-cutting setting that helps either way is guest checkout, because forced registration is one of the largest abandonment causes regardless of layout (guest checkout vs account creation).

Measure before you change anything

Don't change the checkout without baselining first, and don't trust three days of data. Record four numbers from your analytics before you touch anything — checkout completion rate (of customers who start, how many finish), cart-to-checkout rate (of customers with a cart, how many even start), step-by-step drop-off on the current flow, and mobile-versus-desktop completion side by side. After the change, compare the same four over at least 30 days and a few hundred orders, so you're reading a real trend rather than week-to-week noise. If the leak is upstream — people abandoning before they even reach checkout — the checkout layout isn't your bottleneck yet; start with why shoppers abandon carts and the 12 reasons people leave before paying.

And whichever pattern you land on, some customers will still leave with a full cart — that's normal, and it's recoverable. An abandoned-cart email sequence wins a share of them back; see reducing cart abandonment in PrestaShop and the one automation every store needs.

How we'd build this in PrestaShop

Before PrestaShop 9.2, core doesn't ship one-page, express or embedded checkout at all — and even on 9.2, which adds a native one-page option, express and embedded still need a module, as does anything beyond the stock one-page layout. Checkout Revolution is the one we maintain, and the reason it bundles all four is exactly the conclusion of this guide: most shops want a combination, not a single pattern. It installs and configures from the back office without theme surgery or core edits, so the change survives upgrades. What it gives you:

• One-page checkout layout with real-time validation and country-first field ordering
• Apple Pay, Google Pay and PayPal Express buttons across product page, cart, mini-cart and checkout
• Embedded placement — footer, product page or slide-out panel
• One-click reorder for returning customers with tokenised payment
• Guest checkout with optional post-purchase account creation
• Conditional B2B fields that appear only when relevant

If all you need is wallet buttons on your existing checkout, Express Checkout is the lighter option. Either way the principle holds: there is no universally best PrestaShop checkout — there's the one your specific customers complete. Pick the pattern that matches their AOV, their devices and their repeat rate, measure before and after, and layer the accelerators on top once the base is right.