PrestaShop-Bestellprozess: Konfiguration, Zahlungen und Diagnose

So würden wir vorgehen

Welche Änderung hilft, hängt vom bestehenden Shop ab: von seiner PrestaShop-Version, seinem Theme, seinen Zahlungs- und Versandmodulen, individuellem Bestellcode und den Bestands-, Buchhaltungs- oder Lieferintegrationen, die seine Bestellungen empfangen. Halten Sie fest, welche Kunden-, Adress- und Bestelldaten jede dieser Integrationen erhält. Wir würden einen scheiternden Kauf vom Warenkorb bis zur Bestellbestätigung auf genau dieser Kombination nachverfolgen, als neuer Besucher und als wiederkehrender Kunde. Vergleichen Sie jede Einschränkung mit der vom Shop beabsichtigten Regel, bevor Sie sie als Fehler behandeln, und beheben Sie dann zuerst nachgewiesene Konfigurations- oder Integrationsfehler. Ändern Sie das Layout, wenn die Nachweise auf verwirrende Felder oder Navigation deuten; ändern Sie die Zahlungsintegration, wenn eine benötigte Zahlungsart oder ein Zahlungsvorgang fehlt.

Für Änderungen an Konfiguration und Modulen des Bestellprozesses gilt: Reproduzieren Sie das Problem auf einer Staging-Kopie des Shops, die von echten Zahlungen, Kunden-E-Mails und Versandabwicklung isoliert ist; ändern Sie jeweils nur eine Ebene; proben Sie schriftlich festgelegte Kaufszenarien; stellen Sie dann zu einem geplanten Zeitpunkt um, mit einem Datei- und Datenbank-Backup, einem getesteten Rückweg und einem Plan zum Abgleich der zwischenzeitlich eingegangenen Bestellungen. Ein Bestellprozess, der den Bedarf bereits erfüllt, bleibt, wie er ist. Ist die Arbeit am Bestellprozess Teil eines umfassenderen Shop-Neuaufbaus, ist der übliche sichere Weg ein sauberer Zielshop auf Staging, eine geprobte Migration der benötigten Shopdaten und eine geplante Umstellung nach dem Test der Module und Integrationen.

Ist die Ursache verlorener Bestellungen unklar, untersucht das PrestaShop B2C Conversion & Revenue Audit Produktsuche, Warenkorb, Bestellprozess, Zahlung und Bestätigung, beginnend auf dem Smartphone, und liefert einen priorisierten Maßnahmenplan, ohne etwas zu installieren oder zu ändern; die Umsetzung ist eine separate Leistung.

Bestellablauf verstehen

In PrestaShop 1.7.8 und 9.1 erstellt der Bestellcontroller vier logische Schritte: persönliche Angaben, Adressen, Lieferung und Zahlung. Ein rein virtueller Warenkorb überspringt die Lieferung. Warenkorbprüfung und Bestellbestätigung sind separate Abschnitte. Eine einzige Bestell-URL kann trotzdem mehrere Schritte, Anfragen und Zahlungsübergaben enthalten.

Wiederkehrende Kunden haben eventuell bereits Angaben gespeichert. Ein Theme oder Bestellmodul kann die Darstellung ändern. Zählen Sie Dokumentnavigationen und Hintergrundanfragen im Browser, bevor Sie Ihren Ablauf als vier- oder fünfseitig bezeichnen.

PrestaShop 9.2 enthält das native Modul ps_onepagecheckout. Es muss aktiviert und konfiguriert werden, bevor sein vereinheitlichter Bestellprozess aktiv wird. Der mehrstufige Ablauf bleibt verfügbar. Die aktuelle Dokumentation zum nativen Bestellprozess erläutert die Integration.

Halten Sie vier Entscheidungen auseinander: das Layout des Bestellprozesses, die Zahlungsintegration, das Anbieterkonto dahinter und die Art, wie Sie den Kaufweg messen.

Halten Sie die installierte PrestaShop-Version, die PHP-Version, das Theme sowie die Versionen von Bestell- und Zahlungsmodul fest, bevor Sie Anleitungen befolgen, und prüfen Sie, was genau diese Versionen unterstützen. Bewerten Sie native Optionen für den Bestellprozess und Module von Drittanbietern gemeinsam; eine alte Roadmap ist keine Einrichtungsanleitung.

Den nächsten Schritt am Symptom ausrichten

Bevor Sie etwas ändern

1. Versuchen Sie denselben Kauf auf einem Smartphone als neuer Besucher und als wiederkehrender Kunde. Notieren Sie, wo Angaben erneut eingegeben werden müssen oder wo ein Fehler den nächsten Schritt unklar lässt.
2. Trennen Sie Navigation von ungelösten Entscheidungen. Eine späte Versandgebühr, ein ungeeigneter Versanddienst oder eine fehlende Zahlungsart braucht eine eigene Lösung, auch auf einer einzigen Seite.
3. Schreiben Sie ein Abnahmeszenario für das Hindernis: Kundentyp, Warenkorb, Lieferziel, Zahlungsart und erwartetes Ergebnis. Vergleichen Sie damit den aktuellen Bestellprozess mit jeder vorgeschlagenen Alternative.

So kann eine Zahlungsoption etwa für einen inländischen Privatkunden erscheinen, aber verschwinden, nachdem der Käufer ein anderes Land wählt, sich in ein Händlerkonto einloggt oder einen bestimmten Versanddienst auswählt. Vergleichen Sie diesen Warenkorbkontext mit den beabsichtigten Zahlungsregeln, bevor Sie das Layout verantwortlich machen. Eine im Dashboard des Anbieters aktivierte Zahlungsart kann über die installierte Integration dennoch nicht verfügbar sein.

Wo die Integration beides nutzt, sind die Rückkehr des Browsers aus der Bankauthentifizierung und die Serverbenachrichtigung des Anbieters getrennte Nachweiswege. Eine defekte Rückkehrseite beweist nicht, dass die Zahlung fehlgeschlagen ist, und eine fehlende Bestätigungsseite beweist nicht, dass keine Bestellung existiert. Prüfen Sie Status, Betrag, Währung und Referenz beim Anbieter gegen den Datensatz im Shop; autorisierte, ausstehende, eingezogene und abgeschlossene Zahlungen können eine unterschiedliche Behandlung erfordern.

Ein nützlicher Supportbericht enthält den Warenkorb, Kundentyp und Kundengruppe, Markt und Währung, Gerät, den Zeitpunkt des Fehlers mit Zeitzone, die Warenkorb- oder Bestellreferenz, eine geschwärzte Transaktionsreferenz des Anbieters, die Schritte zur Reproduktion und die genaue Meldung. Bitten Sie den Entwickler, Browser- und Servernachweise miteinander abzugleichen. Entfernen Sie Zugangsdaten, Zahlungsdetails und unnötige Kundendaten, bevor Sie Protokolle oder Screenshots weitergeben.

Erst die Lücke bestimmen, dann den Bestellprozess wählen

Behalten Sie den installierten nativen Ablauf, wenn er die Anforderung erfüllt, und behalten Sie eine bestehende Zahlungsintegration, wenn sie die benötigten Zahlungsarten und die benötigte Bestellverarbeitung bietet. Kaufen Sie kein Modul, weil sein Name schneller klingt: Auch eine einzige Seite kann jede erforderliche Entscheidung enthalten, und ein Wallet kann Tipparbeit sparen, ohne Liefer- oder Produktoptionen zu klären.

