Anzeige von Bestellbestätigung trotz PayPal-Fehlermeldung

Hallo,

ich betreue einen Online-Shop bei dem das folgende Phänomen auftritt: Wenn der Kunde ein nicht-vollfunktionsfähiges PayPal-Konto hat und im Shop eine Bestellung abschließt, kommt am Ende auf der Seite der Bestellbestätigung folgende Meldung:

Instruct the customer to retry the transaction using an alternative payment method from the customers PayPal wallet. The transaction did not complete with the customers selected payment method.

Dazu habe ich auch einen Screenshot der Bestellseite angehangen, wo man die Bestellbestätigung sieht, jedoch auch die PayPal-Fehlermeldung.

Weiterhin gehen wir davon aus, das dadurch im Backend Bestellungen scheinbar angelegt, aber dann wieder gelöscht werden. Denn es gibt Sprünge in den Bestellnumern, wo immer mal einige Nummern ausgelassen werden.

Der Shop läuft in Version: 4.9.2
PayPal: 3.1.1

Habe gesehen, dass es für PayPal bereits eine neuere Version gibt, jedoch kann ich das System aus organisatorischen Gründen gerade nicht upgraden.

Ich gehe davon aus, dass das Problem ganz klar bei PayPal liegt. Jedoch würde ich gern den OXID-Shop so anpassen, dass eben keine Bestellbestätigung kommt, wenn PayPal eine Fehlermeldung liefert.

Kann mir hier jemand weiterhelfen?

Danke und viele Grüße

Hallo k00ni :slight_smile:

was sagt den das PayPal Logging?

Viele Grüße
indianer3c

Guten Morgen indianer3c,

was sagt den das PayPal Logging?

Wo finde ich die PayPal Logs?

Grüße

Hi k00ni :slight_smile:

das Logging muss bei den Moduleinstellungen bei PayPal aktiviert sein. Die Log Datei befindet sich im Verzeichnis [B]/modules/oe/oepaypal/logs/[/B]. Dieses Verzeichnis muss Schreibrechte besitzen, damit die Log-Datei angelegt bzw. neue Logeinträge in die Datei geschrieben werden.

Viele Grüße
indianer3c

Hallo,

die PayPal Log hat über 33000 Einträge. (aktiv seit August 2014) Ich habe die mal überflogen und einen beispielhaft hier gepostet: PayPal Log example entry · GitHub (sensible Einträge habe ich mit x-en ersetzt)

Soweit gesehen, sind die Einträge alle gleich. Ich frage mich gerade, wie das mit der obigen Fehlermeldung von PayPal zusammenpasst. Dort steht ja:

Instruct the customer to retry the transaction using an alternative payment method from the customers PayPal wallet. The transaction did not complete with the customers selected payment method.

Jedoch steht in der PayPal Log:

Service_Unavailable_-_DNS_failure
The_server_is_temporarily_unable_to_service_your_request___Please_try_again

Grüße

EDIT1:

Habe gerade festgestellt, dass Bestellungen aus der PayPal Log, die als fehlerhaft gekennzeichnet sind, trotzdem im Shop existieren, obwohl in der PayPal Response sowas steht wie Service_Unavailable_-_DNS_failure.

Interessant wären die Einträge, die zu geposteten Screenshot passen.

Hallo,

ich kann die Einträge nicht exakt eingrenzen, aber folgende fallen ungefähr in den Zeitraum, wo die Bestellung geschehen sein könnte: https://gist.github.com/k00ni/3b753db7d98dc93cf5be

Mir ist grad aufgefallen, dass auf der Seite der Bestellbestätigung des Shops keine Bestellnummer angegeben wurde, sondern nur ein %s steht. (siehe Bild meines ersten Posts). Es scheint also auch keine ordentliche Verarbeitung des Templates stattgefunden zu haben.

Viele Grüße
Konrad

IPN Verification kann doch erst stattfinden, nachdem DoExpressCheckoutPayment erfolgt ist, oder?
https://developer.paypal.com/docs/classic/express-checkout/overview-ec/#how-express-checkout-works
(schau mal das Diagramm unter “Express Checkout API Calls Flow” an)
Warum postest du dann nur Fehlermeldungen, die mit dem Checkout im engeren Sinne gar nichts zu tun haben?
https://developer.paypal.com/docs/classic/products/#reporting

Hallo Martin,

