PrestaShop checkout: configuration, payments and diagnosis

What we would do

Which change helps depends on the existing shop: its PrestaShop release, theme, payment and carrier modules, custom order code, and the stock, accounting or delivery integrations that receive its orders. Map which customer, address and order data each of those integrations receives. We would follow a failing purchase from basket to order confirmation on that exact combination, as a new visitor and as a returning customer. Compare each restriction with the rule the shop intended before treating it as a fault, then fix proven configuration or integration errors first. Change the layout when the evidence points to confusing fields or navigation; change the payment integration when a required payment method or payment operation is missing.

For checkout configuration and module changes: reproduce the problem on a staging copy of the shop, isolated from real payments, customer email and fulfilment; change one layer at a time; rehearse written purchase scenarios; then switch at a planned time with a files-and-database backup, a tested way back and a plan to reconcile orders placed in the meantime. A checkout that already meets the need stays as it is. If checkout work forms part of a wider shop rebuild, the usual safe route is a clean target shop on staging, a rehearsed migration of the required shop data and a planned cutover after testing the modules and integrations.

If the cause of lost orders is unclear, the PrestaShop B2C Conversion & Revenue Audit examines discovery, cart, checkout, payment and confirmation, starting on a phone, and supplies a ranked plan of fixes without installing or changing anything; implementation is separate.

Understand the checkout flow

In PrestaShop 1.7.8 and 9.1, the order controller builds four logical steps: personal information, addresses, delivery and payment. A virtual-only cart omits delivery. Cart review and order confirmation are separate parts of the journey. One checkout URL can still contain several steps, requests and payment handoffs.

A returning customer may already have saved details. A theme or checkout module can change the presentation. Count document navigations and background requests in the browser before describing your shop as a four-page or five-page checkout.

PrestaShop 9.2 includes the native ps_onepagecheckout module. It must be enabled and configured before its unified checkout becomes active. Multi-step checkout remains available. The current native checkout documentation explains the integration.

Keep four choices separate: the checkout layout, the payment integration, the provider account behind it and the way you measure the journey.

Record the installed PrestaShop release, PHP version, theme, checkout module and payment module versions before following any instructions, and check what those exact releases support. Assess native checkout options and third-party modules together; an old roadmap is not a setup guide.

Match the symptom to the next action

Before you change anything

1. Attempt the same purchase on a phone as a new visitor and as a returning customer. Note where information must be entered again or where an error leaves the next action unclear.
2. Separate navigation from unresolved decisions. A late delivery charge, an unsuitable carrier or a missing payment method needs its own fix, even on a single page.
3. Write one acceptance scenario for the obstacle: customer type, basket, destination, payment method and expected outcome. Use it to compare the current checkout with any proposed alternative.

For example, a payment option may appear for a domestic retail customer but disappear after the shopper selects another country, signs into a trade account or picks a particular carrier. Compare that cart context with the intended payment rules before blaming the layout. A method enabled in the provider dashboard may still be unavailable through the installed integration.

Where the integration uses both, the browser's return from bank authentication and the provider's server notification are separate evidence paths. A broken return page does not prove the payment failed, and a missing confirmation page does not prove that no order exists. Check the provider status, amount, currency and reference against the shop record; authorized, pending, captured and completed payments may need different handling.

A useful support report contains the basket, customer type and group, market and currency, device, the failure time with time zone, the cart or order reference, a redacted provider transaction reference, the reproduction steps and the exact message. Ask the developer to correlate browser and server evidence. Remove credentials, payment details and unnecessary customer data before sharing logs or screenshots.

Choose a checkout route after defining the gap

Keep the installed native flow if it meets the requirement, and keep an existing payment integration if it provides the methods and order handling you need. Do not buy a module because its name sounds faster: one page can still contain every required decision, and a wallet can reduce typing without resolving delivery or product options.

