Paypal Checkout 3.4.1 / Oxid Shop 7.2 Fehler bei einigen Bestellungen

Deutsches Forum
1

Hallo Forum / mitlesende OXID Mitarbeiter,

leider haben wir ein merkwürdiges Problem seit der Shopumstellung:

Es kommen Bestellungen rein, die oben in der Bestelliste ausgegraut sind und unten unterhalb
der Artikel den Text “Bestellung wurde storniert” tragen.

Interner Status ist ok und im Tab vom PayPal Checkout ist auch eine Transaktions-ID
vorhanden. PayPal Zahlung im Geschäftskonto auf da, also so alles ok.

Wie passt das zusammen, das dann in der Bestellübersicht “Bestellung wurde storniert” auftaucht und die Bestellung ausgegraut wird?

Gefühlt wird mit jeder neuen Schnittstelle und Umstellung alles anders aber nichts besser,
bei Unzer genau das gleiche. Neue API, Rückschritt in den übertragenen Daten, wie damals beim PayPal Checkout auch.

Jemand eine Idee? Habe jetzt auch nicht im Bugtracker gesucht oder einen Eintrag gemacht,
weil ich nicht genau weiß wonach man da suchen soll.

Man kann den Fehler auch nicht an etwas festmachen, 10 Zahlungen über Paypal laufen ganz normal und dann hast du wieder so einen dazwischen.

Für den, der die Bestellungen checkt und schreibt ist das maximal verwirrend.

Viele Grüße,
Michael

2

Hat das einen bestimmten Grund, dass du nicht die aktuelle Version verwendest? Mein Tipp insbesondere bei Paypal ist bei einem Fehler zunächst prüfen, ob es eine aktuelle Version gibt. Das ist hier der Fall, denn neben der Version (schon ein Minor und mehrere Patch Releases weiter) hat sich auch laut Changelog viel getan.

1 Like
3

Hallo Michael,

ich vermute, dass dein Problem mit einem bekannten Bug in der Version 3.4.1 zusammenhängt. Wie naledre schon geschrieben hat, gibt es mittlerweile neuere Versionen (aktuell 3.5.1), und im Changelog habe ich gesehen, dass dort genau solche Probleme mit dem Bestellabschluss gefixt wurden.

Meine Vermutung ist, dass es sich um ein Timing-Problem mit den PayPal-Webhooks handelt. Der Shop wartet auf die Bestätigung von PayPal, und wenn die nicht schnell genug kommt, markiert er die Bestellung als storniert, obwohl die Zahlung bei PayPal längst durch ist. Das würde auch erklären, warum es nur sporadisch auftritt.

Ich würde dir auch empfehlen, auf Version 3.5.1 zu updaten.

4

Hallo @naledre und @MatsW ,

danke für das Feedback, ich werde dann demnächst mal ein Update des Paypal Moduls machen.
Der Grund warum wir noch mit der älteren Version arbeiten, ist der, dass wir ein Shopupdate
von 6.4.3 auf 7.2 gemacht haben.

Mit allen Haken und Ösen und Stolperfallen. Ehrlich gesagt, wenn ich vorher gewusst hätte,
wie viel beim Apex Theme schlechter umgesetzt ist, als beim Wave Theme, dann hätten wir es bei 6.5.x gelassen. Vielleicht mache ich darüber mal einen extra “Erfahrungsbericht”.

Da waren so einige Dinge, die wir dann quasi über unseren Dienstleister fixen lassen haben, weil
sie im Standard-Apex Theme, gerade in der Mobilansicht, einfach so nicht gehen.
Dinge, die erst auffallen, wennman das ganze dann umsetzt und benutzt.
Als Beispiel z.B. der Modal Zoom, der im Apex Theme benutzt wurde.
Meiner Meinung nach ist die Zoom-Funktion völlig unintuitiv umgesetzt, keiner doppeltippt auf dem Smartphone um etwas zu vergrößern. Normale Benutzererfahrung ist “Pinch-to-Zoom”.

Artikel mit mehreren Bilder? Ja, in der Desktop-Ansicht werden die Vorschaubilder links neben dem Hauptbild angezeigt. Wenn der Viewport auf eine normale Smartphonegröße umschaltet sind die Vorschaubilder auf einmal komplett weg, man sieht überhaupt nicht mehr auf den ersten Blick, dass es mehrere Bilder gibt.

Bilder nur noch aus dem Master laden und nicht mehr aus dem generated als verkleinerte / komprimierte Version? Kann man machen, muss man sich aber nicht wundern, wenn die Ladezeiten bei schlechter Mobilfunkverbindung schlecht sind…

Aber wir wollten es dann gleich modern und zukunftssichert haben, also alles neu, Theming, Module nach Twig umstricken, etc.
Und nachdem wir aus Zeitgründen dann den Livegang schon 2 mal verschieben mussten, musste nun erst einmal der neue Shop online, ohne vorher noch das update auf die neuesten Modulversionen zu machen.

Aber wie gesagt, danke für euer Feedback, ich schau mal ob das Problem nach dem Update dann weg ist.

