Neu Plugin PayPal - capture failed for method PayPal Checkout

ecki

Aktives Mitglied
17. August 2022
75
13
Hallo,

Bei jeder PayPal Bezahlung steht im Logbuch:

Fehler Core
04.07.2025 - 09:05:15
[JTL_PAYPAL_COMMERCE] INFORMATION: Webhook::handleCall - capture failed for method PayPal Checkout

Zahlung kommt an.
Erst seid Update von Shop auf 5.5.2 und PayPal auf 2.0.1, also beides aktuell.
Hat jemand eine Idee was das ist? Schlimm?

Gruß
ecki
 
  • Gefällt mir
Reaktionen: Matchy

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.859
216
Hallo,

Bei jeder PayPal Bezahlung steht im Logbuch:

Fehler Core
04.07.2025 - 09:05:15
[JTL_PAYPAL_COMMERCE] INFORMATION: Webhook::handleCall - capture failed for method PayPal Checkout

Zahlung kommt an.
Erst seid Update von Shop auf 5.5.2 und PayPal auf 2.0.1, also beides aktuell.
Hat jemand eine Idee was das ist? Schlimm?

Gruß
ecki
Gab es irgendwann eine Antwort?

Habe dieselben Log-Einträge bei mir

Worst Case wäre wenn ein Kunde versucht zu bezahlen, bekommt nen Fehler und meldet sich nicht, kommt dann aber auch nie wieder.
 
  • Gefällt mir
Reaktionen: Matchy

ecki

Aktives Mitglied
17. August 2022
75
13
Ne leider nichts neues und keine Antwort bekommen.
Sind aber seid einiger Zeit keine neuen Fehlermeldungen mehr dazu gekommen. Hat irgendwann einfach aufgehört.
 

xadoX

Sehr aktives Mitglied
11. September 2012
651
58
Unser Log ist auch voll damit. Ist da was bekannt?
 

Anhänge

  • Fehlermeldung.jpg
    Fehlermeldung.jpg
    157,1 KB · Aufrufe: 14

NoOne

Sehr aktives Mitglied
16. März 2024
518
175
Unser Log ist auch voll damit. Ist da was bekannt?
Funktioniert euer Mailversand noch? Meistens passiert das in der Häufigkeit eigentlich nur, wenn die Einstellungen für den E-Mail-Server falsch sind, insbesondere der Port (Standardmäßig: 587 für TLS, 465 für SSL) muss korrekt sein. Wenn du in den E-Mail-Einstellungen auf "Speichern und Konfiguration testen" klickst, dann sollte die Meldung ob alles in Ordnung ist oder nicht ziemlich schnell gehen. Falls das in einen Timeout läuft, dann stimmt der Port vermutlich nicht.
 

xadoX

Sehr aktives Mitglied
11. September 2012
651
58
Unser Mailversand funktioniert. Wo ist denn der Zusammenhang zwischen Mailversand und dem PayPal Webhook Fehler?
 

Sirko W.

Aktives Mitglied
Mitarbeiter
27. Januar 2025
94
27
Hallo!

Mit dem Update auf Plugin 2.0.0+ ist ein erneutes Onboarding notwendig. Steht auch so im Changelog vermerkt. Der Schritt wurde hier vemrutlich übersehen.
Also bitte einmal unter "Zugangsdaten" die Verbindung zum Konto trennen und dann erneut verbinden. Danach prüfen, dass unter Webhooks 4 (!) Einträge vorhanden sind.
 

xadoX

Sehr aktives Mitglied
11. September 2012
651
58
Hallo!

Mit dem Update auf Plugin 2.0.0+ ist ein erneutes Onboarding notwendig. Steht auch so im Changelog vermerkt. Der Schritt wurde hier vemrutlich übersehen.
Also bitte einmal unter "Zugangsdaten" die Verbindung zum Konto trennen und dann erneut verbinden. Danach prüfen, dass unter Webhooks 4 (!) Einträge vorhanden sind.
Danke für die Info. Unser Plugin ist noch auf der 1.4.1.. Wir können noch nicht auf die 2.0.0 gehen, weil unser großes Shop-Update erst im Januar geplant ist.
Aktuell sind bei uns nur 3 Webhooks gelistet:
 

Anhänge

  • webhooks.jpg
    webhooks.jpg
    67,1 KB · Aufrufe: 2

MarcoWue

