PayPal Anbindung von isotope

**olef** · 05.12.2010, 18:46

Hallo,

ich habe eine Frage bezüglich der Anbindung von dem isotope Modul an PayPal (im Augenblick noch die Sandbox) und ich hoffe, dass mir jemand dort weiterhelfen kann.

Die Anbindung Richtung Paypal funktioniert soweit (ich kann die Bezahlung mit dem richtigen Betrag dort sehen und auch bestätigen). Die Rückmeldung an das Modul funktioniert allerdings nicht richtig. Bei PayPal habe ich die PDT Funktion aktiviert, isotope ist auf Version 0.2.2 stable Build 6 aktualisiert.

Sobald ich bei der Paypal Sandbox die Zahlung bestätige, bekomme ich folgende Meldung im Systemlog:
Details: New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=3 Array ( )
Funktion: PostSale run()

bzw.
Details: PayPal IPN: data rejected (INVALID) Array ( )
Funktion: PaymentPaypal processPostSale()

Eine Änderung im Status der Bestellung bzw. der Bezahlung ist nicht zu erkennen. Wie kann ich im Contao Backend sehen, dass die Bezahlung erfolgreich war bzw. wie kann ich Paypal / isotope konfigurieren, dass die Rückmeldung bzgl. der Bezahlung erfolgreich durchgeführt werden kann? Gibt es dort bestimmte Einstellungen, die ich noch vornehmen muss?

Vielen Dank im Voraus.

Viele Grüße und einen schönen 2. Advent

Ole

**andreas.schempp** · 06.12.2010, 11:37

Hallo Ole,

Zwei Dinge dazu:
1. PayPal hat mit der Sandbox öfters solche Probleme, im Live-System würde kein INVALID kommen.
2. Du kannst PayPal nur mit Kunden einsetzen, die ein PayPal-Konto haben. Die Funktion "Bezahlen ohne Konto" funktioniert NICHT sauber! Leider können wir das nicht ändern, ist ein PayPal-Problem...

**Spica** · 10.12.2010, 18:57

gibt es zur paypal konfiguration und anbindung eigentlich irgendwo ein tut oder Vorgehensberichte, u. a. auch bezgl. sandbox, testbetrieb und dos and donts?

**buchbergertom** · 05.01.2011, 15:48

Bitte um Hilfe....

Die Paypal Rückmeldung funktioniert auch bei mir nicht!! Leider habe ich keine Ahnung welcher Link auf Paypal eingetragen werden muss, damit Paypal zurück auf den Shop linkt und der Shop die Bestellung korrekt abschließt!!

Danke für alle Tipps!!!

**andreas.schempp** · 06.01.2011, 19:44

Den Link welchen du auf PayPal einträgst ist egal, du musst allerdings etwas eintragen damit du die Option AutoReturn aktivieren kannst.

ACHTUNG: Die Weiterleitung in den Shop funktioniert nicht automatisch/zuverlässig, wenn deine Kunden ohne PayPal-Konto bezahlen wollen. Die entsprechende Option sollte also nicht aktiviert werden!

**buchbergertom** · 07.01.2011, 00:43

Meine Einstellungen sind:

Verkäufereinstellungen -- Website Zahlungsoptionen -- Automatische Rückleitung Aktiviert -- URL http://www.serenity-band.com

Sollte somit passen...

Die "Übertragung der Zahlungsdaten" habe ich aktiviert!

Und soeben festgestellt, dass ich "Paypal Konto nicht erforderlich" auf aktiv hatte. Verdammt... Jetzt muss ich testen, ob es daran gelegen hat!

Ich teste das jetzt nochmals und melde mich dann wieder... DANKE

Gibt es eine vernünftige und einfache sowie kostengünstige (bereits integrierte) Zahlungsmethode für Kreditkarten???

**andreas.schempp** · 07.01.2011, 08:24

Zitat von buchbergertom

Gibt es eine vernünftige und einfache sowie kostengünstige (bereits integrierte) Zahlungsmethode für Kreditkarten???

Was ist denn "vernünftig"?

Es gibt einige, allerdings hängt das halt immer von Land und Umsatz ab.

**buchbergertom** · 07.01.2011, 09:59