Checkout Revolution bringt Kontakt, Adresse, Lieferung, Zahlung, Gutscheine und die Bestellübersicht auf eine Seite, in einer, zwei oder drei Spalten, wobei Sie die Reihenfolge der Abschnitte sowie die angezeigten und die Pflichtfelder selbst wählen. Ihre bestehenden Versand- und Zahlungsarten erscheinen darin, ein wiederkehrender Kunde muss keine Adresse erneut eintippen, Zahlungsregeln können sich nach Shop, Sprache, Kundengruppe, Land, Gerät und Bestellwert richten, und das angenommene Angebot eines Geschäftskunden kann ohne erneute Eingabe zur Bestellung werden. Es enthält außerdem ein Express-Kauffenster auf Produktseiten, in Listen und im Warenkorb.

Express Checkout bündelt Adresse, Lieferung, Zahlung und Bestätigung in einem Fenster auf Produktseiten, in Listen oder im Warenkorb. Zahlungen laufen über Stripe, ohne monatliche Gebühr und mit einer Provision pro Transaktion, für Karten, Wallets und lokale Zahlungsarten; vergleichen Sie diese Bedingungen getrennt von der Frage, ob der Kaufweg zum Shop passt. Sie wählen die Platzierung der Schaltflächen, die Pflichtfelder der Adresse und die Zahlungsberechtigung nach Zielgruppe, Land und Währung. Versandpreise werden live aktualisiert, ausgeschlossene Kombinationen aus Zahlungsart und Versanddienst werden abgewiesen, und vollständige oder teilweise Erstattungen laufen über die Bestellansicht. Ein optionaler einseitiger Bestellprozess bezieht Ihre anderen Zahlungs- und Versandmodule ein.

Bei beiden wird eine Zahlung, die nach dem Schließen des Browsers abgeschlossen wird, dennoch zur Bestellung. Keine der beiden Produktbeschreibungen verspricht gespeicherte Karten oder nennt ein bestimmtes Wallet wie Apple Pay oder Google Pay; prüfen Sie eine solche Anforderung daher vor dem Kauf anhand der Version und Ihres Zahlungskontos. Kein Produktname belegt die Kompatibilität mit Ihrem individuellen Code: Nehmen Sie Overrides des Bestellprozesses, zusätzliche Felder, Bestands- oder Buchhaltungsintegrationen und B2B-Regeln in die Anforderung auf.

Muss die Wahl getestet werden, vergleicht das PrestaShop Module Selection & Fit Assessment native Einstellungen, bereits vorhandene Produkte, Anbieter und individuelle Entwicklung für eine Anforderung, testet Kandidaten auf einer kontrollierten Shopkopie und umfasst Konfiguration, visuelle Anpassung und Bereitstellung eines gewählten fertigen Moduls; Lizenzen kosten extra, und individuelle Entwicklung wird separat angeboten. Besitzen Sie das gewählte Modul bereits, installiert und konfiguriert der PrestaShop Module Installation & Configuration Service ein bestehendes Modul im vereinbarten Umfang und prüft den betroffenen Ablauf; Lizenzen, zusätzliche Module und Entwicklung werden separat berechnet.

Mehrstufigen, einseitigen oder eingebetteten Bestellprozess wählen

PrestaShop 1.6 hatte eine Einstellung für den Bestellprozesstyp. Der neue 1.7-Ablauf nutzte diesen alten Schalter nicht. Unter 1.7, 8 und 9.0/9.1 erfordert ein vollständig alternatives Layout ein geeignetes Modul oder eine individuelle Implementierung. PrestaShop 9.2 liefert natives OPC; prüfen Sie diese Option vor Beauftragung eines Ersatzes.

Natives OPC ist nicht grundsätzlich auf Hummingbird beschränkt. Von Classic abgeleitete und individuelle Themes können die Vorgaben für seine Templates und sein JavaScript erfüllen. Befolgen Sie den Leitfaden zur Theme-Kompatibilität und testen Sie Ihre installierte Kombination.

Komplexe Beschaffung, regulierte Produkte, Personalisierung und mehrere Versandoptionen können von bewusster Gliederung profitieren. Einfache Bestellungen passen eventuell zu einer einheitlichen Ansicht. Machen Sie bei einem hochpreisigen Artikel wie einer Uhr für 2.000 € die abschließende Prüfung deutlich. Wählen Sie das Layout anhand Ihrer Bestellanforderungen und Usability-Tests: Das sinnvolle Ziel sind weniger unnötige Schritte, bei denen die korrekte Bestellung weiterhin zur Prüfung sichtbar bleibt, nicht eine geringere Seitenzahl.

Checkout Revolution setzt einen einseitigen Bestellprozess sowie Express- und Modal-Abläufe um; siehe die Hilfe zu Checkout Revolution. Prüfen Sie Bestellübersicht und Absendeschaltflächen in Desktop- und Mobilbreiten.

Verzicht auf Core-Änderungen kann Wartung reduzieren, garantiert aber keine künftige Kompatibilität. Versionieren Sie Child-Theme-Änderungen und testen Sie Updates mit Ihren Versand- und Zahlungsmodulen.

Ereignisse messen und Abbrüche untersuchen

Erfassen Sie den Übergang vom Warenkorb in den Bestellprozess, den Abschluss des Bestellprozesses, Zahlungsfehler, Abschlussdauer und Bestellwert. Legen Sie fest, ob Abschluss eine erstellte Bestellung oder eine bestätigte Zahlung bedeutet. Verwenden Sie innerhalb eines Vergleichs durchgehend dieselbe Definition und erfassen Sie damit normale, Express- und weitergeleitete Abläufe, damit kein Wallet- oder Modal-Ablauf in den Summen fehlt. Teilen Sie die Ergebnisse nach Gerät, Kundentyp, Land und Zahlungsart auf, wenn das Volumen es erlaubt.

Dies sind Google-E-Commerce-Ereignisse, keine eigenen Ereignisse für jeden nativen Oberflächenschritt. Erfassen Sie explizite Schrittaufrufe, Übermittlungen, Validierungsergebnisse und Abschlüsse, um Abbrüche bei persönlichen Angaben von Adressabbrüchen zu trennen. Senden Sie keine Namen, E-Mail-Adressen, Anschriften oder Zahlungsdetails an Analysesysteme.

Prüfen Sie jedes Ereignis in den Debugging-Werkzeugen Ihres Browsers und Ihrer Analyse, einschließlich der Übermittlung von Versand und Zahlung, virtueller Warenkörbe und Wiederholungen. Für die Google-Analytics-GA4-Integration nutzen Sie die Modulhilfe.

Untersuchen Sie Rückgänge mit Kundenfeedback, einwilligungsgerechten maskierten Sitzungsaufzeichnungen und Browserfehlern. Ein Ausstieg beim Versand kann an Kosten, fehlenden Versanddiensten, Lieferzeit oder technischen Fehlern liegen. Die Trichterposition beweist kein Kundenmotiv. Priorisieren Sie bestätigte Fehler und Chancen nach betroffenem Traffic, Kosten und erwarteter Wirkung.

