Paypal Plugin funktioniert nicht - sehr instabil SW6.2.2 - Plugin Version 1.6.0

Hallo zusammen,

wir haben Probleme mit dem Shopware Paypal Plugin. Aktuell setzen wir die Version 1.6.0 auf Shopware 6.2.2  ein. Fast jede Bestellung ist fehlerhaft und bleibt im Status offen, im Backend erhalten wir einen Fehler:  

**_„The error „INVALID_RESOURCE_ID“ occurred with the following message: The requested resource ID was not found“

 _**

 

Im Log haben wir nur den Hinweis: 

[2020-07-02 07:10:21] swag_paypal.ERROR: Client error: GET https://api.paypal.com/v1/payments/payment/PAYID-L36P7[XYXYXYXYXY]51YR9914426 resulted in a 404 Not Found response: {„name“:„INVALID_RESOURCE_ID“,„message“:„The requested resource ID was not found“,„information_link“:"https://developer. (truncated…)  The requested resource ID was not found [{„name“:„INVALID_RESOURCE_ID“,„message“:„The requested resource ID was not found“,„information_link“:„https://developer.paypal.com/docs/api/payments/#errors",„debug_id“:"5b[XYXYXY]055“},]

Das Verhalten haben wir in 3 verschiedenen Shops. Wir sind verzweifelt, der Support kann uns nicht Helfen und sagt, dass alles scheinbar in Ordnung sei. Bitte teilt eure Erfahrung, es würde uns enorm weiterhelfen. 

 

Vielleicht ist das die Spur:

 

https://forum.shopware.com/discussion/69543/update-6-2-2-konflikt-mit-aktiven-rabatten?

@oliverriske schrieb:

Vielleicht ist das die Spur:

 

https://forum.shopware.com/discussion/69543/update-6-2-2-konflikt-mit-aktiven-rabatten?

Hallo @oliverriske Danke für den Link, leider ist das nicht das Problem. Wir können Bestellungen durchführen mit und ohne Rabatte, alles kein Problem. Aber es kommt immer wieder (sehr sporadisch keine Systematik oder Hinweise) zu Fehlern bei den Kunden. Wir müssen das irgendwie eingrenzen, daher der Aufruf hier, ob jemand ähnliche Fehler Symptome hat?

Hallo,

kannst du das Problem zuverlässig nachstellen? Wie ist der Workflow um diesen Fehler zu provozieren? Wurde zufällig versucht Test-Bestellungen die mit den Sandbox Credentials gemacht worden sind, mit dem Live Credentials abzufragen? 

Wenn nur der Fehler gepostet wird, ist es sehr schwer zu erraten, was schief läuft  Wink Wenn wir an dem Plugin arbeiten, taucht dieser Fehler nicht auf. Daher müssen wir genau wissen, wie die Konstellationen auf den Kunden-Systemen da draußen sind. Andernfalls haben wir wenig Chanchen den Fehler zu reproduzieren und zu beheben. 

Viele Grüße aus Schöppingen

cool Michael Telgmann