Checkout Revolution puts contact, address, delivery, payment, vouchers and the order summary on one page, in one, two or three columns, with your choice of section order and of which fields are shown or required. Your existing carriers and payments appear in it, a returning customer does not retype an address, payment rules can follow shop, language, customer group, country, device and order value, and a business buyer's accepted quote can become an order without re-entry. It also includes an express purchase window on product pages, listings and the cart.

Express Checkout brings address, delivery, payment and confirmation into one window on product pages, listings or the cart. Payments use Stripe, with no monthly charge and a commission per transaction, for cards, wallets and local methods; compare those terms separately from whether its journey suits the shop. You choose button placements, required address fields and payment eligibility by audience, country and currency. Delivery prices update live, excluded payment-and-carrier combinations are rejected, and full or partial refunds run from the order screen. An optional single-page checkout includes your other payment and shipping modules.

In both, a payment completed after the browser closes still becomes an order. Neither product description promises saved cards or names a specific wallet such as Apple Pay or Google Pay, so confirm any such requirement against the release and your payment account before buying. Neither product name establishes compatibility with your custom code: include checkout overrides, additional fields, stock or accounting integrations and B2B rules in the requirement.

If the choice needs testing, the PrestaShop Module Selection & Fit Assessment compares native settings, owned products, suppliers and custom development for one requirement, tests candidates on a controlled shop copy and includes configuration, visual adaptation and deployment of a chosen ready-made module; licenses cost extra and custom development is quoted separately. If you already own the chosen module, the PrestaShop Module Installation & Configuration Service installs and configures one existing module to an agreed scope and verifies the affected journey; licenses, additional modules and development cost separately.

Choose multi-step, one-page or embedded checkout

PrestaShop 1.6 had an order-process-type setting. The rebuilt 1.7 checkout did not use that old switch. On 1.7, 8 and 9.0/9.1, an alternative full checkout layout requires an appropriate module or custom implementation. PrestaShop 9.2 supplies native OPC, so evaluate that available option before commissioning a replacement.

Native OPC is not categorically limited to Hummingbird. Classic-derived and custom themes can integrate with its template and JavaScript contract. Follow the theme compatibility guide and test your installed combination.

Complex procurement, regulated products, customization and several shipping choices may benefit from deliberate grouping. Simple orders may suit a unified view. For a high-value item such as a €2,000 watch, make the final review clear. Choose the layout from your order requirements and usability tests: the useful target is fewer unnecessary steps with the correct order still visible for review, not a lower page count.

Checkout Revolution implements a one-page checkout and express/modal flows; see Checkout Revolution help. Check the order summary and submit controls at desktop and mobile widths.

Avoiding core edits can reduce maintenance, but it does not guarantee future compatibility. Keep child-theme changes under version control and test updates against your carrier and payment modules.

Measure events and diagnose abandonment

Record cart-to-checkout entry, checkout completion, payment failures, completion time and order value. Define whether completion means an order created or a payment confirmed. Use the same definition throughout a comparison, and record normal, express and redirected journeys with it, so a wallet or modal flow is not missing from the totals. Split results by device, customer type, country and payment method when volume permits.

These are Google ecommerce events, rather than one event for each native UI step. To distinguish personal-information abandonment from address abandonment, record explicit step views, submissions, validation results and completion events. Do not send names, email addresses, addresses or payment details to analytics.

Check each event in your browser and analytics debugging tools, including shipping and payment submission, virtual carts and retries. For the Google Analytics GA4 integration, use the module help.

Use customer feedback, consent-appropriate masked session recordings and browser errors to investigate a drop. A delivery-step exit may involve cost, unavailable carriers, delivery time or a technical fault. Funnel position does not prove a shopper's motive. Prioritize confirmed failures and opportunities by affected traffic, cost and expected impact.

Survey abandonment reasons can suggest questions. They do not measure your PrestaShop funnel or predict the uplift from a change, and there is no universal completion target or payback period: compare against your own baseline. Choose a comparison design and sample size from your baseline, the effect you need to detect and traffic variability. Control promotions, seasonality and traffic mix. Wallet uptake without an aggregate conversion change does not prove cannibalization.