Umfragen zu Abbruchgründen können Fragen anregen. Sie messen nicht Ihren PrestaShop-Trichter und sagen nicht den Zugewinn durch eine Änderung voraus, und es gibt keine allgemeingültige Abschlussquote oder Amortisationszeit: Vergleichen Sie mit Ihren eigenen Ausgangswerten. Wählen Sie Vergleichsdesign und Stichprobengröße anhand Ihrer Ausgangswerte, des Effekts, den Sie erkennen müssen, und der Schwankung des Traffics. Kontrollieren Sie Aktionen, Saisonalität und Trafficzusammensetzung. Eine steigende Wallet-Nutzung ohne Veränderung der Gesamtconversion beweist keine Kannibalisierung.

Als Beispiel entspricht ein Anstieg der Abschlussrate von 30 % auf 31 % einer relativen Steigerung um etwa 3,33 %. Der Umsatz steigt nur bei gleichbleibendem Bestellprozessvolumen und durchschnittlichem Bestellwert entsprechend. Diese Rechnung ist keine Prognose.

Warenkorbdaten nutzen, ohne einen Trichter zu erfinden

PrestaShop speichert Warenkörbe dauerhaft. Bestellungen > Warenkörbe ermöglicht ihre Prüfung, doch eine Warenkorbzeile beweist keinen Kassenbeginn. Wählen Sie korrektes Tabellenpräfix und Shop-ID. Dieses lesende Beispiel zählt kürzlich erstellte, aktuell nicht leere Warenkörbe und die Teilmenge mit Verknüpfung zu einer aktuell gültigen Bestellung.

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);

Das ist eine Kohortenquote nicht leerer Warenkörbe zu aktuell gültigen Bestellungen, keine Checkout-Conversion. Neue Warenkörbe hatten weniger Zeit zur Conversion, ausstehende Bestellungen können später gültig werden und ein Warenkorb kann mehrere Bestellungen erzeugen. EXISTS verhindert mehrfaches Zählen eines Warenkorbs.

Definieren Sie Abbruch über eine Inaktivitätsgrenze und eine Bestellrichtlinie. Dieses zweite Beispiel verwendet beispielhaft 24 Stunden ohne Aktualisierung und schließt alle Warenkörbe mit irgendeiner Bestellung einschließlich unbezahlter Bestellungen aus.

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;

Lesen Sie die Stufenbezeichnungen wörtlich. Gespeicherte Adressen und Versanddienste können wiederhergestellt oder automatisch zugewiesen worden sein; sie sind nur Heuristiken. Die Abfrage kann nicht zwischen Recherche, Unterbrechung, Bot-Traffic und einem fehlgeschlagenen Bestellprozess unterscheiden. Wenden Sie dokumentierte Bot-Ausschlüsse an und gleichen Sie Ereignisdaten ab. Verfolgen Sie die Rückgewinnung unbezahlter Bestellungen separat, wenn das Ihr Ziel ist.

Gastbestellungen und Kontofelder konfigurieren

1. Öffnen Sie Shop-Einstellungen > Bestellungen und prüfen Sie Gastbestellungen aktivieren. In modernen Versionen entspricht dies PS_GUEST_CHECKOUT_ENABLED. Speichern Sie im Backoffice im beabsichtigten Shopkontext.
2. Testen Sie eine neue Gastsitzung und ein bestehendes Konto. Im nativen Bestellprozess macht die Gastbestellung das Passwort optional. Anmeldung bleibt möglich.
3. Prüfen Sie Geburtstag, Anrede und zusätzliche Kundenfelder separat. Der B2B-Modus steuert bestimmte Kundenkontofelder; er entfernt Unternehmens- oder VAT-Felder nicht allgemein aus Adressen.
4. Prüfen Sie Adressformat, Postleitzahl- und Bundeslandpflicht jedes Ziellands unter International > Standorte > Länder. Adress- und Versanddienstanforderungen müssen zur Abwicklung passen.

Sie können Konfigurationszeilen ohne Änderungen prüfen:

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

Eine Bestell-E-Mail-Adresse erlaubt kein Marketing. Bieten Sie eine separate angemessene Einwilligung an. Bestellverfolgung kann den nativen Gastverfolgungsablauf verwenden. Die native Umwandlung eines Gasts ist ein expliziter Vorgang; aktivierte Gastbestellungen installieren keine automatische Registrierung nach Kauf. Testen Sie den Umgang mit bestehenden Konto-E-Mail-Adressen, statt doppelte Konten oder automatische E-Mail-Zuordnung zu versprechen.

Konten können eingeschränkten B2B-Zugang, wiederkehrende Serviceverwaltung und Treuedaten unterstützen. Entscheiden Sie anhand dieser Anforderungen: Prüfen Sie beim Verkauf an Verbraucher, ob eine Kontopflicht ein vermeidbares Hindernis schafft; klären Sie beim Verkauf an Unternehmen, welche Käufer freigegebene Konten oder Firmendaten haben müssen. Ein Wechsel des Zahlungsanbieters entscheidet nicht über diese Kontoregeln. Native Downloads virtueller Produkte können geschützte Gastlinks nutzen; der Verkauf eines herunterladbaren Produkts erfordert nicht grundsätzlich die Anmeldung in einem registrierten Konto.

Halten Sie Liefer- und Rechnungsadresse unabhängig voneinander bearbeitbar. Fragen Sie eine Telefonnummer ab, wenn Ihr Lieferdienst eine benötigt. Erhalten Sie gültige internationale Zeichen und erklären Sie Feldfehler, ohne bereits ausgefüllte Felder zu leeren. Klären Sie, bevor Sie ein Pflichtfeld entfernen, mit dem Kunden Schwierigkeiten haben, warum es Pflicht ist.

Testen Sie Bezeichnungen und Fehlermeldungen in jeder Shopsprache, einschließlich Meldungen von Zahlungsmodulen, länderspezifischer Adressfelder und verlinkter Bedingungen. Ein übersetztes Theme beweist nicht, dass jede Modul- oder Anbietermeldung übersetzt ist: Wenn ein französischer Bestellprozess einen englischen Adressfehler zeigt, finden Sie heraus, ob Theme, Modul oder Anbieter ihn erzeugt, bevor Sie entscheiden, wo er übersetzt wird. Ein unsichtbares Pflichtfeld für das Bundesland oder ein unklarer Postleitzahlfehler kann einen Kauf stoppen, bevor die Zahlung beginnt. Der Leitfaden zu Übersetzungen und internationalem Verkauf behandelt die umfassendere Spracheinrichtung.

Die groß angelegten Checkout-Tests des Baymard Institute zeigen, wie oft Shops beide Punkte verfehlen: 98 % der Websites nutzen keine konkreten Fehlermeldungen, und 62 % stellen den Gastkauf nicht als auffälligste Option dar. Die Checkout-UX-Forschung von Baymard erklärt die Belege hinter diesen Empfehlungen.

Kosten, Liefererwartungen und Rückgabebedingungen zeigen

Zeigen Sie bekannte Preise, Steuern und Versandkosten früh an. Kennzeichnen Sie eine Schätzung als Schätzung, wenn die endgültige Adresse oder der Versanddienst noch unbekannt ist. Konfigurieren Sie Steuern, die Preisanzeige je Kundengruppe und Versanddienste für die Ziele, die Sie beliefern; der Versandleitfaden behandelt die Konfiguration der Versanddienste und die Versandkosten. Versand > Voreinstellungen bietet Schwellenwerte für kostenlosen Versand; ein Hinweis auf den noch fehlenden Betrag erfordert eine Ausgabe durch Theme oder Modul.

