Zahlungsmethoden in PrestaShop auswählen und betreiben

So würden wir vorgehen

Wir würden eine funktionierende Zahlungsintegration behalten, solange sie keine Anforderung verfehlt, die Sie tatsächlich brauchen: eine Methode, nach der Ihre Kunden fragen, einen Markt, den der Connector nicht bedienen kann, oder einen Fehler, den Sie reproduzieren können. Ein Wechsel des Connectors verändert Bestellerstellung, Benachrichtigungen, Erstattungen und Abgleich, nicht nur die Schaltfläche im Checkout. Prüfen Sie zuerst, ob die aktuelle Integration es bereits kann: Ein Modul kann mehrere Methoden liefern, und eine fehlende Option kann an einer Einstellung zu Konto, Berechtigung, Währung oder Einschränkungen liegen.

Ist eine Änderung gerechtfertigt, nehmen Sie sie auf einer Staging-Kopie des Live-Shops vor: mit demselben Theme, denselben Modulen, Versanddienstleistern und individuellem Code, isoliert von Live-Zahlungen, Kunden-E-Mails und Exporten an die Auftragsabwicklung und verbunden mit dem Testkonto des Anbieters. Proben Sie die Kauf-, Unterbrechungs- und Erstattungstests, bis sie bestehen, und stellen Sie dann den Live-Shop in einem vereinbarten Zeitfenster um, mit wiederherstellbarer vorheriger Konfiguration und einer benannten Person, die Zahlungen und Bestellungen abgleicht.

Welcher Weg passt zum Problem?

Der native PrestaShop-Checkout zeigt an, was die installierten Gateway-Module zurückgeben. Express Checkout nutzt Stripe und bündelt Adresse, Lieferung, Zahlung und Bestätigung in einem Fenster auf Produktseiten, in Listen oder im Warenkorb. Laut Produktbeschreibung umfasst es Pflichtfelder für die Adresse, Zahlungsberechtigung nach Zielgruppe, Land und Währung, Live-Versandpreise, die Ablehnung ausgeschlossener Kombinationen aus Zahlungsmethode und Versanddienstleister, die Bestellerstellung nach abgeschlossener Zahlung auch bei geschlossenem Browser sowie vollständige oder teilweise Erstattungen aus der Bestellansicht. Checkout Revolution bringt Kontakt, Adresse, Lieferung, Zahlung, Gutscheine und die Bestellübersicht mit Ihren bestehenden Versand- und Zahlungsarten auf eine Seite und bietet ebenfalls ein Express-Kauffenster. Auch Express Checkout hat einen optionalen einseitigen Checkout; vergleichen Sie daher die Überschneidung, bevor Sie beide kaufen. Keine der Beschreibungen belegt, dass die beiden in Ihrem Shop zusammen laufen sollten.

Wenn Sie zwischen Kandidaten wählen, testet das PrestaShop Module Selection & Fit Assessment die Wege anhand Ihrer Anforderung auf einer kontrollierten Shopkopie. Ist das Modul bereits gewählt, installiert der PrestaShop Module Installation & Configuration Service ein bestehendes Modul, konfiguriert die vereinbarten Einstellungen und prüft den relevanten Ablauf; Lizenzen, zusätzliche Module und Entwicklung sind separate Leistungen.

Methoden für Ihre Zielmärkte auswählen

Erstellen Sie anhand der Länder, Währungen und Geräte Ihrer Kunden, der Supportanfragen sowie abgeschlossener und fehlgeschlagener Kaufabschlüsse eine Vorauswahl. Eine fehlende bevorzugte Zahlungsmethode kann zum Abbruch führen. Weder diese Beobachtung noch ein Länderklischee belegt jedoch, welche Methode Ihr Shop benötigt.

Dies ist eine Recherche-Checkliste, keine Rangfolge oder Pflichtliste. Leiten Sie daraus nicht ab, dass Karten in einem ganzen Land selten, ausländisch oder unbrauchbar sind oder dass ein BNPL-Anbieter in allen nordischen Märkten der Standard ist.

Cartes Bancaires ist das nationale Kartennetz Frankreichs. Viele Karten tragen zusätzlich die Marke eines internationalen Netzwerks. Prüfen Sie die Anforderungen an die Netzwerkwahl durch Karteninhaber Ihrer Integration, statt einen bevorzugten Zahlungsweg zu erzwingen und niedrigere Ablehnungsquoten zu versprechen.

Prüfen Sie bei Nachnahme den Geldeinzug durch den Versanddienstleister, Gebühren, Abrechnung sowie den Umgang mit Annahmeverweigerungen und Retouren. Eine Zahlungsoption allein organisiert keinen Geldeinzug.

Module, Methoden und native Einschränkungen verstehen

Ein Zahlungsmodul kann mehrere PaymentOption-Objekte über paymentOptions zurückgeben. PrestaShop 1.7.8 und 9.1 sammeln die Checkout-Optionen nach Modul. Eine Anbieterintegration kann daher Karten, Wallets und lokale Methoden anbieten, ohne für jede Methode ein eigenes Modul zu benötigen.

Zahlung > Einstellungen beschränkt Zahlungsmodule nach Währung, Land, Kundengruppe und Versanddienstleister. Diese Einschränkungen sind dem Modul zugeordnet, nicht jeder einzelnen Methode eines Aggregators. Wenn Sie Mollie oder Stripe für ein Land ausschließen, werden dort auch die von diesem Modul bereitgestellten Kartenoptionen ausgeblendet.

1. Prüfen Sie, ob das Modul für den vorgesehenen Shop aktiv ist.
2. Prüfen Sie die nativen Moduleinschränkungen für den tatsächlichen Warenkorbkontext.
3. Prüfen Sie die im Anbieterkonto aktivierten Methoden, die Händlerberechtigung und unterstützte Währungen.
4. Prüfen Sie methodenspezifische Steuerungsmöglichkeiten dieser Modulversion, einschließlich Betragsgrenzen und Reihenfolge.
5. Testen Sie die resultierende Liste mit repräsentativen Ländern, Währungen, Gruppen und Versanddienstleistern.

Native Hook-Positionen unter Design > Positionen ordnen Module auf paymentOptions; Methoden innerhalb eines Aggregators benötigen die eigenen Sortiermöglichkeiten dieser Integration. Das native Einschränkungsraster hat keine allgemeine Regel für den Bestellbetrag. Gehen Sie nicht davon aus, dass alle Aggregatoren dieselben Steuerungsmöglichkeiten für Rechnungsland, Währung oder Betrag bieten.

