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!
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.
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
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!
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.
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 :)
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:
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).
Ich versteh die Diskussion nicht… Shopware 6 ist ca. ein halbes Jahr stable und das PayPal Plugin ist direkt von Shopware selber. Alles aus einer Hand. Was sollte da denn schief gehen?
Wir wollen in 2 Wochen live gehen. Ich frage mich echt, ob das mit dem System so momentan möglich ist, wenn man mehr als Vorkasse anbieten will. Denn die meisten Zahlungsanbieter haben mit dem unlogischen Verhalten im Checkout ihre Probleme. Und wenn Shopware selber es nicht schafft, ein stabiles Plugin für eine Zahlart zu entwickeln, ist halt auch fraglich, ob das für externe in der Zeit möglich ist.
Man kann ja Alternativen nutzen. Klarna zum Beispiel. Ach ne, seit dem Update auf 6.2 funktioniert das Plugin ja nicht mehr mit der aktuellen Version und mit Fertigstellung ist frühstens in KW 29 zu rechnen. Aber hey, einfach mal 2 Monate auf einen Zahlungsdienstleister verzichten. Macht doch nichts!
PT-11669 - Kompatibilität mit dem Zahlungsprozess nach einer Bestellung hinzugefügt
PT-11707 - Individuelle Formular-Parameter der Bestellseite werden nicht mehr ignoriert
PT-11748 - Weiterleitungs-URL für PayPal Plus und Express Checkout korrigiert. Die Webhook-URL wurde geändert, sodass sie unabhängig von einer Storefront ist PT-11773 - Kaufen von Custom Products mit PayPal korrigiert PT-11813 - Fehlerbehandlung für Express Checkout Buttons PT-11858 - Verarbeitung von mehreren Transaktionen pro Bestellung verbessert
PT-11869 - Handhabung von Zahlungen verbessert, die von Kunden abgebrochen wurden
Das klingt alles recht vielversprechend ich bin super gespannt und ziehe das sofort bei allen von uns betreuten Shops durch.
Werde meine Erfahrungen berichten und freue mich auch auf weiteren Feedback zum Thema
Bei mir bricht das update mit folgender Fehlermeldung ab.
Plugin Update ist fehlgeschlagen
Plugin konnte auf Grund der Fehlermeldung „Unable to generate a URL for the named route „api.action.paypal.webhook.execute“ as such route does not exist.“ nicht aktualisiert werden. Plugin wurde deaktiviert.
Werde direkt mal den Support anschreiben. Ach ne, das Plugin hat ja keinen Support. Ich dummerle.
Danke für den Hinweis. Ich hatte das Update manuell hochgeladen (auo-Updates mach SW bei uns generell nicht). Über deinen Weg hat es jetzt funktioniert. Hoffen wir mal, dass so einige Probleme gelöst werden.
Paypal Kauf auf Rechnung bleibt in einem „Live-Lock“ mit der folgenden Fehlermeldung in der Konsole:
all.js:3 Uncaught Error: The required data attribute "swag-pay-pal-plus-payment-wall-checkout-order-token" does not exist on [object HTMLDivElement]!
at Function.value (all.js:3)
at e.value (all.js:6)
Nach einem Clear Cache / Refresh konnte ich auf dem Testsystem mit Paypal & Sandbox eine Bestellung durchführen. Bestellung im Backend ist leider nicht als Fehlerhaft oder sonst irgendwie markiert, diese ist wieder " offen"! Dann abbrechen der Bestellung => Zahlungsart geändert auf „Paypal“ nicht mehr Kauf auf Rechnung => Erfolgreich => Status im Backend geändert.
Update auf Produktivsystem durchgeführt, eine Testbestellung gestartet und folgenden Fehler erhalten:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'nonce-GB0/D/AELWlNnYpB6uMXa5ZDx1AvT5Ir46zcffISbzjsp34j' 'self' https://*.paypal.com https://*.paypalobjects.com 'unsafe-inline' 'unsafe-eval'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.
Mehrmals Refresh, Bestellung neu gestartet funktioniert wieder.
Nun funktioniert aber in dem produktiven System das Ändern der Zahlungsart nicht mehr! Das untersuchen wir jetzt genauer:
Liest sich mal wieder wie ein klassischer Bug(Fix)-Release von Shopware. Warum auch ordentlich testen, machen ja die Kunden auf produktiv. So kann man auch Geld einsparen. Man ist das peinlich.
@seriewe danke für die ausgiebige Antwort, ich warte dann mal lieber noch bis der Bug(fix)-Release vom Bug(fix)-Release kommt :facepalm:
Michael Telgmann
