Neu PayPal Plugin v1.07 Open Beta

[spaxxilein]

Ist es normal, dass die von Paypal erzeugte Email keine Beschreibung für die Zahlung enthält? Wir würden uns logischerweise wünschen, dass dort die Liste der entsprechend erworbenen Artikel steht.

 

[ThomasE24]

Wir haben ebenfalls das Plugin drauf in der Hoffnung dass der Bug eliminiert wurde, dass PayPal Zahlungen gebucht wurden ohne dass wirklich eine Bestellung erzeugt wurde.



Es geht um die langen Bestellnummern (mit dem Zeitstempel) und dem 2 HEX Zahlen am ende.
Dieser Bug kommt zwar selten vor, aber wir hatten vorgestern wieder den gleichen.

Das Problem ist hier, dass wir selbst das gar nicht erfahren bis wir vom Kunden angeschrieben werden, wo denn der Artikel bleibt.

 

[Dustin]

Den Bug kann ich bestätigen. Ist uns auch aufgefallen.

 

[Dustin]

Nochmal zu dem Bug. Mir ist heute aufgefallen bei einer Kundin bzw. Bestellung. Das hier auch das Tracking an GA ausgeführt wird obwohl die Bestellung nicht durchgeführt wurde.

Siehe Screenshot.

Es scheint das eine Bestellung generiert und abgefeuert wird sobald Paypal die Zahlungsart ablehnt. Es passiert wenn der Kunde Rechnungskauf wählt zb. und er dann aber seitens Paypal abgelehnt wird.

 

[Dustin]

Keiner eine Idee dazu? wir haben damit echt probleme vorallem mit affilinet weil dort Bestellungen getrackt werden die aber nicht abgeschlossen sind!

 

[x86]

@Dustin Kannst du sagen auf welchen Bestellschritt die Kundin in diesem Fall den zurückgeleitet wird u. welche
Shop Version habt Ihr momentan im Einsatz?

Grüße

 

[Dustin]

Naja das muss ja sehr am Ende sein wo die Paymentwall eingeblendet wird und dann weiter zu Paypal geht.

Shop Version 4.05.3

 

[microline]

Diesen Bug kann ich auch bestätigen, schon bei Version 1.06
Die Bestellung läuft komplett durch bis einschliesslich .bestellabschluss.php, es wird jedoch keine Bestellung erzeugt.

Für den Kunden sieht alles normal aus, es fehlt jedoch die Email mit der Bestellbestätigung.

 

[Dustin]

@jtl was sagt ihr dazu? Es ist garnicht auszumalen wieviele Bestellungen dadurch durch die lappen gehen.

 

[Dustin]

Komisch das hier noch keine Reaktion von JTL kam.

 

[JulianG]

Mit der Shop-Version 4.05.3 könnt ihr auch schon die PayPal Pluginversion 1.08 (released mit 4.06) einsetzen. Download unter: http://downloads.jtl-software.de/shop/plugins/
Bitte immer die Integrationsanleitung beachten: http://jtl-url.de/paypaldocs

Der Fehler mit den temporären Bestellnummern sollte darin nicht mehr auftreten, siehe: https://issues.jtl-software.de/issues/SHOP-917

Ein Bestellabschluss findet nur statt, wenn von PayPal eine erfolgreiche Meldung nach dem ExecutePayment (wird beim Klick auf Zahlungspflichtig Bestellen ausgelöst) zum Shop zurück kommt.

Solltet ihr mit der aktuellen 1.08 Version und 4.05.3 oder 4.06 noch Probleme (auch falls diese zwei doch weiterhin auftreten sollten, müssten wir dann individuell nochmals unter die Lupe nehmen) mit den PayPal Bestellungen haben, bitte eine eMail mit folgenden Infos an paypalplugin@jtl-software.de

- Problembeschreibung
- Shop-Domain
- temporär gültige Backend-Zugangsdaten (Administrationsbereich /admin)
- Betroffene, möglichst aktuelle, Beispielfälle mit möglichst vielen Informationen (Shop-Bestellnummer, Bestellzeitpunkt, Zahlungsstatus bei PayPal, etc.)
- ggf. Shop-Version und Plugin-Version (zum Zeitpunkt der Bestellung)

 

[Dustin]

Hi Julian leider ist das nicht die erhoffte Antwort da wir ja schon die 1.08 und Shop 4.05.3 einsetzen.

Ich werde dir jetzt eine Mail an die angegebene Adresse schicken.

 

[Loads]

Ist in der neuen Version auch das Problem angegangen worden, dass Kunden, die per Paypal Express zahlen, stets mit Anrede "Herr" in der Wawi landen, auch wenn es sich um Damen handelt?

Dieser Bug ist mir auch aufgefallen!
Ist in der Version 1.08 immer noch der Fall.
Die Kundinnen denken bestimmt wir hätten sie nicht alle weil wir sie mit "Herr" anreden.
Wann wird das gefixt?

 

[JulianG]

@Loads Das Problem hier ist anscheinend, dass doch an einigen Stellen im Shop eine Anrede vorausgesetzt wird. Es sind also andere Punkte vorher zu klären und überarbeiten, bevor dies geklärt werden kann. Leider schickt PayPal keine Anrede mit, deshalb wird so lange "Herr" als Standard gesetzt. Verfolgen könnt ihr das Problem unter folgender URL: https://issues.jtl-software.de/issues/SHOP-118

 