Checkout Revolution bietet zusätzliche Steuerungsmöglichkeiten für die Darstellung der Zahlungsoptionen, mit eingebetteter Zahlung, wo unterstützt, und Weiterleitungen, wo erforderlich; zur Einrichtung siehe die Modulhilfe.

Prüfen, ob eine weitere Methode ihre Kosten deckt

Beginnen Sie mit Methoden, für die Nachfrage und betriebliche Voraussetzungen bestehen. Eine zusätzliche Option kann eine neue Zielgruppe erreichen, bestehende Käufer zwischen Zahlungsabwicklern verschieben oder Wartungsaufwand verursachen, ohne zusätzliche Bestellungen zu bringen. Es gibt keine feste richtige Anzahl von Methoden oder Modulen.

Betrachten Sie ein beispielhaftes Checkout-Szenario: 1.000 Versuche, ursprünglich 800 abgeschlossene Bestellungen und ein durchschnittlicher Bestellwert von EUR 60. Werden 8% der 200 verlorenen Versuche zurückgewonnen, kommen 16 Bestellungen hinzu, also insgesamt 816 abgeschlossene Bestellungen.

Das sind Einnahmen nach einer angenommenen Gebühr, kein Gewinn und keine prognostizierte Conversion. Ziehen Sie Produkt-, Abwicklungs-, Versand-, Retouren-, Betrugs-, Support- und Integrationskosten ab. Berücksichtigen Sie auch, dass bestehende Käufer eine teurere Methode wählen können. Eine zurückgewonnene Bestellung ist nicht automatisch reiner Mehrertrag.

Zeigen Sie nur Methoden, die im Checkout tatsächlich verfügbar sind. Platzieren Sie hilfreiche Logos und klare Namen dort, wo Käufer sie benötigen, und erklären Sie Weiterleitungen. Eingebettete Felder und Weiterleitungen zu Bank oder App müssen jeweils getestet werden; keines davon konvertiert grundsätzlich besser.

BLIK, iDEAL | Wero und Bancontact verstehen

BLIK, iDEAL und Bancontact haben unterschiedliche Kunden- und Technikabläufe. Sie werden nicht über einen gemeinsamen „3-D Secure“-Schalter gesteuert. 3-D Secure ist ein Protokoll zur Kartenauthentifizierung; Bank- und App-Methoden verwenden ihren eigenen Authentifizierungsprozess.

• BLIK: Kunden können einen sechsstelligen Code aus ihrer Banking-App abrufen und die Zahlung dort autorisieren. Stripes BLIK-API-Dokumentation verlangt PLN als Zahlungswährung. Die Auszahlungswährung des Händlers ist eine separate Frage des Kontos und der Abrechnung.
• iDEAL | Wero: Folgen Sie dem aktuellen gehosteten Bankauswahlablauf des Anbieters. Händler wurden angewiesen, eigene Bankauswahllisten bis zum 31. März 2025 zu entfernen.
• Bancontact: Prüfen Sie den vom Anbieter unterstützten Karten-/App-Ablauf für belgische Käufer. Aus der Existenz des Systems lässt sich nicht die Verbreitung reiner Bancontact-Karten ableiten.

Die Co-Branding-Phase von iDEAL | Wero begann 2026. Die technische Migration erfolgt schrittweise und getrennt von einer Logoänderung. Beschreiben Sie iDEAL nicht als bereits eingestellt. Nutzen Sie die für Ihr Gateway geltenden Marken- und Integrationsanweisungen.

Prüfen Sie die genaue Plugin-Version. Kontrollieren Sie, ob Ihre PrestaShop-Connector-Version BLIK unterstützt, auch wenn die Anbieter-API es unterstützt. Mollies aktuelle Methodenliste führt BLIK und Przelewy24 getrennt auf. Veröffentlichen Sie keine ungetestete Unterstützungsmatrix und bezeichnen Sie die iDEAL-/Bancontact-Abdeckung von P24 nicht ohne Angabe einer konkreten Integration als „eingeschränkt“.

Fehlt eine lokale Methode, prüfen Sie Händlerfreischaltung, Länder-/Währungsberechtigung, Warenkorbbetrag, native Moduleinschränkungen, Integrationsunterstützung und Fehler im Frontoffice.

Integrationen statt Anbieternamen vergleichen

Vergleichen Sie genaue Modulnamen und Versionen, deklarierte PrestaShop-/PHP-Unterstützung, Release-Aktivität, Sicherheitskorrekturen, Lizenzen und Supportbedingungen. Testen Sie Ihr Theme und Ihren Checkout. „Offiziell“, „kostenpflichtig“ und „separate Module“ belegen weder Kompatibilität noch vollständige Funktionalität.

Erfassen Sie gehosteten bzw. eingebetteten Checkout, lokale Methoden, Wallets, Autorisierung/Einzug, Teilerstattungen, gespeicherte Zahlungsdaten, Abonnements, Streitfälle und Multishop. Die Plattform eines Anbieters kann mehr leisten als sein Connector. Gespeicherte Daten und Wallets sind nicht grundsätzlich Premium-Funktionen.

Bestätigen Sie unterstützte Händlerländer, Geschäftskategorie, Identifikationsanforderungen, Bank-/Auszahlungsberechtigung und die Freigabe jeder Methode. Unterscheiden Sie Belastungswährung, Abrechnungswährung und Umrechnung. Eine einzige Integration garantiert weder einen einzigen Saldo noch eine einzige Auszahlungswährung oder ein einziges Abrechnungskonto.

Stripe und PayPal für Ihr tatsächliches Konto vergleichen

Stripe kann je nach Integration ein eingebettetes Zahlungsformular oder einen gehosteten Checkout verwenden. Lokale Methoden und Authentifizierung können weiterleiten. Auch PayPal-Integrationen können unterschiedliche Button-, Wallet- und Kartenabläufe anbieten. Testen Sie die tatsächliche Konfiguration, statt anzunehmen, dass ein Anbieter Kunden immer auf Ihrer Domain hält.

In einem PayPal-Ablauf sind Zustimmung, Autorisierung und Einzug getrennte Schritte. Das PrestaShop-Modul entscheidet, wann die lokale Bestellung angelegt wird. Die Zustimmung eines Käufers belegt keinen Geldeinzug. Fehlt die Browserrückkehr, sollten Sie den Transaktionsstatus abrufen.

