Welches PayPal-Modul ist aktuell?

[Fakrae]

Guten Morgen zusammen
Wir wollen/müssen zum Jahreswechsel PayPal anbieten - welches Modul ist da jetzt das aktuelle? Ich habe einiges von Problemen gehört und auch das PayPal PLUS-Modul gesehen (es sollen nur normale Zahlungen stattfinden, keine Rechnungskäufe oÄ, also brauchen wir das wohl nicht, oder?)

Danke!

Linkback: https://www.modified-shop.org/forum/index.php?topic=34095.0

[Tomcraft]

In dem Fall reicht dir das mit der aktuellen Shopversion ausgelieferte Modul "PayPal Kaufabwicklung (paypal)".

Grüße

Torsten

[Fakrae]

Danke!

[Fakrae]

Hi Leute,
wir haben jetzt die Zahlungen über das PayPal-Modul online.

Allerdings scheint es Probleme mit dem IPN zu geben, alle Bestellungen bleiben in "Offen PP wartend" stecken - egal ob die Zahlung durchgegangen ist ("Abgeschlossen" + Email), ob sie noch nicht da sind ("Pending") oder es einen Fehler gegeben hat ("PayPal Fehler!" - Grund hierfür ist bekannt)
(Klammer-Bezeichnungen immer aus der Detailansicht der Bestellung)

Kann mir jemand einen Ansatz geben, wo ich da genauer nachschauen kann? Ich hab mir gestern nen Wolf gesucht und eigentlich nur ähnliche Problembeschreibungen gefunden, aber keine Lösung (abgesehen von einem .htaccess geschützten Testshop, was es bei uns nicht ist)

Das Errorlogfile ist leer und im normalen Logfile steht bei einer der betroffenen Bestellungen nur der Aufruf

Code: [Auswählen]

xxx.xxx.xxx.xxx - - [05/Jan/2016:14:45:31 +0100] "GET /checkout_process.php?MODsid=UNKENNTLICH&token=UNKENNTLICH&PayerID=UNKENNTLICH HTTP/1.1" 302 20 "https://www.paypal.com/webapps/xoonboarding?exp=signup&flow=1-P&token=UNKENNTLICH&useraction=commit" "Mozilla/5.0 (Windows NT 6.1; rv:43.0) Gecko/20100101 Firefox/43.0" "www.nagers-futterstube.de"
xxx.xxx.xxx.xxx - - [05/Jan/2016:14:45:31 +0100] "GET /checkout_success.php HTTP/1.1" 200 7947 "https://www.paypal.com/webapps/xoonboarding?exp=signup&flow=1-P&token=UNKENNTLICH&useraction=commit" "Mozilla/5.0 (Windows NT 6.1; rv:43.0) Gecko/20100101 Firefox/43.0" "www.nagers-futterstube.de"
yyy.yyy.yyy.yyy - - [05/Jan/2016:14:45:43 +0100 "POST /callback/paypal/ipn.php HTTP/1.0" 200 0 "-" "PayPal IPN ( https://www.paypal.com/ipn )" "www.nagers-futterstube.de"und sonst nichts.
Am PayPal-Modul habe ich nichts geändert, außer die Artikel zu "Warenkorb" zusammen zu fassen, damit PayPal nicht ALLE Daten hat.

Shop ist 1.06SP2, Hoster ist HE, PHP ist 5.5, Shop läuft auf UTF-8 und Full-SSL

Danke!

[Bonner]

Schau mal hier - das sollte die Lösung bieten:

http://www.modified-shop.org/forum/index.php?topic=32740.0

Bonner

[Fakrae]

Danke für den Link, den hatte ich tatsächlich noch nicht gefunden.
Leider kann ich ChristianRothes Ausführungen auf Seite 2 gut nachvollziehen und werde mich jetzt entsprechend mal der Log-Dateien annehmen (wenn dann die nächste Bestellung mit PP kommt) und nicht nur den "Quickfix" von NoRiddle implementieren.

Mit der Übertragung von POST-Werten kenne ich mich nicht aus, aber mir ist aufgefallen, dass die PayPal-Dateien alle eine ANSI-Kodierung haben - könnte das mit meinem UTF-8 kollidieren?

[piru]

@Fakrae, welches Modul hast du benutzt? das von Thorsten empfohlende Modul "PayPal Kaufabwicklung (paypal)"?
Ich muss auch PayPal einrichten und bin nicht sicher welche besser nehmen soll

Gruß piru

[piru]

Also, ich habe das genannte Modul probiert und werde auch benutzen. Danke

Gruß piru

[Fakrae]

Ich habe das ebenfalls in Benutzung.
Bisher habe ich zwei Dinge festgestellt:
Mit einem Full-SSL-Shop mit ENABLE_SSL = false wird das Logo nicht übertragen, dazu muss Zeile 97 in /includes/classes/paypal_checkout.php von

Code: PHP  [Auswählen]

if(ENABLE_SSL == true) {

zu

Code: PHP  [Auswählen]

if(ENABLE_SSL == true || HTTP_SERVER == HTTPS_SERVER) {

geändert werden.

Das zweite:
Mit Hilfe von Logging an verschiedenen Stellen und einem manuellen Error-Reporting habe ich dann doch etwas festgestellt:
das Affiliatemodul aus dem Forum (http://www.modified-shop.org/forum/index.php?topic=3720.0) enthält diese Anweisung in /lang/german/german.php:

Code: PHP  [Auswählen]

require(DIR_WS_LANGUAGES . $_SESSION['language'].'/'.'affiliate_german.php');

weil aber die Variable ($_SESSION['language']) über ipn.php nicht gesetzt wird, wird versucht /lang//affiliate_german.php zu laden, was es natürlich nicht gibt. Einen entsprechenden Post werde ich gleich im Modul verfassen.

Das hat die ipn.php komplett blockiert und zwar an einem Punkt BEVOR normalerweise die PayPal-Daten zu Testzwecken in eine Datei geschrieben werden. Weil aber die ipn.php beim direkten Aufruf eine weiße Seite zeigen SOLL, fällt niemandem dabei auf, dass es ja eine "weiße Seite" zeigt

Der nächste Punkt ist dann aber auch schon wieder eine Frage:
Der direkte Aufruf der Datei fördert jetzt einen Fehler in der xtc_php_mail.php zu Tage, nämlich

Code: [Auswählen]

Class 'Smarty' not found in ... /inc/xtc_php_mail.inc.php on line 30In der /includes/application_top_callback.php wurde die Zeile

Code: PHP  [Auswählen]

require(DIR_WS_CLASSES . 'Smarty_2.6.22/Smarty.class.php');

Auskommentiert (und das gleich zweimal)
- ich habe da jetzt einfach

Code: PHP  [Auswählen]

require_once (DIR_WS_CLASSES.'Smarty_2.6.27/Smarty.class.php');

eingefügt, wie es in der normalen /includes/application_top.php schon der Fall ist, ist das so okay?
Jetzt kann auch die Email über den IPN-Fehler (PayPal IPN Invalid Process - entsteht bei ungültigen Daten wie bspw einem direkten Aufruf) verschickt werden.