Fehler im Paypal Checkout 3.5.1

Hallo an das Forum,

nachdem ich nun das PayPal Checkout auf die aktuelle Modulversion 3.5.1 gebracht habe,
um eventuelle Fehler / Bestellabbrüche weg zu bekommen tut sich nun das nächste Problem auf:

In der aktuellen Schnittstelle ist es nicht mehr möglich ungerade Artikelmengen zu bestellen :distorted_face:

Wir bieten bei uns im Shop Tuch als Meterware an und der Shop ist so eingestellt,
dass Kunden auch z.B. 0.4m von einem Tuch bestellen können.

Hat bisher immer funktioniert, gerade auch noch einmal im alten Shop 6.4.3 mit Checkout 2.3.4 getestet, keinerlei Probleme dort.

Mit Shopversion 7.2 / Checkout 3.5.1 geht es nicht mehr.
Paypal Login-Fenster geht auf, schliesst sich nach einigen Sekunden wieder und man landet wieder auf der Shopseite mit der Bestellzusammenfassung.

Fehler im Log:
Error Details:
[{“field”:“\/purchase_units\/@reference_id==‘OXID_REFERENCE’\/items\/0\/quantity”,“value”:“0.4”,“location”:“body”,“issue”:“INVALID_PARAMETER_SYNTAX”,“description”:“The value of a field does not conform to the expected format.”}]

Also ganz klar ein Problem mit der 0.4

Eintrag im Bugtracker dazu ist gemacht (ID 0007865)

Warum werden eigentlich mit neuen Modulversionen Dinge kaputt gemacht, die vorher funktioniert haben? So mal ganz generell gefragt. Wie kann sowas passieren?

Eigentlich sollte man sich darauf verlassen können, das Dinge, die immer funktioniert haben auch weiterhin keine Probleme machen.

Aber hey, dafür funktioniert jetzt GooglePay und ApplePay, man muss ja auch die psoitiven Seiten erwähnen :wink:

Viele Grüße,
Michael

Nachtrag zum Fehler:

Heute im Bugtrack Eintrag eine neue Notiz mit von @Mario_Lorenz , die da auf gut Deutsch bedeutet:

In der API Dokumentation von Paypal steht für Menge muss ein string sein und eine ganze Zahl.
Die einzige Lösung kann dann nur sein, keine Artikel mit ungeraden Mengen anzubieten.

Aähh, nein, nicht einverstanden.
Ganz ehrlich, weder mit der alten Paypal Schnittstelle noch mit der alten Paypal Checkout Schnittstelle Version 2.3.4 in unserem alten Shop 6.4.3 gab es zu keine Zeit irgendein Problem
mit nicht ganzzahligen Bestellmengen.

Erst seit dem Umstieg auf Shop-Version 7 mit Paypal Checkout Versionszweig 3.x.x gibt es dieses Problem.
Es muss also irgendwo hausgemacht sein.

Ergänzung:
Gerade einmal getestet, in der Paypal Checkout Reihe 2.x.x gehen Bestellungen mit ungeraden Mengen bis zur Version 2.5.0
Ab der Version 2.5.1 geht das Paypal Login Fenster nicht mehr auf und es kommt eine Fehlermeldung “Autorisierung der Zahlung fehlgeschlagen. Bitte prüfen Sie Ihre Eingabe!”

Es muss also in der 2.x.x Serie von 2.5.0 auf 2.5.1 so verändert sein, das der Fehler entsteht.

In der Paypal Checkout Reihe 3.x.x geht das Bestellen von nicht ganzzahligen Mengen bis zur Version 3.4.0
Ab der Version 3.4.1 geht das auf einmal nicht mehr, also muss dort irgendetwas anders sein.

Sollte also eigentlich zu fixen sein. An der Paypal API kann es nicht liegen, da nach einem Downgrade die Bestellung von ungeraden Mengen wieder möglich ist.