For illustration, raising completion from 30% to 31% is a relative increase of about 3.33%. Revenue changes by the same proportion only if checkout volume and average order value stay constant. This arithmetic is not a forecast.

Use cart records without inventing a funnel

PrestaShop persists carts. Orders > Shopping Carts helps you inspect them, but a cart row is not proof of checkout entry. Choose the correct table prefix and shop ID. The following read-only example counts recently created, currently nonempty carts and the subset linked to a currently valid order.

SELECT COUNT(*) AS nonempty_carts,
       SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) AS carts_with_valid_order,
       ROUND(100.0 * SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) / NULLIF(COUNT(*), 0), 1) AS cohort_ratio_pct
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart);

This is a nonempty-cart-to-currently-valid-order cohort ratio. It is not checkout conversion. Recent carts have had less time to convert, pending orders may become valid later, and one cart can create multiple orders. EXISTS avoids counting a cart more than once.

Define abandonment with an inactivity cutoff and an order policy. This second example uses 24 hours without a cart update as an illustrative cutoff and excludes every cart with any order, including unpaid orders.

SELECT CASE
         WHEN c.id_carrier > 0 THEN '3 - carrier value stored'
         WHEN c.id_address_delivery > 0 THEN '2 - delivery address stored'
         ELSE '1 - neither value stored'
       END AS stored_state,
       COUNT(*) AS inactive_nonempty_carts
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 24 HOUR)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart)
  AND NOT EXISTS (SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart)
GROUP BY stored_state
ORDER BY stored_state;

Read the stage labels directly. Stored addresses and carriers may have been restored or assigned automatically; they are only heuristics. This query cannot distinguish research, interruption, bot traffic or a failed checkout. Apply your documented bot exclusions and reconcile against event data. Track unpaid-order recovery separately if that is your aim.

Configure guest checkout and account fields

1. Open Shop Parameters > Order Settings and review Enable guest checkout. On modern versions it maps to PS_GUEST_CHECKOUT_ENABLED. Save through the back office in the intended shop context.
2. Test a fresh guest session and a returning account. In the native checkout, guest checkout makes the checkout password optional. Sign-in remains available.
3. Review birthday requests, social titles and additional customer fields separately. B2B mode controls particular customer-account fields; it does not universally remove company or VAT fields from addresses.
4. Review each destination country's address format, postcode and state requirements under International > Locations > Countries. Address requirements and carrier requirements must match fulfilment.

You can inspect configuration rows without changing them:

SELECT id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name = 'PS_GUEST_CHECKOUT_ENABLED';

An order email address is not permission for marketing. Offer a separate, appropriate opt-in. Order tracking can use the native guest-tracking flow. Native guest conversion is an explicit process; enabling guest checkout does not install automatic post-purchase registration. Test how an existing account email is handled rather than promising duplicate accounts or automatic email routing.

Accounts can support restricted B2B access, recurring service management and loyalty records. Decide from those requirements: for consumer sales, test whether requiring an account creates an avoidable obstacle; for business sales, establish which buyers must have approved accounts or company details. Changing a payment provider does not decide these account rules. Native virtual-product downloads can use protected guest links; selling a downloadable product does not inherently require registered-account login.

Keep delivery and billing addresses independently editable. Request a telephone number where your delivery service needs one. Preserve valid international characters and explain field errors without clearing completed fields. Before removing a required field that customers struggle with, establish why it is required.

Test labels and errors in each shop language, including payment-module messages, country-specific address fields and linked terms. A translated theme does not prove every module or provider message is translated: when a French checkout shows an English address error, find whether the theme, a module or the provider produces it before deciding where to translate it. An invisible required state field or an unclear postcode error can stop a purchase before payment begins. The translations and international selling guide covers the wider language setup.

Baymard Institute's large-scale checkout testing shows how often shops miss both points: 98% of sites don't use specific error messages, and 62% don't make guest checkout the most prominent option. Its checkout UX research explains the usability evidence behind these recommendations.

Show costs, delivery expectations and return terms

