Ottimizzazione Checkout PrestaShop: One Page, Express, Embedded e One-Click a confronto

PrestaShop ships with a five-step checkout. Personal info, addresses, shipping, payment, confirmation. Each step is a separate page load, a separate moment where your customer can reconsider, get distracted, or simply give up. The Baymard Institute puts the average cart abandonment rate at 70%. A significant chunk of that is checkout friction.

But here is the thing most articles will not tell you: the multi-step checkout is not always wrong. The best checkout for your store depends on what you sell, who buys it, and how they buy it. This guide breaks down every checkout approach available for PrestaShop, honestly, so you can pick the right one.

The Default PrestaShop Checkout

The standard PrestaShop checkout walks the customer through five pages: personal information, delivery address, shipping method, payment method, and order confirmation. On desktop with a fast connection, this takes about 90 seconds for a new customer. On mobile, it can take three to four minutes.

The main problem is not the number of steps — it is the number of page loads. Every page load introduces latency, breaks the customer's flow, and creates another opportunity to bounce. On a slow mobile connection, each step can take two to three seconds to load. That is 15 seconds of staring at a loading screen before the customer has even finished ordering.

That said, the multi-step checkout has one genuine advantage: it feels organized. Customers filling in complex B2B orders with separate billing and shipping addresses, custom delivery instructions, and purchase order numbers may actually prefer the step-by-step structure. It breaks a complex task into manageable pieces. We will come back to this.

What the default checkout gets wrong

Beyond the page loads, there are several specific problems with PrestaShop's default checkout that hurt conversion rates:

• Hidden shipping costs — the customer does not see the shipping price until step 3. By then, they have already invested time filling in personal information and their address. If the shipping cost is higher than expected, the frustration of wasted effort leads to abandonment rather than acceptance
• Forced account creation — while PrestaShop technically supports guest checkout, the default flow strongly encourages account creation at step 1. Many customers see the registration form and leave immediately
• No progress indication on mobile — the default checkout does not always make it clear how many steps remain. A customer on step 2 of 5 has no idea whether they are almost done or just getting started. This uncertainty drives abandonment, especially on mobile where patience is lower
• Payment method discovery too late — customers want to know whether their preferred payment method is available before they fill in three pages of forms. Discovering that your store does not accept Apple Pay or PayPal at the very last step is the worst possible moment for that surprise

These are not theoretical problems. Every one of them shows up in checkout funnel analytics as a drop-off point. If you have Google Analytics or Matomo set up on your store, look at the step-by-step funnel — the biggest drops are typically between step 1 and 2 (account creation friction) and between step 3 and 4 (shipping cost surprise).

One Page Checkout

A one page checkout puts everything on a single screen: address fields, shipping options, payment methods. The customer fills it all in without navigating away. When they select a shipping method, the totals update instantly via AJAX — no page reload.

Why it works

• No page loads — everything updates in place, which eliminates the biggest source of friction
• Full visibility — the customer can see the total cost including shipping before they commit, which reduces surprise abandonment at the payment step
• Faster completion — average checkout time drops from 90 seconds to under 40 seconds for new customers
• Mobile-friendly — a well-built one page checkout scrolls naturally on mobile, while a multi-step checkout feels like navigating through a bureaucratic form

The technical side

A one page checkout is more complex under the hood than it appears. Every time the customer changes their country, the available shipping methods need to update. When they select a shipping method, the total needs to recalculate. When they choose a payment provider, the payment form needs to load. All of this happens via AJAX requests — and if those requests are slow or unreliable, the experience degrades quickly.

A well-built one page checkout module handles all of these dependencies gracefully: loading indicators while shipping recalculates, inline validation that catches errors before submission, and smart field ordering that minimizes the number of recalculations needed. A poorly built one can actually be worse than the default checkout — imagine a form that flickers and jumps every time you change a field.

The address field order matters more than you think. If the country selector is at the bottom of the address form, the customer fills in their entire address before selecting their country — and then all the shipping options change. Put the country selector first, so everything downstream is already correct by the time they finish the form.

When it is not ideal

