✓ No commitment · ⚡ Reply within 24 h · 📞 06 78 85 05 63
💸 Every day that passes = lost revenue

Your PrestaShop checkout
is losing orders?
we audit it and fix it.

PrestaShop checkout audit and fix

Cart emptying, step looping, payment button unresponsive, Stripe webhook not received, order paid but never recorded: we replay your journey, identify the leak, we fix within 24 h. Latest audit: +48 carts recovered/month.

Or I call: +33 6 78 85 05 63
✓ Free 30-min pre-audit ✓ Firm quote within 24 business hours ✓ From €60/h excl. VAT ✓ Recoverable revenue estimate
💸 What it really costs you

A checkout bug means revenue leaking, silently

Do the math. The cost of inaction is almost always higher than the cost of intervention.

~50
abandoned carts / month
purely technical causes (audit avg 2025-2026)
× £55
average basket
standard B2C store
£2,750
monthly revenue recoverable
after the bug is fixed
💡 Typical intervention 2-4 h on quote (from €60/h excl. VAT) · ROI from the first month after the fix.
🔎 Typical bugs

The 8 most frequent checkout bugs

Identified across 30 PrestaShop checkout audits 2025-2026. Recognise yours.

1. Cart emptying between address and payment step

Typical cause: incompatible SameSite cookies since Chrome 80. The customer is redirected to Stripe / PayPal, returns to your site, the session is null. Fix: force SameSite=None; Secure on the session cookie, ensure everything is HTTPS, test across 3 browsers.

2. Shipping step looping

Typical cause: no carrier available for the cart's weight/zone. The Next button doesn't validate the step because the carrier array is empty. Fix: full carrier audit (zones, weight, dimensions), creation of a fallback "default" carrier to avoid the zero case.

3. Order paid but not created (Stripe / PayPal webhook)

Typical cause: webhook endpoint blocked or erroring. The customer pays on Stripe, Stripe POSTs a confirmation to your store, your WAF or Cloudflare blocks the request (or the PHP endpoint crashes). Fix: check Stripe dashboard logs, whitelist Stripe IPs on the WAF, debug the PHP handler.

4. Cart total going negative

Typical cause: promotion or voucher module applying a discount poorly on already-discounted products, badly rounded VAT-inclusive math, or ungoverned discount stacking. PrestaShop then silently rejects the order. Fix: promo module audit, validation added on Cart::getOrderTotal().

5. max_input_vars too low

Typical cause: PHP limits reached on a cart with many combinations. max_input_vars defaults to 1000, insufficient for a basket of 8 items × multiple combinations. The POST request is truncated, the cart corrupted. Fix: php_value max_input_vars 4000 in .htaccess or PHP-FPM pool.

6. Payment module timing out

Typical cause: payment module API call exceeding PHP's max_execution_time, or slow DNS resolution to the PSP API (Stripe, PayPal, Klarna, Worldpay, Adyen). The customer sees an infinite spinner then an error. Fix: raise timeout, optimise the API call (cache the PSP token), monitor response time.

7. JavaScript blocked by another module

Typical cause: tracking module injecting a JS with a syntax error, preventing the checkout JS from running. The form doesn't submit. Fix: inspect the Chrome console (F12 → Console), disable the offending module, report to the vendor.

8. Negative stock → order silently rejected

Typical cause: multiple customers ordering the same product simultaneously, stock dropping to -1 between cart validation and order recording, PrestaShop silently rejecting. Fix: enable "allow orders out of stock", or SQL-lock stock during the transaction.

🩺 Audit method

How we audit your checkout

3 to 4 hours of structural diagnosis. No guessing, no generic checklist.

