PrestaShop Checkout: The Process, the Module, and Your Best Options

Last updated: June 2026.

"PrestaShop checkout" means two different things — let's untangle them

Half the support tickets we field about "checkout" turn out to be about the wrong thing entirely. There's the checkout process (the multi-step flow built into every PrestaShop store) and there's ps_checkout, a specific payment module developed by PrestaShop SA in partnership with PayPal. They sound the same. They aren't. Replacing one doesn't replace the other.

We've shipped Checkout Revolution since 2018 because we couldn't get the native checkout to work properly for our clients, and we've seen every variant of PrestaShop checkout broken in production — cart wipes on the payment step, "no payment method available" with five active modules, 3DS redirects landing on 404s. This article is the version of the docs we wish existed when we started building checkout modules.

How the PrestaShop Checkout Process Works

The Default Multi-Step Flow

Every PrestaShop store ships with the same five-step flow, spread across separate page loads:

1. Cart review — products, quantities, totals
2. Personal information — login, register, or guest
3. Address — delivery and invoice
4. Shipping — carrier selection based on the address, weight, and dimensions
5. Payment — payment method and order confirmation

After payment the customer lands on the confirmation page. That's the foundation every theme inherits and every payment module plugs into. It is also the friction we get paid to remove — five page loads for one purchase is a lot.

The default checkout is a sequence, not a payment module.

This contact sheet is built from a fresh ps9-dev checkout run: product added to cart, guest details entered, address saved, carrier selected, payment step reached. When a payment provider fails at the last step, the earlier steps still look healthy — which is why we debug step by step, never assume.

What changed between 1.7 and 8/9

The flow itself has stayed put. The plumbing under it has moved a lot:

• Theme architecture. Classic still uses jQuery-heavy AJAX validation per step. Hummingbird (the 8/9 alternative) rewrote it on a modern stack — if you're still on Classic, you're maintaining frontend code most of the ecosystem has moved on from.
• Payment hooks. paymentOptions replaced the older displayPayment/displayPaymentEU in 1.7. On 8 and 9, legacy payment hooks no longer fire at all. Any module still using displayPayment is silently invisible. We've found this in client shops more than once.
• Symfony migration. Back-office order management is Symfony now. The front-office OrderController still runs on legacy. Module authors targeting both worlds need to know which side of the line they're on.
• Stricter CSP defaults on 8+. The default Content Security Policy headers can block payment-provider JavaScript outright. "My checkout went blank after upgrading" is almost always this.
• PHP 8.1+ on PS 9. Any payment module written against PHP 7 features will surface its sins on upgrade.

If a payment module went invisible after an upgrade to 8 or 9, the fastest way to confirm it's the dead hook is to grep your modules folder for the old one. Anything that still registers displayPayment or displayPaymentEU but never paymentOptions won't render at the payment step:

# modules that still register a legacy payment hook
grep -rln "displayPayment\b\|displayPaymentEU" modules/*/

# of those, which never register the modern hook?
for d in $(grep -rln "displayPayment" modules/*/); do
  grep -q "paymentOptions" "$d" || echo "NO paymentOptions: $d"
done

Each NO paymentOptions line is a module that needs updating before it can take payments on 8/9. The fix is the module author's job — a payment hook that's been removed from core can't be shimmed back into firing — but knowing which module is the culprit turns "checkout is broken" into a specific, answerable problem.

The OrderController and how it fires

The checkout is driven by controllers/front/OrderController.php. It loads the cart, fires hooks, walks through a CheckoutProcess object that holds each step as its own class (CheckoutAddressesStep, CheckoutDeliveryStep, CheckoutPaymentStep, all inheriting from AbstractCheckoutStep).

That modular layout is genuinely well designed — modules can override one step without replacing the whole flow. The catch is that "well designed" doesn't mean "easy to reason about." When five modules each tweak a different step, debugging takes time. Every checkout problem we've ever fixed has started with reading OrderController end to end.

What happens at each step

Behind every step, validation runs and hooks fire that modules use to extend the process:

• Address validation. Required fields, country/state combos, tax rule recalculation based on delivery country.
• Carrier selection. Available carriers filtered by zone, weight, dimensions, restrictions. actionCarrierProcess is the hook to intervene on.
• Payment rendering. Each active payment module registers via paymentOptions and rendering order is whatever you set in Payment > Preferences.
• Order validation. actionValidateOrder fires on confirmation — payment, stock decrement, emails, order row creation, the lot.

This is what makes the checkout extensible. It is also why two badly written modules can interfere with each other and produce errors that nobody can diagnose without `var/logs/` in one hand and the database in the other.

Why your checkout is slow

A slow checkout costs money. Every second of load time costs conversions. When we audit checkout performance, the bottlenecks are nearly always one of these:

• Too many modules on checkout hooks. We have seen shops with 15+ modules firing on displayPayment, displayBeforeCarrier, actionCarrierProcess. Each one adds milliseconds. Together they add seconds.
• External API calls. Live UPS/FedEx rate quotes, TaxJar tax calculation, address verification — any one of these can stall the entire checkout when the upstream service hiccups.
• Carrier configurations gone wild. Dozens of carriers with overlapping zone/weight rules force PrestaShop into long queries on every delivery-step render.
• Cart rule bloat. Hundreds of active cart rules mean hundreds of evaluations per cart. Expired rules should be deleted, not deactivated.
• Missing indexes on cart-rule and specific-price tables. On shops that have been running for years, these tables are huge and frequently un-indexed.
• No OPcache, no Redis. Self-explanatory. If you're still on file sessions and disabled OPcache in 2026, the rest of this article won't save you.

To find the culprit on a staging copy, enable the profiler:

// staging only
define('_PS_DEBUG_PROFILING_', true);

Never leave that on production. Run a test checkout, read the profiler table, the slowest module is usually visible before you need deeper logging. We learned this the hard way on a client shop where one currency-conversion module was eating 1.8 seconds per checkout render.

The checkout errors we see most

"No payment method available." The most googled error. It means no payment module returned anything from paymentOptions. The usual suspects:

• Currency or country restriction excludes the customer's cart
• Payment > Preferences excludes the current carrier, country, or customer group
• The payment module has a PHP error and silently fails — check var/logs/
• On PS 8+, CSP headers are blocking the module's JavaScript

Usually a configuration mismatch, not a theme problem.

In the captured PS9 checkout, cart/address/carrier all worked but the payment step came back empty. The back-office matrix gave it away: native payment modules were restricted to a country other than the test cart's France.

Payment > Preferences is where to look first.

Currency, customer group, country, and carrier restrictions decide whether a module ever appears at checkout. An installed-and-active payment module can still be invisible for the customer if any restriction excludes the current cart context.

"An error occurred while processing your order." The most generic message PrestaShop ships. Start with the actual exception in PHP error log and PrestaShop logs. Then check stock availability (a product going out of stock between cart and payment fails the order), and cart rule conflicts (an invalid voucher quietly poisoning final validation).

Cart emptying on checkout. Always a cookie or session issue. SSL misconfiguration, mismatched shop/SSL domains, full session partition, or (and we have seen this one ship) a module calling Context::getContext()->cart = new Cart() in a checkout hook and accidentally resetting the cart. If you suspect a module, disable them one by one until checkout starts behaving.

Address validation failures. Required state/region on the country that the customer didn't see, malformed address format string, or an over-strict postcode regex. International > Locations > Countries is where to look.

3DS redirect failures. Customer authenticates but lands on an error page or never returns. Causes: return URL is HTTP not HTTPS, session expired during 3DS, callback URL unreachable from the bank, or a multi-domain setup where the 3DS return URL points to a different domain than the customer was shopping on.

Cart rules and discounts: the layer that breaks last

Discount logic is the part of checkout that confuses merchants and developers in equal measure. Cart rules (vouchers, promos, automatic discounts) and product-level specific prices interact in ways that aren't always intuitive.