• High-value orders (€500+) — customers buying expensive items often want to slow down and verify each detail. A one page layout can feel rushed for a €2,000 purchase
• Complex B2B orders — if your customers need to enter VAT numbers, select from multiple delivery addresses per company, or attach purchase orders, a single page can become overwhelming
• Stores with 15+ shipping options — when you have many carriers with complex rules, a single page can become very long and harder to navigate than a focused shipping step

For most B2C stores selling products under €200, a one page checkout is the single biggest conversion improvement you can make. The numbers consistently show 10-30% more completed orders compared to multi-step.

Express Checkout (Apple Pay, Google Pay, PayPal)

Express checkout skips the form entirely. The customer clicks a button — Apple Pay, Google Pay, or PayPal — and uses information already stored in their payment provider account. Name, address, card number: all pre-filled. On mobile, this means a fingerprint or face scan and the order is placed in under 10 seconds.

Where to place express buttons

• Product pages — a "Buy Now with Apple Pay" button next to "Add to Cart" lets impulse buyers skip the cart entirely. This works exceptionally well for stores with low average order values or consumable products that customers re-order frequently
• Cart page — express buttons here catch customers who have already decided what they want but do not want to fill out forms
• Mini-cart dropdown — for the ultimate shortcut: add to cart, click express pay in the dropdown, done
• Checkout page — as an alternative to the traditional form, even on a one page checkout

How express checkout actually works

When a customer clicks "Pay with Apple Pay," a lot happens behind the scenes. The browser triggers the Payment Request API, which communicates with the payment provider (Stripe, in most PrestaShop setups). The payment provider creates a payment sheet — the native Apple Pay or Google Pay overlay — pre-filled with the customer's stored address and card. Once the customer authenticates (Face ID, fingerprint, or device PIN), the payment provider returns a payment token and the shipping address to your store. Your module then creates the PrestaShop order, assigns the address, calculates shipping, and processes the payment — all without the customer ever seeing a form.

This is why express checkout requires a payment gateway that supports the Payment Request API. Stripe supports it natively. PayPal has its own express flow. Many older PrestaShop payment modules (bank transfer, check, custom gateways) cannot participate in express checkout because they have no API to create a payment sheet.

A practical consideration: express checkout only provides a shipping address, not a billing address. For most B2C orders this is fine — the billing address matches the shipping address. But for B2B customers who need a separate company billing address, express checkout cannot handle this. They will need the full form.

The reality check

Express checkout sounds perfect, but it depends heavily on your customer base. Apple Pay works only in Safari (desktop and iOS). Google Pay works in Chrome and Android. PayPal Express requires customers to have a PayPal account. If your customers are primarily desktop Firefox users (surprisingly common in B2B), none of these express options will be available to them.

Also, express checkout handles simple orders well — one shipping address, standard delivery. If the customer needs to add a gift message, choose a specific time slot, or split the order between addresses, they will need to fall back to the regular checkout anyway.

One more thing: express checkout availability varies by country. Apple Pay is available in about 70 countries. Google Pay in about 40. If you sell to customers in countries where these services are not yet available, the express buttons simply will not appear — which is actually good design, but means you should not rely on express checkout as your only fast option.

Best for: mobile-heavy stores, repeat customers, products under €100, impulse purchases.

Embedded Checkout

An embedded checkout takes the checkout form out of the dedicated checkout page and places it directly on other pages throughout your store. The most common approach is embedding a compact checkout form in the site footer — visible on every page, always ready. But you can also embed it on product pages, category pages, or even in a slide-out panel triggered by clicking "Add to Cart."

The idea is radical: why should the customer navigate to a separate page to check out? If the checkout form is already on the page they are browsing, the transition from "shopping" to "buying" becomes invisible. The customer adds a product, scrolls down (or opens a panel), and the checkout fields are right there. No page load, no navigation, no mental shift from "browsing mode" to "buying mode."

Where to embed checkout