Vergleichen Sie Akzeptanz, Kundennachfrage, Zahlungserfolg, Berechtigung für Verkäuferschutz, Erstattungsabläufe und Gesamtkosten. Entscheiden Sie nicht anhand unbelegter Behauptungen, ein Zahlungsabwickler bevorzuge Käufer oder ein neuer Shop benötige immer ein bestimmtes Logo.

Wenn Sie unabhängige Stripe- und PayPal-Konten führen, gleichen Sie deren Salden, Gebühren, Erstattungen und Abrechnungen getrennt ab. Ein zusammengefasster Finanzbericht ist weder ein automatischer Abgleich mit Bankauszahlungen noch eine Zuordnung der Rentabilität nach Zahlungsart, Land oder Gerät.

Unterscheiden Sie Fälle im PayPal-Konfliktlösungscenter von Rückbuchungen durch den Kartenaussteller. Karteninhaber können sich an den Aussteller wenden; das Konfliktlösungscenter ist nicht bei jedem Kartenstreitfall eine obligatorische erste Stufe.

Datierte, marktspezifische Gebühren und vollständige Kostenrechnungen nutzen

Diese veröffentlichten Gebührenbeispiele haben den Stand 27. Oktober 2026. Sie betreffen unterschiedliche Händlermärkte und Produkte und dürfen nicht als gleichwertige Angebote für einen einzelnen Händler verwendet werden.

Holen Sie ein konkretes Angebot für Ihr Händlerland und Produkt ein. Berücksichtigen Sie Festgebühren, Kartenmix, grenzüberschreitende Gebühren, Umrechnung, steuerliche Behandlung, Auszahlungs-/Aktivierungsgebühren, Erstattungen, Streitfälle sowie Modulabonnements oder Integrationskosten. Lokale Methoden haben nicht grundsätzlich feste Gebühren und sind nicht immer günstiger.

Beim Standardkartenbeispiel von Stripe Irland entstehen für Transaktionen über EUR 20, EUR 50 und EUR 150 Abwicklungsgebühren von EUR 0,55, EUR 1,00 und EUR 2,50 vor weiteren anwendbaren Gebühren. Berechnen Sie jeden Anbieter mit denselben Händlerannahmen neu, statt unzusammenhängende europäische Ausgangswerte zu vergleichen.

Das Gebührenverzeichnis von Stripe Irland nennt außerdem EUR 20 für einen eingegangenen Streitfall und separat EUR 20 für dessen manuelle Anfechtung; die Anfechtungsgebühr wird bei Erfolg erstattet. Auch PayPal veröffentlicht Streitfall-/Rückbuchungsgebühren mit regionalen Regeln und Ausnahmen. Gehen Sie nicht davon aus, dass ein Streitfall kostenlos ist oder bei Erfolg jede Gebühr erstattet wird.

Umgebung erfassen und eine rücknehmbare Änderung vorbereiten

Eine Zahlungsänderung betrifft mehr als den Anbieter: den Checkout, Versanddienstleister, Bestellstatus, E-Mails, Bestand und alles, was bezahlte Bestellungen ausliest. Halten Sie die Einrichtung fest, bevor Sie sie ändern, damit Sie dieselbe Kombination auf Staging testen und sie wiederherstellen können, falls der Start schiefgeht.

• Halten Sie die genauen Versionen von PrestaShop, PHP, Theme und Connector fest und lassen Sie sich diese Kombination vom Anbieter des Connectors bestätigen. Ein angegebener Versionsbereich ist kein Test Ihres Shops.
• Listen Sie die anderen Checkout- und Zahlungsmodule, Versandintegrationen, Multistore-Anforderungen und den individuellen Code auf, der Warenkorb, Summen oder Bestellerstellung verändert. Beziehen Sie jedes ERP-, Buchhaltungs- oder Versandwerkzeug ein, das bezahlte Bestellungen verarbeitet.
• Halten Sie die aktuellen Connector-Einstellungen, das Konto, den Modus und die Benachrichtigungskonfiguration sicher fest, ohne geheime Zugangsdaten in Tickets oder Screenshots zu kopieren.
• Erstellen Sie ein wiederherstellbares Backup von Datenbank, Dateien und Konfiguration und bereiten Sie eine Staging-Kopie des Live-Shops vor. Isolieren Sie Staging von Live-Zahlungen, Kundennachrichten und Exporten an die Auftragsabwicklung.
• Vereinbaren Sie das Startfenster, die Rollback-Schritte und die Person, die bei einer Rücknahme Zahlungen und Bestellungen abgleicht. Die Datensätze des Anbieters werden nicht zurückgesetzt, wenn Sie die Shop-Datenbank wiederherstellen; eine Wiederherstellung muss daher die seit dem Backup eingegangenen Bestellungen und Zahlungen schützen.

Staging im Testmodus verbinden und den Abgleich nachweisen

1. Verbinden Sie Staging über die unterstützte Verbindungsmethode des Moduls mit dem vorgesehenen Testkonto. Halten Sie Test- und Live-Zugangsdaten getrennt.
2. Konfigurieren Sie einen erforderlichen Benachrichtigungsendpunkt und dessen Authentifizierung nach den Anweisungen der installierten Version. Liegt Staging hinter einer Anmeldung, geben Sie dem Anbieter kontrollierten Zugriff nur auf diesen Endpunkt, wie im Abschnitt zur Nachverfolgung unten beschrieben.
3. Führen Sie einen dokumentierten Testkauf durch und vergleichen Sie dann die Zustellnachweise des Anbieters mit der Verarbeitung durch den Connector und der entstandenen Bestellung.
4. Wiederholen Sie den Test mit unterbrochener Browserrückkehr. Halten Sie Warenkorbreferenz, Zahlungsreferenz und erwartetes Bestellergebnis für den Support zusammen fest.

Vergleichen Sie bei jedem Test Zahlungsreferenz, Betrag und Währung mit dem Warenkorb und der entstandenen Bestellung. Bestätigen Sie den erwarteten Bestellstatus, E-Mails, Bestandsbewegung und nachgelagerten Export einschließlich ihres Zeitpunkts. Eine erfolgreiche Kartenzahlung beweist nicht den gesamten Weg.

Mollie-Methoden, Kompatibilität und Statuszuordnung prüfen

Mollies Kompatibilitätstabelle trennt die Modulgenerationen: Mollie 6 für PrestaShop ab 1.7.6, Mollie 5 für frühere 1.7-Versionen und ältere Zweige für Altsysteme. Prüfen Sie die PrestaShop-9-/PHP-Angaben der genauen Version, statt alle Versionen als ein getestetes Paket zu betrachten.