Ganz ehrlich: Ich bin mittlerweile richtig enttäuscht von OXID.
Wir haben nach der Änderung der Lizenzbedingungen lange überlegt, was wir machen.
Wechsel zu Shopware, Wechsel zu Shopify, Wechsel irgendwo hin…
Und haben uns letztendlich dann doch entschieden bei OXID zu bleiben, die neuen Lizenzbedingungen zu akzeptieren und dann die monatliche Lizenzgebühr zu zahlen um ein Update auf die Version 7.2 machen zu können.

Finden dann auch eine gute Agentur, die das komplette Template und diverse Fremdmodule auf Twig aufsetzt, unsere Anpassungen einbaut.
Haben eine nicht geringe Summe investiert, um dann auch in Zukunft einen modernen und sicheren Shop zu haben.
Und dann kommt eine Ernüchterung nach der anderen.
-Ein Apex Theme, was sich anscheinend nie einer Qualitätskontrolle auf einem echten Mobilgerät unterzogen hat (keine Miniaturbilder bei mehr als einem Produktbild)

  • Eine Zoom-Funktion die von Pinch to Zoom auf Tap to Zoom umgebaut wird, was kein Mensch benutzt und null intuitiv ist.
    Keine App nutzt sowas, echt nicht. Schon mal ne Bildbearbeitung auf dem Handy gemacht?
    Was machste da zum vergrößern? Doppeltippen oder auseinanderziehen?

  • Lange Ladezeiten der Bilder, da die Bilder nicht mehr verkleinert aus dem generate gezogen werden, sondern das Masterbild benutzt wird

Alles so Dinge, die wir dann durch unsere Agentur (natürlich gegen Geld) haben fixen lassen.
Dinge, die vorher selbstversändlich waren und gut funktioniert haben.
Wird einfach weggeschmissen und schlechter gemacht.

Und schlussendlich dann ein PayPal Checkout 3.x.x, welches auch auf einmal viele nicht beendete Bestellungen generiert, teilweise versuchen Kunden 4, 5 mal mit Paypal zu zahlen bis es dann geht.
Leider keine Fehlermeldung im log, andere Zahlungen laufen ohne Probleme. Also die Suche nach der Nadel im Heuhaufen.

Schlussendlich findet man dann einen sicheren Grund, warum einige Bestellungen nicht durchlaufen und bekommt dann als Antwort: Ja ist so, musste halt nicht so anbieten.

Etwas, was vorhher funktioniert hat. Wie so viele andere Sachen, die auf einmal nicht mehr so funktionieren wie in der 6er Shop-Reihe.

Kann doch echt nicht euer Ernst sein.
Hätte ich das alles vorher geahnt, dann hätte allerhöchstens ein Update auf die 6.5er Version gemacht oder doch ein anderes Shopsystem genommen.

Aktuell haben wir mit dem neuen Shop mehr Frust als Freude und das ich echt schade.
Ich habe OXID immer gemocht, aber so langsam hat man keine Lust mehr ständig auf Fehlersuche zu gehen und Zeit dafür zu verschwenden, weil wieder etwas nicht so funktioniert wie es soll.
Aber nun ist das Kind halt in den Brunnen gefallen, das Geld ist investiert und wir müssen (vielleicht auch nur vorerst) damit leben und das beste draus machen.

Fakt ist auf jeden Fall:
Wenn mich jetzt heute jemand fragen würde, ob er zu OXID kommen soll oder ein Update auf die aktuelle 7er Version machen soll, würde ich ganz klar davon abraten.
Da ist einfach noch zu viel was nicht hinhaut und hier im Forum ist ja auch leider nur noch wenig Austausch.
Und ich denke, das ist nicht eure Intention, ein Shopsystem plus Module zu Entwickeln, was man nicht weiterempfehlen möchte.

Viele Grüße,
Michael

Hallo Michael,

ich verstehe deine Frustration und das ist natürlich Mist.

Das Ding ist: Dezimalmengen bei Zahlungsanbietern wie PayPal sind im E-Commerce insgesamt eher die Ausnahme. Die meisten Zahlungsgateways sind primär auf ganzzahlige Mengen ausgelegt – das ist nicht spezifisch für OXID oder PayPal, sondern eigentlich ein branchenweiter Standard. Deshalb berücksichtigen E-Commerce-Systeme das oft gar nicht als Standard-Use-Case, sondern eher als Spezialfall. Das erklärt auch, warum OXID das wahrscheinlich nicht als Priorität behandelt.