Ein Kunde, der beispielsweise 40 € erwartet, überlegt bei insgesamt 49 € eventuell neu. Zeigen Sie Zusatzkosten und ihre Grundlage vor der abschließenden Bestellaktion. Ein niedrigerer Preis und eine frühere Erklärung lösen unterschiedliche Probleme.

Geben Sie realistische Angaben zu Bearbeitungs- und Laufzeiten der Versanddienste. Estimated Delivery Date liefert Versand- oder Lieferzeitpunkte; siehe die Hilfe zu Estimated Delivery Date. Verwenden Sie für Versandkosten einen separat getesteten Preisrechner oder eine klare Richtlinie zu Lieferpreisen.

Machen Sie tatsächliche Rückgabebedingungen und Kontaktwege auf Produkt- und Warenkorbseiten leicht auffindbar. Der Retourenschalter steuert einen technischen Ablauf. Er schafft oder beseitigt keine gesetzlichen Rechte und rechtfertigt keine Werbung mit 30 Tagen Rückgabe, sofern Sie dies nicht anbieten. Prüfen Sie die geltenden Widerrufsregeln und Ausnahmen.

Express-Wallets und Schaltflächenverfügbarkeit verstehen

Wallets können gespeicherte Kontaktdaten und tokenisierte Zahlungsdaten liefern. Eine vollständige Express-Integration kann Adressen erfassen, unterstützte Versandoptionen anbieten und Summen im eigenen Ablauf aktualisieren. Kunden müssen eventuell dennoch Angaben bestätigen, Lieferung wählen, Bedingungen annehmen oder sich authentifizieren. Eine Wallet-Zahlung im letzten Schritt umgeht frühere Formulare nicht automatisch.

Express-Checkout ist ein Nutzerablauf und erfordert nicht die Payment Request API des Browsers. Integrationen können Wallet-Oberflächen, Anbieter-SDKs, Modals oder Weiterleitungen nutzen. Sie können separate Rechnungs- und Lieferdaten erfassen. Erhalten Sie einen normalen Bestellweg für nicht unterstützte Browser, Ziele und Bestellanforderungen.

Schaltflächen können je nach Integration und ausgegebenen Hooks auf Produktseiten, in Warenkörben, Miniwarenkörben oder an der Kasse erscheinen. Testen Sie, ob Express auf der Produktseite den gewählten Artikel, den gesamten bestehenden oder einen neuen Warenkorb bezahlt. Messen Sie Warenkorbwert und Abschluss, statt geringere Bestellwerte durch Buy Now anzunehmen.

1. Bestätigen Sie die aktivierte Zahlungsart für Händlerkonto, Land, Währung und Warenkorbbetrag.
2. Registrieren Sie jeden relevanten Checkout-Hostnamen nach Zahlungsanbietervorgabe einschließlich betreffender Domains eingebetteter Zahlungen.
3. Prüfen Sie HTTPS, Zertifikate, iframe-Berechtigungen und Konsolen-/Netzwerkfehler.
4. Prüfen Sie die aktuelle Browsermatrix des Zahlungsanbieters und die konfigurierte Wallet oder Zahlungsart des Kunden.
5. Prüfen Sie modulabhängige Einschränkungen und unterstützte Platzierungen. Anbieterfähigkeiten beweisen keine Modulunterstützung.

Browserunterstützung hängt von Wallet und Integration ab. Prüfen Sie Stripes Express-Checkout-Matrix und Apples Kaufleitfaden für aktuelle Geräte- und Autorisierungsoptionen.

Wenn Ihr Zahlungsanbieter eine Zuordnungsdatei verlangt, prüft dies nur ihre Erreichbarkeit:

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

Eine erfolgreiche Antwort beweist weder die Domainregistrierung noch die Wallet-Berechtigung. Ein unterstütztes Zahlungs-Gateway bietet eventuell bereits Express-Schaltflächen; ein separates Beschleunigungsmodul ist eine weitere Option. Siehe die Hilfe zu Express Checkout.

Ein Warenkorbszenario, das falsches Verhalten aufdeckt

Ein Käufer hat bereits einen Filter im Warenkorb, wählt auf einer Produktseite eine Nachfüllvariante und drückt die Express-Schaltfläche. Ihre Spezifikation muss festlegen, ob diese Aktion nur die Nachfüllung, den bestehenden Warenkorb oder beides nach einer Prüfung kauft. Zeigen Sie den Inhalt vor der Zahlung an und prüfen Sie, was danach im Warenkorb verbleibt; eine Schaltflächenbeschriftung klärt das Verhalten des Moduls nicht.

Wiederholen Sie den Test mit einer leer gelassenen und danach ausgefüllten Pflicht-Personalisierung: Der schnelle Weg muss dieselben Produktanforderungen durchsetzen wie der Hauptbestellprozess. Gibt es für das Lieferziel keinen geeigneten Versanddienst, braucht der Kunde eine Erklärung und eine Möglichkeit, Adresse oder Warenkorb vor der Zahlung zu ändern.

Gespeicherte Zahlungen von Ein-Klick-Bestellungen trennen

Wiederverwendbares Zahlungstoken, bekannter Kunde, aktuelle Adresse, auflösbarer Versand, korrekter Steuerkontext und gültige Einwilligung können Wiederholungskäufe verkürzen. Prüfen Sie Bestand, Preise, Lieferung und Pflichtoptionen vor Belastung erneut. Belassen Sie Zahlungsdaten beim Anbieter und speichern Sie nur benötigte Anbieterkennungen für Kunde/Zahlungsart. Speichern Sie keine rohen Kartennummern oder CVV in PrestaShop.

Anna bestellt zum Beispiel Kaffee mit gespeicherter Adresse und Karte nach. Ihre nächste Bestellung erfordert eventuell wenig Eingaben, doch ein geänderter Versandpreis oder eine Bankauthentifizierung kann einen Schritt hinzufügen. Wenn sie das nächste Paket an die Adresse einer Freundin schickt, müssen Lieferverfügbarkeit und Summe erneut geprüft werden. Ein nützlicher schneller Bestellprozess lässt sie die Adresse korrigieren oder die Bankabfrage abschließen und zeigt dann ein klares Bestellergebnis; er hält die Klickzahl nicht niedrig, indem er stillschweigend alte Angaben wiederverwendet. Auch ein Erstbesucher kann ein eingerichtetes Wallet haben, selbst wenn Ihr Shop keinen früheren Kundendatensatz besitzt; beurteilen Sie daher beide Kaufwege nach korrekten Angaben und einem abgeschlossenen Kauf, nicht nach der Registrierungshistorie.

Einen angemeldeten Kunden zu erkennen ist etwas anderes, als die Erlaubnis und die technische Unterstützung zu haben, eine Zahlungsart wiederzuverwenden. Ein Adressbucheintrag oder eine frühere erfolgreiche Bestellung belegt nicht, dass die nächste Bestellung belastet werden darf, und das Speichern einer Adresse speichert keine Karte. Fragen Sie den Anbieter der Integration, wo wiederverwendbare Angaben gespeichert werden, wie der Kunde sie auswählt und wie er diese Wahl ändern kann.