Step 1
Replay of the 5 typical journeys Simple cart, cart with combinations, cart with voucher, B2C / B2B cart, international shipping cart. Each journey is replayed with the Chrome network inspector open.
Step 2
Audit of modules touching checkout Payment, carrier, fees, promotion, loyalty, tax modules. For each: version, last update, registered hooks, injected JS, potential failure surface.
Step 3
Server log reading Apache, PHP-FPM, PrestaShop logs (/var/logs/), PSP webhooks. Identification of silent errors and failed requests.
Step 4
Analytics + abandoned cart analysis GA4 conversion funnel by step, identification of the leak step. If abandoned cart export is available: cross-reference with server logs to identify the exact dropout moment.
Step 5
Multi-browser and multi-device tests Chrome desktop, Safari iOS, Chrome Android, Firefox. Each combo exposes specific bugs (SameSite Safari, Apple Pay iOS, WhatsApp in-app browser, etc.).
Deliverable
Report + recoverable revenue estimate List of bugs found, severity, proposed fix, estimated time, monthly recoverable revenue. You decide what we fix.
💰 Pricing

Pricing stated up-front

Free pre-audit. For the intervention, you know exactly what it costs before we touch the code.

🔍 Pre-audit

Pre-audit

find the funnel leak
0€free
30 min · no commitment
  • Replay of a typical purchase journey
  • 2 most likely bugs identified
  • Firm quote + recoverable revenue estimate
  • You decide if we continue
Start the pre-audit →
⚡ Most requested 🔧 Intervention

Targeted intervention

fix the checkout funnel
from 60€excl. VAT
per diagnostic · price stated up-front
  • Backup of files + DB before any intervention
  • Bug fix (cookies, hook, webhook, carrier...)
  • Tests across 5 typical carts + multi-browser
  • Written report: cause + recoverable revenue
  • 30-day warranty on the fix
🛡️ Maintenance

Performance maintenance

test the funnel every month
from 50€/ month
24/7 monitoring · no commitment
  • Automated replay of monthly purchase journey
  • Daily backups externalised
  • Abandoned cart tracking + alert on abnormal spike
  • Priority intervention on checkout bugs
❓ FAQ

PrestaShop checkout bugs — frequently asked questions

Five causes: (1) incompatible SameSite cookies since Chrome 80, (2) promotion module modifying the cart on actionCartSave, (3) cart token regenerated by a poorly written override, (4) PHP max_input_vars reached, (5) PHP session expiring (gc_maxlifetime too low). Real diagnosis requires a replay with network inspector + server logs.
Three indicators to cross-check: (1) checkout conversion rate in GA4, the step with an abnormal drop reveals the bug, (2) server logs: POST /order-opc in 500 or unexpected redirect, (3) abandoned cart emails. Latest client case: 48 carts/month × £55 = £2,640/month lost, far more than the intervention cost.
Free pre-audit (30 min), then intervention on quote, from €60/h excl. VAT. The majority of standard checkout bugs (cookies, session, faulty hook, carrier, webhook) are resolved in 2 to 4 hours once the cause is identified. Firm quote sent within 24 business hours before any work starts: you know what you pay before we touch the site. For complex cases (funnel rebuild, payment module refactor), scoping is longer and the figure firmed up after audit.
Classic webhook bug. Stripe/PayPal/Klarna POST to your site after payment. If the request fails (WAF firewall, invalid SSL, endpoint in 500/timeout), your site doesn't record the order even though the customer paid. Fix: (1) check webhook logs in the PSP dashboard, (2) test the endpoint with curl, (3) fix the PHP error or whitelist IPs. Silent but costly bug.
Four causes by frequency: (1) no carrier available for the zone/weight, (2) shipping cost module crashing silently, (3) JavaScript blocked by another module, (4) server-side validation rejecting without explicit feedback. Always diagnosed by replay with Chrome Network open.
Yes, FTP or SSH access is enough. We diagnose most bugs by reading Apache logs + /var/logs/ + inspecting payment/carrier module code. For fixes requiring BO (enabling a module, configuring a carrier), we can recover an admin account via SQL if necessary.

Losing orders right now?

Free 30-min pre-audit: we replay your journey, tell you what's broken. Firm quote within 24 business hours, intervention from €60/h excl. VAT.

📞 +33 6 78 85 05 63
📞 Call · 06 78 85 05 63