• Cart rules are evaluated in priority order — some apply to the whole cart, some to specific products or categories.
• Specific prices apply before cart rules. A product already on sale may not qualify for further discounts.
• Stacking restrictions let you mark rules as non-combinable, but the "which one wins" logic isn't obvious in multi-currency stores.

Cart rules are not just promo codes.

The real ps8-dev back office list shows each cart rule's priority, code, quantity limit, expiry, and active flag. When discounts behave strangely at checkout, this list is where we start before blaming the payment module.

Free shipping cart rules and how they interact with carriers

A "free shipping" cart rule does not make every carrier free. If the rule is not restricted to specific carriers, it applies to whatever the customer picks. If it's restricted to certain carriers, only those go to zero — the others still display their normal price. Country and zone restrictions on the cart rule narrow it further. If multiple free-shipping rules apply, the highest-priority valid one is used and the rest are silently dropped.

The priority and stacking trap

Priority matters more than most merchants realise. Take a common case:

• Rule A (priority 1): 20% off entire cart, non-combinable
• Rule B (priority 2): Free shipping over 50 EUR

Because Rule A is non-combinable and goes first, Rule B never applies. The customer gets 20% off and still pays shipping. Either make Rule A combinable or build free shipping into Rule A directly.

The other classic: a customer enters a 10 EUR voucher, but the cart already has an automatic 15% discount that's non-combinable. PrestaShop rejects the voucher with a useless "not valid" message. We have rebuilt cart-rule logic for clients more than once because it was easier than explaining this to support staff.

Minimum amount on cart rules

The minimum-amount check runs before or after other discounts depending on configuration, and it can include or exclude taxes and shipping. Result: a cart worth 110 EUR pre-discount but 95 EUR post-discount may or may not pass a "minimum 100 EUR" rule. Always test minimum-amount rules with real cart scenarios across countries before going live.

Guest checkout vs account creation

Guest checkout is an order setting, not a payment setting — Shop Parameters > Order Settings in PS 8. We enable it on almost every B2C client because forcing account creation kills mobile conversion. B2B is the exception: account-based purchasing, repeat-order history, and proper invoicing usually outweigh the one-form friction.

Guest checkout lives in Order Settings.

This ps8-dev capture shows the actual Enable guest checkout toggle. Switching it off changes the very first step of checkout before any carrier or payment module gets a look in.

The ps_checkout module — what it actually is

