A customer has chosen your product, added it to the cart, and clicked "Checkout." They have already decided to buy. Then your store asks them to create an account first: pick a password, confirm their email, maybe clear a CAPTCHA. A meaningful share of them walk away at exactly that moment, not because they changed their mind about the product, but because you asked for a relationship before they had a transaction. This post is about what the evidence actually says on forced registration, and what to do about it specifically in PrestaShop.
It is a narrow question on purpose. For why people abandon carts in general, see the 12 reasons people leave before paying; for the wider checkout teardown, why your checkout page is losing you sales. Here we stay on one decision: guest checkout versus mandatory account creation.
What the data actually says
The most-cited number comes from the Baymard Institute's ongoing checkout research: when asked why they abandoned a checkout they had started, a large minority of shoppers point to being forced to create an account. In Baymard's surveys that figure has sat consistently around the high-twenties to mid-thirties percent. Second only to unexpected extra costs (shipping, taxes, fees) as a stated reason. Treat the exact percentage as directional rather than a law of physics: it is a self-reported survey answer, not a measurement from your store, and it moves a few points between study waves.
Two things about that data are more reliable than the headline number:
- Direction, not magnitude. Across studies and store types, removing forced registration moves conversion up, not down. The size of the lift depends on how bad your current flow is, a store that already offers a clean guest option has little to gain; one that gates every first order behind a password has a lot.
- Who it hits. The penalty lands almost entirely on first-time buyers. A returning customer who already has an account barely notices. Someone buying from you for the first time has no stored relationship and no reason to invest two extra minutes, so a registration wall taxes precisely the customers you most want to convert.
So the honest framing is not "guest checkout adds X% conversion." It is: forced registration is a self-inflicted friction point that a measurable share of first-time shoppers tell researchers made them quit, and it is one of the cheapest frictions to remove. Whether it is worth removing on your store is something you measure, more on that at the end.
The reasons stores force registration, and what the data says back
Almost every store that mandates accounts does it for a sensible-sounding reason. Held against the evidence, most of those reasons don't survive.
| The stated reason | What actually happens |
|---|---|
| "Customers need an account to track orders." | Order tracking works fine off an email link. PrestaShop already emails an order confirmation with a guest-tracking URL; the customer never needs a password to see status. |
| "We need the email for marketing." | You collect the email at checkout regardless. It is required for the order confirmation. A newsletter opt-in checkbox captures consent without a password. |
| "Accounts make customers reorder." | Customers who intend to return create accounts voluntarily when offered after the sale. Forcing it on first-timers who may never come back trades a sale for an account you may never use. |
| "Accounts reduce fraud." | Fraudsters create accounts too, it is trivial. Registration is not a fraud control; AVS, 3-D Secure and your payment provider's risk scoring are. |
The pattern is consistent: every goal behind forced registration is reachable without the wall. You can keep the order-tracking, the email list and the reorder convenience and drop the part that costs you first-time conversions.
The pattern the evidence points to: guest-first, account-after
The data doesn't argue for guest-only. It argues against making registration a gate. The flow that lines up with the evidence is guest-first with an optional account offered after the order is placed:
During checkout
Take only what the order needs: name, email, shipping address, payment. No password, no username, no "confirm your email" double-entry. The customer reaches the confirmation as fast as their typing allows. (Putting that whole flow on one screen instead of stepped gates is a separate lever, covered in one-page checkout for PrestaShop, and for the fastest variant, express checkout.)
After purchase
On the confirmation page and in the confirmation email, offer it as a reward rather than a toll: "Set a password to check out faster next time." The customer has already received value, so an account now reads as a convenience, not a barrier. In practice this recovers a large share of would-be account holders, you end up with the orders and a healthy portion of the registrations, instead of trading orders for registrations.
Smart routing on the email field
If the email a shopper types already belongs to an account, prompt them to log in instead of silently sending them through guest checkout (and creating a duplicate). If it is new, default to guest. That one piece of logic serves returning and new customers without adding a step for either, and it is exactly the kind of behaviour PrestaShop's native checkout does not do on its own.
Where this lives in PrestaShop's back office
PrestaShop supports guest checkout natively, and it is the first thing to switch on:
- Shop Parameters → Order Settings → Enable guest checkout (the PS_GUEST_CHECKOUT_ENABLED configuration value). Set it to Yes. With it off, every customer is forced down the account path, the worst-case setting for the conversion problem above.
- Then look at Shop Parameters → Customer Settings, a separate tab. Here you control "Ask for a birthday" and "Re-display cart at login", plus your custom registration fields. Every required field is friction, and the registration form is where stores quietly pile them on.
If you'd rather confirm the setting's real value without clicking through the back office, or check it across several shops at once, it lives in the configuration table:
-- Check whether guest checkout is enabled (1 = on, 0 = forced registration)
SELECT name, value
FROM ps_configuration
WHERE name = 'PS_GUEST_CHECKOUT_ENABLED';Flip it from the back office rather than editing the row by hand. PrestaShop clears its configuration cache when you save through the UI, and a raw UPDATE can leave a stale cached value until the cache is cleared. The query above is for reading, not for changing it on a live store.
Switch guest checkout on and PrestaShop's native checkout already does more of this than most merchants realise. On the personal-information step (the CheckoutPersonalInformationStep class in the order controller) the default tab becomes "Order as a guest", with "Sign in" alongside for returning customers, and inside the guest form, account creation is reduced to an optional "Create an account (optional), and save time on your next order" password field. So the premise that native checkout forces a relationship before the transaction is, on a correctly configured 1.7-to-9 store, simply not true: guest is the default and the account is already optional.
What native does not do is route on the email field, and it does not move the account offer to after the order. The shopper still types their email into a form that has no idea whether they are a returning customer, so a returning buyer who starts as a guest can end up duplicated, and a new buyer still sees the optional account field competing for attention during the order rather than as a clean reward once the order is done. That gap, login detection on the email field, and an after-purchase account offer, is where the real lift lives.
Closing that gap with Checkout Revolution
This is the specific gap our Checkout Revolution module is built to close. The part native checkout leaves open even after you enable guest. It works on PrestaShop 1.6 through 9, no theme surgery, no core edits, so it survives upgrades. So what does that mean in practice? The optional account field stops competing for attention during the order; the account offer moves to after the sale, where it converts as a bonus instead of a distraction. The returning customer who types a known email is detected and routed to log in rather than silently duplicated as a fresh guest. And because it configures from the back office, you are not paying a developer to patch the personal-information step by hand. We rebuilt it around this flow. The detail is in Checkout Revolution 3.0.
If your needs are narrower, you just want the absolute shortest guest path, the same guest-first logic underpins our express checkout approach, covered in express checkout.
When forced registration is actually justified
Evidence-led doesn't mean dogmatic. Some stores have a real reason to require an account, and the data above doesn't apply to them the same way:
- B2B with access control, when pricing, catalogue visibility or payment terms vary by customer, an account is the access mechanism, not a marketing nicety.
- Subscriptions and recurring orders. Managing a recurring charge needs a persistent identity.
- Digital downloads with entitlement. Gated files need an account to manage access after purchase.
- Loyalty programmes. Points, tiers and rewards need somewhere to live.
Even here, the lesson from the data holds: minimise the registration itself. A B2B first order needs company name and VAT number. It does not need a CAPTCHA, a double email entry and a marketing consent wall before the customer can place it. Ask for exactly what the use case requires and nothing more.
How to measure it on your own store
Do not take the survey numbers as your numbers, measure. Before you change anything, record your cart-to-order conversion rate and your checkout abandonment rate (shoppers who start checkout but don't finish), split by new versus returning customer if you can. Then enable guest checkout, restructure to guest-first, and compare the same figures over at least 30 days and a few hundred orders. Enough volume that you are reading a trend, not the week-to-week noise that tricks merchants into reverting a change that was actually working. The metric that matters is total orders and revenue, not how many accounts you collected.
And remember that even a frictionless checkout loses some carts to causes that have nothing to do with registration. Winning a share of those back is a separate job, see reducing cart abandonment in PrestaShop and the abandoned-cart email automation that does the recovering.
FAQ
Does PrestaShop support guest checkout out of the box?
Yes. Since 1.7 (through 8 and 9) guest checkout is native, you enable it under Shop Parameters → Order Settings. With it on, the personal-information step defaults to "Order as a guest" and account creation becomes an optional password field rather than a wall. The common misconception that native checkout forces registration is only true on a store where someone left this switch off.
If guest is already optional in native checkout, what's left to fix?
Two gaps. Native checkout doesn't route on the email field, type a known customer's email and it still sends you down the guest path, creating a duplicate instead of prompting a login. And it offers the account during the order, competing for attention, rather than after the sale where it reads as a reward. Closing those two gaps is where the remaining lift lives.
Won't guest checkout cost me customer accounts and my email list?
No to the email, and rarely to accounts. You collect the email at checkout regardless, it's required to send the order confirmation, and a newsletter opt-in checkbox captures marketing consent without a password. For accounts, offering registration after the sale ("set a password to check out faster next time") recovers a large share of would-be account holders. You end up with the orders and a healthy portion of the registrations.
Is forced registration ever the right call?
Sometimes. B2B stores where pricing or catalogue visibility depends on the customer, subscriptions, gated digital downloads, and loyalty programmes all have a real reason to require an account, it's the access mechanism, not a marketing nicety. Even then, minimise the registration itself: ask for exactly what the use case needs and drop the CAPTCHA, double email entry, and consent walls.
Does removing forced registration really increase conversion?
The direction is consistent across studies, removing the wall moves conversion up, not down, but the size depends on your current flow. A store that already offers a clean guest option has little to gain; one that gates every first order behind a password has a lot. The penalty falls almost entirely on first-time buyers, so measure on your own store with new-versus-returning split rather than trusting a survey headline.
The through-line is simple. Forced registration is one of the few abandonment causes that is entirely within your control, costs nothing to remove, and falls hardest on the first-time buyers you most want to keep. Flip the PrestaShop setting on so guest becomes the default, route returning customers by their email instead of duplicating them, move the account offer to after the sale, and let your own numbers, not a survey headline, tell you how much it was worth.