Umsatz ist nicht sehr hoch -- vielleicht 100-200 Euro im Monat!

Wir sind in Österreich (also der "Firmensitz" ist in AT) -- Kreditkarten sollten aber von jedem Land aus bezahlbar sein...

Bin für jeden Tipp dankbar! lg, tom

**andreas.schempp** · 07.01.2011, 11:38

Die Kreditkarte wird sicher in jedem Land akzeptiert, aber dein Finanzparter (Payment Gateway) muss wohl lokal sein. Schau doch mal ob Saferpay in Österreich anbietet und was das kostet.

**buchbergertom** · 09.01.2011, 12:10

Habe jetzt alles noch mal getestet (wegen dem PayPal Problem) -- es wird nach der Bezahlung korrekt zurückgeleitet.

Aber dann steht nur "Your PayPal payment is being processed" -- er lädt immer wieder nach und am Ende kommt die Fehlermeldung "Your PayPal payment could not be processed". Die Bezahlung hat aber funktioniert...

Woran kann das liegen??? Kann es eigentlich nicht verstehen...

**buchbergertom** · 09.01.2011, 16:59

GELÖST: Habe ein Update des isotope Systems von 1.irgendwas auf die aktuelle 2er gemacht!!! Jetzt läuft es... Musste aber leider ein paar Änderungen in meinen iso Templates vornehmen... Aber jetzt klappt das mal alles... Es muss also ein "alter" Fehler in Isotope gewesen sein...

**sganz** · 21.01.2011, 10:11

Hallo Andreas,

Zitat von andreas.schempp

2. Du kannst PayPal nur mit Kunden einsetzen, die ein PayPal-Konto haben. Die Funktion "Bezahlen ohne Konto" funktioniert NICHT sauber! Leider können wir das nicht ändern, ist ein PayPal-Problem...

Gibt es hierzu eigentlich schon was Neues? Wo genau liegt denn der Fehler bzw. müsste PayPal hier nicht schon reagiert haben, wenn es ein generelles Problem ist, das andere Shops ja auch betreffen müsste?

Die Funktion an sich ist sehr sexy für Kunden, die sich scheuen, extra ein PayPal-Konto zu eröffnen. Echt schade, wenn man die mit isotope nicht einsetzen kann! :-(

Viele Grüße
Stefan

**andreas.schempp** · 21.01.2011, 10:36

In der 0.3 wird das Problem behoben sein, das geht aber noch etwas...

**fokus-ux** · 22.03.2016, 08:49

Nach Tagen der Recherche und des Debuggings habe ich nun auch eine weitere Fehlerursache gefunden, weshalb das beschriebene Problem (PayPal Bezahlung erfolgt, Bestellung erscheint nicht in Isotope -> „Der Bezahlvorgang ist fehlgeschlagen. Bitte versuchen Sie es erneut oder wählen Sie eine andere Bezahlmethode.“) mit PayPal auftreten kann.
Es lag im Fall unseres Kunden an seiner Piwik Installation, die in der php.ini die Einstellung "always_populate_raw_post_data=-1" erfordert. Mit dieser Einstellung scheint die Rückmeldung von der Paypal IPN (sofortige Zahlungsbenachrichtigung) nicht mehr zu funktionieren...

Nochmal zusammengefasst für alle die mit PayPal und Isotope (daran liegt es meistens nicht!) am Verzweifeln sind.

Mögliche Ursachen:

In eurem PayPal-Konto (Privat- oder Verkäuferkonto) muss IPN (sofortige Zahlungsbenachrichtigung) aktiviert sein! Die Rückleitungs-URL spielt keine Rolle, da Sie von Isotope überschrieben wird. Es muss seit neustem, laut PayPal, eine verschlüsselte Seite, also "https://..." sein. Wenn Ihr kein SSL nutzt (solltet ihr aber) dann könnt ihr auch einfach z.B. "https://paypal.de" eintragen. Wie gesagt, Isotope überschreibt diesen Wert!
Die E-Mail-Adresse, die in Isotope unter "Shop-Konfiguration/Zahlungsarten/Paypal" eingetragen ist, MUSS die primäre/Standard Email-Adresse eures PayPal-Kontos sein.
Strato Kunden müssen unbedingt im Backend die Einstellung "Sicherheit/ServerSide Security/ Filter gegen Gästebuch-Spam" deaktivieren. Diese block die PayPal IPN Rückmeldung
Piwik und PayPal IPN vertagen sich nicht, da Piwik die Einstellung always_populate_raw_post_data=-1 voraussetzt. Anscheinend benötigt Piwik (ab 2.15.0) unter PHP 7 die Einstellung «always_populate_raw_post_data=-1» nicht mehr. Allerdings können dadruch evtl. andere Probleme auftreten. Also wenn es unbedingt Pwiki sein soll, MÜSST Ihr auf PHP 7 umstellen und testen testen testen!!!

Ich hoffe, das hilft dem Einen oder Anderen!

**kubjo** · 22.03.2016, 14:38

Hallo fokus-ux,
danke dass Du Dich da so reinhängst!

Ich habe 2 Fragen zu Deinen Punkten 1 und 2:
zu1.) "In eurem PayPal..." Meinst Du damit eine Einstellung im Backend bei PayPal im Händlerkonto?
zu2.) Ich habe das Isotop-Modul "Kasse" geöffnet (Themes>Frontendmodule>Kasse) dort aber keine Möglichkeit gefunden eine Email Adresse zu hinterlegen. Bin ich auf der falschen Spur?