Nutzen Sie die offizielle Integrationsdokumentation für die Installation des Moduls und die Kontoverbindung.

Prüfen Sie Konto-/Profilfreigabe, Trennung von Test- und Livebetrieb, aktivierte Methoden und die im Checkout tatsächlich verfügbare Liste. Die aktuelle Dokumentation nennt Karten, Bankmethoden, Wallets und spätere Zahlung, darunter BLIK und Przelewy24 als separate Methoden. Eine Anbieterliste bedeutet nicht, dass jedes ältere installierte Modul diese anbietet.

Bestätigen Sie die tatsächliche Benachrichtigungs-URL, die für die Integration erzeugt wird. Erraten Sie sie nicht anhand des Beispiels einer anderen Version. Ein Endpunkt kann bei Browser-GET und Anbieter-POST unterschiedlich reagieren. Ein Browser-Timeout kann durch eine andere Route oder einen anderen Netzwerkweg entstehen und beweist nicht, dass Mollie den Endpunkt nicht erreichen kann.

Ordnen Sie Status anhand von Mollies Definitionen zu: open/pending bedeutet nicht bezahlt; authorized bedeutet nicht eingezogen. Prüfen Sie die tatsächliche Zahlung, bevor Sie entscheiden, warum eine lokale Bestellung auf Zahlung wartet. Prüfen Sie anschließend Zustellung, Validierung und lokale Verarbeitung der Benachrichtigung.

Prüfen Sie bei Multishop den Geltungsbereich der Zugangsdaten/Profile und die Benachrichtigungsweiterleitung je Shop. Testen Sie jede Währung, auch einen Fall, in dem eine währungsgebundene Methode nicht verfügbar ist. Eine unzulässige lokale Methode darf Käufer nicht ohne nutzbare Alternative zurücklassen.

Przelewy24-Konto, Zugangsdaten und Verifizierung prüfen

Nutzen Sie das offizielle Paket und die Anweisungen von P24 zur Einrichtung seines Moduls. Die Downloadseite trennt ältere Pakete für 1.5/1.6 und 1.7.0-1.7.5.2 vom aktuellen Paket für 1.7.6/8/9. Ein Modul, das ursprünglich 1.7 unterstützte, ist nicht automatisch mit späteren Hauptversionen inkompatibel.

Klären Sie Onboarding und Dokumentanforderungen für Ihre Rechtsform und Ihr Land direkt mit P24. Versprechen Sie ohne Vertrag weder die Freigabe ausländischer Händler noch eine Prüfdauer oder eine bestimmte Währungsumrechnungs-/Auszahlungsregelung.

Unterscheiden Sie je nach gewähltem Paket Händler-/POS- oder Shop-Kennungen, API-Zugangsdaten und CRC-/Signaturdaten. Stimmen Sie Sandbox- und Produktionsmodus durchgehend ab. Ein Signaturfehler erfordert die Prüfung der genauen Zugangsdaten, Signaturfelder/Serialisierung und Transaktionsdaten. Gehen Sie nicht davon aus, dass immer ein nachgestelltes Leerzeichen die Ursache ist.

Das offizielle Änderungsprotokoll enthält Unterstützung für Zahlungen außerhalb von PLN. Beschränken Sie eine Methode anhand der Methode selbst, des Händlerkontos und des Moduls; blenden Sie P24 nicht pauschal für EUR aus. Halten Sie Warenkorb, übermittelten Zahlungsbetrag und Währung konsistent.

Eine gültige P24-Benachrichtigung erfordert die dokumentierten Signatur- und Transaktionsprüfungen sowie eine serverseitige Transaktionsverifizierung über die P24-API. Testen Sie eine Zahlung, bei der der Kunde nicht zurückkehrt. Wird eine Bestellung allein auf der Zusammenfassungsseite als bezahlt markiert, beweist das keinen ausgelösten Callback, da eine Integration den Status auch bei der Rückkehr prüfen kann.

Bieten Sie die unterstützte Sprache und Methoden an, die Ihre Zielgruppe nutzen kann. Wählen Sie Karten- und Bankmethoden nach den Bedürfnissen Ihrer Kunden. Bestätigen Sie die Unterstützung von gespeichertem BLIK und Ratenzahlungsfunktionen getrennt für Modul und Konto.

Stripe-Integration, Wallets und Anforderungen an wiederkehrende Zahlungen prüfen

Nutzen Sie Stripes Dokumentation zum PrestaShop-Modul für die Einrichtung und unterstützten Methoden dieses Connectors.

Prüfen Sie Kontofreigabe, Identität des Test-/Livekontos, Schlüssel und Objektzugehörigkeit. „No such payment intent“ kann durch vermischte Umgebungen oder Konten oder durch ein veraltetes Zahlungsobjekt entstehen. Prüfen Sie das tatsächliche Objekt und den gewählten Modus, bevor Sie den Checkout erneut versuchen.

• Veröffentlichbarer Schlüssel: Bei manueller Schlüsselverwendung ist dies der für die Zahlungsoberfläche im Shop bestimmte Wert.
• Geheimer Schlüssel: Die serverseitige Berechtigung, das Zahlungskonto aufzurufen. Halten Sie ihn aus Theme, Browsercode, Screenshots und Supportnachrichten heraus.
• Signaturgeheimnis für Benachrichtigungen: Der gegebenenfalls zur Validierung eingehender Benachrichtigungen benötigte Wert. Er ist nicht mit einem geheimen API-Schlüssel austauschbar.

Das sind Rollen, keine Regel, dass jeder Connector alle drei Werte auf einer Seite abfragt. Express Checkout wird zum Beispiel mit zwei Schlüsseln aus dem Zahlungskonto eingerichtet. Stimmen Sie Konto-, Umgebungs- und Benachrichtigungseinstellungen auf die Anweisungen des installierten Moduls ab.

Webhooks können je nach Modul automatisch oder manuell registriert werden. Nutzen Sie den tatsächlichen Endpunkt, das Signaturgeheimnis, die Ereignisliste und die Handler-Abdeckung der Integration. Eine allgemeine Liste von Zahlungs-, Erstattungs- und Streitfallereignissen ist keine gültige Abonnementanleitung für jedes Modul. Die Liste muss zu den implementierten Handlern und dem Abgleich passen.