Show known prices, taxes and delivery charges early. Label an estimate as an estimate when the final address or carrier is still unknown. Configure taxes, customer-group price display and carriers for the destinations you serve; the shipping guide covers carrier configuration and delivery costs. Shipping > Preferences provides free-shipping thresholds; a remaining-spend message requires theme or module rendering.

For example, a shopper expecting €40 may reconsider when the total becomes €49. Show the extra charge and its basis before the final order action. A lower price and an earlier explanation solve different problems.

Provide realistic carrier processing and transit information. Estimated Delivery Date supplies dispatch or delivery timing; see Estimated Delivery Date help. Use a separately tested price estimator or a clear delivery-price policy for shipping costs.

Make the actual return policy and contact route easy to find on product and cart pages. The merchandise-return switch controls a technical workflow. It does not create or remove statutory rights, and it does not justify advertising 30-day returns unless you offer them. Check the applicable withdrawal rules and exceptions.

Understand express wallets and button eligibility

Wallets can supply saved contact details and tokenized payment credentials. A complete express integration can collect addresses, offer supported shipping choices and update totals within its flow. The customer may still need to confirm details, choose delivery, accept terms or authenticate. A wallet payment at the last checkout step does not automatically bypass earlier forms.

Express checkout is a user journey, not a requirement to use the browser Payment Request API. Integrations may use wallet interfaces, provider SDKs, modals or redirects. They can collect separate billing and shipping details. Keep a regular checkout path for unsupported browsers, destinations and order requirements.

Buttons may appear on product pages, carts, mini-carts or checkout, depending on the integration and rendered hooks. Test whether product-page express pays for the selected item, the full existing basket or a newly created cart. Measure basket value and completion rather than assuming Buy Now reduces order value.

1. Confirm the payment method is enabled for your merchant account, country, currency and cart amount.
2. Register every relevant checkout hostname as required by the processor, including applicable embedded payment domains.
3. Check HTTPS, certificates, iframe permissions and browser console/network errors.
4. Check the current processor browser matrix and the customer's configured wallet or payment method.
5. Check module-specific restrictions and supported placements. Provider capability does not prove module support.

Browser support depends on the wallet and integration. Check Stripe's express checkout matrix and Apple's purchase guidance for current device and authorization options.

Where your processor requires an association file, this checks reachability only:

curl -I https://example.com/.well-known/apple-developer-merchantid-domain-association

A successful response does not prove domain registration or wallet eligibility. A supported gateway may already provide express buttons; a separate accelerator is another option. See Express Checkout help.

A basket scenario that exposes the wrong behavior

A shopper already has a filter in the cart, selects a refill combination on a product page and presses the express button. Your specification must say whether that action buys the refill alone, the existing basket, or both after review. Show the contents before payment and check what remains in the cart afterwards; a button label does not settle the module's behavior.

Repeat with a required customization left blank, then completed: the fast route must enforce the same product requirements as the main checkout. If the destination has no suitable carrier, the customer needs an explanation and a way to change the address or basket before paying.

Separate saved payments from one-click order placement

A reusable payment token, known customer, current address, resolvable shipping, correct tax context and valid consent can shorten a repeat purchase. Recheck stock, prices, delivery and required options before charging. Keep the payment details with the provider and store only the provider customer/payment-method identifiers needed by your integration. Do not store raw card numbers or CVV in PrestaShop.

For example, Anna reorders coffee with a saved address and card. Her next order may need little input, but a changed shipping price or bank authentication can add a step. When she sends the next pack to a friend's address, delivery availability and the total need checking again. A useful fast checkout lets her correct the address or complete the bank challenge, then shows a clear order outcome; it does not keep a click count by silently reusing old information. A first-time visitor may also have a configured wallet, even when your shop has no previous customer record, so judge both journeys by accurate details and a completed purchase rather than by registration history.

Recognizing a signed-in customer is different from having permission and technical support to reuse a payment method. An address book entry or a previous successful order does not establish that the next order may be charged, and saving an address does not save a card. Ask the integration supplier where reusable details are held, how the customer chooses them and how they can change that choice.