• Site footer — a persistent mini checkout form at the bottom of every page. Once the customer has items in their cart, the footer expands to show address fields, shipping options, and a payment button. This works because the footer is always there — the customer does not have to go looking for the checkout
• Product pages — checkout fields appear directly below (or beside) the product details. The customer never leaves the product page. This is especially effective for single-product stores, landing pages, and digital goods where the buying decision happens on the product page itself
• Slide-out / modal panel — clicking "Add to Cart" opens a side panel with the full checkout form instead of (or alongside) a mini-cart. The customer completes the purchase without ever navigating away from the current page
• Category pages — for stores with simple, low-consideration products (phone accessories, consumables), a compact checkout widget next to each product listing lets customers buy individual items without ever visiting a product page or cart

Why it works

The psychological mechanism is powerful: there is no "commit" moment. Traditional checkout requires a deliberate action — clicking "Proceed to Checkout" — that signals to the customer's brain "now you are spending money." This is the moment doubt creeps in. An embedded checkout removes that transition entirely. The customer is simply filling in fields on a page they were already looking at.

Footer-embedded checkout has an additional advantage: it is persistent. As the customer browses products, the checkout form travels with them. There is no risk of losing the customer during the navigation from product → cart → checkout, because those transitions do not exist. The checkout is always one scroll away.

The challenges

Embedded checkout adds technical complexity. The checkout form needs to work on every page type — product pages, category pages, CMS pages — each with different layouts and JavaScript environments. Shipping calculations need to update in real time as the customer changes their address, even though the form is not on a dedicated checkout page. Payment provider scripts (Stripe Elements, PayPal buttons) need to initialize correctly regardless of which page the form is embedded on.

There is also a UX balance to strike. A footer checkout form needs to be compact enough not to dominate every page, but complete enough to handle the full checkout flow. Collapsible sections work well here — show a summary line ("2 items, €45.00 — Ready to checkout?") that expands into the full form when clicked.

On mobile, a persistent footer checkout can eat into screen real estate. The best implementations use a sticky bottom bar with a "Checkout" button that expands into a full-screen overlay, rather than trying to squeeze form fields into the page footer on a small screen.

Best for: single-product stores, digital goods, landing pages, stores with impulse-buy products, subscription services where the product selection is simple but you want zero friction between "I want this" and "I bought this."

One-Click Checkout (Returning Customers)

One-click checkout is specifically for returning customers who have previously placed an order. Their address and payment information are already stored (with their consent), so repeating the purchase is literally a single click.

This is not a checkout layout — it is a feature that works on top of any checkout type. When a logged-in returning customer views their cart, instead of showing the full checkout form, you show a summary of their saved details with a single "Place Order" button.

The conversion rate for one-click checkout is dramatically higher than any other method — we have seen 90%+ completion rates on repeat orders. But it only applies to returning customers with saved payment methods, so it supplements your main checkout rather than replacing it.

An important detail: one-click checkout requires stored payment tokens, which means PCI-compliant tokenization through a payment provider like Stripe. The actual card data is never stored on your server — only a token that references the card at the payment provider. This is both a security requirement and a practical one: it means one-click checkout only works with payment methods that support tokenization. Bank transfers, cash on delivery, and check payments cannot be one-clicked.

Think about how Amazon handles returning customers: when you are logged in, you can place an order with a single click because your address and payment are already set. This is exactly the same concept, just applied to PrestaShop. The difference in conversion rate between "fill out the same form you filled out last time" and "confirm and pay" is enormous.

Best for: stores with high repeat purchase rates, subscription-style products, consumables.

The Hidden Complexity: Dynamic Carriers and Payment Methods

Every checkout type described above faces the same underlying challenge that most guides never mention: nothing on the checkout page is static. The available shipping carriers, their prices, and the available payment methods all change dynamically based on what the customer has in their cart, where they live, and sometimes even who they are.

Dynamic carriers

PrestaShop calculates available carriers based on a matrix of conditions: the delivery country and zone, the total weight of the cart, the total price of the cart, the dimensions of individual products, and any carrier-specific restrictions the merchant has configured. Change any one of these variables and the list of available carriers — and their prices — can change completely.