Stripes Supportseite zum Connector erklärt, dass der Connector Einzelzahlungen statt Stripe Billing unterstützt. Abonnementfähigkeit des Anbieters, gespeicherte Daten und eine vollständige PrestaShop-Verlängerungsintegration sind getrennte Fähigkeiten.

Holen Sie für Off-Session-Zahlungen die passende Einwilligung ein und richten Sie die Zahlungsmethode für diesen Zweck ein. Bieten Sie einen Wiederherstellungsweg, der Kunden bei Bedarf zur Authentifizierung zurückholt. Verlängerungen mit gespeicherter Karte vermeiden künftige Abfragen nicht garantiert.

Registrieren Sie alle relevanten Domains und Subdomains für unterstützte Wallets gemäß Stripes Domainanforderungen für Zahlungsmethoden. Auch Google Pay kann eine Domainregistrierung erfordern. Unterscheiden Sie die Domainregistrierung von Apples Dateiverifizierung. Testen Sie geeignete Geräte, Browser und konfigurierte Wallet-Konten; ein aktivierter Button erscheint dadurch nicht überall.

Fehlt eine Wallet-Schaltfläche, reproduzieren Sie das Problem zuerst auf einem Gerät und mit einem Konto, die laut Anbieter des Connectors berechtigt sind. Prüfen Sie dann das gewählte Land, die Währung und die Berechtigungseinstellungen des Moduls, und erst danach die Domain- und Wallet-Konfiguration. Eine Produktbeschreibung, die Wallets aufführt, sagt nicht, welche die installierte Version unterstützt: Prüfen Sie Apple Pay, Google Pay oder jede lokale Methode anhand von Version, Konto, Land, Währung und Gerät. Unterscheiden Sie eine nicht verfügbare Methode von einem defekten Checkout; ein nicht berechtigter Käufer braucht dennoch eine nutzbare Alternative.

Status prüfen und jede Zahlung einmal verarbeiten

Trennen Sie die Zahlungserstellung beim Anbieter, Browserzustimmung/-rückkehr, Benachrichtigungsverarbeitung, lokale Bestellerstellung und spätere Statusübergänge. Je nach Integration kann eine serverseitige Statusabfrage bei der Browserrückkehr, einem Webhook oder einem Abgleichsjob erfolgen. Bestätigen Sie die Zahlung über den authentifizierten Status- oder Benachrichtigungsmechanismus des Anbieters.

1. Authentifizieren Sie die Benachrichtigung mit dem dokumentierten Signatur- oder Verifizierungsmechanismus des Anbieters. Rufen Sie bei Bedarf den maßgeblichen Status ab.
2. Prüfen Sie Händlerkonto, Test-/Livemodus, Anbieter-Zahlungs-ID, Warenkorb-/Bestellzuordnung, erwarteten Betrag und Währung. Verwenden Sie die Währungseinheiten-Konventionen des Anbieters.
3. Unterscheiden Sie ausstehend, autorisiert, eingezogen/bezahlt, fehlgeschlagen, storniert, abgelaufen, teilweise erstattet und erstattet.
4. Reservieren Sie das Ereignis/die Transaktion dauerhaft zur Verarbeitung, damit parallele Handler und spätere Wiederholungen es nicht zweimal anwenden können. Ereignisdeduplizierung allein reicht nicht, wenn mehrere Ereignistypen dieselbe Zahlung beschreiben.
5. Erstellen Sie nur dann eine Bestellung, wenn der validierte Ablauf dies vorsieht und der Warenkorb noch nicht bestellt wurde. Aktualisieren Sie eine bestehende ausstehende Bestellung über den passenden Zahlungs-/Verlaufsablauf.
6. Protokollieren Sie das Ergebnis und Fehler, bei denen ein erneuter Verarbeitungsversuch möglich ist. Bestätigen Sie erst nach der Verarbeitung oder sicherer dauerhafter Einreihung in eine Warteschlange gemäß dem Integrationskonzept.

Die Core-Funktion PaymentModule::validateOrder() lehnt einen Warenkorb ab, zu dem bereits eine Bestellung besteht. Verwenden Sie sie nicht als universelle Funktion zum Fortschreiben ausstehender Bestellungen.

Lassen Sie Rückkehr, Benachrichtigungen und geplanten Abgleich dieselben validierten Übergangsregeln verwenden. Doppelte oder falsch sortierte Ereignisse dürfen keine zusätzlichen Bestellungen, Zahlungen, Bestandsänderungen oder E-Mails erzeugen. Statusänderungen bestehender Bestellungen benötigen passende Verlaufs-/Zahlungs-APIs statt direkter SQL-Änderungen des angezeigten Status.

Die Bestellerstellung kann je nach Integration und Bestellstatus bereits vor der Zahlungsbestätigung den Bestand beeinflussen. Leiten Sie Reservierung oder Bestandsabbuchung nicht allein aus der Zahlungsstatusbezeichnung ab.

Bezahlte Anbieterzahlung mit ausstehender oder fehlender Bestellung nachverfolgen

1. Halten Sie Zahlungsreferenz, Konto, Test- oder Livemodus, Betrag, Währung und Uhrzeit fest. Prüfen Sie den tatsächlichen Transaktionsstatus im Dashboard oder über die API des Anbieters. Bestätigen Sie den Einzug statt nur Zustimmung oder Autorisierung, und prüfen Sie Konto und Modus. Vergleichen Sie diesen Status mit dem für die Auftragsabwicklung vereinbarten.
2. Ordnen Sie die Transaktion Shop, Warenkorb/Bestellung, Betrag und Währung zu. Durchsuchen Sie Warenkörbe, Bestellungen und Connector-Protokolle nach der Zahlungsreferenz, nicht nur nach dem Kundennamen. Prüfen Sie mögliche aufgeteilte Bestellungen oder einen weiteren Zahlungsversuch.
3. Prüfen Sie die Zustellprotokolle der Benachrichtigung: Ziel, Methode, Antwort, Wiederholungen und Zeitstempel.
4. Prüfen Sie Reverse-Proxy-, WAF-, Zertifikats- und Anwendungsprotokolle für diesen Endpunkt. Anmeldeseiten, HTTP-Basisauthentifizierung, Wartungsverhalten und Browser-Challenges können Anbieteranfragen blockieren.
5. Prüfen Sie nach der Zustellung Signaturprüfung, Exceptions im Handler, fehlende Zuordnungen, Sperren und Datenbankschreibvorgänge. Individueller Bestellcode oder eine ERP-Integration, die während der Bestellvalidierung läuft, kann scheitern, nachdem eine gültige Benachrichtigung eingetroffen ist.
6. Bitten Sie den Modulbetreuer, den Datensatz des Anbieters mit dem Serverfehler und den Modulprotokollen abzugleichen. Schwärzen Sie Zugangsdaten und unnötige Kundendaten, bevor Sie Nachweise weitergeben.
7. Wiederholen oder gleichen Sie über einen unterstützten idempotenten Prozess ab. Rufen Sie den aktuellen Status ab, bevor Sie etwas anlegen oder eine Bestellung als bezahlt markieren.