Grüße
Jochen

**fokus-ux** · 24.03.2016, 11:26

Hallo Jochen,

ich habe meinen Beitrag entsprechend angepasst!

**bes0nic** · 05.04.2016, 12:16

Bei uns wollte PayPal in einem frisch aufgesetzten Shop auch partout nicht laufen - es kam immer nach der Bezahlung und Rückleitung in den Shop die Meldung, daß die Zahlung durchgeführt wird und man warten solle. Die Seite mit dieser Meldung wurde dann fröhlich immer wieder neugeladen, bis der Shop den Vorgang abbrach und zur Nutzung einer anderen Zahlungsmethode aufforderte - wohlgemerkt *nach* erfolgter Paypal-Zahlung. Da zudem die Bestellung nicht im Backend angezeigt wurde, konnte der Shop in dieser Form nicht auf die Menschheit losgelassen werden. Im Contao-Log erschien dabei immer diese Meldung:

Code:

New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=8

und danach dann:

PayPal IPN: Request Error (Bad Request)

Kurz zum technischen Hintergrund. Der Kunde kauft ein und landet während der Bezahlung bei PayPal. Die Zahlung wird durchgeführt und der Kunde dann in den Shop zurückgeleitet. Bis zur Rückleitung weiß der Shop nichts von einer Zahlung. Erst durch die Rückleitung bekommt er alle Zahlungsdetails von PayPal zugespielt. Um Mißbrauch zu verhindern, schickt der Shop nun alle erhaltenen Daten noch einmal zur Verifizierung an PayPal. Dort wird nur mit "Verified" oder "Invalid" geantwortet, und somit weiß der Shop dann auch, ob die Daten gültig sind oder nicht.

Problem: Beim Senden der Daten antwortete PayPal immer nur mit "Bad Request" (siehe obige Fehlermeldung im Log), weshalb die Verifizierung nicht abgeschlossen werden konnte - daher ging es dann im Bestellprozess auch nicht weiter voran. Irgendetwas an den gesendeten Daten schien PayPal nicht zu gefallen. Wie sich herausstellte, lag der Fehler einfach an einer falschen Adresse. In der Datei "/system/modules/isotope/library/Isotope/Model/Payment/Paypal.php" steht ca. in Zeile 50 folgende Adresse:

Code:

https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate

Damit funktioniert es nicht (zumindest bei uns). Korrekt heißen muss es:

Code:

https://www.sandbox.paypal.com/cgi-bin/webscr

Nun hat der angehängte Parameter natürlich einen Sinn, weshalb man ihn nicht komplett auslassen darf. Also muss er zusammen mit den anderen von PayPal erhaltenen Daten mitgesendet werden. Dazu muss der send-Aufruf ca. in Zeile 50 geändert werden. Bisher:

Code:

        $objRequest = new \Request();
        $objRequest->send(('https://www.' . ($this->debug ? 'sandbox.' : '') . 'paypal.com/cgi-bin/webscr?cmd=_notify-validate'), file_get_contents("php://input"), 'post');