Consider a practical example. A customer in France adds a 500g product to their cart. Colissimo, DPD, and Mondial Relay are available. They add a second product that weighs 25kg — suddenly only DPD and a freight carrier are available, because Colissimo has a 30kg limit and Mondial Relay a 20kg limit per parcel. The customer then changes their delivery country to Switzerland — now the EU-only carriers disappear and only international carriers remain, with completely different prices and delivery times.

This is why a well-built checkout must recalculate shipping every time the customer changes their address or modifies their cart. On a one page checkout, this means AJAX calls that update the carrier list and prices in real time. On a multi-step checkout, the carrier list is only calculated when the customer reaches the shipping step — which means any address change on step 2 requires rebuilding step 3 entirely. On an embedded checkout, the challenge is even greater: the carrier calculation must happen on pages that were never designed for it (product pages, the footer, category listings).

Stores with complex shipping setups — multiple warehouses, carrier weight limits, zone-based pricing, free shipping thresholds, product-specific carrier restrictions — put more stress on the checkout than simple flat-rate shipping. If your checkout module does not handle these recalculations gracefully (with loading indicators, smooth transitions, and no page jumps), the customer sees a confusing flicker of changing options and prices. This is one reason why testing your checkout with realistic cart scenarios matters more than testing with a single lightweight product.

Dynamic payment methods

Payment methods are equally dynamic, though many merchants do not realize it. The available payment options can change based on:

• Cart total — many payment providers have minimum and maximum transaction limits. Klarna might only appear for orders between €35 and €1,500. Bank transfer might only show for orders above €500. PayPal may have a maximum of €10,000
• Customer country — iDEAL only works for Dutch customers. Bancontact is Belgium-only. BLIK is Poland-only. Sofort works in Germany, Austria, and a few other countries. A German customer and a Spanish customer looking at the same checkout will see different payment options
• Device and browser — as mentioned in the express checkout section, Apple Pay and Google Pay are browser-specific. If your customer switches from their iPhone to a desktop Firefox browser, the express payment buttons disappear entirely. This is not a bug — it is a platform limitation that your checkout must handle gracefully by showing alternative payment methods
• Product type — some merchants disable cash on delivery for high-value items (fraud risk) or disable certain payment methods for digital goods (no delivery address to verify)
• Customer group — B2B customers might see "Payment on Invoice (Net 30)" while B2C customers see credit card and PayPal. Wholesale customers might only have bank transfer available
• Currency — not all payment providers support all currencies. A multi-currency store might offer Stripe in EUR and USD but need a different provider for PLN or CZK

The checkout module needs to resolve all of these conditions in real time. When the customer changes their country, both the carrier list and the payment method list may need to update simultaneously. When the cart total changes (because shipping was added, or a coupon was applied), payment methods with minimum/maximum thresholds need to be re-evaluated.

Why this matters for checkout choice

The more dynamic your carriers and payment methods are, the more important your checkout module's architecture becomes. A one page checkout handles this best because all the variables are visible on one screen — change the country and both carriers and payment methods update together. The customer sees the full picture immediately.

A multi-step checkout can actually hide problems: the customer selects a payment method on step 4, but if they go back to step 2 and change their address, the payment method they already selected might no longer be available. Poor modules do not handle this gracefully — the customer hits "Confirm" and gets an error, or worse, the order silently falls back to a default payment method.

Express checkout (Apple Pay, Google Pay) sidesteps most of this complexity because the payment method is determined by the device, and the address comes from the payment provider. But it also means the customer cannot choose a different carrier — express checkout typically uses the cheapest or default carrier. If carrier selection matters to your customers (express delivery vs standard, pickup points vs home delivery), express checkout alone is not enough.

An embedded checkout faces the hardest version of this problem: the checkout form exists on pages where PrestaShop's carrier and payment calculation hooks were never designed to run. The module must initialize these calculations independently of the checkout controller, which requires deep integration with PrestaShop's cart and carrier logic.

The takeaway: test your checkout with real scenarios. Add heavy products, change countries, apply coupons, switch between customer groups. If your checkout handles all of these transitions smoothly — no errors, no missing options, no price jumps — you have a solid implementation. If it breaks on edge cases, your customers will find those edges before you do.

