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

"How do I change my PrestaShop checkout?" is one question with three completely different answers, and most merchants don't know which one they're actually asking. Some want to swap the payment provider. Some want fewer steps. Some want a field PrestaShop doesn't collect. They all say "checkout," and they all get pointed at the wrong fix. This is the page that untangles it: how the PrestaShop checkout is actually built, the three real routes to changing it — native settings, a module, or custom code — and a decision framework for picking the one that fits your shop. It's the map. Every deep dive links out from here.

One distinction to settle before anything else, because half the support tickets we field hinge on it: the checkout process (the multi-step flow built into every PrestaShop store) is a completely different thing from ps_checkout, the free PayPal-backed payment module PrestaShop ships pre-installed. They sound identical. They aren't. Replacing one does nothing to the other. Keep that line in your head and most "checkout" confusion dissolves.

How the PrestaShop checkout actually works

Since PrestaShop 1.7 — and unchanged in spirit through 8 and 9.0–9.1 — the checkout lives on a single URL driven by one controller: controllers/front/OrderController.php. The customer never changes pages. What they move through instead is a sequence of steps, each one its own PHP class, all inheriting from AbstractCheckoutStep and orchestrated by a CheckoutProcess object:

• CheckoutPersonalInformationStep — login, register, or guest
• CheckoutAddressesStep — delivery and invoice address
• CheckoutDeliveryStep — carrier selection by zone, weight and dimensions (a virtual cart with nothing to ship skips this one)
• CheckoutPaymentStep — payment method and order confirmation

A step stays collapsed until the one before it is complete. So "one page" in the technical sense, but four gates in the experience — the customer reveals shipping only after addresses, payment only after shipping. That gating is well-engineered: a module can override a single step without touching the rest of the flow. The flip side is that when five modules each tweak a different step, a checkout bug takes time to isolate, and every fix starts with reading OrderController end to end and watching var/logs/.

If you remember a one-click "one-page checkout" toggle, you're not imagining it. PrestaShop 1.5 and 1.6 had Preferences → Orders → Order process type (the PS_ORDER_PROCESS_TYPE config value). It was removed in 1.7 when the checkout was rebuilt. An upgraded database may still carry the leftover key, but it no longer drives anything. This is the single most common migration surprise we hear about — and the reason "native one-page checkout" is now a module question, not a settings question (until 9.2; more below).

What changed under the hood between 1.7 and 8/9

The visible flow held steady; the plumbing moved a lot. If you're choosing a checkout or payment approach, these are the version facts that decide whether a module silently breaks:

• Payment hooks. paymentOptions replaced the older displayPayment/displayPaymentEU in 1.7. On 8 and 9 the legacy hooks no longer fire at all — any module still using displayPayment is silently invisible at checkout.
• Symfony split. Back-office order management is Symfony now; the front-office OrderController still runs on legacy. Module authors need to know which side of that line their code lives on.
• Stricter CSP on 8+. Default Content Security Policy headers can block a payment provider's 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 idioms surfaces its sins on upgrade.
• Theme stack. Classic still uses jQuery-heavy per-step AJAX; Hummingbird (the 8/9 alternative) rebuilt it on a modern stack — and the forthcoming native one-page checkout targets Hummingbird, not Classic.

The three routes to changing your checkout

Once you know the checkout is a stepped flow on one controller, every change you might want falls into one of three buckets. Naming the bucket first saves you from buying the wrong fix.

Route 1: What native settings and the theme can do

Reach for built-in tools before any third-party code. More is configurable than merchants expect, and all of it survives updates when you work in a child theme:

• Guest checkout. An order setting, not a payment setting — Shop Parameters → Order Settings in PS 8 (Enable guest checkout). It changes the very first checkout step before any carrier or payment module gets a look in. Whether you should force registration is a data question we answer in guest checkout vs account creation.
• Required address fields. Customers → Addresses controls which fields are mandatory; the country editor under International → Locations → Countries controls field order, postcode rules, and which delivery countries drive which tax zones and carriers.
• Carrier presentation. Names, delivery estimates, and display order — all native.
• Payment restrictions. Payment → Preferences controls, via currency/country/group/carrier restrictions, whether a payment module appears at all. The order methods appear in isn't set here — it follows each module's position and its own configuration.
• Theme & CSS. Edit checkout Smarty templates and styles in your child theme for layout, field order, and brand alignment — never the parent theme, or the next update overwrites you.

For the field-by-field optimisation of this layer — what to cut, where to put the coupon box, how to order payment methods — see our PrestaShop checkout optimization guide.

Route 2: When you need a module

Native settings can't restructure the flow. The moment you want a genuine one-page layout, wallet buttons, or fields PrestaShop doesn't collect, you're in module territory. The good news is that a well-built checkout module does its work through hooks and overrides rather than core edits, so it survives upgrades — the thing custom hacks rarely do.

This is where our own Checkout Revolution lives. So what does that mean for a store owner? One module turns the stepped native checkout into a true single page — address, shipping and payment on screen together, a live-updating total, guest checkout as default, inline validation — and it adds Stripe-powered express wallet buttons, installing and configuring from the back office instead of a developer invoice. We rebuilt it from the ground up; the why is in Checkout Revolution 3.0. If you only need to accept PayPal on a brand-new shop, the free ps_checkout below does that for less money — different problem, different tool.

Route 3: When custom development earns its cost