ich habe den Inhalt der PayPal-Log gepostet, wie von indianer3c erfragt. Da stehen für das Datum der fehlerhaften Buchung (01.07.2015) nur die von mir zuletzt geposteten Einträge drin. Das Bild meines ersten Posts gehört ebenfalls zu der fehlerhaften Buchung.

Kennst du weitere Logs für PayPal?

Mir fiel gerade noch die EXCEPTION_LOG.txt von OXID selbst ein. Dort gibt es an besagtem Datum folgende Einträge, welche aber eigentlich nicht in Betracht kommen, weil der Kunde um 13 Uhr herum bestellt hat (laut Screenshot).

Faulty component –> help

oxSystemComponentException-oxException (time: 2015-07-01 10:43:31): [0]: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND
Stack Trace: #0 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxutilsobject.php(188): oxUtilsObject->_getObject(‘oxsystemcompone…’, 0, Array)
#1 [internal function]: oxUtilsObject->oxNew(‘oxSystemCompone…’)
#2 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxfunctions.php(348): call_user_func_array(Array, Array)
#3 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxutilsobject.php(178): oxNew(‘oxSystemCompone…’)
#4 [internal function]: oxUtilsObject->oxNew(‘help’)
#5 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxfunctions.php(348): call_user_func_array(Array, Array)
#6 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxshopcontrol.php(396): oxNew(‘help’)
#7 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxshopcontrol.php(338): oxShopControl->_initializeViewObject(‘help’, NULL, NULL, NULL)
#8 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxshopcontrol.php(126): oxShopControl->_process(‘help’, NULL, NULL, NULL)
#9 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxid.php(40): oxShopControl->start()
#10 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/index.php(26): OXID::run()
#11 {main}

Faulty component –> help

oxSystemComponentException-oxException (time: 2015-07-01 10:43:31): [0]: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND
Stack Trace: #0 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxutilsobject.php(188): oxUtilsObject->_getObject(‘oxsystemcompone…’, 0, Array)
#1 [internal function]: oxUtilsObject->oxNew(‘oxSystemCompone…’)
#2 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxfunctions.php(348): call_user_func_array(Array, Array)
#3 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxutilsobject.php(178): oxNew(‘oxSystemCompone…’)
#4 [internal function]: oxUtilsObject->oxNew(‘help’)
#5 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxfunctions.php(348): call_user_func_array(Array, Array)
#6 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxshopcontrol.php(396): oxNew(‘help’)
#7 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxshopcontrol.php(338): oxShopControl->_initializeViewObject(‘help’, NULL, NULL, NULL)
#8 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxshopcontrol.php(126): oxShopControl->_process(‘help’, NULL, NULL, NULL)
#9 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/core/oxid.php(40): oxShopControl->start()
#10 /var/www/vhosts/mein-zelt-steht-schon.de/httpdocs/index.php(26): OXID::run()
#11 {main}

Hi k00ni :slight_smile:

mir ist noch einfallen wegen der [B]Poodle Sicherheitslücke[/B] http://t3n.de/news/paypal-ssl-tls-poodle-578642/ solltest deine [B]PayPal Version 3.1.1[/B] aktualisieren auf[B] 3.2.1 for 4.9.x[/B]. Die aktuelle Modulversion für den CE Shop findest du unter http://exchange.oxid-esales.com/de/OXID-Produkte/OXID-eFire-Extensions/OXID-eFire-Extension-PayPal-3-2-1-for-4-9-x-Stable-CE-4-4-x-4-9-x.html#versionTab

Weil PayPal hat das veraltete SSL-3-Protokoll abgeschaltet und dies könnte evtl. sogar die Ursache für deinen Fehler sein.

Die entscheidende Quellcode Änderung findest unter https://github.com/OXID-eSales/paypal/commit/63f5162cba4ecb52361f251033c105fce33e1e34#diff-7140d0ecbd8967bcf0d5f7cfbdccd4df

Viele Grüße
indianer3c

Hallo indianer3c,

danke für den Hinweis. Ich hatte jedoch als die Lücke bekannt wurde schon an einem Fix für das PayPal-Modul gearbeitet, als es noch keinen offiziellen Fix gab (siehe Link).

Das Krude ist halt, dass über den Shop ungefähr 5 - 10 PayPal-Bestellungen pro Tag abgewickelt werden und der Fehler nur bei einem Bruchteil auftritt.

Grüße