Viele Grüße,
Michael

1 Like
6

Ja, bitte! Das würde uns sehr weiterhelfen. Wir betreiben ja selbst keinen Shop. Also sind solche Erfahrungen für uns immer sehr wichtig. Auch gern jederzeit direkt an [email protected] oder in den Bugtracker (da kann man ja auch Features anfragen)

Ich nehme das mal auf. Wie sieht es denn bei den anderen Zoom-Modi aus?

Viele Grüße,

Sven

7

Hallo @naledre und @MatsW ,

so, ich habe das Paypal Modul nun auf die aktuelle Version gebracht, mal gucken wie das ganze so läuft.

Nichts desto trotz ist es schon erstaunlich, das es seit der API v2 gehäuft immer mal wieder Probleme gibt.

Ich will ja nicht unken das früher alles besser war, aber mit dem alten Paypal (nicht Check-Out) Modul und der API v1 hat alles immer hervorragend zuverlässig funktioniert.
Da gab es eigentlich nie Probleme.

Naja, wie gesagt, ich werde mal beobachten.
Bei der Gelegenheit testen wir auch noch einmal GooglePay / ApplePay, das hatte damals auch nicht funktioniert wie es sollte.

An @SvenBrunk

Erfahrungsbericht werde ich gerne einmal nachreichen, da waren doch so einige Dinge,
die im Apex meiner Meinung nach nicht gut umgesetzt sind.
Im Moment fehlt da die Zeit, wir haben natürlich wie alle Weihnachtsgeschäft am laufen und dann auch noch so ungeliebte Dinge wie Inventur :joy:

Kommt aber auf jeden Fall noch nach.

Bei den anderen beiden Zoom-Modi sind im Smartphone Viewport auch keine Vorschaubilder bei mehreren Bildern vorhanden.
Beim Lupen-Zoom ist in der Mobilansicht gar kein Zoom möglich, weil die Zoom Box rechts neben dem Artikelbild außerhalb des Viewports liegt.

Viele Grüße,
Michael

1 Like
8

Hallo @SvenBrunk und @Mario_Lorenz ,

ich muss mich hier noch einmal reinklinken wegen Paypal und OXID Shop.

Wir haben seit dem Update auf den OXID Shop 7.2 und der PayPal Schnittsteller aus der 3.x Reihe echt haufenweise Probleme mit Bestellungen die nicht sauber durchlaufen.

Das ist schon nicht mehr ärgerlich, das ist echt schon problematisch.
Aktuell nutzen wir den Shop in der Version 7.2 und die Schnittstelle mit der Version 3.5.2

Gerade gestern hatten wir auch wieder einen Kunden mit 5 Bestellversuchen.
3 davon mit Paypal, Bestellstatus “Error”, 2 davon mit Apple Pay, eine davon mit Status “Error”
die andere mit Status “not finished”

Bei der Bestellung Apple Pay mit Status not finished ist im Reiter vom Paypal Checkout aber eine Zahlung mit Transaktions-ID Sichtbar.

Bei der Bestellung ApplePay mit Status Error ist ebenfalls eine Zahlung mit Transaktions-ID sichtbar.

Bei den 3 Paypal Bestellungen ist im Reiter Checkout nichts sichtbar, dort sind keine Transaktionen ersichtlich.

Komischerweise sind aber vom Shop nach Paypal falsche Bestellnummern für die Zahlungen zugeordnet.

Da passt echt nichts zusammen und macht massiv Probleme.
Die Bestellungen hatten die Nummern:

886379 → Apple Pay → Status “not finished” → Transaktions-ID und Zahlung bei Paypal vorhanden
886378 → Apple Pay → Status “Error” → Transaktions-ID und Zahlung bei Paypal vorhanden
886377 → Paypal → Status “Error” → Keine ID und Zahlung vorhanden
886376 → Paypal → Status “Error” → Keine ID und Zahlung vorhanden
886375 → Paypal → Status “Error” → Keine ID und Zahlung vorhanden

Bei Paypal im Verlauf sind jedoch die Bestellungen 886377 und 886378 als Bestellnummer übermittelt.
Die Transaktions-ID bei den Bestellungen sind jedoch passend mit den bei OXID den Bestellungen 886378 und 886379 angelegten ID im Paypal Checkout-Reiter.

Also irgendwas komplett durcheinandergewürfelt.

Das Log sagt nichts darüber aus. Lediglich bei den erfolgreich abgeschlossenen Zahlungen sind Einträge mit Post/Get im Log.
Bei den abgebrochenen Paypal Bestellungen findet sich immer nur

[2025-12-11 22:15:16] PayPal Payment Logger.DEBUG: finalizeOrder
[2025-12-11 22:15:29] PayPal Payment Logger.DEBUG: finalizeOrder
[2025-12-11 22:15:53] PayPal Payment Logger.DEBUG: finalizeOrder

Diesen massiven Probleme hatten wir vor dem Shop-Update mit der Shop Version 6.4.3 und der Schnittstelle 2.3.4 überhaupt nicht. Gelegentlich kam das mal vor, aber eher die Ausnahme.