A customer actively buying uses an on-session saved-payment flow. Off-session describes merchant-initiated charging while the customer is absent. Do not mark an interactive checkout charge off-session merely to avoid authentication. Handle required authentication and asynchronous outcomes according to the provider's integration, and ask the supplier how customer confirmation, saved-payment permission and an authentication challenge are handled.

1. Recalculate and validate the cart server-side.
2. Confirm the customer's authorization using the provider's supported flow.
3. Verify the trusted payment result, amount, currency and cart mapping.
4. Create or update the PrestaShop order idempotently. Handle duplicate callbacks and retries.
5. Reconcile the eventual paid, failed, pending or refunded state.

A PaymentIntent creation snippet does not complete this order lifecycle. Offline methods can also simplify order placement without tokenizing a card, but the resulting order may still be unpaid and require bank reconciliation or payment on delivery. No literal tap count or authentication-free purchase can be guaranteed.

Choose and troubleshoot payment integrations

ps_checkout, PrestaShop Checkout, is a payment integration rather than the name of the whole checkout process. It handles payment options, authorization/capture, transactions and refunds through its supported PayPal integration. The merchant connects a PayPal Business account. Review settlement and payout terms for your connected merchant account.

Bundling depends on distribution and date. Check the installed module and supported release. Use the official module repository for its documentation and the official transaction guide for payment states. Official account troubleshooting and support routes exist; follow their published terms.

For installation, onboarding and removal, use the official PrestaShop Checkout documentation. Before disabling any provider, confirm another working payment path remains available.

You can evaluate Stripe, Mollie, PayPal, Adyen, Amazon Pay and dedicated installment integrations such as Klarna, Alma or Clearpay/Afterpay against your requirements. Verify the particular PrestaShop module rather than the provider's catalog-wide method count. Compare authorization support, refunds, disputes, settlement, currencies, account eligibility, recurring payments, reporting and support. The payments guide covers choosing and operating methods in more depth.

Possible regional methods to investigate include iDEAL for the Netherlands, Bancontact for Belgium, BLIK or Przelewy24 for Poland, SEPA or invoice options for Germany/Austria, Cartes Bancaires or installment options for France, Bizum for Spain, Satispay or MyBank for Italy and open-banking options for the UK. These are research examples, not promises of availability in your module. Do not plan new integrations around retired standalone SOFORT or Giropay. Check the provider's current method documentation.

Compare actual fees for your legal entity, method, card origin, currency, currency conversion, unsuccessful payments, refunds and disputes. A free module can still have processing costs. Bank transfer avoids a card gateway charge but can incur bank fees and manual reconciliation. Check incoming funds before fulfilment; see the native bank-transfer module.

For any delayed method, define when an order may be fulfilled and who confirms receipt of funds: an order confirmation is not evidence that payment has arrived, so include that staff reconciliation work in the choice. Where you receive transfers into several accounts or currencies, Bank Transfer Accounts shows customers the account for their order currency, with the amount and order reference, on the confirmation page, in the instructions email and on the order details page; you still confirm receipt and update the order yourself.

Questions for the provider and module supplier

• Is each required method available for our legal entity, customer markets, currencies and module release?
• Where will staff find transaction references, reconcile payouts and handle full or partial refunds?
• Who handles integration faults, account restrictions and payment disputes, and what evidence will support need?
• After a switch, where are refunds for orders taken through the previous module processed and recorded?

No payment method available

1. Check active modules and Payment > Preferences restrictions for currency, country, group and carrier.
2. Check provider credentials, account state, amount limits and live/test mode.
3. Inspect the options actually returned, PHP logs and browser errors.
4. Inspect real response headers if scripts are blocked. Do not assume stock PrestaShop 8/9 has a universal checkout CSP that causes the failure.

Modern payment integrations should implement paymentOptions. The 1.7.8 and 9.1 cores also read displayPaymentEU and advancedPaymentOptions compatibility paths. Searching for an old hook name alone does not diagnose invisibility. Availability restrictions differ from ordering: inspect paymentOptions positioning under Design > Positions and any ordering inside the payment module.