Ein Kunde, der aktiv kauft, nutzt einen On-Session-Ablauf für gespeicherte Zahlungen. Off-Session beschreibt eine vom Händler ausgelöste Belastung, während der Kunde abwesend ist. Kennzeichnen Sie eine interaktive Belastung im Bestellprozess nicht als Off-Session, nur um die Authentifizierung zu umgehen. Behandeln Sie erforderliche Authentifizierung und asynchrone Ergebnisse gemäß der Integration des Anbieters, und fragen Sie den Anbieter, wie Kundenbestätigung, Erlaubnis für gespeicherte Zahlungen und eine Authentifizierungsabfrage behandelt werden.

1. Berechnen und validieren Sie den Warenkorb serverseitig neu.
2. Bestätigen Sie die Kundenautorisierung mit dem unterstützten Anbieterablauf.
3. Prüfen Sie vertrauenswürdiges Zahlungsergebnis, Betrag, Währung und Warenkorbzuordnung.
4. Erstellen oder aktualisieren Sie die PrestaShop-Bestellung idempotent. Behandeln Sie doppelte Callbacks und Wiederholungen.
5. Gleichen Sie den endgültigen bezahlten, fehlgeschlagenen, ausstehenden oder erstatteten Zustand ab.

Ein Snippet zur PaymentIntent-Erstellung vollendet diesen Bestelllebenszyklus nicht. Auch Offline-Zahlungen können Bestellungen ohne Kartentoken vereinfachen, doch die Bestellung bleibt eventuell unbezahlt und benötigt Bankabgleich oder Zahlung bei Lieferung. Eine feste Anzahl von Tippvorgängen oder ein Kauf ohne Authentifizierung lässt sich nicht garantieren.

Zahlungsintegrationen wählen und Fehler beheben

ps_checkout, PrestaShop Checkout, ist eine Zahlungsintegration und nicht der Name des gesamten Bestellprozesses. Sie verarbeitet Zahlungsoptionen, Autorisierung/Einzug, Transaktionen und Erstattungen über ihre unterstützte PayPal-Integration. Der Händler verbindet ein PayPal-Geschäftskonto. Prüfen Sie Abrechnungs- und Auszahlungsbedingungen Ihres verbundenen Händlerkontos.

Die Bündelung hängt von Distribution und Zeitpunkt ab. Prüfen Sie installiertes Modul und unterstützte Version. Nutzen Sie das offizielle Modul-Repository für die Dokumentation und den offiziellen Transaktionsleitfaden für Zahlungszustände. Offizielle Wege zur Kontofehlerbehebung und Unterstützung sind vorhanden; beachten Sie deren veröffentlichte Bedingungen.

Nutzen Sie für Installation, Einrichtung und Entfernung die offizielle PrestaShop-Checkout-Dokumentation. Bestätigen Sie vor Abschalten eines Anbieters einen anderen funktionierenden Zahlungsweg.

Sie können Stripe, Mollie, PayPal, Adyen, Amazon Pay und spezielle Ratenzahlungsintegrationen wie Klarna, Alma oder Clearpay/Afterpay an Ihren Anforderungen messen. Prüfen Sie das konkrete PrestaShop-Modul statt der Gesamtzahl an Zahlungsarten im Katalog des Anbieters. Vergleichen Sie die Unterstützung für Autorisierung, Erstattungen, Streitfälle, Auszahlung, Währungen, Kontoberechtigung, wiederkehrende Zahlungen, Berichte und Support. Der Zahlungsleitfaden behandelt Auswahl und Betrieb von Zahlungsarten ausführlicher.

Mögliche regionale Prüfbeispiele sind iDEAL für die Niederlande, Bancontact für Belgien, BLIK oder Przelewy24 für Polen, SEPA oder Rechnung für Deutschland/Österreich, Cartes Bancaires oder Ratenzahlung für Frankreich, Bizum für Spanien, Satispay oder MyBank für Italien und Open Banking für das Vereinigte Königreich. Dies sind Recherchebeispiele, keine Verfügbarkeitszusagen Ihres Moduls. Planen Sie keine neuen Integrationen mit den eingestellten eigenständigen Diensten SOFORT oder Giropay. Prüfen Sie die aktuelle Zahlungsartendokumentation des Anbieters.

Vergleichen Sie die tatsächlichen Gebühren für Ihr Unternehmen, die Zahlungsart, Kartenherkunft, Währung, Währungsumrechnung, erfolglose Zahlungen, Erstattungen und Streitfälle. Auch ein kostenloses Modul kann Transaktionskosten haben. Banküberweisung vermeidet Gebühren eines Karten-Gateways, kann aber Bankgebühren und manuellen Abgleich verursachen. Prüfen Sie den Zahlungseingang vor dem Versand; siehe das native Modul für Banküberweisung.

Legen Sie bei jeder verzögerten Zahlungsart fest, wann eine Bestellung versandt werden darf und wer den Zahlungseingang bestätigt: Eine Bestellbestätigung ist kein Nachweis, dass die Zahlung eingegangen ist; beziehen Sie diesen Abgleichaufwand der Mitarbeiter daher in die Wahl ein. Wenn Sie Überweisungen auf mehrere Konten oder in mehreren Währungen erhalten, zeigt Bank Transfer Accounts Kunden das Konto für ihre Bestellwährung mit Betrag und Bestellreferenz auf der Bestätigungsseite, in der E-Mail mit den Zahlungsanweisungen und auf der Seite mit den Bestelldetails an; Zahlungseingang bestätigen und Bestellung aktualisieren müssen Sie weiterhin selbst.

Fragen an Zahlungsanbieter und Modulanbieter

• Ist jede benötigte Zahlungsart für unser Unternehmen, unsere Kundenmärkte, Währungen und Modulversion verfügbar?
• Wo finden Mitarbeiter Transaktionsreferenzen, gleichen Auszahlungen ab und bearbeiten vollständige oder teilweise Erstattungen?
• Wer bearbeitet Integrationsfehler, Kontobeschränkungen und Zahlungsstreitfälle, und welche Nachweise benötigt der Support?
• Wo werden nach einem Wechsel Erstattungen für Bestellungen, die über das vorherige Modul eingegangen sind, abgewickelt und erfasst?

Keine Zahlungsart verfügbar

1. Prüfen Sie aktive Module und Beschränkungen nach Währung, Land, Gruppe und Versanddienst unter Zahlung > Voreinstellungen.
2. Prüfen Sie Anbieterzugangsdaten, Kontostatus, Betragsgrenzen und Live-/Testmodus.
3. Prüfen Sie tatsächlich gelieferte Optionen, PHP-Protokolle und Browserfehler.
4. Prüfen Sie bei blockierten Skripten echte Antwortheader. Unterstellen Sie PrestaShop 8/9 im Auslieferungszustand keine allgemeine Checkout-CSP als Fehlerursache.

Moderne Zahlungsintegrationen sollten paymentOptions implementieren. Die Cores 1.7.8 und 9.1 lesen außerdem displayPaymentEU und advancedPaymentOptions als Kompatibilitätswege. Die Suche nach einem alten Hook-Namen allein diagnostiziert keine Unsichtbarkeit. Verfügbarkeitsbeschränkungen unterscheiden sich von Reihenfolge: Prüfen Sie die Positionierung von paymentOptions unter Design > Positionen sowie jede interne Sortierung des Zahlungsmoduls.

Dynamischen Versand, Rabatte und B2B-Anforderungen testen