What ps_checkout does (and doesn't do)

The PrestaShop Checkout module (technical name ps_checkout) is a free payment module developed jointly by PrestaShop SA and PayPal. It ships pre-installed on every PrestaShop since 1.7.5.

Here is the distinction that trips merchants up daily: ps_checkout is a payment module, not the checkout flow. It does not change the steps, the layout, the order of fields, or anything else about how PrestaShop walks the customer through the purchase. It only renders payment options at the payment step. Anyone selling you "one-page checkout via ps_checkout" hasn't read the module's own README.

What it offers

For free, the feature list is reasonable:

• Card payments (Visa, Mastercard, AmEx) via PayPal-hosted fields
• PayPal wallet
• Apple Pay and Google Pay where available
• Local methods — iDEAL, Bancontact, BLIK, others depending on market
• Pay Later / Pay in 3-4 (PayPal BNPL)
• 3DS2
• 20+ currencies through PayPal's network

Full source on the ps_checkout GitHub repository.

Transaction fees

The module is free. The processing isn't. Treat any quoted fee as a market-specific example: PayPal, Stripe, Mollie, Adyen all vary by merchant country, card origin, method, currency, volume, and risk profile. Get a quote in writing for your own merchant country before committing.

Pricing references, last checked May 2026: Stripe France, Mollie, Adyen, PayPal UK. Use the equivalent page for your merchant country.

Comparing payment providers — fees aren't everything

We've watched merchants pick a provider over a 0.3 EUR difference per order, then lose customers at the payment step because the local method they trust wasn't offered. Authorisation rate, local payment coverage, refund flow, support quality, and back-office debuggability matter at least as much as the headline percentage.

ps_checkout vs Stripe vs Mollie at a glance

Installing and configuring ps_checkout

Install the module (pre-installed on new stores, otherwise from Addons), link a PrestaShop Addons account, connect your PayPal Business account via the onboarding wizard (personal PayPal accounts are not supported and that trips people up) pick which payment methods to offer, check rounding/currency settings against PayPal's expectations, and test in sandbox before going live. We always do at least one sandbox order per currency the shop sells in.

Setup is account onboarding plus payment configuration.

The module can be installed without the payment experience being complete. PrestaShop account linked, PayPal business account associated, rounding compatible, and at least one sandbox or live payment confirmed from the checkout — only then is it done.

Uninstalling ps_checkout

Modules > Module Manager, find ps_checkout, Disable first (safe — stops it without losing data). To remove fully, Uninstall, then optionally delete modules/ps_checkout/. Make sure another payment module is configured first or your shop will throw "No payment method available" on the next checkout.

The intermediary architecture (and why it matters)

This is where ps_checkout differs from a direct integration. Stripe, Mollie, Adyen settle payments straight into your merchant account. ps_checkout routes them through PrestaShop SA's PayPal commerce platform account — PrestaShop SA is the payment facilitator.

What this changes in practice:

• You link your PayPal business account through PrestaShop's flow, not directly with PayPal
• Settlement timing depends on both PayPal's policies and PrestaShop SA's platform configuration
• Chargebacks go through an extra layer — disputes take longer to resolve
• Raw transaction data is less visible than on a direct gateway

It isn't inherently bad — Shopify Payments works the same way. But for high-volume or regulated merchants, it adds operational complexity worth knowing about before you commit.

The limitations we keep seeing

From GitHub issues, community forums, and the support tickets clients have brought us:

• Theme compatibility. ps_checkout works best on Classic. Heavily customised themes routinely break hosted payment field rendering.
• The infinite spinner. Payment form never finishes loading. Usually JavaScript conflict with another module or a CSP header blocking PayPal scripts.
• Unhelpful 3DS errors. When 3DS fails, the customer sees a generic message that doesn't help them retry — abandonment that could have been recovered with clearer wording.
• No direct support. Help comes through community channels. For shops actively losing money during a payment outage, this is the part that hurts most.
• Upgrade risk. Major versions have introduced breaking changes. Fast feature pace, fragile upgrades. Test in staging every time.

None of these are dealbreakers in isolation. Together they are why we always test ps_checkout updates on a staging copy first.

When ps_checkout makes sense

Despite all the above, it's a reasonable starting choice for:

• New stores that need to accept payments tomorrow without upfront cost
• Single-market shops with no complex multi-currency settlement requirements
• Budget-conscious merchants who'd rather pay per transaction than buy modules
• Simple catalogues — no subscriptions, no pre-orders, no exotic payment workflows

Customising the PrestaShop checkout

What you can change without modules

Before adding third-party code, several things can be changed with built-in tools:

• Theme templates. Edit checkout Smarty templates in your child theme — layout, field order, custom content between steps.
• CSS. Colours, spacing, buttons, typography. Brand alignment without touching logic.
• Carrier configuration. Carrier names, descriptions, delivery estimates, display order.
• Payment module order. Payment > Preferences controls which method appears first.
• Required fields. Customers > Addresses controls which fields are mandatory.

All safe customisations that survive PrestaShop updates if you're using a child theme — which you should be. For more on this, our checkout optimization guide goes deeper.

Address formatting is built into PrestaShop.

The country editor controls which fields appear and how they're ordered. It matters at checkout because the delivery country drives validation, postcode rules, tax zone, and carrier availability.

Custom checkout fields

Most merchants we work with eventually need fields PrestaShop doesn't collect by default. Mobile for SMS notifications, company name and VAT number for B2B, gate codes and "leave with neighbour" delivery instructions, custom PO references for B2B procurement.

The back office address form (Customers > Addresses) covers the basics. For anything more involved you'll need either a custom module hooking into actionValidateOrder, or a checkout-field module from Addons. Both work — pick the one that matches your team's PHP comfort level.

Translating the checkout

If you sell internationally and your checkout shows English error messages on a French shop, you're losing orders. Customers won't pay for something they don't understand.

The pieces to translate:

• Step labels. International > Translations > Front office translations, your theme.
• Payment module strings. Each payment module has its own translation files, separate from core.
• Error messages. "Please enter a valid address" and friends — the strings that surface at the worst possible moment.
• Terms and conditions. The "I agree" checkbox links to a CMS page that must exist in every language.
• Address form labels. Country-specific formats must match the customer's locale.

The classic pitfall: installing a language pack does not translate module strings. We've shipped seven multi-store translations across our client base and this trap catches everyone the first time.

Search for the checkout string, then edit the theme domain.

This ps8-dev translation screen filtered for checkout shows strings from Shop > Theme > Actions. The same workflow applies to every label, button, and front-office message that appears during checkout.

One page checkout

The most-requested checkout customisation. Five separate page loads collapse to a single page where address, shipping, and payment fields are visible at once.

The reason it works isn't magical: it removes navigation friction and keeps the full order context visible. The conversion lift varies — traffic source, device mix, shipping complexity, payment methods, and required field count all matter. We don't claim a fixed percentage. We do consistently see fewer drop-offs in the analytics after one page checkout goes live on a client shop. Run it as an experiment, not as a universal "X% better" claim.

From a UX standpoint: every field visible at once, AJAX shipping cost updates, inline validation as the customer types, no progress indicator needed, persistent order summary. Done well, this is meaningfully calmer than a multi-step flow.

PrestaShop has no native one page checkout today. The roadmap lists it for PrestaShop 9.2 alongside Hummingbird v2, but it'll be optional and the multi-step flow won't go away. Until then, the answer is a module.

This is the territory where Checkout Revolution lives — we built it because every alternative either looked dated, broke on Hummingbird, or layered four other modules on top of itself to function. It's our flagship, and we genuinely believe it's the best one-page checkout on the market for PrestaShop. We'd say so even if we hadn't built it.

The structural difference, side by side.

Left: the default PrestaShop 9 multi-step flow on ps9-dev. Right: Checkout Revolution on ps178-dev — contact, shipping, payment, and order summary all visible on one page.

Express checkout — a different thing entirely

Express checkout is often confused with one-page checkout. It is not the same thing.

One page checkout = a complete replacement for the multi-step flow. Express checkout = wallet buttons (Apple Pay, Google Pay, PayPal Express, Link) on the product page and cart that skip the entire checkout. The customer taps Apple Pay on the product page, authenticates with Face ID, and the order is placed. No address form, no carrier selector, no payment step — the wallet supplies all of it.

This isn't a checkout flow replacement. It's an alternative entry point. On mobile, where every address-form field is a conversion-killer, it's the most impactful thing we can add to a client shop. We sell it as its own product: Express Checkout. For shops that want both (wallet buttons and a one-page checkout) Checkout Revolution bundles them.

Express checkout starts before the cart page.

This ps178-dev product page shows a real Express Checkout button right next to the product purchase controls. Depending on provider, browser, country, and wallet eligibility, the visible button can be a generic express button or wallet-specific Apple Pay, Google Pay, PayPal, or BNPL.

Embedded and modal checkout

A less common pattern: payment form appears in a modal or inline on the current page without navigating to a separate checkout URL. Stripe's Payment Element and PayPal's in-context flow both support this. The psychological distance between "I want this" and "I bought this" shortens. We use this approach in Checkout Revolution when the merchant wants the most aggressive friction-reduction possible.

Alternatives to ps_checkout

If ps_checkout doesn't fit, the mature options for PrestaShop payment processing:

Stripe

Stripe's Payment Element is the most developer-friendly payment integration in the market. We use it under the hood in Checkout Revolution because it gives us the broadest method coverage with the cleanest API.

• Direct merchant account — no intermediary on settlement
• 135+ currencies, automatic FX
• Apple Pay, Google Pay, Link, 40+ local methods
• The best API documentation in payments
• Stripe Radar for fraud protection

Best for: international stores, technical teams, anyone who wants full control over their payment data.

Mollie

A European payment provider with strong coverage for Netherlands, Belgium, Germany, and France.

• Per-transaction pricing, no monthly fees
• Native iDEAL, Bancontact, SOFORT, EPS, Giropay, KBC/CBC
• Solid PrestaShop module maintained by Mollie themselves
• Fast onboarding

Best for: EU shops, especially Benelux or DACH where local methods dominate.

Buy now, pay later: Klarna, Alma, Clearpay/Afterpay

BNPL is worth adding when basket sizes are large enough that splitting payments changes the buying decision. In PrestaShop it's almost always added via a payment provider or dedicated module — not through core checkout settings.

• Klarna — DACH, Nordics, UK, broader European stacks. Pay later, Pay in 3/4, financing, or express depending on integration.
• Alma — strong in France and southern Europe for installments on higher baskets.
• Clearpay/Afterpay — markets where Afterpay operates, including the UK as Clearpay.

The catch: BNPL fees are higher than card processing, and the merchant carries dispute/refund operational overhead. Check country eligibility and settlement schedule (upfront vs deferred) before enabling.

Local payment methods by market

If you sell across Europe, local payment coverage can matter as much as card pricing. Customers trust the method they already use with their bank or mobile wallet. Providers like Stripe and Mollie can expose these dynamically, but only if your PrestaShop module, currency, country restrictions, and provider account are configured for them.

For current method support, check Stripe payment methods, Mollie payment methods, and the Stripe Giropay deprecation notice.

Adyen

The enterprise option. Used by Booking.com and eBay, 250+ payment methods, intelligent routing, RevenueProtect fraud detection, and direct acquiring — Adyen is both processor and acquirer, removing intermediaries.

The trade-off is complexity and cost. For high-volume merchants Adyen often comes out ahead. For everyone else, Stripe, Mollie, or ps_checkout will get you live faster with fewer commercial and technical conversations.

Amazon Pay

Customers check out using their existing Amazon account — address, payment, and all. One-tap checkout with Amazon's stored details and A-to-Z buyer protection. A PrestaShop module is on Addons. Works well as a secondary option next to cards and PayPal, less well as a primary.

Standalone PayPal module

If you want PayPal without the PrestaShop SA intermediary layer, a standalone module connects directly to your PayPal business account. You get direct control over settlements and dispute handling, the same PayPal wallet experience customers know, and Pay Later configured through your own PayPal dashboard.

Best for: merchants who want PayPal but want a direct relationship with PayPal rather than a facilitated one.

Bank transfer — the zero-fee option people forget

Easy to dismiss because it's not a wallet or a card form. Still useful in the right shop. The native ps_wirepayment module displays your bank details during checkout and lets the customer place an order without a card gateway at all.

The commercial case is straightforward: no gateway fee, no card scheme fee, no intermediary payout schedule. For B2B, made-to-order, wholesale accounts, high-value baskets, and markets where bank transfer is culturally normal, that's genuinely attractive.

The operational cost is reconciliation. Funds don't confirm instantly, customers leave your site to complete payment in their banking app, and someone on your team has to match incoming transfers to orders before fulfilment. We've set this up for B2B clients and the day-2 cost is "ten minutes of accountant time per morning." Worth it for the right shop.

Reference: PrestaShop ps_wirepayment.

Checkout Revolution (yes, ours)

Full disclosure: Checkout Revolution is our flagship and we obviously think it's the right answer for most shops that have outgrown the native checkout. It combines one-page checkout and express buttons in a single Stripe-powered module. Buy buttons on product page, cart, and checkout. Apple Pay, Google Pay, PayPal, Link, cards, and 30+ additional methods via Stripe's Payment Element. Payments go direct to your Stripe account.

We built it because clients kept installing three or four separate modules to get functionality that should have shipped together. If you want a one-page checkout, express buttons, and a modern payment stack from one vendor with one support contract, this is what we'd suggest. If you just need a quick PayPal solution for a new shop, ps_checkout will do the job for less money.

Quick comparison

Checkout security and PCI compliance

This is not the section to skip. Customers trust your shop with their card details. A breach costs you money, customers, and rankings — in that order.

What PCI DSS actually means for your shop

PCI DSS applies to any business that accepts, processes, stores, or transmits card information. Your compliance burden depends entirely on how your checkout handles card data:

• SAQ A (lowest burden). Hosted payment fields or redirect — card data never touches your server. This is where ps_checkout, Stripe Payment Element, and Mollie hosted checkout put you. Aim here.
• SAQ A-EP. Payment-provider JavaScript runs on your page and captures card data, even if it's sent direct to the provider. Slightly more burden.
• SAQ D (highest burden). Card data passes through your server at any point. Custom payment forms that POST card numbers to your shop before forwarding fall here. Expensive, complex, almost never the right choice. Avoid.

Use payment modules with hosted fields or hosted checkout pages. Confirm the exact SAQ with your provider or acquirer because implementation details matter and we are not your QSA.

Hosted payment fields, not raw card inputs

Hosted payment fields are iframes served by the payment provider, embedded in your checkout page. The card number, expiry, and CVV look like part of your form but run on the provider's domain — your server never touches the card data. Every major provider supports this. If a module asks you to add raw HTML card inputs to your shop, walk away. That's a PCI red flag and a maintenance nightmare.

SCA, 3DS2, and SSL

SCA in the EU requires 3DS2 for most card payments. Your payment module must support it — anything 3DS1-only will see rising failure rates and eventually stop working at all. 3DS2 adds an authentication step that can hurt completion rates, so pick a provider with high 3DS2 success rates and don't show generic errors when authentication fails. "Try again" beats "an error has occurred" every time.

Every checkout page must be HTTPS. Without a valid certificate, browsers refuse to load hosted fields, Google penalises rankings, and "Not Secure" warnings spook customers. Let's Encrypt is free. After installing, verify that all HTTP redirects to HTTPS — mixed content will break payment modules silently.

Check HTTPS in the browser, not just configuration.

This is a real Chrome capture of the ps178-dev checkout over HTTPS. Modern Chrome dropped the green padlock, but the security control is still in the address bar — and the checkout URL must load securely before hosted payment fields will work reliably.

Measuring checkout performance

You can't improve what you don't measure. The metrics that matter for a PrestaShop checkout:

Key metrics

• Checkout completion rate — completed orders / checkout sessions. The single most important number.
• Checkout abandonment rate — percentage who start checkout but don't finish. Isolates checkout problems from window-shoppers.
• Step drop-off — which step loses most customers. If 40% leave at shipping, carrier options are your problem.
• Time to complete — longer correlates with higher abandonment.
• Payment failure rate — high rates usually mean 3DS misconfiguration or aggressive fraud rules.

A/B testing checkout changes

When you change layout, test against your own baseline. Send part of comparable traffic to the current checkout and part to the new flow, then compare completion rate, payment failures, AOV, and support tickets. Keep the test comparable — don't mix logged-in B2B, first-time mobile, and returning desktop into one conclusion if they behave differently.

GA4 enhanced ecommerce

The standard way to measure the funnel. Install a GA4 module that fires begin_checkout, add_shipping_info, add_payment_info, and purchase. Configure a funnel report under GA4 > Explore > Funnel Exploration with steps matching your checkout.

For accurate purchase tracking, consider server-side. Client-side JavaScript can be blocked, delayed, or lost across redirects. A server-side GA4 Measurement Protocol implementation triggered by PrestaShop order hooks is what we use on shops where revenue reporting actually matters.

What a "good" completion rate looks like

There isn't a universal number. A 5 EUR t-shirt shop, a B2B spare-parts catalogue, and a 3,000 EUR furniture shop will not behave the same way. Build a baseline from your own analytics, then watch for changes after checkout edits. If completion drops suddenly: forced account creation, surprise shipping costs, missing payment options, address validation, payment module errors. In that order.

What's coming: native one-page checkout in 9.2

PrestaShop's roadmap lists 9.2 for Q2-Q3 2026, including a native one-page checkout. That's a meaningful change — merchants on the right stack will be able to offer single-page checkout without a third-party module.

The caveats:

• Hummingbird v2 theme only. Classic shops won't see it.
• Optional, not the default. Multi-step stays available.
• Module authors will need to adapt their payment and shipping modules to the new flow.
• Roadmap timing is not a release date. It can move.

Should you wait? If you're launching today, no — waiting months (or longer) for something that may require a full theme migration is impractical. If you're already on Hummingbird and planning an upgrade, watch the roadmap. Our take on the PS 9.2 plans lives in PrestaShop's native OPC plans.

Picking the right checkout for your shop

No single "best" configuration exists. Our framework after a decade of building these:

• Just starting, tight budget. Default multi-step + ps_checkout. Free, it works, upgrade later.
• Established shop, high abandonment. One page checkout module. The conversion lift typically pays for itself in weeks.
• Mobile-heavy traffic. Express checkout with Apple Pay and Google Pay. Mobile address forms are the biggest conversion-killer in ecommerce.
• Selling across Europe. Mollie for strong local methods, or Stripe for broader international coverage.
• High volume. Direct integration with Stripe or Adyen — settlement, reporting, dispute handling all matter more at scale.
• Enterprise / omnichannel. Adyen for unified online + in-store on a single platform.
• Want everything from one vendor. Solutions that combine flow optimisation and payments in a single module rather than layering three or four.

Whatever you pick, test it. Place test orders on different devices, try different payment methods, apply discount codes, check what happens when things go wrong. Checkout is where revenue happens. It deserves more attention than most shops give it.

FAQ

Is ps_checkout the same as the PrestaShop checkout process?

No, and this is the single most common confusion we field. The checkout process is the multi-step flow (cart, personal info, address, shipping, payment) built into every PrestaShop store. ps_checkout is a free payment module developed by PrestaShop SA with PayPal that only renders payment options at the payment step. It doesn't change the steps, the layout, or the field order. Uninstalling ps_checkout doesn't change your checkout flow, and installing it won't give you a one-page checkout — anyone telling you otherwise hasn't read the module's README.

Why does my checkout say "No payment method available"?

It means no payment module returned anything from the paymentOptions hook. The usual causes, in order: a currency or country restriction excludes the cart; Payment > Preferences excludes the current carrier, country or customer group; the payment module hit a PHP error and failed silently (check var/logs/); or on PS 8+, CSP headers are blocking the module's JavaScript. Start with Payment > Preferences — a fully installed and active module can still be invisible if any restriction excludes the current cart context.

Why does my cart empty out on the payment step?

Cart wipes are almost always a cookie or session problem: an SSL misconfiguration, mismatched shop and SSL domains, a full session partition, or a module that resets the cart inside a checkout hook. Disable modules one at a time until checkout behaves to find a culprit. It's rarely the payment provider itself — the cart is gone before the provider is ever called.

Do I have to handle PCI compliance myself?

Keep card data off your server and your burden stays at the lowest level (SAQ A). Use a module with hosted payment fields or a redirect — ps_checkout, Stripe's Payment Element and Mollie hosted checkout all put you there, because the card number, expiry and CVV run on the provider's domain inside an iframe, not on your shop. If a module asks you to add raw HTML card inputs to your page, walk away: that pushes you toward SAQ D, which is expensive and almost never the right choice. Confirm the exact SAQ with your provider — we're not your QSA.

Should I wait for the native one-page checkout in 9.2?

If you're launching today, no — waiting months for a feature that may require a full Hummingbird theme migration is impractical, and the native version is Hummingbird-only and optional rather than the default. If you're already on Hummingbird and planning an upgrade, watch the roadmap. Until it ships, a one-page checkout means a module — that's the territory Checkout Revolution lives in. Our fuller take is in PrestaShop's native OPC plans.

Related reading

• PrestaShop Checkout Optimization Guide — concrete changes that move completion rate
• PrestaShop 9.2 Native One Page Checkout — our take on the roadmap
• Checkout Revolution — our one-page + express module
• Express Checkout — wallet buttons without replacing your checkout
• PrestaShop Hooks & Overrides — the hooks the checkout fires and how to plug into them safely