Test dynamic shipping, discounts and B2B requirements

Changing country, postcode, quantity or product can change carriers, taxes, payment eligibility and total. Preserve still-valid selections, clear invalid ones visibly and prevent submission while recalculation is incomplete. Test real heavy, virtual, mixed and multi-package carts.

For illustration, a 0.5 kg item plus a 25 kg item totals 25.5 kg. That exceeds a hypothetical 20 kg carrier cap but does not exceed a 30 kg cap. Other dimensions, zones and restrictions can still exclude a carrier. These are sample limits, not published carrier terms.

Cart rules have priorities, compatibility rules, customer/product restrictions, dates and usage limits. A non-combinable 20% rule and a separate free-shipping rule need a tested compatibility setup. A fixed €10 voucher may conflict with an automatic 15% rule. Eligibility conditions and the discount action are different controls.

The cart-rule minimum uses product totals with the selected tax and currency settings, plus shipping when configured. Product-specific price reductions already affect those totals. In PrestaShop 9.1, the calculation also subtracts applicable gifts from rules already in the cart. Test a €100 threshold with a qualifying basket and one just below it, with discounted products, gift products, currency conversion and shipping included or excluded.

Rehearse one combined case as well. A basket has an automatic product discount, the customer enters a voucher and a delivery promotion should apply. Write down the intended result first: which discounts combine, which carriers qualify and the final payable amount. Repeat after changing quantity, carrier and delivery country, and compare the visible summary, the amount sent to the provider and the order record. A rejected voucher should leave a clear explanation and a usable route to payment.

Free-shipping rule carrier restrictions must match your intended choices. Profile slow rule evaluation before deleting historical rules; expired dates already affect eligibility. Retain configuration according to your operational needs.

A compact “Have a code?” control can reduce clutter while keeping vouchers usable. Promotional code application must use a tested, token-aware cart flow. The bare addDiscount=1&discount_name=SUMMER10 URL is not universally sufficient, especially for authenticated customers. Validate eligibility on the actual cart.

For B2B, specify separate billing/delivery, company details, purchase-order references, account approval and agreed payment terms. Valid VAT identification is only part of cross-border VAT treatment; supply conditions and supporting records also matter. Treat VIES unavailability separately from an invalid result. Check the EU cross-border VAT guidance.

Additional fields need a full lifecycle: render, validate, persist and expose them where needed on orders, exports or invoices. A purchase-order reference is useful only if it is validated, kept with the order and visible to the staff or export that needs it; delivery instructions must reach fulfilment. Making a field appear in a template is not a complete implementation. Customer-form extensions can use additionalCustomerFormFields and validateCustomerFormFields; the hooks and overrides guide explains how modules attach to them. actionValidateOrder alone cannot implement the form.

That order-creation hook runs inside PaymentModule::validateOrder(), before subsequent status handling. It can run for pending or offline orders. Check payment status and browser confirmation separately from this hook. Use appropriate provider callbacks and order-state handling for payment, stock and email actions.

Make the journey usable on phones

Use device-category analytics with working purchase events. The legacy Browsers and operating systems report is a compatibility report, not a modern mobile-revenue funnel. Traffic intent, acquisition mix, cross-device buying and tracking gaps can also explain device differences.

Classic remains common on older and upgraded shops. Hummingbird became the default for fresh PrestaShop 9.1 installations. Neither a responsive label nor a new theme guarantees no overflow, usable keyboards or accessible modules.

• Use type="email" and autocomplete="email" for email, and type="tel" with autocomplete="tel" for phone.
• Use text inputs for postcodes. Add inputmode="numeric" only for the selected country's numeric format. UK, Dutch and Canadian formats need letters.
• Use appropriate name and address autocomplete tokens. Inspect the actual generated fields. The modern address form uses customer/_partials/address-form.tpl and shared field rendering, not an assumed input file under checkout partials.
• Use large, spaced controls and fully labeled carrier/payment rows. A 44 to 48 CSS pixel target is a practical design option; check the control size and spacing on real devices.
• Keep the updated total and review path easy to reach. Ensure sticky submit controls do not cover terms, errors, chat or consent controls.
• Preserve typed values, visible focus and specific inline error messages.