Änderungen an Land, Postleitzahl, Menge oder Produkt können Versanddienste, Steuern, Zahlungsberechtigung und Summe ändern. Erhalten Sie weiterhin gültige Auswahlen, entfernen Sie ungültige sichtbar und verhindern Sie Abschicken während unvollständiger Neuberechnung. Testen Sie echte schwere, virtuelle, gemischte und Mehrpaket-Warenkörbe.

Beispielsweise ergeben ein Artikel mit 0,5 kg und einer mit 25 kg zusammen 25,5 kg. Das übersteigt eine hypothetische Versandgrenze von 20 kg, aber keine Grenze von 30 kg. Andere Abmessungen, Zonen und Beschränkungen können einen Versanddienst dennoch ausschließen. Dies sind Beispielgrenzen, keine veröffentlichten Versandbedingungen.

Warenkorbregeln haben Prioritäten, Kombinationsregeln, Kunden-/Produktbeschränkungen, Gültigkeitszeiträume und Nutzungslimits. Eine nicht kombinierbare 20-%-Regel und eine separate Gratisversandregel benötigen getestete Kompatibilität. Ein fester 10-€-Gutschein kann mit einer automatischen 15-%-Regel kollidieren. Eignungsbedingungen und Rabattaktion sind unterschiedliche Steuerungen.

Der Mindestbetrag einer Warenkorbregel verwendet Produktsummen mit den gewählten Steuer- und Währungseinstellungen, zuzüglich Versand, wenn so konfiguriert. Produktspezifische Preisnachlässe wirken sich bereits auf diese Summen aus. In PrestaShop 9.1 zieht die Berechnung außerdem anwendbare Geschenke aus Regeln ab, die sich bereits im Warenkorb befinden. Testen Sie eine Schwelle von 100 € mit einem qualifizierenden Warenkorb und einem knapp darunter, mit rabattierten Produkten, Geschenkprodukten, Währungsumrechnung und mit ein- oder ausgeschlossenem Versand.

Proben Sie auch einen kombinierten Fall. Ein Warenkorb hat einen automatischen Produktrabatt, der Kunde gibt einen Gutschein ein, und eine Versandaktion soll greifen. Notieren Sie zuerst das beabsichtigte Ergebnis: welche Rabatte sich kombinieren, welche Versanddienste infrage kommen und welcher Endbetrag zu zahlen ist. Wiederholen Sie den Test nach Änderung von Menge, Versanddienst und Lieferland, und vergleichen Sie die sichtbare Übersicht, den an den Anbieter gesendeten Betrag und den Bestelldatensatz. Ein abgelehnter Gutschein sollte eine klare Erklärung und einen nutzbaren Weg zur Zahlung hinterlassen.

Versanddienstbeschränkungen der Gratisversandregel müssen zu den beabsichtigten Optionen passen. Profilieren Sie langsame Regelauswertung vor Löschen historischer Regeln; abgelaufene Gültigkeitszeiträume beeinflussen bereits, ob Regeln anwendbar sind. Bewahren Sie Konfiguration nach betrieblichem Bedarf auf.

Ein kompaktes „Haben Sie einen Code?“-Element reduziert Unübersichtlichkeit und hält Gutscheine nutzbar. Aktionscodes müssen über einen getesteten, tokenbewussten Warenkorbablauf angewendet werden. Die bloße URL addDiscount=1&discount_name=SUMMER10 reicht nicht allgemein aus, besonders bei angemeldeten Kunden. Validieren Sie die Eignung am tatsächlichen Warenkorb.

Definieren Sie für B2B separate Rechnungs-/Lieferadresse, Firmendaten, Bestellreferenzen, Kontofreigabe und vereinbarte Zahlungsbedingungen. Eine gültige VAT-Kennung ist nur ein Teil grenzüberschreitender VAT-Behandlung; Lieferbedingungen und Nachweise zählen ebenfalls. Trennen Sie VIES-Nichterreichbarkeit von ungültigem Ergebnis. Prüfen Sie den EU-Leitfaden zur grenzüberschreitenden VAT.

Zusätzliche Felder brauchen einen vollständigen Lebenszyklus: Ausgabe, Validierung, Speicherung und Anzeige dort, wo sie bei Bestellungen, Exporten oder Rechnungen benötigt werden. Eine Bestellnummer des Kunden (PO-Referenz) ist nur nützlich, wenn sie validiert, mit der Bestellung gespeichert und für die Mitarbeiter oder den Export sichtbar ist, die sie benötigen; Lieferhinweise müssen die Versandabwicklung erreichen. Ein Feld in einem Template erscheinen zu lassen, ist keine vollständige Implementierung. Erweiterungen des Kundenformulars können additionalCustomerFormFields und validateCustomerFormFields nutzen; der Leitfaden zu Hooks und Overrides erklärt, wie Module sich daran anbinden. actionValidateOrder allein kann das Formular nicht umsetzen.

Dieser Hook zur Bestellerstellung läuft innerhalb von PaymentModule::validateOrder() vor der anschließenden Statusbehandlung. Er kann bei ausstehenden oder Offline-Bestellungen laufen. Prüfen Sie Zahlungsstatus und Browserbestätigung separat. Nutzen Sie passende Anbieter-Callbacks und Bestellstatusbehandlung für Zahlungs-, Bestands- und E-Mail-Aktionen.

Den Ablauf auf Smartphones nutzbar machen

Nutzen Sie Analysen nach Gerätekategorie mit funktionierenden Kaufereignissen. Der ältere Bericht zu Browsern und Betriebssystemen ist ein Kompatibilitätsbericht, kein moderner mobiler Umsatztrichter. Besuchsabsicht, Akquisitionsmix, geräteübergreifende Käufe und Trackinglücken können Geräteunterschiede ebenfalls erklären.

Classic ist in älteren und aktualisierten Shops weiter verbreitet. Hummingbird wurde Standard neuer PrestaShop-9.1-Installationen. Weder eine Responsive-Kennzeichnung noch ein neues Theme garantieren, dass Inhalte ohne Überlaufen dargestellt werden, Tastaturen nutzbar sind oder Module barrierefrei funktionieren.

• Verwenden Sie type="email" und autocomplete="email" für E-Mail sowie type="tel" mit autocomplete="tel" für Telefon.
• Nutzen Sie Texteingaben für Postleitzahlen. Ergänzen Sie inputmode="numeric" nur beim numerischen Format des gewählten Landes. Britische, niederländische und kanadische Formate benötigen Buchstaben.
• Verwenden Sie passende Autocomplete-Tokens für Namen und Adressen. Prüfen Sie die tatsächlich erzeugten Felder. Das moderne Adressformular verwendet customer/_partials/address-form.tpl und gemeinsames Feld-Rendering, keine unterstellte Eingabedatei in Checkout-Teilen.
• Nutzen Sie große, beabstandete Bedienelemente und vollständig beschriftete Versand-/Zahlungszeilen. Eine Zielgröße von 44 bis 48 CSS-Pixeln ist eine praktische Designoption; prüfen Sie Größe und Abstand auf echten Geräten.
• Halten Sie aktualisierte Summe und Prüfweg leicht erreichbar. Fixierte Abschlussschaltflächen dürfen Bedingungen, Fehler, Chat oder Einwilligungssteuerung nicht verdecken.
• Erhalten Sie eingegebene Werte, sichtbaren Fokus und konkrete direkte Fehlermeldungen.