Aktives Mitglied
20. Dezember 2018
68
23
Hallo zusammen,
das Problem tritt bei uns ebenfalls auf, JTL- Shop 5.4 mit PayPal Plugin 2.1.1. Onboarding wurde neu durchgeführt und alle vier Webhooks sind im Plugin sichtbar.
Die Bestellungen werden zum Glück angelegt und die Zahlungen kommen an.

Folgender Fehler tritt sporadisch, jedoch mehrmals täglich, bei Bestellungen über PayPal Commerce im Logbuch auf (/admin/systemlog):
[JTL_PAYPAL_COMMERCE] INFORMATION: Webhook::handleCall - capture failed for method PayPal Checkout

Für betreffende Bestellungen wird dann jeweils folgender Eintrag im Zahlungslog von PayPal Checkout hinterlegt (/admin/paymentmethods):
[JTL_PAYPAL_COMMERCE] PAYMENT: handleCaptureWebhook: shop order does not existsstdClass Object ( [kBestellung] => 12345 [kZahlungsart] => 345 [cId] => [txn_id] => )

Bemerkenswert ist hier, dass txn_id bei allen Einträgen leer ist.
Über kBestellung kann die betreffende Bestellung jedoch in der Datenbank (tBestellung) ausfindig gemacht und geprüft werden - in unseren Stichproben sieht das soweit okay aus.


Der Fehler wird in handleCaptureWebhook() in PayPalPayment.php geschmissen: $ppOrder === null da empty($payment->txn_id)
https://gitlab.com/jtl-software/jtl.../master/paymentmethod/PayPalPayment.php#L1377
PHP:
 public function handleCaptureWebhook(string $eventType, Capture $capture, object $payment): bool
    {
        $logObject = new ObjectLogger($payment);
        $this->getLogger()->write(\LOGLEVEL_DEBUG, 'handleCaptureWebhook', $logObject);

        $ppOrder   = !empty($payment->txn_id) ? $this->getPPOrder($payment->txn_id) : null;
        $shopOrder = $ppOrder !== null ? $this->helper->getShopOrder($ppOrder) : null;

        if ($ppOrder === null || $shopOrder === null) {
            $this->getLogger()->write(\LOGLEVEL_ERROR, 'handleCaptureWebhook: shop order does not exists', $logObject);

            return false;
        }

Wo sollte $payment->txn_id herkommen? Sehen wir nach:

handleCaptureWebhook() wird zuvor von der gleichnamigen Funktion in WebhookHandler.php aufgerufen:
https://gitlab.com/jtl-software/jtl...ster/frontend/Handler/WebhookHandler.php#L118
PHP:
private function handleCaptureWebhook(WebhookCallResponse $response, string $eventType): void
    {
        try {
            $capture = new Capture($response->getData());
        } catch (JsonException | UnexpectedResponseException $e) {
            $this->logger->write(\LOGLEVEL_ERROR, 'Webhook::handleCall - Unexpected data for payment process id: '
                . $e->getMessage());

            self::exitResult(400, 'Unexpected data for payment process id.');
            exit();
        }

        $db      = Shop::Container()->getDB();
        $txnId   = $capture->getRelatedOrderId();
        $payment = $db->getSingleObject(
            'SELECT tbestellung.kBestellung, COALESCE(tzahlungsid.kZahlungsart,
                    tbestellung.kZahlungsart) AS kZahlungsart,
                    tzahlungsid.cId, tzahlungsid.txn_id
                FROM tbestellung
                LEFT JOIN tzahlungsid ON tbestellung.kBestellung = tzahlungsid.kBestellung
                    AND tzahlungsid.txn_id = :txnId
                WHERE cBestellNr = :oderNumber',
            [
                'txnId'      => $txnId,
                'oderNumber' => $capture->getInvoiceId(),
            ]
        );

        if ($payment === null || (int)$payment->kZahlungsart === 0) {
            // payment process id not found
            // - there is no session hash created for the captured payment or payment is already processed
            $this->logger->write(
                \LOGLEVEL_NOTICE,
                'Webhook::handleCall - No payment for order id ' . $txnId . ' found'
            );

            self::exitResult();
            exit();
        }

        $paymentHelper = Helper::getInstance($this->plugin);
        $payMethod     = $paymentHelper->getPaymentFromID((int)$payment->kZahlungsart);
        if ($payMethod === null) {
            $this->logger->write(
                \LOGLEVEL_NOTICE,
                'Webhook::handleCall - No payment method for order id ' . $txnId . ' found'
            );

            self::exitResult();
            exit();
        }
        $this->logger->setMethod($payMethod);

        if (!$payMethod->handleCaptureWebhook($eventType, $capture, $payment)) {
            $this->logger->write(
                \LOGLEVEL_ERROR,
                'Webhook::handleCall - capture failed for method ' . $payMethod->getMethod()->getName()
            );
        }

$payment->txn_id wird also aus der Datenbank aus Tabelle tzahlungsid abgerufen. Für betroffene Zahlungen geprüft, die txn_id ist in der Datenbank (nachträglich) korrekt eingetragen und entspricht der PayPal Transaktions-ID.
Zum Zeitpunkt des Webhook Calls scheint der Zahlungseintrag in tzahlungsid jedoch noch nicht zu existieren, sonst würde es ja nicht zu dem Errorlog kommen.

Das war genug Debugging für heute, ich hoffe @Sirko W. und das Team können das zügig beheben.

Ach ja, Tippfehler in einer Payment API machen sich nicht besonders gut, gerne direkt mit verbessern :)
  • 'handleCaptureWebhook: shop order does not exists'
  • 'orderNumber' => $capture->getInvoiceId()
  • ordertransaction id ' . $txnId