Halten Sie die Auftragsabwicklung an, solange der Status ungeklärt ist. Bitten Sie den Kunden nicht, erneut zu zahlen, und markieren Sie die Bestellung nicht als bezahlt, um die Supportwarteschlange zu leeren, bevor die ursprüngliche Zahlung abgeglichen ist: Ein weiterer Versuch kann den Kunden doppelt belasten.

Verwenden Sie eng begrenzte, dokumentierte Endpunktregeln und behalten Sie die Benachrichtigungsauthentifizierung bei. Ein erfolgreicher GET, ein HTTP 200 einer unbeteiligten Seite oder eine Browserrückkehr belegt keine erfolgreiche Webhook-Verarbeitung. Auch ein erreichbarer Endpunkt kann eine Signatur ablehnen oder nach Annahme einer Anfrage scheitern.

Nutzen Sie für lokale Entwicklung oder eine private Staging-Kopie einen autorisierten Weiterleitungs- oder Testmechanismus, wenn der Anbieter öffentliche Erreichbarkeit benötigt, oder geben Sie dem Anbieter kontrollierten Zugriff nur auf den Benachrichtigungsendpunkt, ohne die gesamte Kopie freizugeben oder Signaturprüfungen abzuschwächen. Gehen Sie nicht davon aus, dass ein Anbieter eine private localhost-URL aufrufen kann. Prüfen Sie das Wiederholungsverhalten jedes Anbieters, statt einen universellen Timeout von 30 Sekunden zu übernehmen.

Eine bezahlte Bestellung ohne Browserrückkehr nachvollziehen

Ein Kunde kauft eine personalisierte Tasse, schließt die Zahlung ab und schließt den Browser auf dem Smartphone vor der Bestätigungsseite. Die Mitarbeiter sehen die Zahlung beim Anbieter, finden aber die erwartete Bestellung nicht. Der Abnahmetest besteht darin, dass die Integration den vereinbarten Bestellinhalt wiederherstellt und die Zahlung erfasst, ohne den Kunden erneut zahlen zu lassen.

Proben Sie diesen Fall auf Staging. Halten Sie vor dem Start die gewählte Personalisierung, die Lieferadresse, den Versanddienstleister, die Endsumme und die Währung fest. Ordnen Sie danach die Zahlungsreferenz dem Warenkorb und allen entstandenen Bestellungen zu, und prüfen Sie neben dem Betrag auch Personalisierung und Lieferhinweise. Eine Zahlung, die dem falschen Warenkorb zugeordnet ist, bleibt ein gescheiterter Kaufvorgang.

Trifft die Benachrichtigung später ein, bestätigen Sie, dass die Bestellung den vereinbarten Abwicklungsstatus genau einmal erreicht. Fragen Sie den Anbieter, wie sein unterstütztes Abgleichverfahren diesen Fall behandelt. Wer eine Bestellung manuell anlegt, während die Wiederherstellung noch läuft, kann eine zweite Bestellung erzeugen; eine manuelle Reparatur gehört in den dokumentierten Wiederherstellungsweg des Connectors, geprobt auf Staging, und nicht in eine direkte Datenbankbearbeitung.

Erstattungen, Stornierungen und Abrechnungen abgleichen

Trennen Sie das Aufheben einer Autorisierung, Zahlungserstattung, Erzeugung einer Rechnungskorrektur, Gutscheinausstellung, Warenrücknahme und Bestellstatusänderung. Eine PrestaShop-Bezeichnung auf „erstattet“ zu ändern, beweist keine Rückzahlung durch ein Gateway.

1. Bestätigen Sie die ursprüngliche Zahlung und den eingezogenen/erstattungsfähigen Betrag.
2. Veranlassen Sie die vollständige oder teilweise Erstattung über den unterstützten Integrations-/Anbieterablauf.
3. Speichern Sie deren Anbieterreferenz und verfolgen Sie ausstehende, erfolgreiche oder fehlgeschlagene Ergebnisse.
4. Aktualisieren Sie den lokalen Zahlungs-/Buchhaltungseintrag und Bestand nur gemäß der tatsächlichen Erstattungs- und Retourenrichtlinie.
5. Gleichen Sie Anbietersalden und Auszahlungen mit Verkäufen, Gebühren, Erstattungen und Streitfällen ab.

Vermeiden Sie es, einmal im Modul und noch einmal im Dashboard des Anbieters zu erstatten. Halten Sie fest, ob Mitarbeiter Erstattungen in PrestaShop oder im Dashboard des Anbieters starten und wer eine anderswo begonnene Erstattung abgleicht. Prüfen Sie für jede Methode die unterstützte Erstattungsfrist, die Möglichkeit von Teilerstattungen, nicht zurückerstattete Abwicklungsgebühren und den Abrechnungszeitpunkt. Ein Anbieter kann in einer anderen Währung oder nach einem anderen Zeitplan auszahlen als die Belastung des Kunden.

Testen Sie eine Teilerstattung für die vorgesehenen Bestellpositionen und die Versandkosten und bestätigen Sie dann den Betrag beim Anbieter, den Bestelldatensatz und jeden erforderlichen Buchhaltungsbeleg. Entscheiden Sie über die Wiedereinlagerung separat: Eine Rückzahlung ist kein Nachweis, dass die Ware im Lager angekommen ist.

Bewahren Sie relevante Rechnungen, Sendungsverfolgung und Zustellnachweise, Kundenkommunikation und Originalnachrichten gemäß einer angemessenen Aufbewahrungsrichtlinie auf. Der Bestellverlauf im Core speichert die Statushistorie; er archiviert nicht automatisch jedes für einen Streitfall benötigte Dokument. Halten Sie diese Nachweise für eine benannte Person im Team zugänglich, prüfen Sie im Anbieterkonto die Antwortanweisungen und die Frist jedes Falls, und gehen Sie nicht davon aus, dass die Erstattungsfunktionen eines Moduls auch einen Ablauf für Streitfälle bieten.