Nutzen Sie im übrigen mobilen Shop antippbare Menüerweiterungen mit Elternlinks, eine bedienbare Filterschublade, lesbare Produktinformationen und schließbare Popups. Halten Sie wichtige Inhalte und strukturierte Daten mobil verfügbar. Nutzen Sie responsive Bildgrößen und Lazy Loading unterhalb des Sichtbereichs, ohne das Titelbild zu verzögern.

Telefonlinks können mobil und in unterstützten Desktop-Anruf-Apps helfen. Zuletzt angesehene Produkte und fixierte Warenkorbschaltflächen sind Optionen für Tests im installierten Theme oder Modul, kein allgemeines natives Verhalten. Vergleichen Sie Kategorieausstiege, Produktentdeckung und Käufe neben Bestellabschlüssen.

Profilieren Sie Bestellanfragen auf isoliertem Staging. Modul-Hooks, externe Tarif-/Steuer-/Adressanfragen, Versanddienstauflösung, Warenkorbregeln, Datenbankabfragen und Skripte sind mögliche Engpässe. Verwenden Sie _PS_DEBUG_PROFILING_ nur bei privater Debugausgabe. Aktivieren Sie Produktivcaching und Ressourcenoptionen erst nach Test des entstehenden Zahlungsablaufs. Halten Sie personalisierte Warenkorb-, Checkout- und JSON-Antworten aus gemeinsamen Ganzseiten-/CDN-Caches heraus.

Nutzen Sie aktuelle PageSpeed Insights/Lighthouse, Search Console und echte Gerätetests. Der alte Google Mobile-Friendly Test ist eingestellt. Testen Sie Mobilfunkbedingungen, unterstützte Smartphones, Autofill an/aus, Länderwechsel, alle angebotenen Zahlungsarten, Authentifizierungsabbruch und Wiederholungen. Ein verkleinertes Desktopfenster testet weder echte Tastatur noch Wallet.

Warenkörbe wiederherstellen und Aktualisierungsfehler untersuchen

Angemeldete Kunden können nutzbare offene Warenkörbe gemäß dem Anmeldeverhalten des Shops wiederherstellen. Bei Gästen hängt dies hauptsächlich am identifizierenden Browsercookie. Cookie-Löschen, Gerätewechsel oder private Sitzungen können die Zuordnung trennen, während die Datenbankzeile bestehen bleibt. Bestellte Warenkörbe sind nicht mehr offen.

PS_COOKIE_LIFETIME_FO steuert die Frontoffice-Cookie-Lebensdauer, nicht die Datenbankaufbewahrung von Warenkörben. Suchen Sie das passende Lebensdauerfeld in der Verwaltung Ihrer Version und bestätigen Sie den Wert im richtigen Shopkontext. Cookie-Einstellungen wechselten über Versionen zwischen Verwaltungsseiten.

1. Reproduzieren Sie das Problem mit einem bestimmten Produkt, einer Variante, Menge, einem Kunden und Land, und notieren Sie die fehlschlagende URL und Uhrzeit. Öffnen Sie Konsole und Netzwerk in den Browserwerkzeugen.
2. Prüfen Sie Warenkorbanfrage und Antwort. Status 200 kann dennoch Anwendungsfehler oder HTML statt erwartetem JSON enthalten. Bei 500 sind PHP-/Serverprotokolle nötig, bei 403 Token-, Berechtigungs-, WAF- und Sicherheitsprüfungen.
3. Wiederholen Sie die tatsächliche Browseranfrage nur in sicherem Testkontext mit Sitzungscookies und aktuellem Token. Ein erfundenes curl-Beispiel mit statischem Token ist kein zuverlässiger Warenkorbtest.
4. Leeren Sie relevante Template-/Ressourcen-Caches unter Erweiterte Einstellungen > Leistung. Deaktivieren Sie Bündelung vorübergehend auf Staging, wenn ein Bundle den Fehler verdeckt.
5. Prüfen Sie Cookiedomain, HTTPS, SameSite-/Secure-Verhalten und lastverteilte Sitzungsspeicherung. Verifizieren Sie www-/Nicht-www-Behandlung.
6. Prüfen Sie warenkorbbezogene Modul-Hooks und isolieren Sie Konflikte auf einer gesicherten Staging-Kopie mit Rollback-Plan. Deaktivieren Sie Gruppen und grenzen Sie dann auf das verantwortliche Modul ein. Testen Sie Anbieter-Callbacks nach der Änderung erneut.

Behandeln Sie Befunde zu Domain, Cookies und Modulen als Ermittlungsansätze, bis der Fehler reproduziert ist und die Korrektur ihn beseitigt. Erzeugen Sie den relevanten CDN- oder Asset-Cache nach einer Korrektur neu oder leeren Sie ihn. Gemeinsames Caching muss kundenspezifische Warenkorb-Endpunkte umgehen. Ein JavaScript-Fehler kann den betroffenen Ablauf stoppen, doch ein einzelner Fehler beweist nicht automatisch, dass jedes Skript auf der Seite angehalten wurde.

Zahlungen absichern und übrige verlassene Warenkörbe zurückgewinnen

Liefern Sie Ressourcen des Bestellprozesses und des Anbieters über gültiges HTTPS aus. Prüfen Sie gemischte Inhalte, Rückkehr-URLs und die Erreichbarkeit von Callbacks. Bevorzugen Sie, wo angemessen, vom Anbieter gehostete Felder oder einen gehosteten Bestellprozess, und halten Sie rohe Kartendaten aus Anwendungsprotokollen und Shopformularen heraus. Fügen Sie keinen individuellen Code hinzu, der rohe Kartendaten über Ihren Shop sendet.

Der PCI-Umfang hängt von der gesamten Implementierung ab. Gehostete iframes oder Weiterleitungen garantieren allein keine SAQ-A-Eignung. Für eingebettete Formulare umfassen aktuelle SAQ-A-Kriterien die Bestätigung, dass die Händlerseite nicht für Skriptangriffe anfällig ist. Bestätigen Sie die anwendbare Bewertung mit der Stelle, die Ihren Konformitätsnachweis annimmt. Befolgen Sie den PCI-SSC-Eignungsleitfaden; entscheiden Sie SAQ A gegenüber A-EP nicht allein anhand von Anbieter-JavaScript.

Starke Kundenauthentifizierung hat Ausnahmen und nicht erfasste Transaktionen. 3D Secure ist ein Mechanismus unterstützter Kartenintegrationen, nicht die Vorschrift selbst. Manche Transaktionen enden ohne sichtbare Abfrage, andere erfordern Authentifizierung. Testen Sie Erfolg, Ablehnung, Abbruch, Timeouts und Rückkehr von externer Zahlungsseite.

Dauerhafte Warenkorbspeicherung und Wiederherstellungs-E-Mails sind getrennte Funktionen. Die native Warenkorbspeicherung versendet nicht automatisch Erinnerungen. Ein spezielles Werkzeug oder eine Marketingintegration kann die Rückgewinnung übernehmen, vorbehaltlich der geltenden Regeln für Nachrichten, Einwilligungen oder Soft-Opt-in-Bedingungen. Siehe die Hilfe zu Sales Revolution und die Hilfe zu Klaviyo Integration.