Guest Checkout: The Often-Overlooked Essential

There is one feature that matters regardless of which checkout layout you choose: guest checkout. Allowing customers to complete a purchase without creating an account is not a nice-to-have — it is essential.

The data is clear: forced account creation is the second most common reason for cart abandonment, right after "extra costs too high." About 24% of customers will leave if they are required to register. Think about it from their perspective: they want to buy a €15 phone case, and you are asking them to create yet another password, verify an email, and remember login credentials for a store they may never visit again.

The best approach is to offer guest checkout as the default, with an optional "save your details for next time" checkbox that creates an account after the order is placed. The customer gets their purchase with zero friction, and if they choose to save their details, they get the one-click experience next time. Everyone wins.

PrestaShop supports guest checkout out of the box (Settings → Orders → Allow Guest Checkout), but many store owners leave it disabled because they want customer data for marketing. This is short-sighted: a completed guest order gives you more usable data (name, email, address, purchase history) than an abandoned cart from a customer who refused to register.

B2B Checkout Considerations

B2B checkout deserves its own section because it has fundamentally different requirements from B2C. A consumer buying a pair of shoes has simple needs: one address, one payment, ship it. A business buyer placing a procurement order may need:

• VAT number validation — EU intra-community sales require VAT ID verification for zero-rating. This validation needs to happen in real-time during checkout via the VIES database, and if the VAT number is invalid, the prices need to update to include VAT
• Separate billing and shipping addresses — the warehouse receiving the goods is rarely at the same address as the accounts payable department
• Purchase order numbers — many companies require a PO number on every invoice, and procurement staff may not have the authority to place orders without one
• Net payment terms — paying by credit card at checkout is the exception, not the rule, in B2B. Most business customers expect to receive an invoice and pay within 30, 60, or 90 days
• Tax display flexibility — B2B customers want to see prices excluding tax, while B2C customers on the same store expect prices including tax

A one page checkout can handle some of these requirements, but it gets crowded quickly. If your store serves both B2B and B2C customers, consider a hybrid approach: a streamlined one page checkout for B2C customers, with additional fields that appear when the customer indicates they are buying for a business (for example, when they tick a "I am buying for a company" checkbox or when they enter a VAT number).

Modules like Automatic EU VAT Checker, B2B Deferred Payment Terms, and Tax Display Switcher handle these B2B-specific requirements and integrate with one page checkout modules so you do not have to choose between speed and functionality.

When Multi-Step Checkout Is Actually Better

We sell checkout modules for a living, so take what we say with a grain of salt — but honesty builds better relationships than a hard sell. There are legitimate cases where the traditional multi-step checkout outperforms one page:

• Luxury and high-ticket items — when someone is spending €1,000+ on a watch or a piece of furniture, they want to feel in control. A step-by-step process feels deliberate and trustworthy. Rushing the checkout on an expensive purchase can actually increase anxiety. The customer wants to see their order summary clearly, verify the shipping method is insured, and double-check the billing address — each on its own screen where nothing else competes for attention
• Complex B2B purchases — orders with VAT validation, purchase order numbers, multiple approval steps, and net-30 payment terms benefit from a structured flow. A one page checkout would need to show all these fields at once, which is visually overwhelming
• Configurable products — if the checkout includes product customization (engraving, color selection, size configuration), each step serves a purpose and the customer expects a guided experience
• Markets with low digital trust — in some markets, customers are more comfortable with a checkout that looks "official" and structured. A one page form can feel too casual for customers who are already nervous about buying online. Adding trust badges, security certifications, and clear step indicators can make the multi-step experience feel more secure than a single-page form
• Heavily regulated products — if you sell age-restricted goods, products requiring license verification, or items with legal disclaimers that require explicit consent, dedicated checkout steps for compliance make both legal and UX sense. Burying a mandatory age verification checkbox at the bottom of a one page checkout is asking for trouble

The key insight is: match your checkout to your customer's mental model. A teenager buying a phone case wants speed. A procurement manager placing a €5,000 order wants control and documentation. Serve both well.