On the rest of the mobile store, use tap-operated menu expansion with parent links, a usable filter drawer, readable product information and dismissible popups. Keep important content and structured data available in the mobile rendering. Use responsive image sizes and below-the-fold lazy loading without delaying the hero image.

Telephone links can help on mobile and supported desktop calling apps. Recently viewed products and sticky add-to-cart are options to test in the installed theme or module, not universal native behavior. Compare category exits, product discovery and purchases alongside checkout completion.

Profile checkout requests on an isolated staging copy. Module hooks, external rates/tax/address calls, carrier resolution, cart rules, database queries and script work are possible bottlenecks. Use _PS_DEBUG_PROFILING_ only where debug output is private. Enable production caching and asset options only after testing the resulting payment flow. Keep personalized cart, checkout and JSON responses out of shared full-page/CDN caches.

Use current PageSpeed Insights/Lighthouse, Search Console and real-device testing. The old Google Mobile-Friendly Test is retired. Test cellular conditions, supported phones, autofill on and off, country changes, every offered payment method, authentication cancellation and retries. A resized desktop window does not test the real keyboard or wallet.

Restore carts and investigate cart update failures

Logged-in customers can recover usable open carts according to the shop's cart-at-login behavior. Guest recovery relies mainly on the browser cookie that identifies the cart. Clearing cookies, changing devices or private sessions can break that association while the database row still exists. Ordered carts are no longer open baskets.

PS_COOKIE_LIFETIME_FO controls the front-office cookie lifetime, not database cart retention. Locate the matching cookie-lifetime field in your version's administration and confirm its value in the correct shop context. Cookie settings have moved between administration pages across versions.

1. Reproduce the issue with a specific product, combination, quantity, customer and country, and note the failing URL and time. Open Console and Network in browser tools.
2. Inspect the cart request and response. A 200 status can still contain an application error or HTML where JSON was expected. A 500 needs PHP/server logs; a 403 needs token, permissions, WAF and security checks.
3. Replay the actual browser request only in a safe test context with its session cookies and current token. A fabricated static-token curl example is not a reliable cart test.
4. Clear relevant template/asset caches through Advanced Parameters > Performance. Temporarily disable asset combination on staging if a combined bundle obscures the failure.
5. Check cookie domain, HTTPS, SameSite/Secure behavior and any load-balanced session storage. Verify www and non-www handling.
6. Check cart-related module hooks and isolate conflicts on a backed-up staging copy with a rollback plan. Disable groups, then narrow to the responsible module. Retest provider callbacks after the change.

Treat domain, cookie and module findings as investigation leads until the failure reproduces and the fix removes it. Regenerate or purge the relevant CDN/asset cache after a fix. Shared caching must bypass customer-specific cart endpoints. A JavaScript error can stop the affected flow, but one error does not automatically prove every script on the page stopped running.

Secure payment and recover remaining abandoned carts

Serve checkout and provider resources over valid HTTPS. Check mixed content, return URLs and callback reachability. Prefer provider-hosted fields or hosted checkout where appropriate, and keep raw card data out of application logs and shop forms. Do not add custom code that sends raw card details through your shop.

PCI scope depends on the complete implementation. Hosted iframes or redirects do not by themselves guarantee SAQ A eligibility. For embedded forms, current SAQ A criteria include confirming the merchant page is not susceptible to script attacks. Confirm the applicable assessment with the entity accepting your compliance submission. Follow the PCI SSC eligibility guidance; do not decide SAQ A versus A-EP from the mere presence of provider JavaScript.

Strong Customer Authentication requirements have exemptions and out-of-scope transactions. 3D Secure is a mechanism supported by card integrations, not the regulation itself. Some transactions complete without a visible challenge; others require authentication. Test success, refusal, cancellation, timeouts and return from an external payment page.