BNPL-Bedingungen, Darstellung und Deckungsbeitrag bewerten

Klarna, Clearpay/Afterpay, PayPal Pay Later, Riverty und andere Produkte unterscheiden sich nach Markt, Händlerberechtigung, Zahlungsplan und Integration. Prüfen Sie das konkrete Angebot, statt für jeden Käufer denselben Vertrag mit drei oder vier Raten anzunehmen.

Prüfen Sie Autorisierung, Einzug, Versandmeldung, Teileinzug, Stornierung, Erstattungen und Auszahlungszeitpunkt. Manche Integrationen ziehen bei Versand ein. Versenden Sie nicht allein aufgrund einer Zustimmung und nehmen Sie nicht an, dass der normale Auftragsabwicklungsprozess unberührt bleibt.

Der Kreditgeber kann ein bestimmtes Kreditrisiko übernehmen, während der Händler vertragliche Pflichten und Risiken aus Lieferstreitigkeiten oder anderen Rückgriffsmöglichkeiten behält. Lesen Sie die tatsächlichen Schutzbedingungen. Wiederkehrende Nutzung hängt vom Anbieterprodukt und einer verlängerungsfähigen Integration ab; sie ist weder grundsätzlich unmöglich noch automatisch unterstützt.

Vergleichen Sie vertragliche Gebühren, Festbeträge, Umrechnung, steuerliche Behandlung und Regeln zu Erstattungsgebühren. Nehmen Sie weder einen festen BNPL-Aufschlag gegenüber Karten an noch eine Preisobergrenze von 6%. Die aktuelle Seite von PayPal UK veröffentlicht einen eigenen Pay-Later-Preis. Eine alte pauschale Aussage „ohne Aufpreis“ darf dieses Angebot daher nicht ersetzen.

Bei einer beispielhaften Kategorie mit EUR 10.000 Monatsumsatz kostet ein hypothetischer Gebührenaufschlag von drei Prozentpunkten EUR 300, wenn alle diese Verkäufe vom ursprünglichen Zahlungsweg wechseln, noch vor zusätzlichen Bestellungen. Um zu entscheiden, ob sich die Änderung lohnt, benötigen Sie das tatsächlich verlagerte Volumen, neue Bestellungen und den Deckungsbeitrag.

Zeigen Sie vom Anbieter genehmigte Ratenhinweise bei relevanten Produktpreisen und im Checkout, sofern die Voraussetzungen erfüllt sind. EUR 99,99 dürfen beispielsweise nur dann als drei Zahlungen von EUR 33,33 dargestellt werden, wenn genau dieser Plan und die erforderlichen Pflichtangaben gelten. Aktualisieren Sie Hinweise bei Änderungen von Preis, Währung oder Produktauswahl.

Verschwinden Hinweise, prüfen Sie Berechtigung, Anbieter-/Client-Konfiguration, Skripte, Container und den tatsächlichen Theme-Hook. Ein fehlender Hook ist eine mögliche Ursache. Gehen Sie nicht davon aus, dass eine feste Warenkorb- oder Altersspanne die rentable Zielgruppe definiert.

Wenden Sie die Regeln des Kundenlandes an. Richtlinie (EU) 2023/2225, Artikel 48, sieht vorbehaltlich nationaler Umsetzung die Anwendung der Maßnahmen ab dem 20. November 2026 vor. Die FCA begann am 15. Juli 2026 mit der Regulierung relevanter britischer Deferred Payment Credits. Die Bonitätsprüfung des Kreditgebers hebt Darstellungs- und Vertragspflichten des Händlers nicht auf.

Vergleichen Sie nach Möglichkeit berechtigte, zufällig zugewiesene Gruppen. Höhere Warenkörbe bei BNPL-Nutzern können aus der Kundenauswahl statt aus einer ursächlichen Steigerung entstehen. Berücksichtigen Sie Verlagerungen, Retouren und Gebühren und vermeiden Sie starre Regeln wie „60 Tage und 200 Bestellungen“.

Authentifizierung und PCI-Umfang korrekt behandeln

SCA gilt nach den jeweiligen Regeln für erfasste elektronische Zahlungen, mit Ausschlüssen und Ausnahmen. EWR- und britische Regeln haben eigene Rechtsgrundlagen. Ein PSP kann Authentifizierung oder eine Ausnahme anfordern; der Aussteller entscheidet über das Ergebnis. Die Authentifizierung kann per App, Code oder einem anderen unterstützten Verfahren erfolgen.

Verwenden Sie gepflegte EMV-3DS-Unterstützung. Sowohl ein reibungsloses Ergebnis ohne Abfrage als auch eine Challenge sind möglich; 3DS1 ist keine aktuelle europäische Alternative, die empfohlen werden sollte. Die verlängerte E-Commerce-Umsetzungsfrist der FCA war der 14. März 2022.

3DS kann bei berechtigten Streitfällen zu betrügerischen Zahlungen die Haftung nach Maßgabe der Netzwerk-/Anbieterbedingungen und Ausnahmen verlagern. Es versichert Sie nicht gegen jeden Streitfall, Lieferausfall oder jede ausgenommene Transaktion. Prüfen Sie Authentifizierungs- und Haftungsergebnis der tatsächlichen Zahlung.

Die Domain der umgebenden Seite bestimmt den Umfang nicht. Fragen Sie, wer die Erfassungsfelder bereitstellt und wo Kartendaten durchlaufen. Bestätigen Sie den anwendbaren SAQ und die Validierungspflichten mit dem Acquirer bzw. der Stelle, die den Compliance-Nachweis abnimmt.

PCI SSC FAQ 1604 bestätigt ASV-Scanpflichten für relevante SAQ-A-E-Commerce-Seiten, einschließlich Weiterleitungen und eingebetteter iframes. Beschreiben Sie SAQ A nicht als banales jährliches Häkchen oder Scans als ausschließlich SAQ D betreffend; berücksichtigen Sie anwendbare vierteljährliche Scans.

Für eingebettete Zahlungsformulare enthält der aktuelle SAQ A außerdem eine Bedingung zur Abwehr von Skriptangriffen, beschrieben in PCI SSC FAQ 1588. Gehostete Verarbeitung reduziert den direkten Umgang mit Kartendaten. Eine kompromittierte Händlerseite kann Käufer dennoch weiterleiten oder ein betrügerisches Erfassungsformular einschleusen.

Betrugssignale nutzen und einen Vorfallsprozess vorhalten