Aber hier ist das Gute: Es gibt dafür eine bewährte Lösung, die im E-Commerce eigentlich Standard ist. Statt mit 0,4 m zu arbeiten, würdest du einfach intern mit Zentimetern rechnen – also 40 cm. Das funktioniert nicht nur mit PayPal, sondern mit wirklich allen Zahlungsanbietern problemlos. Menge ist dann 40 (ganzzahlig), die Einheit ist cm, und der Preis pro Einheit ist einfach der Meterpreis geteilt durch 100.

Wir haben mehrere Kunden, die ebenfalls Meterware verkaufen, und ehrlich gesagt: die arbeiten alle über Zentimeter. Das ist nicht irgendein Workaround, sondern eigentlich der Standard-Ansatz.

Falls du nicht auf cm umstellen möchtest, gäbe es noch einen anderen Ansatz: Die sogenannte “Single Line Item”-Lösung. Dabei würde der gesamte Warenkorb als ein einzelner Posten an PayPal übermittelt. Das ist ein technischer Ansatz auf Modulebene, würde aber auch Anpassungen erfordern.

1 Like

Hallo @MatsW ,

danke für deine Antwort. Was mich eben so wurmt ist, das wir den OXID Shop inkl. Paypal seit 2016 nutzen. Bisher gab es nie Probleme mit unserer Konfiguration.

Dann machste ein Update, weil der Shop sicher und von der Laufzeitumgebung her aktuell sein soll und kriegst auf gut Deutsch gesagt nur “auf die Fresse” weil zig Sachen auf einmal nicht mehr so gehen wie es jahrelang usus war.

Das frustriert echt.

Ich hab gerade schon eine Mail bekommen, das ein neues Release vom Paypal Modul draußen ist,
was wohl ungerade Artikelmengen abfängt und dann den Warenkorb nicht mehr an Paypal überträgt um das Problem zu vermeiden.

Ich habe @Mario_Lorenz auch falsch verstanden, es las sich so, als ob wir einfach darauf verzichten sollen ungerade Meter anzubieten, im Nachhinein stellt sich heraus, das das als Lösungsansatz für den Modulfix gedacht war.
@Mario_Lorenz Falls das irgendwie blöd rüberkam und Du dich durch das vorherige posting auf den Schlips getreten fühlst, entschuldige ich mich. Ich habe das dann einfach nur falsch verstanden.

Viele Grüße,
Michael

@djelo , @MatsW : Guten Morgen,

es ist doch schön, wenn sich Missverständnisse von allein klären :wink:. Die Funktions-Erklärung von @MatsW trifft es genau. Auch der Ansatz von “m” auf “cm” zu gehen ist pragmatisch smart. Dennoch war ich sehr überrascht, als über den BugTracker die Fehlerbeschreibung reinkam und wir es nachvollzogen haben. Also hier noch einmal auf Deutsch, was wir in der 3.5.2 angepasst haben: Wir prüfen nach, ob sich im Warenkorb Artikel mit Mengenangaben befinden, die Dezimalzahlen enthalten. Wenn ja, dann stellen wir die Artikel-Positionen PayPal nicht per API bereit. Sprich der Shop-Kunde und der Shop-Besitzer sehen im PayPal Backend nicht, welche Artikel im Warenkorb waren. Das Geld fließt trotzdem. Nach der Rechtslage könnte es schwierig werden, sollte ein Kunde mit einer Position der Lieferung nicht zufrieden sein und daraufhin einen Nachlass, Rückabwicklung etc. haben zu wollen. PayPal wüsste dann nicht um was es konkret geht. Ich weiß noch nicht, was das wiederum bedeutet. Ich kenne noch keinen Präzendenz-Fall dazu. Ich weiß nur, das alle Payment-Provider bestrebt sind, diese Informationen zu haben, um sicher zu sein und agieren zu können.
Das erklärt vielleicht auch, warum es in einem Payment-Modul von 2016 damit noch keine Probleme gab, einfach weil das Thema da noch gar nicht existierte.
Nun gibt es also für diesen konkreten Fall im PayPal-Modul eine Ausnahme.
Wir werden die Entwicklung aber weiter beobachten.