Comparing Checkout Types

How to Choose the Right Approach

Start by answering three questions:

1. What is your average order value? Under €100, optimize for speed (one page + express). Over €500, optimize for trust (structured flow, clear summaries, prominent security indicators). Between €100 and €500, one page checkout with strong order summary visibility is usually the sweet spot.
2. What device do your customers use? Check your analytics. If 60%+ of traffic is mobile (this is the case for most B2C stores today), express checkout buttons are not optional — they are essential. Also check which browsers your mobile visitors use — Safari share tells you how many potential Apple Pay users you have.
3. Do customers buy once or come back? High repeat rates mean one-click checkout will have a big impact. Low repeat rates mean focus on first-time buyer experience. If your repeat rate is below 10%, investing in one-click checkout is less important than nailing the first-time buyer flow.

For most PrestaShop stores, the answer is: one page checkout as the base, with express checkout buttons layered on top. This covers both the customer who wants to fill in a form at their own pace and the one who just wants to pay and move on.

A decision framework by store type

• Fashion / apparel store — one page checkout + express checkout + guest checkout. Average cart has 2-3 items, price range €30-€150, high mobile traffic. Speed wins.
• Electronics / high-value store — one page checkout with prominent order summary + security badges. Express checkout as option but not the focus. Customers want to verify what they are buying.
• B2B / wholesale store — multi-step or one page with expandable B2B fields. VAT checker integration. Deferred payment terms. Purchase order field. Skip express checkout — your buyers do not use Apple Pay for business purchases.
• Single-product / landing page store — embedded checkout in the footer or directly on the product page. No cart step, no checkout page. Express checkout buttons alongside. The customer should go from "I want this" to "I bought this" without ever leaving the page they are on.
• Subscription / consumables store — one-click reorder for returning customers is your highest-value feature. Invest heavily in the returning customer experience since most of your revenue comes from repeat orders.

Measuring Your Checkout Performance

Changing your checkout is not a one-time decision. You should measure the impact and iterate. Here are the metrics that matter:

• Checkout completion rate — percentage of customers who start checkout and finish it. This is your primary metric. The industry average for a standard multi-step checkout is around 30-35%. A good one page checkout pushes this to 45-55%.
• Cart-to-checkout rate — percentage of customers with items in their cart who actually start the checkout process. If this number is low, the problem is not your checkout — it is your cart page (shipping estimate, coupon field, trust signals).
• Step-by-step drop-off — for multi-step checkouts, where exactly do customers leave? If most drop-offs happen at the shipping step, the problem might be shipping cost surprise, not the checkout layout.
• Mobile vs desktop completion rate — compare these separately. If your mobile completion rate is significantly lower than desktop, express checkout and form optimization should be your priority.
• Time to complete — how long does the average checkout take? Anything over 2 minutes on mobile is too long. Under 30 seconds (with express checkout) is where you want to be for mobile impulse buyers.

Set up these measurements before you change anything. Otherwise, you have no baseline to compare against and no way to know if your changes actually helped.

Implementation in PrestaShop

PrestaShop does not offer one page checkout or express checkout out of the box. You need a module. Our Checkout Revolution module combines all of the above in a single package:

• One page checkout layout with real-time validation and smart field ordering
• Apple Pay, Google Pay, and PayPal Express buttons on product pages, cart, mini-cart, and checkout
• One-click reorder for returning customers with stored payment tokens
• Embedded checkout — place the checkout form in your footer, on product pages, or in a slide-out panel
• Guest checkout with optional post-purchase account creation
• Conditional field display — show B2B fields only when relevant
• Compatible with PrestaShop 1.6 through 9.1

For stores with B2B requirements, pair it with our Automatic EU VAT Checker for real-time VIES validation, B2B Deferred Payment Terms for net-30/60/90 invoicing, and Tax Display Switcher so B2B and B2C customers see prices the way they expect.

But regardless of which module you use, the principles in this guide apply. Understand your customers, pick the checkout approach that matches their expectations, and measure the results. The best checkout is the one your specific customers are most likely to complete.