Replay der 5 typischen Wege
Einfacher Warenkorb, Warenkorb mit Kombinationen, Warenkorb mit Gutschein, B2C-/B2B-Warenkorb, internationaler Versand-Warenkorb. Jeder Weg wird mit geöffnetem Chrome-Netzwerk-Inspektor replayet.
💸 Jeder Tag, der vergeht = verlorener Umsatz
Ihr PrestaShop-Checkout
Ihr PrestaShop-Checkout
verliert Bestellungen?
wir auditieren und reparieren ihn.
PrestaShop-Checkout-Audit und Reparatur
Warenkorb leert sich, Schritt in Schleife, Zahlungsbutton ohne Reaktion, Stripe-Webhook nicht empfangen, Bestellung bezahlt aber nie aufgezeichnet: wir replayen Ihren Weg, identifizieren das Leck, wir reparieren innerhalb 24 h. Letztes Audit: +48 Warenkörbe gerettet/Monat.
✓ Kostenloses Vor-Audit 30 Min
✓ Angebot innerhalb 24 h (Werktag)
✓ Ab 60 €/h netto
✓ Berechnung des wiederherstellbaren Umsatzes
💸 Was es Sie wirklich kostet
Ein Checkout-Bug bedeutet stillen Umsatzverlust
Rechnen Sie nach. Die Kosten des Nichtstuns sind fast immer höher als die Kosten des Einsatzes.
~50
abgebrochene Warenkörbe / Monat
rein technische Ursachen (Audit-Mittel 2025-2026)
rein technische Ursachen (Audit-Mittel 2025-2026)
× 60 €
durchschn. Warenkorb
Standard-B2C-Shop
Standard-B2C-Shop
3 000 €
Umsatz/Monat wiederherstellbar
nach Bug-Behebung
nach Bug-Behebung
💡 Typischer Einsatz 2-4 h auf Angebot (ab 60 €/h netto) · ROI ab dem ersten Monat nach dem Fix.
🔎 Typische Bugs
Die 8 häufigsten Checkout-Bugs
Identifiziert aus 30 PrestaShop-Checkout-Audits 2025-2026. Erkennen Sie Ihren.
1. Warenkorb leert sich zwischen Adress- und Zahlungsschritt
Typische Ursache: inkompatible SameSite-Cookies seit Chrome 80. Der Kunde wird zu Stripe / PayPal / Klarna umgeleitet, kehrt zu Ihrer Site zurück, die Session ist leer. Fix: SameSite=None; Secure auf das Session-Cookie erzwingen, sicherstellen, dass alles HTTPS ist, in 3 Browsern testen.
2. Schritt „Versand“ in Endlosschleife
Typische Ursache: kein Versender verfügbar für Gewicht/Zone des Warenkorbs. Der „Weiter“-Button validiert den Schritt nicht, weil das Versender-Array leer ist. Fix: vollständiges Versender-Audit (Zonen, Gewichte, Maße), Anlegen eines Fallback-Versenders „Standard“, um den Null-Fall zu vermeiden.
3. Bestellung bezahlt, aber nicht erstellt (Stripe-/PayPal-/Klarna-Webhook)
Typische Ursache: Webhook-Endpoint blockiert oder fehlerhaft. Der Kunde zahlt bei Stripe oder Klarna, der PSP sendet einen Bestätigungs-POST an Ihren Shop, Ihr WAF oder Cloudflare blockiert die Anfrage (oder der PHP-Endpoint stürzt ab). Fix: Stripe-Dashboard-Logs prüfen, PSP-IPs im WAF whitelisten, PHP-Handler debuggen.
4. Warenkorbsumme wird negativ
Typische Ursache: Promotion- oder Gutschein-Modul, das einen Rabatt auf bereits reduzierte Produkte falsch anwendet, schlecht gerundete Brutto-Berechnung oder ungeregeltes Rabatt-Stacking. PrestaShop lehnt die Bestellung dann lautlos ab. Fix: Promo-Modul-Audit, Validierung in Cart::getOrderTotal() ergänzen.
5.
max_input_vars zu niedrig
Typische Ursache: PHP-Limits erreicht bei einem Warenkorb mit vielen Kombinationen. max_input_vars standardmäßig = 1000, reicht nicht für einen Warenkorb mit 8 Artikeln × mehreren Kombinationen. Die POST-Anfrage wird abgeschnitten, der Warenkorb korrumpiert. Fix: php_value max_input_vars 4000 in .htaccess oder im PHP-FPM-Pool.
6. Zahlungsmodul mit Timeout
Typische Ursache: API-Aufruf des Zahlungsmoduls (Stripe, PayPal, Klarna, Sofort, Giropay, Mollie, Adyen, Apple/Google Pay) überschreitet max_execution_time in PHP oder DNS löst langsam zur PSP-API auf. Der Kunde sieht einen Endlos-Spinner, dann einen Fehler. Fix: Timeout erhöhen, API-Aufruf optimieren (PSP-Token cachen), Response-Zeit monitoren.
7. JavaScript durch anderes Modul blockiert
Typische Ursache: Tracking-Modul, das ein JS mit Syntaxfehler einfügt und damit die Ausführung des Checkout-JS verhindert. Das Formular wird nicht abgeschickt. Fix: Chrome-Console prüfen (F12 → Console), das fehlerhafte Modul deaktivieren, dem Anbieter melden.
8. Negativer Bestand → Bestellung lautlos abgelehnt
Typische Ursache: mehrere Kunden bestellen gleichzeitig dasselbe Produkt, der Bestand fällt zwischen Warenkorb-Validierung und Bestellungs-Speicherung auf -1, PrestaShop lehnt lautlos ab. Fix: Modus „Bestellungen ohne Bestand erlauben“ aktivieren oder SQL-Lock auf den Bestand während der Transaktion setzen.
🩺 Audit-Methode
Wie wir Ihren Checkout auditieren
3 bis 4 Stunden strukturelle Diagnose. Kein Raten, keine generische Checkliste.
Audit der Module am Checkout
Zahlungs-, Versender-, Gebühren-, Promotion-, Treue-, Steuer-Module. Für jedes: Version, letztes Update, gehängte Hooks, eingespeistes JS, potenzielle Fehlerfläche.
Server-Logs lesen
Apache, PHP-FPM, PrestaShop-Logs (
/var/logs/), PSP-Webhooks. Identifikation lautloser Fehler und fehlgeschlagener Anfragen.
Analytics + Warenkorb-Abbruch-Analyse
GA4-Conversion-Funnel pro Schritt, Identifikation des Leck-Schritts. Wenn ein Warenkorb-Abbruch-Export verfügbar ist: Abgleich mit Server-Logs, um den exakten Abbruch-Moment zu identifizieren.
Multi-Browser- und Multi-Device-Tests
Chrome Desktop, Safari iOS, Chrome Android, Firefox. Jede Kombination deckt spezifische Bugs auf (SameSite Safari, Apple Pay iOS, WhatsApp In-App-Browser usw.).
Bericht + Schätzung wiederherstellbarer Umsatz
Liste der gefundenen Bugs, Schwere, vorgeschlagener Fix, geschätzte Zeit, monatlicher wiederherstellbarer Umsatz. Sie entscheiden, was wir beheben.
💰 Preise
Preise vorab angekündigt
Kostenloses Vor-Audit. Für den Einsatz wissen Sie genau, was er kostet, bevor ich den Code anfasse.
🔍 Vor-Audit
Vor-Audit
das Funnel-Leck finden
0€kostenlos
30 Min · ohne Verpflichtung
- Replay eines typischen Kaufwegs
- 2 wahrscheinlichste Bugs identifiziert
- Beziffertes Angebot + Schätzung wiederherstellbarer Umsatz
- Sie entscheiden, ob wir weitermachen
⚡ Am meisten gefragt
🔧 Einsatz
Gezielter Einsatz
den Kauf-Funnel reparieren
ab 60€netto
je nach Diagnose · Preis vorab angekündigt
- Backup Dateien + DB vor dem Einsatz
- Bug-Behebung (Cookies, Hook, Webhook, Versender...)
- Tests auf 5 typischen Warenkörben + Multi-Browser
- Schriftlicher Bericht: Ursache + wiederherstellbarer Umsatz
- 30 Tage Garantie auf den Fix
🛡️ Wartung
Performance-Wartung
monatlicher Funnel-Test
ab 50€/ Monat
24/7-Überwachung · ohne Verpflichtung
- Automatisierter Replay des monatlichen Kaufwegs
- Tägliche Backups automatisch ausgelagert
- Warenkorb-Abbruch-Tracking + Alarm bei abnormalem Anstieg
- Priorisierter Einsatz bei Checkout-Bug
❓ FAQ
PrestaShop-Checkout-Bugs — häufige Fragen
Fünf Ursachen: (1) inkompatible SameSite-Cookies seit Chrome 80, (2) Promotion-Modul, das den Warenkorb am
actionCartSave ändert, (3) Warenkorb-Token durch schlecht geschriebenes Override neu generiert, (4) PHP max_input_vars erreicht, (5) PHP-Session läuft ab (gc_maxlifetime zu niedrig). Echte Diagnose erfordert ein Replay mit Netzwerk-Inspektor + Server-Logs.Drei Indikatoren zum Abgleich: (1) Checkout-Conversion-Rate in GA4, der Schritt mit abnormalem Abfall verrät den Bug, (2) Server-Logs: POST
/order-opc mit 500 oder unerwartetem Redirect, (3) Warenkorb-Abbruch-Mails. Letzter Kundenfall: 48 Warenkörbe/Monat × 60 € = 2 880 €/Monat verloren, deutlich mehr als die Einsatzkosten.Kostenloses Vor-Audit (30 Min) und anschließend Einsatz auf Angebot, ab 60 €/h netto. Die meisten Standard-Checkout-Bugs (Cookies, Session, fehlerhafter Hook, Versender, Webhook) werden in 2 bis 4 h gelöst, sobald die Ursache identifiziert ist. Angebot innerhalb 24 h (Werktag) vor jedem Start: Sie wissen, was Sie zahlen, bevor wir die Site anfassen. Bei komplexen Fällen (Funnel-Umbau, Zahlungsmodul-Refactoring) ist das Scoping länger und der Preis wird nach Audit präzisiert.
Klassischer Webhook-Bug. Stripe/PayPal/Klarna senden nach der Zahlung einen POST an Ihre Site. Wenn die Anfrage fehlschlägt (WAF-Firewall, ungültiges SSL, Endpoint in 500/Timeout), zeichnet Ihre Site die Bestellung nicht auf, obwohl der Kunde bezahlt hat. Fix: (1) Webhook-Logs im PSP-Dashboard prüfen, (2) Endpoint mit curl testen, (3) PHP-Fehler beheben oder IPs whitelisten. Lautloser, aber teurer Bug.
Vier Ursachen nach Häufigkeit: (1) kein Versender verfügbar für Zone/Gewicht, (2) Versandkosten-Modul stürzt lautlos ab, (3) JavaScript durch anderes Modul blockiert, (4) serverseitige Validierung lehnt ohne explizites Feedback ab. Diagnose immer per Replay mit geöffnetem Chrome Network.
Ja, FTP- oder SSH-Zugang reicht. Wir diagnostizieren die meisten Bugs durch Lesen der Apache-Logs +
/var/logs/ + Inspektion des Codes der Zahlungs-/Versender-Module. Für Fixes, die einen BO-Zugriff erfordern (Modul aktivieren, Versender konfigurieren), können wir bei Bedarf einen Admin-Account per SQL wiederherstellen.Verlieren Sie Bestellungen gerade jetzt?
Kostenloses Vor-Audit 30 Min: wir replayen Ihren Weg, sagen Ihnen, was kaputt ist. Angebot innerhalb 24 h (Werktag), Einsatz ab 60 €/h netto.