[@Michael Telgmann](http://forum.shopware.com/profile/17553/Michael Telgmann “Michael Telgmann”)‍ genau das ist mein Problem, ich kann das Fehlverhalten nicht nachstellen! Die Logs zeigen nichts an, meine Tests sind immer erfolgreich egal, ob ich das mit Firefox, Chrome, Safari oder mobile Device durchführe. Ich habe mit Paypal, Lastschrift, Kreditkarte bezahlt, Express Checkout durchgeführt, InPrivate bestellt, neuen Account erstellt und damit bestellt. Unterschiedliche Paypal Accounts verwendet alles ohne Erfolg. Aber die Kunden schaffen das immer wieder, den Fehler herbeizuführen!

Wir brauchen einen Art debug modus mit dem wir es zumindest eingrenzen können, welcher Schritt es ist, im welchen Context der user sich befindet, warum eine ID generiert und im System abgelegt wird, diese dann aber beim Abrufen der Transaktion ungültig ist.  Das würde mir weiterhelfen deine Fragen zu beantworten.

Beste Grüsse vom Bedensee

Kann es nicht einfach sein, dass hier ein Kunde die Zahlung im Bestellprozess abbricht? Das passiert häufiger als man denkt, nur dass es hier jetzt mehr auffällt, da die Bestellung unabhängig von der Zahlung angelegt wird.

Handelt es sich bei den Bestellungen um welche, die auf PayPal-Seite abgebrochen worden sind?

Viele Grüße aus Schöppingen

cool Michael Telgmann

Hallo,

@AndreHerking‍  Bestellungen dir Abgebrochen sind, sollten keinen Fehler beim Wechseln in den PayPal Tab werfen, zumindest bleibt dieser bei meinen Tests einfach leer. 

[@Michael Telgmann](http://forum.shopware.com/profile/17553/Michael Telgmann “Michael Telgmann”)‍ Wir haben gerade einen Kunden erreichen können bei dem genau der gleiche Fehler im Backend auftritt, sobald wir auf den PayPal Tab switchen => Er hat den Button “Zahlungspflichtig bestellen” bestätigt => wurde zu Paypal weitergeleitet => hat seine Zugangsdaten bei paypal eingegeben => dann kam eine loading Animation für das Einloggen bei paypal die lange nicht weiter reagiert hat => daraufhin hat er auf abbrechen geklickt.  

Es scheint, aber das haben wir noch nicht reproduzieren können, das es entweder beim Paypal login oder übergaben von Daten oder tatsächlich beim Kunden probleme gibt, jedoch haben wir das so oft, das ich kaum glauben kann das alle Kunden sich nicht bei paypal einloggen können.

1 Like

Ich kann das bestätigen. Erhebliche Probleme mit Paypal gehabt, haben aber das Problem bei Paypal gesucht und versucht herauszufinden welcher Art von Abbruch hier stattfindet. Paypal sagte uns dann, dass es Kundenabbrüche sind. Auch wir haben Leute erreicht die abgebrochen und dann zB erneut per anderer Zahlungsmethode bestellt haben. Oft kam einfach keine Bestätigung von Paypal (endloses Laden) und die Leute haben daraufhin das Fenster geschlossen.

Die Häufigkeit mit der das passiert, war allerdings nicht im geringsten vergleichbar mit den Erfahrungen die wir zeitgleich mit Shops die mit Shopware 5 bzw. andere Systemen liefern. War also definitiv kein Problem mit Paypal oder dergleichen, sondern definitiv irgendetwas in Verbindung mit SW6. 

Eine Lösung / Workaround dafür kann ich leider nicht anbieten.

1 Like

Hallo @seriewe‍,

wenn du dir die abgebrochenen Bestellungen direkt anschaust, kann ich das Verhalten bestägigen. Allerdings sind die abgebrochenen Zahlungen, die bei PayPal angelegt worden sind, irgendwann nicht mehr verfügbar. Schau mal bitte, ob du morgen oder übermorgen immer noch ein leeres Formular hast, oder ob dann der Fehler auftritt. 

Viele Grüße aus Schöppingen

cool Michael Telgmann

Bei uns das Selbe Problem! 

Ich habe auch den Fehler aus dem Screenshot oben im Backend. Hatte jetzt auch eine Bestellung eines Kunden via PayPal, die nicht abgeschlossen wurde. Ich habe den Kunden jetzt kontaktiert und warte auf Antwort, vermute aber, dass es das oben bereits beschrieben Verhalten ist, was hier Probleme macht. 

Ich habe gerade auch einen Testkauf durchgeführt, ohne Probleme. Trotz Fehlermeldung im Backend.

Vor ein paar Wochen hatten wir schon einmal das Problem, da kam man aber nicht ienmal zur PayPal-Abwicklung. Man klickte einfach auf “Zahlungspflichtig bestellen” und kam dann auf einen weißen Bildschirm.

Ich hoffe es gibt hier schnell eines Lösung! Falls es irgendwelche Tickets gibt, die man voten kann immer her damit!

@gentlemon schrieb:

Die Häufigkeit mit der das passiert, war allerdings nicht im geringsten vergleichbar mit den Erfahrungen die wir zeitgleich mit Shops die mit Shopware 5 bzw. andere Systemen liefern. War also definitiv kein Problem mit Paypal oder dergleichen, sondern definitiv irgendetwas in Verbindung mit SW6. 

Eine Lösung / Workaround dafür kann ich leider nicht anbieten.

@gentlemon‍

Das können wir genau so bestätigen, wir haben noch ein altes xtCommerce System am Laufen und bis vor kurzem ein Prestashop das wir auf SW6 migriert haben. Bei diesen Systemen hatten wir es nie in dieser Häufigkeit / Ausprägung gesehen!  Das macht unsere Kunden super nervös, der xtCommerce Kunde hat sich nun sogar gegen eine Migration zu SW6 entschieden. 

[@Michael Telgmann](http://forum.shopware.com/profile/17553/Michael Telgmann „Michael Telgmann“)‍

Das mit der Fehlermeldung haben wir nun nachstellen können, tatsächlich werfen abgebrochene Bestellungen nach einer gewissen Zeit den oben gezeigten Fehler.

Was wir noch beobachtet haben ist ein Timeout im Hintergrund, lassen wir das Paypal Login Fenster offen und warten (bzw. lassen das einfach stehen) wird die Bestellung als Zahlungsstatus offen im Backend abgelegt, es wäre sicherlich informativer bei einem Timeout seitens Paypal die Bestellung in den Zahlungsstatus „Fehlgeschlagen“ zu setzen.
Auch wenn der Kunde abgebrochen hat (mit dem Abbruch link bei paypal) und dann die Zahlungsart nicht verändert, der Zahlungsstatus auf „Abgebrochen“ oder ähnliches gesetzt wird.

Es macht es leichter nachzuvollziehen was gelaufen ist und wir können das dem Kunden / Shopbetreiber besser erklären!

Noch besser ist natürlich ein stabiler kundenfreundlicher PayPal Check-out Prozess

1 Like

[@Michael Telgmann](http://forum.shopware.com/profile/17553/Michael Telgmann “Michael Telgmann”)‍

So sehen bei uns Bestellungen aus, zum Glück hatten wir eine hartnäckige Kundin, die uns angerufen hat und immer wieder die Bestellung durchführte bis diese endlich auf dem Handy erfolgreich war. Laut Ihrer Aussage, die Dame war leider nicht sehr Computer affine, stürzte der Browser immer ab, es kam zu einem Fehler, den Sie uns nicht genau erklären konnte. Was wir jetzt vermuten, scheint es bei dem Redirect zum Paypal Prozess einen Fehler zu geben!
 

 

Um hier einmal einzuhaken: Bei uns sah da Problem so aus (als ich es reproduzieren konnte): Kunde legt Artikel in Warenkorb, geht zur Kasse, wählt PayPal als Zahlungsmethode und geht auf „Zahlungspflichtig bestellen“. Der Browser bleibt weiß. In Shopware taucht kein Fehler-Log auf, bei PayPal kommt laut Technical Support keine Anfrage an (lt. deren Logs). Es scheint also keine Übergabe der Daten an PayPal statt zu finden, weshalb die Anfrage nicht weiter geleitet wird.

Probleme mit payPal (habe schon weiteret Beitrag aufgemacht):

Kunde führt eine Bestellung durch und wählt PayPal und tätigt die Bestellung. Sofort wird die Bestellung im System als offen angelegt und die Bestellbestätigung geht raus!

Bezahlt man mit PayPay wird eine weitere Bestellung (Bezahlt) angelegt.

Das laden von PayPal dauert eine Ewigkeit. Abbrüche sind vorprogrammiert. Wenn man wirklich abbricht und die Seite neu lädt und wieder PayPal wählt, wird wieder eine offene Bestellung angelegt!

Bricht man die PayPal-Bestellung bei PayPal ab, muss man eine neue Zahlungsart wählen. PayPal ist nicht mehr dabei!

Hallo zusammen,

den Fehler von @seriewe‍ bekomme ich nun auch. Es sind also tatsächlich Bestellungen die abgebrochen worden sind. Allerdings haben diese Bestellungen bei mir den Payment Status „Failed“ und nicht „Open“
Ich habe mal ein Ticket angelegt Shopware Issuetracker Da sollten wir einen Hinweis für den Kunden anzeigen, dass es sich um eine abgebrochene Zahlung handelt und nicht länger eingesehen werden kann.
Die Ursache für die Häufigkeit liegt vermutlich darin, dass in Shopware 6 nun immer eine Bestellung angelegt wird. Völlig egal, wie die Zahlung im Anschluss ausgeht. Dies ist der große Unterschied zu Shopware 5 z.B.

@Stephan_Grass‍ : Das PayPal Plugin ist momentan noch nicht mit dem After Order Payment Process kompatibel. Das Ticket dazu ist bereits umgesetzt und ich denke, dass wir nächste Woche das Update herausbringen können. 

Viele Grüße aus Schöppingen

cool Michael Telgmann

1 Like

@Stephan_Grass schrieb:

Probleme mit payPal (habe schon weiteret Beitrag aufgemacht):

Kunde führt eine Bestellung durch und wählt PayPal und tätigt die Bestellung. Sofort wird die Bestellung im System als offen angelegt und die Bestellbestätigung geht raus!

Bezahlt man mit PayPay wird eine weitere Bestellung (Bezahlt) angelegt.

Das laden von PayPal dauert eine Ewigkeit. Abbrüche sind vorprogrammiert. Wenn man wirklich abbricht und die Seite neu lädt und wieder PayPal wählt, wird wieder eine offene Bestellung angelegt!

Bricht man die PayPal-Bestellung bei PayPal ab, muss man eine neue Zahlungsart wählen. PayPal ist nicht mehr dabei!

Danke für das Teilen deiner Erfahrung, mehrfach Bestellungen hatten wir auch gehabt, leider ohne den Kunden jemals dazu befragen zu können. Denke, dass wir das von dir beschriebene Verhalten sein.

[@Michael Telgmann](http://forum.shopware.com/profile/17553/Michael Telgmann “Michael Telgmann”)‍   Bei uns sind diese tatsächlich überwiegend offen! Kann leider auch nicht genau nachvollziehen, wann diese als Fehlerhaft und wann als offen gespeichert werden.  Sollte der Check-out aber nicht Event basiert sein zum gewissen Grad? Aktuell scheint es mehr eine Art Time / Timeout + Random() - Weather Formel  zu sein :) 

 

Hallo zusammen,

auch mich betrifft dieses Problem massiv. Ich habe sehr oft, entweder Bestellungen die offen sind und bei denen die Zahlung ebenfalls auf offen steht. 

Gerade heute hatten wir wieder diesen Fall. Das Problem für mich ist, dass ich in keinster Art und Weise unterscheiden kann, ob ich jetzt einen Fehler im Shop habe und irgendetwas nicht funktioniert. Oder ob der Kunde im Zahlungsprozess abgebrochen hat. Das ist extrem verwirrend und ich kann, und will nicht jeden Kunden anschreiben und Ihn fragen. Weder die PayPal Logs noch die Shopware Logs, sagen etwas aus… Kann man hier nicht vielleicht einen Debug Modus einbauen, damit wir wissen an welcher Stelle und warum der Kunde rausgeflogen ist?

Beispiel heute:

Kunde hat um 11:09 “bestellt” oder vielleicht auch nur “abgebrochen” (ich weiß es ja nicht). 

Bestellung ist im Backend zu sehen und alle Stati stehen auf “offen”. Bei PayPal in den API Logs sehe ich, dass die Bestellung wenigstens angefragt wurde:

 

/v1/payments/payment/PAYID-L4AZRXXXXXX0G6482800T  9532d5c467XXXX Jul 2020 02:09:47
/v1/payments/payment 4d6d8e422dXXXXX  Jul 2020 02:09:46

Nirgendwo kann ich aber erkennen was passiert ist. Falls Ihr mehr Infos, braucht sagt gerne Bescheid. Ich möchte nicht noch mehr Kunden verlieren. 

Wie @seriewe‍ schon sagt, nicht jeder Kunde ist so hartnäckig wie die Dame.

Danke!

 

1 Like

ja verkaufen über den Shop ist schwer.

 

Wir versuchen unser Glück nun mit customweb saferpay plugin.

Paypal ist instabil und der von Shopware sogenannte “Post order process” ist völlig unklar.

Wir haben viele Jahre Magento, Woocommerce und andere Shops gebaut. Warum Shopware dem Kunden bei Kreditkartenzahlung vor der Bezahlung eine Bestellbestätigung sendet (auch bei Abbruch) ist mir schleierhaft und entspricht keinem normalen Shopverhalten.

An Shopware: ich möchte nun keine weitere Begründung für dieses seltsame Verhalten, sondern erwarte, dass man das konfigurieren kann (Also wann das Email rausgeht).

Ist vermutlich zu viel verlangt.

 

 

2 Likes

Wir überschreiben nun den halben core, um einen vernünftigen Bestellprozess zu realisieren.