Grüße,
Marco
 

NoOne

Sehr aktives Mitglied
16. März 2024
518
175
Das kommt halt meistens bei Überlastungen oder schlechtem Timing vor. Wenn das aus *irgendeinem* Grund nicht schnell genug in die DB geschrieben wird, also der Webhook quasi ankommt, bevor die Bestellung komplett finalisiert ist, dann passiert das. Ich glaube auch nicht das sich das vermeiden lässt. Eigentlich sollte https://issues.jtl-software.de/issues/SHOP-7894 das beheben. Also auch, wenn die Bestellungen erstmal Pending sind, und bleiben, sollte das Irgendwann trotzdem an die Wawi gehen. Das läuft aber anscheinend über die LastJobs, also wenn der Abgleich fehlschlägt, auch wenns nur beim Schritt "Abschluss" ist, dann passiert das nicht.
 

MarcoWue

Aktives Mitglied
20. Dezember 2018
68
23
Das kommt halt meistens bei Überlastungen oder schlechtem Timing vor. Wenn das aus *irgendeinem* Grund nicht schnell genug in die DB geschrieben wird, also der Webhook quasi ankommt, bevor die Bestellung komplett finalisiert ist, dann passiert das. Ich glaube auch nicht das sich das vermeiden lässt. Eigentlich sollte https://issues.jtl-software.de/issues/SHOP-7894 das beheben. Also auch, wenn die Bestellungen erstmal Pending sind, und bleiben, sollte das Irgendwann trotzdem an die Wawi gehen. Das läuft aber anscheinend über die LastJobs, also wenn der Abgleich fehlschlägt, auch wenns nur beim Schritt "Abschluss" ist, dann passiert das nicht.
Wir erhalten die Error Einträge mehrmals täglich. Die Bestellungen kommen aber ganz normal rein und müssen auch nicht im Plugin manuell übernommen werden.
Der Webserver ist performant, es gibt keine Slow Log Einträge in MySQL.
Lässt sich das Problem irgendwie weiter debuggen?
 

Matchy

Aktives Mitglied
4. Januar 2011
85
13
Hallo Zusammen,

auch wir haben unser gesamtes Log voll mit diesen Einträgen, alle Zahlungen werden aber korrekt abgeschlossen. Onboarding hatten wir auch erneut gemacht, alle 4 Webhooks sind eingetragen. Trotzdem kommt ständig dieser Fehler.

Wir sind uns nicht sicher, ob dieser Fehler eventuell auch andere Probleme verursacht (oder die Ursache für diesen Fehler, andere Fehler provoziert)

Auch unser Server ist sehr schnell, Dedicated Server, er hat auch keine Log-Einträge, die auf Performance Probleme schließen lassen.

Shop-Version 5.5.3
Plugin: JTL PayPal Checkout: 2.2.0

Viele Grüße
Matze
 

Sirko W.

Aktives Mitglied
Mitarbeiter
27. Januar 2025
94
27
Hallo,

