> ## Documentation Index > Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt > Use this file to discover all available pages before exploring further. # Bekannte Fehlermeldungen > Antworten und Lösungen für bekannte Fehlermeldungen aus dem LogManager. export const KonfigDeeplink = ({node}) => <> Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden:{" "} {`https:///admin/config/${node}`}{" "} (Deeplink-Übersicht) ; Auf dieser Seite werden bekannte Meldungen aus dem [LogManager](/admin-interface/logmanager-logs) gesammelt und beantwortet. Zu jeder Fehlermeldung erfahren Sie, wie der Fehler entsteht und welche Maßnahmen Sie ergreifen können, um den Fehler zu beheben. Fehler, die nicht durch eigene Konfiguration lösbar sind, sind entsprechend gekennzeichnet. Wie Sie Log-Gruppen anlegen, welche Filter es gibt und was die Log-Level bedeuten, erfahren Sie auf der Seite [LogManager (Logs)](/admin-interface/logmanager-logs). Wenn eine Ursache unklar bleibt, wenden Sie sich bitte an das [WEBSALE Service Desk](https://websale.atlassian.net/servicedesk/customer/portal/6) und nennen Sie dabei immer die Bestellnummer, den Subshop und den Zeitraum. *** ## 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 (beispielsweise `canceledByUser` ). Für den aktuellen Zahlungsanbieter ist jedoch keine eigene Fehlerweiterleitung implementiert. **Wichtig:**
Die Fehlermeldung "`Configure an error template`" klingt, als würde eine Admin-Einstellung fehlen. Für Stripe (Payment-IDs beginnen mit "`pi_`") gibt es diese Funktion aktuell jedoch nicht. Nur die PayPal-Integration hat eine eigene Fehlerseiten-Konfiguration. Bei Stripe handelt es sich also nicht um einen Konfigurationsfehler, den man selbst beheben kann, sondern um eine aktuell fehlende Funktion in der Integration. #### Vorgehen 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_`. 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. 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: ` 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ächst `Received 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. | **Grund** | **Zahlungsart** | **Bedeutung** | | ---------------------------------------------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Webhook Validation FAILURE` | PayPal und Stripe | Die Signaturprüfung der eingehenden Benachrichtigung ist fehlgeschlagen. Entweder stammt die Anfrage nicht vom Zahlungsanbieter oder die im Shop hinterlegten Zugangsdaten zur Prüfung der Signatur sind nicht mehr korrekt. | | `Internal error while validating order` | PayPal | Die Rückfrage bei PayPal nach dem aktuellen Bestellstatus ist fehlgeschlagen oder hat einen unerwarteten Status geliefert. Siehe [Internal error while validating order](#internal-error-while-validating-order-payment-is-in-invalid-state-setting-payment-to-error-checkoutcapture-response-status-is-not-valid-regular). | | `ERROR, Order Validation FAILURE` | PayPal | Die von PayPal gelieferten Bestelldaten, beispielsweise der Betrag oder die Artikel, entsprechen nicht den Erwartungen des Shops. | | `unknown clearer order status in paypal checkout hook: ` | PayPal | PayPal meldet einen Bestellstatus, den der Shop an dieser Stelle nicht verarbeiten kann. | | `transaction not found` | PayPal | Im Shop gibt es zu der Benachrichtigung keine passende Transaktion. | | `failed to parse stripe event:
` | Stripe | Der von Stripe gesendete Inhalt war technisch fehlerhaft und konnte deshalb nicht gelesen werden. | | `Stripe event type not supported: ` | Stripe | Stripe hat ein Ereignis geschickt, das der Shop nicht auswertet. Verarbeitet werden nur `payment_intent.succeeded` und `payment_intent.payment_failed`. | | `not supported for this payment type` | alle übrigen | Für diese Zahlungsart werden im Shop keine Benachrichtigungen verarbeitet. Computop sendet selbst keine, daher entsteht dieser Fall im Normalbetrieb nicht. Er deutet auf eine fehlgeleitete oder manuell aufgerufene Webhook-Adresse hin. | 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 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. 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. 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. `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. 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. 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: ` 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 Grund `unable 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: | **Nachrichten-ID** | **Bedeutung** | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `paypalCheckoutService.callApiHttpError` | PayPal hat geantwortet, aber mit einem Fehlercode. Die Bedeutung der Codes steht unter [Error setting up the connection to paypal api](#error-setting-up-the-connection-to-paypal-api-http-404). Direkt danach steht der Original-Antworttext von PayPal unter `paypalCheckoutService.callApiHttpErrorResult`. | | `paypalCheckoutService.callApiCurlError` | Die Verbindung zu PayPal kam gar nicht zustande, beispielsweise durch ein Netzwerkproblem oder eine Zeitüberschreitung. Für Verbindungsaufbau und Gesamtdauer gelten jeweils 10 Sekunden. PayPal hat in diesem Fall nicht geantwortet. | | `paypalCheckoutService.callApiCurlInitFailed` | Ein technisches Problem im Shop selbst beim Aufbau der Anfrage. Sehr selten und eher ein Hinweis auf ein Infrastrukturproblem als auf PayPal oder die Konfiguration. | 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, und * `paypalCheckout.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 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. 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. Kontrollieren Sie Client-ID, Secret und den Betriebsmodus. Sandbox und Live sowie die hinterlegten Zugangsdaten müssen zusammenpassen, besonders nach einem kürzlichen Wechsel. 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. 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. 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 Status `APPROVED`, `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: | **Zusatz** | **Zahlungsablauf** | **Akzeptierte PayPal-Status** | | -------------- | ----------------------------- | ------------------------------------------------------ | | `(regular)` | Reguläre PayPal-Zahlung | `APPROVED`, `PENDING`, `COMPLETED` | | `(cc)` | Kreditkarte | `APPROVED`, `PENDING`, `CREATED` | | `(invoice)` | Rechnungskauf | `APPROVED`, `PENDING`, `COMPLETED`, `PENDING_APPROVAL` | | `(apm)` | Alternative Zahlungsart | `APPROVED`, `PENDING`, `COMPLETED` | | `(no payment)` | Zahlungsart nicht ermittelbar | `APPROVED`, `PENDING` | #### Vorgehen Vereinzeltes Aufkommen kann als normales Kundenverhalten (beispielsweise durch eine abgebrochene Zahlung im PayPal-Fenster) angesehen werden und ist kein Fehler im Shop.  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. 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](/verknuepfung-zahlungsanbieter). 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 Status `APPROVED` , `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...](#failed-to-load-payment-status-for-orderpayment-is-in-invalid-state-setting-payment-to-error-checkoutcapture-response-status-is-not-valid-regular). 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. **Wichtig:**
Die Statusprüfung erfolgt vor der Auswertung des Ereignistyps. Die Ereignisse `PAYMENT.CAPTURE.DENIED` (Zahlung abgelehnt) und `CHECKOUT.PAYMENT-APPROVAL.REVERSED` (Genehmigung zurückgezogen) würden die Bestellung eigentlich sauber auf "abgelehnt" setzen. Bricht die vorgelagerte Statusprüfung jedoch ab, wird der Ereignistyp nie ausgewertet und die Bestellung bleibt in ihrem bisherigen Zahlungsstatus stehen. Dies ist keine Frage der Konfiguration, sondern eine Lücke im Zusammenspiel der beiden Prüfungen. #### Vorgehen 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. 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. Aus dem Ereignistyp und dem PayPal-Status ergibt sich, was zu tun ist. | **Gefundener Wert** | **Bedeutung** | **Maßnahme** | | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event_type` ist `PAYMENT.CAPTURE.DENIED` oder `CHECKOUT.PAYMENT-APPROVAL.REVERSED` | Die Zahlung wurde abgelehnt oder die Genehmigung wurde zurückgezogen. Das ist inhaltlich kein Fehler des Shops, sondern eine echte Zahlungsablehnung. | Bestellstatus im Admin-Interface prüfen. Bleibt die Bestellung in einem offenen Zahlungsstatus hängen, setzen Sie sie manuell auf storniert oder fehlgeschlagen. | | `status` ist `VOIDED` oder `PAYER_ACTION_REQUIRED` | Die PayPal-Bestellung ist verfallen oder wartet auf eine Kundenaktion, die nie erfolgt ist. | Kein Konfigurationsfehler. Die Bestellung ist für den Kunden nicht mehr abschließbar. | | `status` ist `CREATED` | Der Kunde hat die Zahlung im PayPal-Fenster nie freigegeben. | Kein Handlungsbedarf, solange es Einzelfälle bleiben. | 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. 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 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. Kontrollieren Sie die Client-ID, das Secret und den Betriebsmodus. Der Modus (`sandbox` oder `live`) muss zu den hinterlegten Zugangsdaten passen. 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. 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. | **HTTP-Code** | **Bedeutung** | **Typische Ursache** | | ------------- | -------------------------------- | ------------------------------------------------------------ | | `400` | Ungültige Anfrage | Fehlerhafte Daten in der Anfrage an PayPal. | | `401` | Authentifizierung fehlgeschlagen | Client-ID oder Secret stimmen nicht. | | `403` | Nicht berechtigt | Die Zugangsdaten haben für diesen Aufruf keine Berechtigung. | | `404` | Nicht gefunden | PayPal kennt die angefragte Order-ID nicht (mehr). | 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: ```json theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}} Result: {"name":"RESOURCE_NOT_FOUND","details":[{"issue":"INVALID_RESOURCE_ID"}]} ``` `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 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. Client-ID, Secret und der Betriebsmodus müssen zusammenpassen. Dies ist besonders relevant, wenn kürzlich zwischen Sandbox und Live gewechselt wurde. 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. 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 Konfigurationsknoten `payment.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 Die Zahlungsart-ID können Sie der Meldung entnehmen. Den Subshop entnehmen Sie dem Log-Eintrag, denn jeder Eintrag ist einem Subshop zugeordnet. Öffnen Sie den Knoten `payment.computopHosted` und prüfen Sie für den betroffenen Subshop, ob ein Eintrag mit dieser ID existiert. 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.  Führen Sie im betroffenen Subshop eine Testtransaktion durch und beobachten Sie dabei die Log-Gruppe. 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. ## Related topics - [LogManager (Logs)](/admin-interface/logmanager-logs.md) - [actions - Warenkorb & Checkout](/konfiguration/actions-fehlertexte-e-mails/actions-warenkorb-checkout.md) - [actions - Benutzerkonto](/konfiguration/actions-fehlertexte-e-mails/actions-benutzerkonto.md) - [actions - Produkte](/konfiguration/actions-fehlertexte-e-mails/actions-produkte.md) - [actions - Anmeldung & Registrierung](/konfiguration/actions-fehlertexte-e-mails/actions-anmeldung-registrierung.md)