Because each step is a class, a developer can override CheckoutDeliveryStep or hook actionValidateOrder to inject bespoke logic — a PO-reference field for B2B procurement, a custom carrier rule, an external validation call — without forking the whole flow. Done with overrides it's upgrade-safe; done by editing core files it's a future upgrade you'll dread. Custom only earns its cost when your requirements are genuinely specific and you have the PHP skill in-house or on retainer. For most "I want one-page" or "I want express" requests, a module gets you there in an afternoon instead of a sprint.

The payment layer: ps_checkout and the alternatives

Changing how the customer pays is a separate axis from changing the flow — and it's where the ps_checkout confusion bites hardest.

ps_checkout is a free payment module built jointly by PrestaShop SA and PayPal, pre-installed since 1.7.5. It renders payment options at the payment step — cards via PayPal-hosted fields, the PayPal wallet, Apple Pay / Google Pay where available, local methods (iDEAL, Bancontact, BLIK), Pay Later, 3DS2, 20+ currencies. What it emphatically does not do is change the steps, the layout, the field order, or anything else about the flow. Anyone selling you "one-page checkout via ps_checkout" hasn't read its README. Source: ps_checkout on GitHub.

One architectural fact worth knowing before you commit: ps_checkout is an intermediary integration. Where Stripe, Mollie and Adyen connect you straight to your own merchant account, ps_checkout adds a PrestaShop/PayPal service layer on top of your PayPal merchant relationship. That isn't inherently bad — it's how PrestaShop's official PayPal partnership is packaged — but it means an extra party sits in the integration, which high-volume or regulated merchants should weigh.

The mature direct alternatives, at a glance — verify fees for your own merchant country, because every provider varies by country, card origin, method, currency and volume:

Two things matter more than the headline percentage, and merchants routinely overlook both. First, local payment coverage: a Dutch shopper expects iDEAL, a Pole expects BLIK or Przelewy24, a Belgian expects Bancontact — a card-only checkout simply looks incomplete in those markets, and the trust gap costs more than a 0.3 EUR fee difference ever will. Second, 3DS2 / SCA support: EU card payments require it, so any 3DS1-only module will see failure rates climb and eventually stop working. Pick a provider with strong 3DS2 success rates and clear retry messaging.

The free zero-fee option people forget is ps_wirepayment: it shows your bank details at checkout and lets the order through with no card gateway at all. For B2B, wholesale, and high-value baskets the commercial case is real — the only ongoing cost is matching incoming transfers to orders before fulfilment, roughly "ten minutes of accountant time per morning" on the clients we've set it up for.

A note on PCI scope

How your checkout handles card data decides your PCI burden, and the right answer is almost always to keep card data off your server entirely. Use modules with hosted payment fields (provider-served iframes) or hosted checkout — that's the low-burden SAQ A / A-EP path that ps_checkout, Stripe's Payment Element and Mollie all support. If a module asks you to add raw card-number inputs to your own HTML, walk away: that drags you toward SAQ D, the expensive end, and it's a maintenance liability. Confirm the exact SAQ level with your provider or acquirer — implementation details matter and we are not your QSA.

Choosing the right checkout for your shop

No single configuration is "best." After a decade of building these, this is the framework we actually use:

Going deeper: the rest of the checkout cluster

Each of the changes above is deep enough to deserve its own treatment. Rather than rush them here, here's the map — follow the link for the subtopic you're actually working on:

• One-page checkout. What PrestaShop gives you, why it stops short, and the realistic routes to a true single-page flow: one-page checkout for PrestaShop. The native flow specifically — and why the old toggle is gone — is in PrestaShop's native one-page checkout (OPC), and the ground-up rebuild of our own answer is Checkout Revolution 3.0.
• Native one-page checkout in 9.2. PrestaShop is building OPC into the platform (Hummingbird-only, optional, multi-step stays). Whether to wait or act now: PrestaShop 9.2 native one-page checkout.
• Express & wallet checkout. Buttons that skip the whole flow — tap, Face ID, done: express checkout for customers who just want to buy fast.
• Mobile checkout. Tap targets, the right input types, and wallet payments where over half of checkouts now happen: mobile checkout optimization.
• Diagnosing a leaking checkout. If conversion is poor and you don't yet know the leak, start here: why your checkout page is losing you sales.
• The full optimization playbook. Field counts, validation, payment placement and the measurement loop: PrestaShop checkout optimization guide.

And after they still leave: cart recovery

Even a flawless checkout loses some carts. Recovery is the other half of the revenue story, so it has its own posts rather than a buried paragraph here:

• Why shoppers abandon. The psychology and the fixes in PrestaShop terms: why shoppers abandon carts and how to fix it, and the longer list in 12 reasons people leave before paying.
• Proven reduction strategies. What actually moves the number on a PrestaShop store: reducing cart abandonment in PrestaShop.
• Abandoned-cart emails. The one automation every store should run, and how to wire it up: abandoned-cart emails and the broader email automation for abandoned-cart recovery.

The checkout is the most valuable surface in your store: everyone who reaches it has already decided to buy, and your only job is to not get in their way. On PrestaShop specifically that means knowing the flow is a stepped sequence on one controller, knowing the native one-page toggle is gone, and choosing deliberately between native settings, a module, and custom code — then measuring the change on your own analytics before you trust it. Pick the route that matches the problem you actually have, follow the cluster link for the detail, and don't let the word "checkout" send you to the wrong fix.