AVS- und CVV-Prüfungen sind begrenzte Signale. Eine erfolgreiche CVV-Prüfung beweist weder physischen Kartenbesitz noch einen rechtmäßigen Käufer. Prüfungen können nicht verfügbar sein, und legitime Adressen können abweichen. Prüfen Sie das Verhalten nach Aussteller/Land und die Verifizierungsergebnisse Ihres Anbieters.

Bewerten Sie die Häufigkeit von Zahlungsversuchen, wiederholte Fehler, ungewöhnliche Lieferänderungen und relevante Konto-/Gerätesignale mit verhältnismäßigen Kontrollen. PrestaShop-Bestell-/Warenkorbdaten können bei Untersuchungen helfen, bieten aber keine universelle Gerätefingerabdruck- oder kontenübergreifende Betrugserkennung. Testen Sie Gateway-Risikoregeln auf Fehlalarme.

Wählen Sie manuelle Prüfung oder zusätzliche Kontrollen anhand von Bestellwert, Wiederverkaufsrisiko der Produkte, Angriffshäufigkeit und Streitfallrisiko. Es gibt keinen universellen Schwellenwert der Bestellanzahl, unterhalb dessen Betrugskontrollen unnötig wären.

Halten Sie Kartennummern und sensible Authentifizierungsdaten aus Anwendungsprotokollen, Debug-Werkzeugen und Supporttickets fern. Auch Tokens und Transaktionsreferenzen benötigen Zugriffskontrollen; Webhook-Nutzdaten können ebenfalls personenbezogene Daten enthalten. Protokollieren Sie nur die bereinigten Felder, die für die Diagnose erforderlich sind.

1. Grenzen Sie den betroffenen Zahlungsweg oder die kompromittierte Komponente ein und stoppen Sie unsichere Auftragsabwicklung.
2. Sichern Sie relevante Protokolle und Beweise, ohne zusätzliche Kartendaten zu sammeln.
3. Kontaktieren Sie PSP/Acquirer und geeignete Vorfallshelfer, tauschen Sie kompromittierte Zugangsdaten aus und ermitteln Sie den betroffenen Umfang.
4. Prüfen Sie Meldepflichten zu personenbezogenen Daten und kommunizieren Sie korrekt.
5. Reparieren und validieren Sie die Integration, bevor Sie die normale Verarbeitung wieder aufnehmen.

Wenn GDPR gilt und Sie Verantwortlicher sind, verlangt Artikel 33 die unverzügliche Meldung an die zuständige Behörde, möglichst innerhalb von 72 Stunden nach Bekanntwerden, sofern ein Risiko für natürliche Personen nicht unwahrscheinlich ist. Prüfen Sie die Benachrichtigung betroffener Personen gesondert nach Artikel 34.

Gesamten Ablauf testen und Ergebnis messen

Verwenden Sie vom Anbieter unterstützte Sandboxes/Testzugangsdaten und Testwerte. Befolgen Sie bei einer separaten Produktionsvalidierung die Regeln des Anbieters. Geben Sie niemals echte Kartendaten in eine Testumgebung ein, nur weil eine Anleitung dazu auffordert.

Stripes Testdokumentation enthält diese Beispiele für den Testmodus:

Führen Sie jedes Szenario auf Staging aus und bewahren Sie die Nachweise auf, damit Sie die Prüfung nach einer Änderung an Theme, Connector oder Integration wiederholen können.

Prüfen Sie in jedem Szenario lokale Zahlungsdatensätze, Bestandsverhalten, Bestellverlauf, E-Mails und die spätere Abrechnung durch den Anbieter. Wiederholen Sie die Tests mit mobilen Wallets, lokalen Methoden, jeder unterstützten Währung, Multistore und Ihrem tatsächlichen Theme und Checkout. Eine erfolgreiche Testkarte beweist nicht, dass Wallets oder Erstattungen funktionieren; bewahren Sie daher Nachweise vom jeweiligen Gerät und von der entstandenen PrestaShop-Bestellung auf.

Erfassen Sie Checkout-Versuche, Abbrüche im Zahlungsschritt, Erfolg und Fehlschlag beim Anbieter, Methodennutzung, Erstattungen, Supportfälle, Checkout-Geschwindigkeit und Deckungsbeitrag. Segmentieren Sie nach Ländern und Geräten nur, wo Ihre Berichte diese Daten tatsächlich liefern. Die Warenkorbliste in PrestaShop 9.1 enthält die Status bestellt, nicht bestellt und verlassen, ohne nativen Länderfilter. Wählen Sie den vorgesehenen Status und nutzen Sie einen abgegrenzten Export oder eine geeignete Analyse für die Segmentierung nach Ländern.

Ein Warenkorbeintrag erklärt nicht, warum Käufer den Shop verlassen haben. Vergleichen Sie nach Möglichkeit kontrollierte Änderungen, berücksichtigen Sie Saisonalität und Kundenmix und beobachten Sie genügend geeigneten Traffic für den Effekt, den Sie erkennen müssen. Versprechen Sie keine Conversion-Steigerung und wählen Sie keinen Zahlungsabwickler anhand eines allgemeinen Branchendurchschnitts.

Die Änderung live schalten und übergeben

Folgen Sie nach bestandenem Staging den Anweisungen des Connectors für den Livemodus und den Regeln des Anbieters für eine vereinbarte Live-Verifizierung. Halten Sie die vorherige Konfiguration und die Rollback-Schritte bereit. Beobachten Sie nach dem Start tatsächliche Bestellungen, Zahlungen und Übergaben an die Auftragsabwicklung, und wiederholen Sie die relevanten Tests nach Änderungen an Theme, Connector oder Integrationen.

Fragen an den Entwickler vor der Übergabe

• Welche Modulversion und Shopkonfiguration wurden getestet, und wo liegen die Ergebnisse?
• Was erstellt oder rekonstruiert eine Bestellung, wenn der Browser nie zurückkehrt, und wie werden wiederholte Benachrichtigungen behandelt?
• Welche Zahlungsstatus erlauben die Auftragsabwicklung, und wie erreichen Erstattungen, Streitfälle und verzögerte Methoden die Mitarbeiter?
• Wie kommt ein Käufer nach einer fehlgeschlagenen oder abgebrochenen Authentifizierung weiter, und welche Kombinationen aus Zahlungsmethode und Versanddienstleister sind ausgeschlossen?
• Wo finden Mitarbeiter bereinigte Protokolle, Zahlungsreferenz, Wiederherstellungsanleitung und die zuständige Person für eine ungeklärte Zahlung?