Zahlungsabwicklung
... but the clearer provides no failure url. The customer stays on the page the clearer returned to. Configure an error template for this payment method.
Nachrichten-ID: paymentCheckBeforeRoute.missingFailureRedirectUrl
Symptom
Der Kunde bleibt auf der Seite, auf die er vom Zahlungsanbieter zurückgeschickt wurde. In der Regel ist das die reguläre Checkout- oder Pending-Seite. Es kommt zu keinem Absturz und es wird keine leere Seite angezeigt.
Ursache
Eine Zahlung ist in einem Status geendet, für den eigentlich eine eigene Fehlerseite benötigt wird (beispielsweisecanceledByUser ). Für den aktuellen Zahlungsanbieter ist jedoch keine eigene Fehlerweiterleitung implementiert.
Vorgehen
1
Betroffenen Zahlungsanbieter bestimmen
In der Meldung werden die Transaktions-ID und die Bestellnummer genannt. Welcher Zahlungsanbieter dahintersteht, sehen Sie an der Transaktion im Admin-Interface. Ein schneller Anhaltspunkt ist die Transaktions-ID: Transaktions-IDs von Stripe beginnen üblicherweise mit
pi_.2
Häufigkeit einordnen
Einzelne Treffer sind unkritisch, denn der Kunde landet auf einer nutzbaren Seite und kann die Bestellung erneut versuchen. Ein Ticket ist dafür nicht nötig.
3
Bei häufigem Auftreten als Anforderung melden
Wenn sich die Meldung häuft und Kunden den Kaufvorgang nachweislich abbrechen, weil sie auf der Pending-Seite ohne Rückmeldung stehen bleiben, melden Sie das bitte als Funktionswunsch bei WEBSALE. Über die Shop-Konfiguration ist diese Problematik nicht lösbar.
Failed to handle webhook: <Grund>
Nachrichten-ID: paymentCheckBeforeRoute.handleHook
Symptom
Ein vom Zahlungsanbieter gemeldetes Ergeignis wird nicht verarbeitet. Der Zahlungsstatus der betroffenen Bestellung bleibt unverändert. Der Shop antwortet dem Zahlungsanbieter mit dem HTTP-Status 400. Daraufhin wiederholt dieser die Zustellung über längere Zeit.
Ursache
PayPal und Stripe benachrichtigen den Shop im Hintergrund über Ereignisse zu einer Bestellung, beispielsweise “Zahlung eingegangen”. Diese Benachrichtigungen laufen über eine zentrale Stelle im Shop, die für beide Anbieter dieselbe ist. Beim Eingang wird zunächstReceived webhook auf Log-Level “Info” protokolliert. Schlägt die Verarbeitung danach fehl, protokolliert dieselbe Stelle Failed to handle webhook: gefolgt von einem kurzen Grund.
Die Meldung ist somit keine eigenständige Fehlerursache, sondern eine Überschrift für mehrere sehr unterschiedliche Probleme. Entscheidend ist der Text hinter dem Doppelpunkt.
Wenn die Zahlung bereits einen endgültigen Status hat, antwortet der Shop mit dem HTTP-Status 200 und protokolliert stattdessen
paymentCheckBeforeRoute.handleHookAlreadyFinalized. In diesem Fall wiederholt der Zahlungsanbieter die Zustellung nicht.
Die Nachrichten-ID
paymentCheckBeforeRoute.handleHook wird auch für die Info-Meldung Received webhook verwendet. Eine Log-Gruppe, die nur auf diese Nachrichten-ID filtert, enthält deshalb auch alle erfolgreich verarbeiteten Webhooks. Grenzen Sie deshalb zusätzlich über das Log-Level ein.Vorgehen
1
Grund lesen
Lesen Sie den vollständigen Text hinter
Failed to handle webhook:. Die Nachrichten-ID allein genügt nicht, denn sie ist bei allen Gründen dieselbe.2
Bei Webhook Validation FAILURE die Zugangsdaten prüfen
Kontrollieren Sie die für die Signaturprüfung hinterlegten Zugangsdaten des betroffenen Zahlungsanbieters. Prüfen Sie außerdem, ob kurz davor ungewöhnliche Zugriffe im Log auftauchen, denn eine fehlgeschlagene Signaturprüfung kann auch ein Zugriffsversuch von außen sein.Bei Stripe grenzen die Meldungen
stripe.timestampInvalid und stripe.timestampTooOld den Grund weiter ein. Erscheint keine von beiden, passte die Signatur selbst nicht.3
Bei den PayPal-Statusgründen weiterlesen
Lautet der Grund
Internal error while validating order, folgen Sie dem eigenen Eintrag zu dieser Meldung. Lautet er ERROR, Order Validation FAILURE oder unknown clearer order status in paypal checkout hook, prüfen Sie die betroffene Bestellung im Admin-Interface daraufhin, ob sie bei PayPal in einem unerwarteten Zustand hängt.4
Stripe-Gründe einordnen
failed to parse stripe event und Stripe event type not supported sind in der Regel unkritisch, denn Stripe sendet auch Ereignistypen, die der Shop bewusst nicht auswertet. Erst wenn derselbe Ereignistyp gehäuft auftritt, lohnt sich eine Rückfrage bei WEBSALE, ob dieser Typ ergänzt werden sollte.5
Bestellung und Antwortstatus ermitteln
Suchen Sie im selben Zeitfenster nach der Nachrichten-ID
paymentCheckBeforeRoute.handleHookResponseStatus. Diese Meldung steht auf Log-Level “Info” und nennt den an den Zahlungsanbieter gesendeten HTTP-Status sowie die Bestellnummer und die Transaktions-ID.6
Wiederholte Zustellungen einordnen
Nach einer Antwort mit dem HTTP-Status 400 stellt der Zahlungsanbieter denselben Webhook wiederholt zu. Mehrfache Treffer zu derselben Bestellung sind deshalb kein neues Problem, sondern Wiederholungen desselben Falls. Vereinzelte Treffer sind meist unauffällig. Tritt derselbe Grund gehäuft auf, melden Sie ihn bitte bei WEBSALE mit einigen Beispielzeitpunkten und Bestellnummern, denn ein dauerhaft fehlschlagender Endpunkt kann vom Zahlungsanbieter abgeschaltet werden.
Failed to create clearing request: <Grund>
Nachrichten-ID: checkout.onlineClearingTransactionCreationFailed
Symptom
Der Kunde kann die Bestellung nicht abschließen. Anstatt zur Bezahlseite des Zahlungsanbieters weitergeleitet zu werden, bleibt er im Checkout-Prozess und erhält die im Shop für clearingFailure hinterlegte Fehlermeldung. Der Shop setzt den Zahlungsstatus der Bestellung auf “Fehler” und macht bereits verbuchte Beträge wieder rückgängig.
Ursache
Bevor der Kunde zur Zahlung weitergeleitet wird, meldet der Shop den Zahlvorgang beim Zahlungsanbieter an. Diese Anmeldung ist fehlgeschlagen, sodass gar kein Zahlungsvorgang beginnen konnte. Die Meldung gilt für alle Online-Zahlungsanbieter. Der Grund dahinter stammt aus der jeweiligen Zahlungsart. Bei PayPal lautet der Grundunable to create order. Unmittelbar davor erscheint die Meldung createRequest: unable to create order mit der Nachrichten-ID paypalCheckout.createRequestOrderError. Warum die Anmeldung bei PayPal scheiterte, verrät erst eine weitere Meldung kurz davor:
Es gibt zwei weitere Gründe, die an derselben Stelle vor dem Aufruf bei PayPal entstehen:
paypalCheckout.createRequestPayloadError, wenn der Shop die Bestelldaten für PayPal nicht aufbauen konnte, undpaypalCheckout.createRequestNoId, wenn die Antwort von PayPal keine Bestell-ID enthält.
Bei einem Authentifizierungsfehler mit dem HTTP-Status 401 holt der Shop automatisch ein frisches Zugriffstoken und wiederholt die Anfrage einmal. Erscheint der Fehler trotzdem, stimmen die hinterlegte Client-ID oder das Secret nicht.
Vorgehen
1
Eigentliche Ursache im Log suchen
Suchen Sie zeitlich direkt vor dieser Meldung nach
paypalCheckoutService.callApiHttpError und paypalCheckoutService.callApiCurlError. Daran sehen Sie, ob PayPal überhaupt geantwortet hat und mit welchem Statuscode, oder ob die Verbindung gar nicht erst zustande kam.2
PayPals Fehlertext lesen
Liegt ein HTTP-Statuscode vor, prüfen Sie den Eintrag
paypalCheckoutService.callApiHttpErrorResult direkt danach. Er enthält PayPals Original-Fehlertext und benennt konkret, was PayPal bemängelt hat.3
Bei Status 401 die Zugangsdaten prüfen
Kontrollieren Sie Client-ID, Secret und den Betriebsmodus. Sandbox und Live sowie die hinterlegten Zugangsdaten müssen zusammenpassen, besonders nach einem kürzlichen Wechsel.
4
Bei Status 400 das bemängelte Feld eingrenzen
Der Fehlertext aus Schritt 2 weist meist auf ein konkretes Feld hin, beispielsweise Betrag, Währung oder Adresse. Tritt der Fehler wiederholt mit demselben Feld auf, melden Sie das bitte bei WEBSALE.
5
Verbindungsfehler einordnen
Bei
callApiCurlError prüfen Sie, ob es ein einmaliger Ausreißer war oder ob PayPal gerade größere Störungen hat. Tritt der Fehler gehäuft auf, melden Sie ihn bitte bei WEBSALE.6
Dringlichkeit einschätzen
Vereinzelte Treffer durch kurze Verbindungs- oder Serverprobleme sind normal. Häufen sich die Fehler oder betreffen sie mehrere Kunden gleichzeitig, sollten Sie zeitnah melden, denn dann können Kunden mit dieser Zahlungsart überhaupt nicht bezahlen.
PayPal Checkout
Failed to load payment status for order:Payment is in invalid state setting payment to error: checkoutCapture: response status is not valid (regular)
Nachrichten-ID: paymentCheckBeforeRoute.clearerStatusUpdateFailed
Symptom
Eine über PayPal begonnene Bestellung wird nicht als bezahlt bestätigt. Sie behält im Shop den Zahlungsstatus, den sie vor dem Abgleich hatte. In den allermeisten Fällen liegt das daran, dass der Kunde den Vorgang im PayPal-Fenster nicht zu Ende geführt hat.
Ursache
Der Shop fragt den PayPal-Auftragsstatus ab, um die Zahlung zu bestätigen. An dieser Stelle akzeptiert er für eine reguläre PayPal-Zahlung nur den StatusAPPROVED, PENDING oder COMPLETED. PayPal meldet jedoch einen anderen Status. Der häufigste Grund dafür ist, dass der Kunde die Zahlung im PayPal-Fenster nie final abgeschlossen hat, beispielsweise weil er das Fenster geschlossen oder zurücknavigiert hat. Die Order steht bei PayPal dann noch auf CREATED, während der Shop trotzdem eine Statusabfrage anstößt.
Der Teil vor dem Doppelpunkt, Failed to load payment status for order, ist dabei keine eigenständige Ursache, sondern eine Rahmenmeldung, die in allen Fällen angezeigt wird, in denen der Shop den Zahlungsstatus nicht abrufen konnte. Die eigentliche Ursache steht dahinter.
Der Zusatz in Klammern sagt Ihnen, um welchen Zahlungsablauf es geht:
Vorgehen
1
Häufigkeit und Kontext prüfen
Vereinzeltes Aufkommen kann als normales Kundenverhalten (beispielsweise durch eine abgebrochene Zahlung im PayPal-Fenster) angesehen werden und ist kein Fehler im Shop.
2
Tatsächlichen PayPal-Status nachlesen
Suchen Sie im Log nach der Nachrichten-ID
paypalCheckoutService.checkoutValidateOrderDetails. Diese Meldung steht auf Log-Level “Info” und enthält die vollständige Antwort von PayPal einschließlich des tatsächlichen status-Werts. Daran sehen Sie, in welchem Zustand die Order bei PayPal hängt.Legen Sie die Log-Gruppe deshalb so an, dass sie das Level Info mit einschließt. Sonst fehlt Ihnen genau die Meldung, die die Antwort enthält.3
Button-Integration prüfen
Wenn die Meldung gehäuft und reproduzierbar auftritt, prüfen Sie bitte die Integration des PayPal-Buttons im Checkout-Template. Konkret ist zu prüfen, ob der Aufruf mit
wsPaymentStatus=refresh bereits ausgelöst wird, bevor der Kunde die Freigabe bei PayPal abgeschlossen hat. Das ist das typische Symptom bei selbst angepassten PayPal-Button-Handlern, siehe Praxisbeispiele - Verknüpfung mit dem Zahlungsanbieter.4
Unklare Fälle melden
Wenn der Status weder
APPROVED noch PENDING oder COMPLETED ist, obwohl der Kunde den Checkout augenscheinlich nochmal durchlaufen hat, melden Sie den Fall mit der Bestellnummer an WEBSALE.Internal error while validating order: Payment is in invalid state setting payment to error: checkoutCapture: response status is not valid (regular)
Nachrichten-ID: paypalCheckout.handleHookValidationError
Symptom
Ein von PayPal dem Shop im Hintergrund gemeldetes Ereignis wird nicht verarbeitet. Der Zahlungsstatus der Bestellung bleibt unverändert. Der Shop antwortet PayPal mit einem Fehler, woraufhin PayPal dasselbe Ereignis über Tage hinweg erneut zustellt. Bei dauerhaftem Auftreten dieses Problems kann PayPal den Webhook-Endpunkt des Shops abschalten.
Ursache
PayPal benachrichtigt den Shop serverseitig über verschiedene Ereignisse zu einer Bestellung, zum Beispiel “Zahlung genehmigt”, “Betrag eingezogen” oder “Zahlung abgelehnt”. Zur Absicherung fragt der Shop bei jedem eingehenden Webhook zusätzlich den aktuellen Bestellstatus direkt bei PayPal ab und prüft ihn. Bei einer regulären PayPal-Zahlung akzeptiert diese Prüfung nur die StatusAPPROVED , PENDING und COMPLETED. WIrd ein anderer Status gemeldet, beispielsweise CREATED , VOIDED oder PAYER_ACTION_REQUIRED , wird die Verarbeitung des Webhooks mit dieser Meldung abgebrochen.
Dies ist die Webhook-Variante eines verwandten Problems. Kommt der Kunde selbst per Browser-Weiterleitung in den Shop zurück und der Shop fragt dabei den Status ab, entsteht die fast wortgleiche Meldung Failed to load payment status for order:Payment is in invalid state…. Beide laufen über dieselbe Prüffunktion und unterscheiden sich nur im Auslöser: einmal die Rückkehr des Kunden, einmal die serverseitige Benachrichtigung durch PayPal.
Vorgehen
1
Tatsächlichen PayPal-Status nachlesen
Suchen Sie im Log kurz davor nach der Nachrichten-ID
paypalCheckoutService.checkoutValidateOrderDetails. Diese Meldung steht auf Log-Level “Info” und enthält die vollständige Antwort von PayPal einschließlich des tatsächlichen status-Werts.2
Auslösendes Ereignis bestimmen
Suchen Sie direkt davor nach der Nachrichten-ID
paypalCheckout.validateWebhookPayload. Diese Meldung steht ebenfalls auf Log-Level “Info” und enthält den vollständigen Webhook-Inhalt von PayPal. Darin finden Sie im Feld event_type das auslösende Ereignis.Legen Sie die Log-Gruppe deshalb so an, dass sie das Level Info mit einschließt. Sonst fehlen Ihnen beide Meldungen.3
Fall einordnen
Aus dem Ereignistyp und dem PayPal-Status ergibt sich, was zu tun ist.
4
Häufigkeit prüfen
Vereinzeltes Aufkommen ist angesichts dieser Fälle normal. Tritt der Fehler gehäuft und immer mit demselben
event_type auf, insbesondere mit PAYMENT.CAPTURE.DENIED oder CHECKOUT.PAYMENT-APPROVAL.REVERSED, melden Sie das bitte an WEBSALE. Zu prüfen ist dann, ob die Reihenfolge von Statusprüfung und Ereignisauswertung angepasst werden sollte, damit diese beiden Ereignisse wie vorgesehen als abgelehnte Zahlung durchlaufen.5
Unklare Fälle melden
Bleibt die Ursache unklar, melden Sie den Fall bei WEBSALE unter Angabe der Bestellnummer sowie der in Schritt 1 und 2 gefundenen Werte.
Failed to load payment status for order:getOrderDetails: Failed to communicate with paypal
Nachrichten-ID: paymentCheckBeforeRoute.clearerStatusUpdateFailed
Symptom
Der Zahlungsstatus einer Bestellung wird nicht aktualisiert. Die Bestellung behält daher den Status, den sie vor dem Abgleich hatte.
Ursache
Der Shop wollte den Zahlungsstatus einer Bestellung bei PayPal abfragen, beispielsweise, wenn der Kunde von PayPal in den Shop zurückgeleitet wurde oder ein automatischer Statusabgleich lief. Der Aufruf an PayPal ist jedoch fehlgeschlagen und der Shop hat keine verwertbare Antwort erhalten. Die konkrete Ursache, beispielsweise eine Zeitüberschreitung, ungültige Zugangsdaten oder eine Störung bei PayPal, ist in dieser Meldung nicht angegeben. Es gibt eine zweite Variante mit dem Zusatz “result was not a valid JSON”. In diesem Fall hat PayPal zwar geantwortet, aber nicht in einem für den Shop auswertbaren Format.
Vorgehen
1
Häufigkeit prüfen
Vereinzeltes Vorkommen, das sich über die Zeit verteilt, ist meist auf ein vorübergehendes Netzwerk- oder PayPal-Problem zurückzuführen. Hier besteht kein Handlungsbedarf.
2
Zugangsdaten prüfen
Kontrollieren Sie die Client-ID, das Secret und den Betriebsmodus. Der Modus (
sandbox oder live) muss zu den hinterlegten Zugangsdaten passen.3
Subshops vergleichen
Prüfen Sie zunächst, ob alle Subshops oder nur einzelne betroffen sind. Sind nur einzelne betroffen, deutet das auf eine subshop-spezifische Fehlkonfiguration hin, denn Konfigurationsknoten lassen sich pro Subshop überschreiben.
4
Dauerhafte Fälle eskalieren
Wenn die Konfiguration korrekt aussieht, der Fehler aber weiterhin dauerhaft auftritt, melden Sie das bitte an WEBSALE. Dahinter kann eine Netzwerk- oder Firewall-Blockade in Richtung PayPal stehen oder ein Problem auf PayPal-Seite, das sich über die Shop-Konfiguration nicht lösen lässt.
Error setting up the connection to paypal api (Http: 404)
Nachrichten-ID: paypalCheckoutService.callApiHttpError
Symptom
Ein Vorgang, in den PayPal involviert ist, wird nicht abgeschlossen. Je nach betroffenem Aufruf wird entweder eine Zahlung nicht eingezogen oder ein Zahlungsstatus nicht aktualisiert. Bei den Fehlercodes 401 und 403 betrifft das sämtliche PayPal-Zahlungen im Shop, bei 404 in der Regel nur einzelne Bestellungen.
Ursache
PayPal hat einen Aufruf der PayPal-REST-API, beispielsweise eine Statusabfrage oder einen Zahlungseinzug, mit einem Fehlercode beantwortet. Diese Meldung erscheint bei jedem HTTP-Code, der nicht erfolgreich ist. Der Code in Klammern entscheidet über die Bedeutung.
Bei
404 sind zwei Ursachen üblich. Entweder existiert die PayPal-Bestellung nicht mehr, weil der Kunde sie nie abgeschlossen hat und sie auf PayPal-Seite verfallen ist. Oder die Sandbox- und die Live-Umgebung passen nicht zusammen, beispielsweise weil Live-Zugangsdaten hinterlegt sind, die Order aber noch unter Sandbox angelegt wurde.
Direkt danach steht im Log die Rohantwort von PayPal unter der Nachrichten-ID paypalCheckoutService.callApiHttpErrorResult, beispielsweise:
RESOURCE_NOT_FOUND und INVALID_RESOURCE_ID bestätigen dies. Die angefragte Order-ID existiert bei PayPal nicht mehr.
Es gibt eine ähnliche Fehlermeldung beim Abholen des Zugriffstokens: “
Error setting up the connection to Paypal API for Access Token (Http: ...)”. Tritt diese auf, sind die Zugangsdaten grundsätzlich ungültig, unabhängig von einer einzelnen Bestellung.Vorgehen
1
Bestellung identifizieren
In der Meldung selbst ist keine Bestellnummer enthalten. Suchen Sie im selben Zeitfenster nach der Nachrichten-ID
paypalCheckoutService.callApiErrorResponse. Diese Meldung steht auf Log-Level Info und enthält die Bestellnummer, die Transaktions-ID, die gesendete Anfrage und die vollständige Antwort von PayPal.2
Sandbox- und Live-Konfiguration abgleichen
Client-ID, Secret und der Betriebsmodus müssen zusammenpassen. Dies ist besonders relevant, wenn kürzlich zwischen Sandbox und Live gewechselt wurde.
3
Alter der Bestellung prüfen
Wenn die Bestellung bereits mehrere Stunden zurückliegt, ist die PayPal-Bestellung regulär verfallen. Das ist kein Konfigurationsfehler. Die Bestellung lässt sich für den Kunden ohnehin nicht mehr abschließen.
4
Frische Bestellungen melden
Wenn der Fehler bei aktuellen Bestellungen auftritt, melden Sie ihn bitte unter Angabe der Bestellnummer aus Schritt 1 bei WEBSALE.
Computop Hosted
payment method invalid, not defined in computopHosted config
Nachrichten-ID: computopHosted.getComputopHostedConfigPaymentMethodInvalid
Symptom
Der Kunde wählt im Checkout eine bestimmte Zahlungsart aus, doch statt zur Computop-Bezahlseite weitergeleitet zu werden, bricht die Zahlung ab. Betroffen ist genau die Zahlungsart, deren ID in der Meldung angegeben ist.
Ursache
Die gewählte Zahlungsart soll über Computop Hosted abgewickelt werden. Das Shopsystem sucht dazu im Konfigurationsknotenpayment.computopHosted nach dem Eintrag mit dieser Zahlungsart-ID, kann ihn jedoch nicht finden. Daraufhin bricht die Zahlung kontrolliert ab. Dies ist kein technischer Fehler, sondern eine fehlende oder falsche Zuordnung in der Konfiguration.
Die betroffene Zahlungsart-ID steht ohne Leerzeichen direkt hinter dem Doppelpunkt der Meldung.
Vorgehen
1
Zahlungsart-ID und Subshop notieren
Die Zahlungsart-ID können Sie der Meldung entnehmen. Den Subshop entnehmen Sie dem Log-Eintrag, denn jeder Eintrag ist einem Subshop zugeordnet.
2
Konfiguration prüfen
Öffnen Sie den Knoten
payment.computopHosted und prüfen Sie für den betroffenen Subshop, ob ein Eintrag mit dieser ID existiert.3
Fehlenden Eintrag ergänzen oder Template korrigieren
Wenn die ID unter
payment.payment aktiv ist, aber nicht unter payment.computopHosted hinterlegt ist, müssen Sie sie dort ergänzen. Konfigurationsknoten lassen sich pro Subshop überschreiben. Prüfen Sie deshalb jeden betroffenen Subshop einzeln.Wenn die ID nicht mehr existiert, weil sie umbenannt oder entfernt wurde, prüfen Sie Ihre Templates auf eine fest eingetragene alte Zahlungsart-ID und stellen Sie auf eine dynamische Referenz um. 4
Testbestellung durchführen
Führen Sie im betroffenen Subshop eine Testtransaktion durch und beobachten Sie dabei die Log-Gruppe.
5
Wechselnde IDs einordnen
Wenn die Meldung trotz korrekter Konfiguration bestehen bleibt, sehen Sie sich das Muster an. Viele verschiedene, wechselnde Zahlungsart-IDs stammen erfahrungsgemäß eher aus veralteten Sitzungen oder von automatisierten Zugriffen als aus einer Fehlkonfiguration.