Einen guten Wochenstart an Euch.

1 Like

Hallo @Mario_Lorenz ,

danke für Deine Antwort und die Erklärungen!
Im Stage Shop und Sandbox Mode funktioniert alles, ich zieh das im Laufe des Tages oder Morgen in den Live Shop.

Was die Rechtslage angeht: Hm, kann ich auch schlecht einschätzen. Aber im Endeffekt ist ja
Auschlaggebend die Bestellung / die Rechnung.
Bei anderen Zahlungsanbietern wird ja auch kein Warenkorb übertragen, die einzelnen Artikel
sind ja auch für die Abwicklung der Zahlung nicht relevant.

Ich würde das sogar so weit gehen, das es eher nach DSGVO rechtlich fraglich ist, ob Warenkorbinhalte nach PayPal übertragen werden dürfen.
Es sind ja eindeutig personenbezogene Daten.
Und wenn ich mir überspitzt gesagt das 10x was bei Orion bestelle, geht PayPal sicherlich nicht der Inhalt des Paketes etwas an. Sicherlich etwas überzogen das Beispiel, aber ich denke Du verstehst das.

Den konkreten Fall, das man einfach einen Fall bei PayPal eröffnet hat, ohne vorher mit uns zu kommunizieren, hatten wir in den ganzen Jahren (seit 2002) übrigens erst 3 Mal.
Wir regeln das eigentlich immer kundfreundlich und im Zweifel im Sinne des Kunden, dafür ist uns unser guter Ruf einfach zu wichtig. Wird auch tatsächlich nicht ausgenutzt.

Ich danke Dir auf jeden Fall für die schnelle Lösung!

Achso: Der Ansatz von laufenden Metern auf cm zu wechseln ist bei uns nicht so trivial.
Wir haben einige sehr spezielle und kostspielige Tücher, welche meistens als 0,1 bis 0,5m bestellt werden, aber wiederum auch andere Tücher von denen dann 22,5m benötigt werden.
Erzähl mal einem Kunden, der seit 2003 in unserem Shop 22,5m bestellen kann, dass er auf einmal im Mengenfeld 2250 als Menge für Zentimeter eingeben muss.
Die Begeisterung wird sich in Grenzen halten :joy:

Viele Grüße,
Michael

Hier eine Liste mit Gründen:

1. Käuferschutz-Entscheidungen Wenn ein Käufer einen Dispute öffnet (“Ware nicht erhalten” oder “nicht wie beschrieben”), können Paymenter mit den Artikeldaten viel besser entscheiden. Sie sehen genau, was bestellt wurde, zu welchem Preis, und können das mit dem Streitgrund abgleichen.

2. Transparenz für den Käufer In der Paymenter-Oberfläche und in den Transaktionsdetails sieht der Kunde, was er gekauft hat. Das schafft Vertrauen und reduziert “Ich erkenne diese Zahlung nicht”-Beschwerden.

3. Steuer- und Compliance-Anforderungen Je nach Land und Produkttyp gelten unterschiedliche Steuerregeln. Paymenter muss teilweise nachweisen können, welche Art von Waren verkauft wurden.

4. Seller Protection Auch für dich als Händler: Wenn du detaillierte Artikeldaten übermittelst, stehst du bei Disputes besser da. Paymenter können nachvollziehen, dass du eine legitime Bestellung mit korrekten Details verarbeitet hast.

Hallo @Mario_Lorenz ,

bis auf den Punkt Käufertransparenz, weil der Kunde die gekauften Produkte erkennt, stimme ich da nicht so zu.

Paymenter ist nichts anderes wie ein Zahlungsdienstleister. Er hat nur dafür zu sorgen, dass ich Warenkörbe bei Händler XY bezahlen kann.