[Loads]

Hallo Julian,

beim Shop 3 ist mir das allerdings nicht aufgefallen.
Erst seitdem wir auf Shop 4 umgestiegen sind.

 

[JulianG]

@Loads Das Problem tritt auch im Shop4 nicht auf mit PayPal, PayPal Basic, PayPal PLUS und PayPal Ratenzahlung.
Nur PayPal Express, was es in Shop3 noch nicht gab, hat dieses Problem, da hier die Kundendaten nicht aus dem Shop kommen, sondern von PayPal übernommen werden (müssen!) und PayPal sendet keine Anrede mit.

 

[bbfdesign]

Wie sieht die Unterstützung zu PHP 7.1 aus? Folgendes Problem ist bei PHP 7.1 aufgetreten:

Sobald der Cache gelöscht wird, ist zwar das Plugin in der Pluginverwaltung vorhanden und kann hier auch getestet werden, jedoch kann man in den Versandarten kein PayPal Plus auswählen. Es verschwindet einfach. Weiterhin konnte ich folgenden Fehler in den error logs finden: Fatal error: Uncaught Error: Wrong parameters for Exception([string $message [, long $code [, Throwable $previous = NULL]]]) in /var/www/virtual/.../htdocs/includes/plugins/jtl_paypal/version/106/paymentmethod/class/PayPalPlus.class.php:569 Stack trace: #0 /var/www/virtual/.../htdocs/includes/plugins/jtl_paypal/version/106/paymentmethod/class/PayPalPlus.class.php(569): Exception->__construct('Unhandled payme...', 'approved') #1 /var/www/virtual/.../htdocs/includes/bestellabschluss_inc.php(922): PayPalPlus->preparePaymentProcess(Object(Bestellung)) #2 /var/www/virtual/.../htdocs/bestellabschluss.php(99): setzeSmartyWeiterleitung(Object(Bestellung)) #3 {main} thrown in /var/www/virtual/.../htdocs/includes/plugins/jtl_paypal/version/106/paymentmethod/class/PayPalPlus.class.php on line 569

Darauf hin habe ich ein Ticket eröffnet und bekam zunächst diese Rückmeldung.

ja da haben wir häufiger meldungen erhalten, bitte max. php 7.0.x nutzen.

Da habe ich als Anmerkung darauf geantwortet, dass PHP 7.0 faktisch nahezu EOF ist (siehe angefügtes Bild von der offiziellen PHP Seite die hier zu finden ist: http://php.net/supported-versions.php). Die Unterschiede von PHP 7.0 => 7.1 sind ja relativ überschaubar: http://php.net/manual/de/migration71.incompatible.php

Zudem ist ja PHP 7.1 schon seit dem 01.12.2016 veröffentlicht und somit nichts Top aktuelles...

Auf jeden Fall habe ich dann dieses im Ticket angemerkt und bekam dann diese Rückmeldung:

ich denke das es den Entwicklern durchaus bewusst ist, aber bitte haben Sie verständnis dafür da aufgrund der Änderungen bereits von 7.0.x zu 7.1. dazu nicht mal eben ein Hotfix bereitgestellt werden kann oder der Shop in den vorhandenen versionen umgeschrieben wird. Ich denke doch das unsere Entwickler dort in einer neueren Shop Version dieses auch berücksichtigen.

Das bedeutet also, dass auch der "neue" 4.06er Shop nicht für PHP 7.1 geeignet ist und man hier auf eine veraltete PHP Version zurück greifen muss, was im Hinblick auf die Sicherheit grade im Shopbetrieb nicht sinnvoll ist, oder?

Wie sieht das eigentlich mit der Risikoübernahme aus, falls bis Ende Dezember keine zu 7.1 kompatible JTL-Version existieren sollte und PHP 7.0 dann endgültig EOL sein wird. Der Hoster wird sicherlich jegliche Haftung ausschließen, sollte ein JTL Shop aufgrund der Nutzung einer PHP Version ohne Security Support gehackt werden. Die Auswirkungen eines gehakten JTL Shops könnten dann, je nach vorliegender Lücke, im PHP-System auch andere Hosting-Kunden betreffen, da wir seit Spectre/Meltdown wissen, dass Separierungstechniken auch fehlbar sein können. Die Risikoübernahme für einen solchen Fall, wird sicherlich nicht JTL oder der Shopbetreiber gerne übernehmen wollen.

 

[david]

Hey, ich denke hier lag ein Missverständnis vor. Der Fehler in Verbindung mit PP PLUS ist uns bisher nicht bekannt.
Dieses Problem wird genauer untersucht. Ursächlich scheint ja ein PaymentState "approved" dafür verantwortlich zu sein (erwartet wird "created"), und irgendwas im Exception-Call läuft dann weiter schief.
Wird keine große Sache sein, das Problem abzufangen, allerdings wäre es auch wichtig, die tatsächliche Ursache aufzudecken, warum hier kein "created" kommt.

 

[FMoche]

Abgesehen davon wäre die Version 1.08 die aktuellste Version - nicht 1.06.

 

[bbfdesign]

Hi,
das stimmt mit der 1.08 - aber es ändert ja erstmal an der Aussage zu PHP 7.1 nichts, die ja fast noch wichtiger ist in diesem Zusammenhang.