@NoOne hat das völlig korrekt beschrieben. Manchmal ist PayPal sehr fix was das Senden des Webhook angeht. Wenn zu dem Zeitpunkt das Frontend noch "nicht fertig" ist weil das Senden der Mails bspw. etwas länger dauert oder noch irgendwelche Prüfungen gemacht werden, dann passiert genau das: Der Webhook läuft ins Leere weil es die Bestellung (noch) nicht gibt, aber das Frontend macht alles "Step by Step fertig", so dass am Ende alles passt. Ggfs. hilft hier ein Blick ins Log und ein Vergleich der Zeiten für den Webhook, das Erstellen der Bestellung und das Versenden der Bestätigungs-Mail.
U.U. hilft auch das Einschalten der Mail-Queue, um den Bestellprozess zu beschleunigen.
 
Ähnliche Themen
Titel Forum Antworten Datum
Neu Paypal Checkout Plugin - Ist vorhanden aber nichts funktioniert Plugins für JTL-Shop 1
Neu WERO Plugin? Kampfansage gegen PayPal? User helfen Usern 66
Neu Paypal Plugin JTL-Shop - Fehler und Bugs 1
Neu Neues Plugin: Sauberes Meta-Tracking für JTL-Shop 5 (Pixel + CAPI + Consent) Plugins für JTL-Shop 0
Neu 📢 Plugin "Kreditlimit Plugin für JTL-Shop 5 " von CIN GmbH Plugins für JTL-Shop 0
Neu Händlerbund-Plugin lädt Texte herunter, ersetzt sie aber nicht im Frontend Technische Fragen zu Plugins und Templates 1
Neu 503 Service Unavailable bei Payrexx Webhook nach Plugin-Update - wer hat das auch? Plugins für JTL-Shop 0
Neu JTL-Shop 5.2.3 – Google-Shoppin-Plugin 2.3.0: Mehrere Rückgaberichtlinien (DE + Ausland) bei einem Feed / return_policy_label Plugins für JTL-Shop 0
Neu Coupon-Steuer Plugin: Korrekte Steuerberechnung für JTL-Shop Coupons Plugins für JTL-Shop 1
Neu How to properly update order status through JTL Shop plugin? Allgemeine Fragen zu JTL-Shop 4
Neu Update auf 5.6.1. – Trusted Shops Plugin erzeugt Fehlercode 500 Installation / Updates von JTL-Shop 6
Neu 🌟Neues Plugin: 35up Automatisiertes Cross-Selling Plugins für JTL-Shop 0
Neu 🚀 Pilotkunden gesucht: HS Dynamic Pricing Plugin für JTL-Shop Plugins für JTL-Shop 0
Neu Plugin: DITH Mengenrabatt – Warenkorbrabatte nach Stückzahl (mix + match), ohne Preisänderung am Artikel Plugins für JTL-Shop 0
Neu 🚀 JTL Shop Performance Check (Free): Kostenloses Plugin Plugins für JTL-Shop 0
Neu HTTP ERROR 500 - plugin installieren JTL-Shop - Fehler und Bugs 0
Neu Neues Plugin: DITH ShipNow – Versand-Countdown ⏱️ Plugins für JTL-Shop 0
Neu Fragen zum KBA Finder Plugin (CiN) Plugins für JTL-Shop 1
Neu Eingabefeld der PayPal Kreditkartenzahlung wird bei eingeloggten Kundenkonto nicht angezeigt JTL-Shop - Fehler und Bugs 1
Neu PayPal Checkout: rechte Button "Später Bezahlen" fehlt JTL-Shop - Fehler und Bugs 3
Neu Probleme beim Lizenzkauf im Extension Store – PayPal-Fehler? Plugins für JTL-Shop 0
Neu JTLPOS PayPal Reader JTL-POS - Fehler und Bugs 0
Neu PayPal lehnt Zahlung ab, weil PLZ angeblich nicht beliefert wird User helfen Usern 2
Neu Paypal Checkout nimmt neue CLIENT ID und SECRET nicht wahr User helfen Usern - Fragen zu JTL-Wawi 1
Neu Link zu Paypal Zahlungsaufforderung funktioniert nicht mehr User helfen Usern - Fragen zu JTL-Wawi 3
Neu PayPal-Meldung: XXX versendet nicht an diesen Ort. Verwenden Sie eine andere Adresse. Plugins für JTL-Shop 43
Neu Paypal bei bestimmten Produkten nicht anbieten Plugins für JTL-Shop 1

Ähnliche Themen