Den Paymenter geht es schlicht und ergreifend nichts an, was der Kunde irgendwo kauft.
Sensibles Beispiel: Du leidest an einer Krankheit und über im Internet gekaufte Medikamente sich ein Rückschluss daraus ziehen, was für Du hast.

Oder viel banaler: Was geht Paypal an, welche Unterwäschegröße eine Frau trägt, wenn sie Wäsche im Internet kauft.

Wenn es um Käuferschutz Entscheidungen geht, muss man im Zweifelsfall sowieso Bestellbestätigungen, Rechnungen und Versanddaten als Nachweise einreichen.

Steuer: Dafür bin ich als Händler zuständig, die entsprechenden Umsatzsteuern korrekt zu berechnen und abzuführen, nicht Paypal.

Sehe ich alles nicht so.
Wenn Du irgendwo per SEPA Lastschrift bezahlst, fungiert Deine Bank ja auch nur als Diensleister für die Zahlung und sieht nur wo Du einkaufst, aber nicht welche Artikel.

Für meine Verhältnisse ist Paypal da etwas zu neugierig.
Wir bieten auch Kreditkartenzahlungen über Unzer an, dort werden auch keine Produktdaten / Warenkörbe übertragen.

Wie dem auch sei.
Interessanterweise funktioniert aber eine ältere Schnittstellenversion zuverlässig.

Ich habe am Montag ein Downgrade auf die Paypal Checkout Version 3.3.4 gemacht, das ist die letzte Version, die anscheinend keine Warenkörbe nach PayPal überträgt und somit auch kein Problem mit ungeraden Artikelmengen hat.

Diese Version läuft bisher absolut unauffällig, eine einzige Zahlung, die als not finished Status versehen war, dafür viele andere Bestellungen, die ohne Probleme gleich beim ersten Mal durchlaufen, wie es sein muss.

Keine 5 mal angefangenen und abgebrochenen Bestellungen mehr, keine stornierten Bestellungen, keine Zahlungseingänge für nicht im Shop vorhandene Bestellungen.

Fazit:
Die neuen Checkout Schnittstellen Versionen laufen einfach nicht zuverlässig, zumindest bei uns nicht. Ich habe keine Ahnung wie viele Shops da draußen schon auf Version 7 mit der letzten Checkout Schnittstelle gelaufen sind, aber für uns war das einfach Mist.
Nichts hat so funktioniert wie es sollte und ich glaube, dass hat uns real Geld und Kunden gekostet, weil das nicht zuverlässig funktioniert hat.

Was mir sofort aufgefallen ist:
Die alte 3.3.4 leitet nach “Jetzt Kaufen” im selben Browserfenster nach Paypal weiter, Log-In und Rückleitung geht problemlos und schnell.

Die neuen Versionen öffnen ein Pop-Up für den Log-In bei Paypal und die Shop-Seite bleibt im Hintergrund offen.
Das Prozedere dauert im Vergleich deutlich länger, bis man sich einloggen kann und die Zahlung dann letztendlich auslösen kann.

Nicht mit der Stoppuhr gemessen, aber sehr sehr deutlich langsamer als die alter Weiterleitung nach Paypal ohne Warenkorbübertrag.

Wir lassen nun gezwungenermaßen die alte Version laufen, weil ich einfach keine Zeit und Lust habe, jeden Tag alle Bestellungen durchzugucken, Paypal zu checken ob Gelder geflossen sind, für die es keine Bestellung gibt und mich über abgebrochene Bestellungen und verlorene Kunden zu ärgern.

Das ganze ist für uns einfach im höchsten Maße ärgerlich. Ich kann es nicht anders sagen, aber im Nachhinein, wäre es vielleicht wirklich klüger gewesen den Shop auf Version 6.5 zu lassen oder auf ein anderes Pferd zu setzen.
Schade, aber so fühlt es sich nunmal an. Obwohl ich OXID als Shopsystem einfach mag und seit 2016 damit immer gut gefahren bin.

Viele Grüße,
Michael