Eine Erinnerung kann unterbrochenen oder länger überlegenden Kunden helfen. Sie kann auch zum selben ungelösten Fehler zurückführen. Beheben Sie bestätigte Bestellfehler und messen Sie Rückgewinnung separat. Beziehen Sie Nachrichtenkosten, Rabatte, Abwicklung und Support in die Gewinnbewertung ein. Beachten Sie Abmeldungen und halten Sie Erinnerungen ohne Rabatt nicht automatisch für rein transaktional.

Den Bestellablauf vor der Live-Umstellung proben

Halten Sie für Änderungen am Bestellprozess einen Ausgangsstand mit Zeitstempel und einen Rollback-Weg bereit. Erstellen Sie vor dem Ersetzen, Deaktivieren oder Deinstallieren eines Bestell- oder Zahlungsmoduls ein Datei- und Datenbank-Backup, arbeiten Sie auf einer Staging-Kopie und testen Sie den Rückweg. Isolieren Sie Staging von echten Zahlungen, Kunden-E-Mails und Versandabwicklung. Befolgen Sie die Entfernungsanleitung des Moduls und behalten Sie die Datensätze und Zugänge, die für bestehende Zahlungen und Erstattungen nötig sind; der Leitfaden zur Modulentfernung beschreibt, was aufzubewahren ist.

• Neuer Kunde: ein Gastkauf, sofern angeboten, dann ein Kauf mit Registrierung, auf Smartphone und Desktop. Prüfen Sie Pflichtfelder und getrennte Liefer- und Rechnungsangaben.
• Wiederkehrender Kunde: Auswahl einer gespeicherten Adresse, eine Adressänderung und der Ablauf für gespeicherte Zahlungen oder Wallets, den der Anbieter bestätigt hat.
• Produkt und Warenkorb: eine Variante, eine Pflicht-Personalisierung und ein Warenkorb mit mehreren Artikeln. Bestätigen Sie, dass ein Express-Fenster den beabsichtigten Inhalt kauft.
• Lieferung und Summen: Land und Versanddienst mittendrin ändern, einen Gutschein anwenden und die endgültigen Steuer- und Versandbeträge für jedes Land, jede Währung und jede Kundengruppe prüfen, die Sie bedienen.
• Zahlung: Erfolg, Ablehnung, abgeschlossene und abgebrochene Authentifizierung, verzögerte Bestätigung, geschlossener Browser und eine wiederholte Benachrichtigung, mit dem unterstützten Testverfahren des Anbieters.
• Betrieb: Summen, Rechnungen, Bestandsänderungen, Bestätigungs-E-Mails, Erstattungen, Anbieterdatensätze und Exporte an Buchhaltung oder Versandabwicklung, einschließlich individueller Integrationen.

Beurteilen Sie jedes Szenario anhand dieser Datensätze, nicht nur anhand der Bestätigungsseite. Prüfen Sie, dass eine abgelehnte Zahlung oder abgebrochene Authentifizierung ein klares Zahlungsergebnis zeigt, den beabsichtigten Warenkorb erhält und einen erneuten Versuch oder einen Wechsel der Zahlungsart ohne unbeabsichtigte doppelte Belastung erlaubt. Halten Sie für jede Zahlungsart den erwarteten Bestell- und Zahlungsstatus fest: Für eine ausstehende Überweisung und eine bestätigte Kartenzahlung sollte nicht dieselbe Erwartung an den Versand gelten. Prüfen Sie die Verhinderung doppelter Bestellungen ausdrücklich: Ein Neuladen oder erneuter Aufruf der Bestätigungsseite darf keine unbeabsichtigte zweite Bestellung oder Belastung erzeugen.

Vom Anbieter Nachweise statt Geschwindigkeitsversprechen verlangen

• Welcher Ablauf nutzt unsere aktuellen Zahlungsmodule, und welcher die eigene Zahlungsintegration des Moduls? Welche genauen Versionen wurden geprüft?
• Kauft eine Schaltfläche auf der Produktseite den gewählten Artikel oder den Warenkorb, und wie werden Varianten, Personalisierung und eine geänderte Adresse geprüft?
• Welche Anforderung an gespeicherte Zahlungsarten oder Wallets wird unterstützt, und was geschieht nach abgelehnter oder abgebrochener Authentifizierung?
• Wie gleichen Mitarbeiter eine Zahlung ab, die nach dem Schließen des Browsers abgeschlossen wurde, und wie stellen sie den vorherigen Bestellprozess wieder her, wenn die Prüfungen beim Start fehlschlagen?

Bitten Sie eine Agentur, eine Versionsübersicht, die vereinbarten Kaufszenarien, Testnachweise, die gespeicherte Konfiguration und die Rollback-Schritte zu übergeben und anzugeben, wer nach dem Start verzögerte Zahlungen, Erstattungen und das Monitoring übernimmt.

Gleichen Sie nach dem Start neue Bestellungen mit den Transaktionen des Anbieters ab. Wird eine Rücknahme nötig, berücksichtigen Sie die Verkäufe seit dem Backup, bevor Sie eine Datenbank wiederherstellen. Vergleichen Sie abgeschlossene bezahlte Bestellungen, Zahlungsfehler und Supportprobleme nach Gerät und Kundentyp mit Ihren eigenen Ausgangswerten.

Fragen von Shopbetreibern

Ist ein Bestellprozess mit einem Klick in PrestaShop möglich?

Eine einzige Aktion kann eine Bestellung aufgeben, wenn Identität, Adresse, Lieferung und Zahlungsvereinbarung bereits geklärt sind. Abläufe mit gespeicherten Zahlungen erfordern eine unterstützte Wiederverwendung und die Erlaubnis des Kunden; eine Offline-Zahlungsart kann eine unbezahlte Bestellung ohne wiederverwendbare Kartendaten aufgeben. Selbst dann fügen eine geänderte Adresse, ein nicht verfügbarer Versanddienst oder eine Authentifizierungsanfrage der Bank einen Schritt hinzu; beschreiben Sie den Bestellprozess daher als schnell, ohne jedem Käufer dieselbe Zahl an Aktionen zu versprechen.

Sollte ein Shop mit überwiegend neuen Kunden auf einen Klick abzielen?

Beginnen Sie, wo angemessen, mit Gastbestellungen, früh angezeigten Summen und einem gut nutzbaren Formular, und testen Sie dann ein unterstütztes Wallet. Eine Abkürzung für wiederkehrende Kunden löst wenig von dem, was Erstkäufern begegnet.

Bekommen wir mit ps_checkout einen einseitigen Bestellprozess?

Nein. Es fügt dem Zahlungsschritt PayPal-basierte Zahlungsoptionen hinzu. Unter 9.2 ist für die Layoutfrage das native One-Page-Modul zuständig, in älteren Versionen ein Bestellmodul oder individuelle Entwicklung.

Brauchen wir sowohl Checkout Revolution als auch Express Checkout?

Meist nicht. Beide bieten ein Kauffenster auf Produktseiten, in Listen und im Warenkorb, und beide machen aus einer Zahlung, die nach dem Schließen des Browsers abgeschlossen wird, eine Bestellung. Entscheiden Sie danach, ob die Anforderung eine Seite mit Ihren bestehenden Versand- und Zahlungsarten ist oder ein Stripe-basiertes Kauffenster; keine der Beschreibungen belegt, dass beide zusammen laufen. Testen Sie die Kombination daher auf Staging, bevor Sie beide aktivieren.