Ich habe auf dem Server mal in das access.log geschaut, bei einigen Zeiten wo Paypal nicht durchging findet man so etwas im Log:
xx.xx.xx.xx - - [11/Dec/2025:22:15:41 +0100] “POST /index.php?cl=oscpaypalwebhook HTTP/1.1” 404 7951 “-” “PayPal/AUHR-1.0-1”

Bei den fehlerhaften Apple Pay Zahlungen ist im OXID Shop so etwas zu finden:
[2025-12-11 22:16:33] OXID Logger.ERROR: Controller method is not accessible: OxidEsales\EshopCommunity\Core\Controller\BaseController::finalizeapplepay

Im Paypal Log sind diese Zahlungen aber sichtbar und auch mit Transaktions-ID eingegangen.

Dann hat man zwischendurch wieder 5 Bestellungen, die einfach so ohne Probleme laufen, egal ob PayPal oder Apple / GooglePay und dann wieder so extrem unzuverlässig.

Ich bin langsam echt am verzweifeln und ich glaube auch, dass uns das mittlweile auch echt
finazielle Eibußen bringt, weil Kunden dann komplett abspringen.

Grafana vom Server zeigt im übrigen keine nennenswerte Serverauslastung zu den Zeiten, an denen die Schnittstelle spinnt.

Hat hier irgendwie irgendwer noch eine Idee? Bin mittlerweile soweit, Apple und Googlepay abzuschalten und auf eine alte Schnittstelle downzugraden, in der Hoffnung das die Zuverlässig ist.

Viele Grüße,
Michael

9

Hallo @djelo ,

folgender Vorschlag: In den Moduleinstellungen findest Du am Ende eine Option für das Debug-Level. Stelle das auf “Debug”. Nun werden in den Logs alle Requests geloggt.
Sammel parallel auch das Apache-Log.
Wenn Du wieder so einen Fall komplett per Log dokumentiert hast, stelle beides via https://bugs.oxid-esales.com/ uns und dem Support zur Verfügung. Dann brauchst Du es hier nicht im Klartext zu teilen.

Hier zwei Sätze, wie Du die Logs “verstehen” kannst:

Der Kunde geht durch den Checkout. Das siehst Du anhand des Apache-Logs und den ersten Authorize-Requests im PayPal-Log. Je nachdem wie sich der Kunde nun verhällt, so wie auch seine Karten gedeckt sind entstehen jetzt Requests in Richtung “Capture”. Im Apache-Log siehst Du das PayPal parallel nun beginnt per Webhook “zu informieren”.

Falls der Kunde z.B. frühzeitig den Checkout-Flow verlässt, weil er denkt, das er mit der Zahlung durch ist, greift jetzt der Webhook ein und bringt die Bestellung zum Abschluss.

Es kann auch vorkommen, das der Webhook schneller ist, als der Kunde durch den Checkout durch kommt, auch das lässt sich dann gut erkennen.

Bis später,

Grüße, Mario

10

Hallo @Mario_Lorenz ,

danke für den Vorschlag, ich habe jetzt einmal exemplarisch eine Bestellung von gestern herausgesucht und entsprechende Zeilen aus dem access.log / paypal.log und 2 Screenshots im Bugtracker hinterlegt.

Seltsamerweise ist trotz Einstellung auf Debug nichts im Log zu sehen außer PayPal Payment Logger.DEBUG: finalizeOrder

Das was mich so “bekloppt” macht ist einfach die Tatsache, dass wir seit dem neuen Onlineshop und der neueren Version bzw. jetzt ganz aktuellen Version des Paypal Checkouts jeden Tag Kunden haben, die 2, 3 manchmal auch mehr Versuche haben, bis Paypal dann durchgeht oder auf eine andere Zahlungsart gewechselt wird.

Ich weiß halt nicht, ob das an der neuen Gestaltung des Checkout liegt, das die Kunden das Pop-Up wegklicken und nicht mehr wiederfinden oder was auch immer.

Ich weiß nur, dass wir diese Probleme mit dem alten Shop 6.4.3 und der alten Paypal Checkout 2.3.4 nicht hatten. Das war dort eher die Ausnahme, das dort Paypal nicht funktioniert hat.

Seit dem Shop Update und der neueren Version haben wir jeden Tag Probleme. Auch teilweise, dass Shop-Bestellungen gar nicht angelegt werden und trotzdem eine Zahlung per Paypal eingeht.
Das haben wir heute gleich 2 Mal gehabt.

Das macht einfach extrem viel zusätzlich Arbeit, wenn man morgend erst einmal alle Bestellungen checken muss, ob eine Zahlung da ist oder ob Zahlungen da sind, für die es keine Bestellung gibt.

Viele Grüße,
Michael

11

Liebe Mitlesende,
wir haben heute Version 3.5.3 bereitgestellt.
Wichtigster Punkt neben weiteren Fixes: Deutliche Erhöhung der Geschwindigkeit im Checkout. Dadurch Senkung der Fehler- und Abbruchquote.

Viele Grüße,

Mario