Neu:

Code:

        $strAck = 'cmd=_notify-validate&';
        $strAck .= file_get_contents("php://input");

        $objRequest = new \Request();
        $objRequest->send(('https://www.' . ($this->debug ? 'sandbox.' : '') . 'paypal.com/cgi-bin/webscr'), $strAck, 'post');

Damit klappt's dann auch endlich

Vielleicht hilft's dem einen oder anderen.

**maipe** · 31.05.2016, 16:45

@bes0nic - Danke! Die Änderungen in der paypal.php hatten mir im April geholfen, einige Tests erfolgreich durchzuführen (Testsystem). Jetzt bekomme ich die Bad Requests jedoch wieder, hatte das System in der Zwischenzeit nicht angefasst. Nochmal alle Einstellungen geprüft und getestet, IPN-Einstellungen im Test Account aktiviert, Live Emailadresse gegen Testadresse im Zahlungsmodul ausgetauscht - immer wieder bad Requests. Hat sich da bei Paypal etwas geändert? Kann es sein, dass Isotope hier vielleicht falsche Infos an Paypal zur Verifizierung gibt? Gibt es hier von Eurer Seite ein Update?

<EDIT>

Habe jetzt den Livebetrieb getestet - exakt der selber Fehler. Hoster ALL INKL. Contao 3.2.20 + Isotope 2.1.13, Zahlung geht durch, Bezahlmethode fehlgeschlagen, Bad Request im LOG.

Error LOG:

[01-Jun-2016 16:29:35 Europe/Berlin] PHP Fatal error: Call to undefined method Isotope\Frontend::loadOrderEnvironment() in /www/htdocs/wxxxx/yyyyyy/system/modules/isotope/postsale.php on line 142

Syslog:

ID: 53
Datum: 2016-06-01 16:29
Ursprung: Frontend
Kategorie: ACCESS
Benutzer:
Details: New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=15
Funktion: Isotope\PostSale::run
IP-Adresse: 173.0.81.0
Browser: PayPal IPN ( https://www.paypal.com/ipn )

ID: 54
Datum: 2016-06-01 16:30
Ursprung: Frontend
Kategorie: ERROR
Benutzer:
Details: Payment could not be processed.
Funktion: Isotope\Model\Payment\Postsale:

rocessPayment
IP-Adresse: 37.5.202.0
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

**andreas.schempp** · 02.06.2016, 08:45

Ich kann dir dazu leider nicht helfen, am besten machst du ein Update auf die neuste Version. Es scheint als hast du deine Version kaputt gemacht, du solltest nie Änderungen an Core- oder Modul-Dateien vornehmen…

**maipe** · 03.06.2016, 09:26

Kaputt machen sagt immer mein kleiner Sohn, wenn ihm was nicht gefällt. Wenn eine Standard-Zahlungsmethode wie Paypal bei Isotope schwächelt, macht man halt was möglich ist. Dazu gibt es ja teilweise diametrale Lösungsansätze hier im Forum, die werden halt nach und nach ausgetestet. Wenn es mit den gegebenen "Boardmitteln" nicht funktioniert, geht man halt weiter.

Ein Update ist natürlich immer ein Lösung, wenn bekannt ist, dass sich um einen Bug handelt, der in einer neuen Version behoben ist. Auf Github habe ich zu der Sandbox allerdings kein geschlossenes Ticket gefunden.

Nach rückspielen der postsale.php funktioniert der LIVE Betrieb.

An der Sandbox bin ich noch dran und versuche gerade die Logs dazu zu finden.

**maipe** · 06.06.2016, 13:30

Welche Logs kann man eigentlich am besten zur Fehleranalyse bei dem Payment mit Paypal hernehmen? Nachdem ich die Fallbacksprache geändert habe (alle Seitenbäume sind zur Hauptsprache eingestellt, auch der Beanchrichtigungscenter), erhalte ich wieder keine Bestellungen mehr.

Es erscheint nur "Kasse - Ihr Warenkorb ist leer", Zahlung ist erfolgt, aber keine Bestellung im Backend sichtbar. /kasse/failed.html

Die Seite mit dem Hinweis "Bezahlvorgang fehlgeschlagen" erscheint nicht mehr.

Danke für jeden Tip.

**andreas.schempp** · 06.06.2016, 14:17

In der Version 1.4 gibt es nach meiner Erinnerung keine Logs… die haben wir erst später eingeführt.

**maipe** · 06.06.2016, 14:24

Zitat von andreas.schempp

In der Version 1.4 gibt es nach meiner Erinnerung keine Logs… die haben wir erst später eingeführt.

Contao 3.2.20 + Isotope 2.1.13

**maipe** · 06.06.2016, 15:05

Zitat von maipe

Welche Logs kann man eigentlich am besten zur Fehleranalyse bei dem Payment mit Paypal hernehmen? Nachdem ich die Fallbacksprache geändert habe (alle Seitenbäume sind zur Hauptsprache eingestellt, auch der Beanchrichtigungscenter), erhalte ich wieder keine Bestellungen mehr.

Es erscheint nur "Kasse - Ihr Warenkorb ist leer", Zahlung ist erfolgt, aber keine Bestellung im Backend sichtbar. /kasse/failed.html

Die Seite mit dem Hinweis "Bezahlvorgang fehlgeschlagen" erscheint nicht mehr.

Danke für jeden Tip.

Bis auf weiteres muß ich den Benachrichtigungscenter und die Eingaben dort verdächtigen - nach "ent"öffentlichen der 3-sprachigen "Order" Besetellbestätigung funktioniert Paypal wieder.

**maipe** · 06.06.2016, 17:21

Zitat von maipe

Bis auf weiteres muß ich den Benachrichtigungscenter und die Eingaben dort verdächtigen - nach "ent"öffentlichen der 3-sprachigen "Order" Besetellbestätigung funktioniert Paypal wieder.

Aber wie kann denn das sein?

Die Error log bringt nach Aktivieren der Nachricht:

Allowed memory size of 134217728 bytes exhausted... eval()'d code on line 1

**d23** · 07.06.2016, 17:08

Ich klinke mich an dieser Stelle einfach mal ein. Habe ebenfalls das Problem, dass PP Sandbox nicht funktioniert.
Buchungen finden bei PP sowohl auf Käufer- als auch auf Verkäuferseite statt –*aber beim Zurückleiten auf die Shopseite kommt die bereits bekannte Endlosschleife mit finalem Abbruch ("Der Bezahlvorgang ist fehlgeschlagen...").

In der Datenbank taucht die Bestellung auf, allerdings nur mit order_status = 0, wodurch sie im Backend natürlich auch nicht sichtbar wird.

Ich habe das Forum mittlerweile komplett auf den Kopf gestellt, konnte aber leider keine Lösung finden. Alle bisherigen Lösungsvorschläge und Hinweise (à la IPN korrekt einstellen etc.) habe ich schon versucht – ohne Erfolg.

Witzigerweise funktioniert der vollständige Prozess mit Live-Accout-Daten wunderbar. Allerdings kann man ja in der Entwicklungsphase zum Testen nicht dauernd echte Bestellungen tätigen und wieder stornieren.

Jemand eine Idee? Ist die PP Sandbox einfach nur bekloppt, gibt es vielleicht doch noch einen Bug im payment module oder bin ich zu doof?

**andreas.schempp** · 08.06.2016, 11:53

Mit der PayPal Sandbox hatte ich auch immer wieder meine liebe Mühe. Es müsste auf jeden Fall etwas im System-Log im Backend stehen, wenn die IPN-Nachricht von PayPal ankommt. Es kann aber sein dass die Sandbox diese nicht sendet, oder z.B. durch Http-Auth nicht auf deinen Server kommt… Leider kann ich dir das nicht wirklich beantworten, du müsstest einen PHP-Entwickler auf dein Problem ansetzen.

**d23** · 08.06.2016, 11:59

Zitat von andreas.schempp

Mit der PayPal Sandbox hatte ich auch immer wieder meine liebe Mühe. Es müsste auf jeden Fall etwas im System-Log im Backend stehen, wenn die IPN-Nachricht von PayPal ankommt.

Ist bei mir leider auch nicht das erste Mal, dass die Sandbox Zicken macht...
Im Log steht bei mir aber auch nicht viel mehr, als bei den anderen Leuten, die Probleme haben:

HTML-Code:

New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=3

und

HTML-Code:

PayPal IPN: Request Error (Bad Request)

**Toflar** · 08.06.2016, 14:39

Isotope loggt in der neusten Version die komplette Server zu Server Kommunikation mit. Du solltest also noch weiterführende Infos in der "isotope_postsale.log" in "system/logs" finden

**d23** · 08.06.2016, 15:11

Zitat von Toflar

Isotope loggt in der neusten Version die komplette Server zu Server Kommunikation mit. Du solltest also noch weiterführende Infos in der "isotope_postsale.log" in "system/logs" finden

Hab ich bereits gesehen

Ist ein sehr feines Feature! Nur sehe ich in den Einträgen auf Anhieb auch keinen Hinweis.

HTML-Code:

[08-Jun-2016 13:07:48] New request to https://XXXXXX.de/system/modules/isotope/postsale.php?mod=pay&id=3.

Headers: array (
  'USER_AGENT' => 'PayPal IPN ( https://www.paypal.com/ipn )',
  'HOST' => 'XXXXXXX.de',
)

$_GET: array (
  'mod' => 'pay',
  'id' => '3',
)

$_POST: array (
  'mc_gross' => '1.00',
  'invoice' => '92',
  'protection_eligibility' => 'Ineligible',
  'item_number1' => 'Z-02',
  'payer_id' => 'EVQRUXBHCVZ22',
  'tax' => '0.00',
  'payment_date' => '02:49:25 Jun 08, 2016 PDT',
  'payment_status' => 'Completed',
  'charset' => 'windows-1252',
  'mc_shipping' => '0.00',
  'mc_handling' => '0.00',
  'first_name' => 'John',
  'mc_fee' => '0.37',
  'notify_version' => '3.8',
  'custom' => '',
  'payer_status' => 'verified',
  'business' => 'shop@XXXXXX.de',
  'num_cart_items' => '1',
  'mc_handling1' => '0.00',
  'verify_sign' => 'AZxbwZ9bPVPFFf7hCCNemacLJwlCAoTDotN7k-NJvepH3zXAfD8SiUa-',
  'payer_email' => 'john.doe@domain.de',
  'mc_shipping1' => '0.00',
  'tax1' => '0.00',
  'txn_id' => '84X64393RT561222J',
  'payment_type' => 'instant',
  'last_name' => 'Doe',
  'item_name1' => 'Produktname',
  'receiver_email' => 'shop@XXXXXX.de',
  'payment_fee' => '',
  'quantity1' => '1',
  'receiver_id' => 'YZ2DB99WTRGZN',
  'txn_type' => 'cart',
  'mc_gross_1' => '1.00',
  'mc_currency' => 'EUR',
  'residence_country' => 'DE',
  'test_ipn' => '1',
  'transaction_subject' => '',
  'payment_gross' => '',
  'ipn_track_id' => 'd0b895b6ba488',
)

Body:
mc_gross=1.00&invoice=92&protection_eligibility=Ineligible&item_number1=Z-02&payer_id=EVQRUXBHCVZ22&tax=0.00&payment_date=02%3A49%3A25+Jun+08%2C+2016+PDT&payment_status=Completed&charset=windows-1252&mc_shipping=0.00&mc_handling=0.00&first_name=John&mc_fee=0.37&notify_version=3.8&custom=&payer_status=verified&business=shop%40XXXXX.de&num_cart_items=1&mc_handling1=0.00&verify_sign=AZxbwZ9bPVPFFf7hCCNemacLJwlCAoTDotN7k-NJvepH3zXAfD8SiUa-&payer_email=john.doe%40domain.de&mc_shipping1=0.00&tax1=0.00&txn_id=84X64393RT561222J&payment_type=instant&last_name=Doe&item_name1=Produktname&receiver_email=shop%40XXXXX.de&payment_fee=&quantity1=1&receiver_id=YZ2DB99WTRGZN&txn_type=cart&mc_gross_1=1.00&mc_currency=EUR&residence_country=DE&test_ipn=1&transaction_subject=&payment_gross=&ipn_track_id=d0b895b6ba488

exxxxxx · 16.08.2016, 00:46

Beitrag auf Wunsch des Nutzers entfernt

**andreas.schempp** · 16.08.2016, 07:17

Ein 500er-Fehler deutet auf ein Serverproblem (oder Skriptproblem) hin. Da bräuchte ich aber mehr Fehlerinformation. Steht vielleicht etwas dazu in der system/logs/error.log ?

exxxxxx · 16.08.2016, 17:43

Beitrag auf Wunsch des Nutzers entfernt

**Toflar** · 23.08.2016, 10:11

Guten Morgen allerseits,

Ich habe ein kleines Update zur Funktionsweise von PayPal mit dem Sandbox- aka Testmodus.
PayPal hat auf HTTP 1.1 umgestellt. Ich denke aus Kompatibilitätsgründen aber erst auf dem Sandbox-Endpoint und nicht auf dem produktiven Endpoint.

Requests mit Version 1.0 werden konsequent abgelehnt und die Antworten kommen neu Transfer-Encoded. Das ist alles richtig und gut, nur das Problem ist, dass die Request-Klasse von Contao schon sehr alt ist und leider 1.1 und Transfer-Encoding nicht unterstützt.
Es wäre auch ziemlich unnötig, das nachzurüsten, weil es hunderte von tollen, besseren Bibliotheken gibt, die wir mit Composer einfach holen können.
Für Contao 4 oder Contao 3.5 + Composer ist das also gar kein Problem. Für Contao 3.5 + ER2 werden wir wohl auf Chris' httprequestextended setzen. Wir schauen mal mit ihm ob wir das Projekt übernehmen sollen oder nicht etc. um die Kompatibilität herzustellen.

Das werden wir aber erst mit der kommenden 2.4 angehen, da müsst ihr euch also noch etwas gedulden.
Das zur Info: wie gesagt, produktiv läuft alles noch problemlos.

exxxxxx · 23.08.2016, 17:08

Beitrag auf Wunsch des Nutzers entfernt

**Toflar** · 24.08.2016, 08:15

Guzzle ist wohl der beliebteste PHP-Client. Aber diese Bibliothek nur zu installieren hilft ja nix, der Code muss sie ja auch noch brauchen

exxxxxx · 25.08.2016, 11:38

Beitrag auf Wunsch des Nutzers entfernt

**k-webdesign** · 20.03.2017, 13:09

Hi,

bei mir hängen gerade 2 Shops an der Problematik, dass ich zwar über Paypal bezahlen kann, die Rückleitung trotz aktivierter IPN aber nicht funktioniert. Wenn ich sie manuell über den Button "Zurück zum Händler" ansteuere, komme ich zur complete.html, sie lädt sich mehrfach neu und irgendwann kommt "Der Bezahlvorgang ist fehlgeschlagen. Bitte versuchen Sie es erneut oder wählen Sie eine andere Bezahlmethode.".
Die Zahlung über Paypal selbst funktioniert, ich bekomme auch die Mails dazu (und der Kunde auch). Nur kommt es eben durch die fehlerhafte Rückleitung nicht im Shop an.

Unser system/logs wird gar nichts vermerkt, im Backend System-Log aber:

ID: 227
Datum: 20.03.2017 13:49
Ursprung: Frontend
Kategorie: ERROR
Benutzer: ***@*****.de <- hab ich anonymisiert

Details: Payment could not be processed.
Funktion: Isotope\Model\Payment\Postsale:

rocessPayment
IP-Adresse: 217.241.18.0
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Der Shop läuft auf meinem Test-Hosting auf einer Subdomain, dort kann ich leider kein SSL bereitstellen. In der IPN ist als URL daher testweise https://paypal.de eingetragen. Es gibt nur eine Standard-Mailadresse, die ist auch im Bezahlmodul eingetragen. Das Hosting liegt nicht bei Strato und Piwik ist auch nicht aktiv. Jetzt bin ich mit meinem Latein am Ende

**k-webdesign** · 20.03.2017, 20:39

Toflar hat mich eben aufgeklärt, dass die URL, die man bei der IPN im Paypal einträgt, nicht automatisch von Isotope überschrieben wird, wie viele (und auch ich) denken/dachten. Man muss dort eintragen:
https://www.domainname.de/system/mod...ahlungsmodulID.