Cart persistence and recovery email are separate features. Native cart storage does not automatically send reminders. A dedicated tool or marketing integration can supply recovery, subject to the applicable messaging rules, consent or soft-opt-in conditions. See Sales Revolution help and Klaviyo Integration help.

A reminder may help a shopper who was interrupted or wanted more time. It can also return someone to the same unresolved error. Fix confirmed checkout faults and measure recovery separately. Include messaging fees, discounts, fulfilment and support costs when assessing profit. Respect opt-outs and do not assume a reminder without a discount is purely transactional.

Rehearse the order journey before the live switch

Keep a timestamped baseline and a rollback route for checkout changes. Before replacing, disabling or uninstalling a checkout or payment module, take a files-and-database backup, work on a staging copy and test the way back. Isolate staging from real payments, customer email and fulfilment. Follow the module's removal instructions and keep the records and access needed for existing payments and refunds; the module removal guide covers what to keep.

• New customer: a guest purchase where offered, then a registered purchase, on phone and desktop. Check required fields and separate delivery and billing details.
• Returning customer: saved-address selection, an address change and whatever saved-payment or wallet flow the supplier has confirmed.
• Product and cart: a combination, a required customization and a basket with several items. Confirm that an express window buys the intended contents.
• Delivery and totals: change country and carrier part-way through, apply a voucher and check the final tax and delivery amounts for each country, currency and customer group you serve.
• Payment: success, decline, authentication completed and cancelled, delayed confirmation, browser closure and a repeated notification, using the provider's supported test procedure.
• Operations: totals, invoices, stock changes, confirmation emails, refunds, provider records and exports to accounting or fulfilment, including any custom integration.

Judge each scenario by those records, not just the confirmation screen. Check that a declined payment or cancelled authentication shows a clear payment outcome, preserves the intended cart and allows retry or a change of method without an unintended duplicate charge. Record the expected order and payment state for each method: a pending transfer and a confirmed card payment should not share one fulfilment expectation. Check duplicate-order prevention explicitly: refreshing or revisiting the confirmation page must not create an unintended second order or charge.

Ask the supplier for evidence, not a speed adjective

• Which journey uses your current payment modules, and which uses the module's own payment integration? Which exact versions were checked?
• Does a product-page button buy the selected item or the basket, and how are variants, customization and a changed address reviewed?
• Which saved-payment or wallet requirement is supported, and what happens after declined or cancelled authentication?
• How do staff reconcile a payment completed after browser closure, and restore the previous checkout if launch checks fail?

Ask an agency to hand over a version inventory, the agreed purchase scenarios, test evidence, saved configuration and rollback steps, and to state who handles delayed payments, refunds and monitoring after launch.

After launch, reconcile new orders with provider transactions. If reversal becomes necessary, account for sales since the backup before restoring a database. Compare completed paid orders, payment failures and support problems by device and customer type with your own baseline.

Questions shop owners ask

Is one-click checkout possible in PrestaShop?

One action can place an order when identity, address, delivery and the payment arrangement are already resolved. Saved-payment flows require supported reuse and customer permission; an offline method can place an unpaid order without reusable card details. Even then, a changed address, an unavailable carrier or a bank authentication request adds a step, so describe the checkout as fast without promising the same number of actions to every buyer.

Should a shop with mainly new customers aim for one click?

Start with guest checkout where appropriate, totals shown early and a usable form, then test a supported wallet. A returning-customer shortcut solves little of what first-time buyers face.

Will installing ps_checkout give us a one-page checkout?

No. It adds PayPal-based payment options to the payment step. On 9.2 the layout question goes to the native one-page module; on earlier releases to a checkout module or custom work.

Do we need both Checkout Revolution and Express Checkout?

Usually not. Both offer a purchase window on product pages, listings and the cart, and both turn a payment completed after the browser closes into an order. Choose by whether the requirement is one page using your existing carriers and payments, or a Stripe-based purchase window; neither description establishes that both run together, so test the combination on staging before activating both.