Probleme mit Paypal Standard/Express & Isotope

[danielm]

Ich sehe den Wald vor lauter Bäumen nicht mehr...
Wie lautet die Rückleitungs-URL, die ich bei PayPal angeben muss??

[andreas.schempp]

Es ist egal was du da einträgst, weil wir die korrekte URL an den Shop übermitteln. Aber PayPal zwingt dich was einzutragen, um die Option zu aktivieren... Also einfach deine Domain oder so ;-)

[Paradroid]

Ganz ähnliche Probleme hier: eMail Adresse ist die standard-Adresse, welche auch bei PayPal eingetragen ist. IPN ist aktiviert, URL ist "irgendwas", weil's ja ohnehin durch das Payment-Modul überschrieben wird.

Zahlung geht tatsächlich durch (habe die Sandbox testweise ausgeschaltet), IPN wird wohl versuchsweise zugestellt, aber dann hakt es irgendwo. Screenshots von relevanten Log-Einträgen würde ich gern anhängen, aber irgendwie will das Foum wohl gerade nicht (Fenster geht auf, aber alles bleibt grau).

In den Logs steht:

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

..und sofort danach (gleiche Uhrzeit, taucht wenige Sekunden später auf):
Request Error: 110 Connection timed out
Payment could not be processed.

Der Benutzer bekommt einen Hinweis, dass die Zahlung nicht geklappt hat, obwohl sie tatsächlich durchgeführt wurde. Contao V3.3.3, Isotope 2.1.5.

Für jede Hilfe dankbar,
Jens

[Paradroid]

Ganz ähnliche Probleme hier:

...selbst gelöst: Die VM in der Contao/Isotope läuft, hatte 'rausgehende https: Verbindungen geblockt. Das ist jetzt "chirurgisch" geöffnet mit einem forward Proxy, der nur Verbindungen zu PayPal zulässt (das ganze Scheunentor öffnen wäre ein Sicherheitsrisiko, falls mal jemand die VM hackt).

Jens

[danielm]

Wäre jemand so nett, ein paar Screenshot seiner Contao-Einstellungen hier zu posten?
Ich bekomme dieses Paypal nicht zum Laufen und habe den dumpfen verdacht, dass es an irgendeinem blöden kleinen Häkchen liegt, dass ich zuviel oder zu wenig gesetzt habe.

Paypal ist ein absolutes KO-Kriterium. Ich finde Isotope echt klasse, aber wenn wir es nicht hinkriegen, bleibt keine andere Chance als ein Wechsel. So nervig und doof das auch wäre.
Punkt zwei ist das fehlende Feld für Gutschein-Codes. Dass ausgerechnet diese beiden super-wichtigen Funktionen nicht laufen ist in einem modernen Webshop leider nicht zu kompensieren...

Also falls jemand mal 5 Minuten Zeit für ein paar Screenshots hat wäre ich wirklich dankbar!
Danke!

[Paradroid]

Wäre jemand so nett, ein paar Screenshot seiner Contao-Einstellungen hier zu posten?

Ein Screenshot wäre mit Kanonen auf Spatzen schießen. Es gibt genau ein Häkchen das zu setzen ist, und das ist "enabled" - den Rest aus machen. OK, vielleicht den "debug mode" so lange eingeschaltet lassen, bis es funktioniert, aber das versteht sich von selbst.

Ich hatte Dir letzte Woche ja schon per PM mitgeteilt, dass es bei uns daran gelegen hat, dass die VM ein wenig zu sehr abgeschottet war. Ich hoffe ich trete Dir nicht zu nahe wenn ich jetzt sage, dass Du - wenn Du den Begriff VM schon nicht kanntest - besser Hilfe bei der Serverkonfiguration in Anspruch nehmen solltest. Dort kann man nämlich viel mehr falsch machen, als im Contao/Isotope Backend.

Auf was für einem Server läuft Deine Installation? Welche Rechte hast Du auf der Maschine, und vor Allem: Ist das eigene Hardware, Miet-Hardware oder eine virtuelle Maschine?

Jens

[danielm]

Ein Screenshot wäre mit Kanonen auf Spatzen schießen. Es gibt genau ein Häkchen das zu setzen ist, und das ist "enabled" - den Rest aus machen. OK, vielleicht den "debug mode" so lange eingeschaltet lassen, bis es funktioniert, aber das versteht sich von selbst.

Ich hatte Dir letzte Woche ja schon per PM mitgeteilt, dass es bei uns daran gelegen hat, dass die VM ein wenig zu sehr abgeschottet war. Ich hoffe ich trete Dir nicht zu nahe wenn ich jetzt sage, dass Du - wenn Du den Begriff VM schon nicht kanntest - besser Hilfe bei der Serverkonfiguration in Anspruch nehmen solltest. Dort kann man nämlich viel mehr falsch machen, als im Contao/Isotope Backend.

Auf was für einem Server läuft Deine Installation? Welche Rechte hast Du auf der Maschine, und vor Allem: Ist das eigene Hardware, Miet-Hardware oder eine virtuelle Maschine?

Jens

Ich weiss, was eine VM ist. War mir nur wegen des Kontextes unsicher, ob auch eine VM gemeint ist.
Nachdem ich gestern meinen Fehler im Gutschein System lösen konnte indem ich einfach dem Template wieder den originalen Namen gegeben habe, werde ich Paypal auch nochmals mit möglichst allen originalen Templates testen.
Es ging mir nicht um einen Screenshot der Paypal Einstellungen, sondern der Contao-Grundeinstellungen. Denn wenn wir mal ehrlich sind, könnte auch schon ein simples "utf-8" anstelle eines "UTF-8" für den Fehler verantwortlich sein.
Oder ein ähnlich dummer und ärgerlich "Fehler". Daher wollte ich den Screenshot.

[giorgiojob]

Hallo,

ich habe folgende Installation: Isotope 2.1.4 und Contao 3.3.3
Alle Zahlungen funktionieren einwandfrei.
Bestellungen die mit PayPAl bezahlt werden werden im Shop nicht gespeichert also keine Bestelldaten, absolut nichts.
Geld kommt zwar an und die Bestellung wird korrekt an PayPal übergeben, da stimmt alles.
Nur im Shop steht nichts von der Bestellung.

Im Modul läßt sich ja nicht viel einstellen also keine API oder so. Kann mir nicht erklären wo der Fehler liegen kann.

Danke für jede Hilfe.

[Paradroid]

Geld kommt zwar an und die Bestellung wird korrekt an PayPal übergeben, da stimmt alles.
Nur im Shop steht nichts von der Bestellung.

Sieht aus wie der Fehler, den ich anfangs hatte: 'rausgehende https: Verbindungen waren nicht zugelassen. Das ist ein Job für Deinen Admin.

Jens

[giorgiojob]

Sieht aus wie der Fehler, den ich anfangs hatte: 'rausgehende https: Verbindungen waren nicht zugelassen. Das ist ein Job für Deinen Admin.

Jens

Ist vermutlich was anderes denn ich nutze kein https - Gibt es irgendwo eine Anleitung, wie man sein PayPal-Konto einstellen muss, damit das überhaupt funktionieren kann.
Habe jetzt nämlich etwas verändert und PayPAl leitet zurück in den Shop und es kommt eine Hinweis, daß die Zahlung bearbeitet wird und um Geduld gebeten wird.

Im Browser header steht was von../kasse/complete.html?=UID....... die URL wird dann ein paarmal aufgerufen und endet mit der Fehlermeldung, daß die Zahlung nicht ausgeführt werden kann und man eine andere Zahlungsmethode wäheln soll, allerdings wurde der Betrag richtig abgebucht und auf dem Empfängerkonto richtig im Guthaben verbucht. Also Zahlung wird bei PayPal nach wie vor mit den korrekten Beträgen abgerechnet, nur der Shop will von alldem nichts wissen und speichert auch nichts.

Habe hier jetzt auch noch den Sandbox Moduls aktiviert und an allen Einstellungen rumgefummelt (bei PAyPAl) die so gehen allerdings ohne irgendeinen prostivien Effekt. Die URL mit www.eigeneDomain.de/kasse/complete.html gibt es in der gesamten Shopstrucktur nicht, denke aber daß das über das Isotope Modul lasse gesteuert wird.

Also leider kann ich im Netz auch keine Tips finden, jedenfalls nicht mit meiner Installation : Isotope 2.1.4 Contao 3.3.3

[danielm]

Ist vermutlich was anderes denn ich nutze kein https - Gibt es irgendwo eine Anleitung, wie man sein PayPal-Konto einstellen muss, damit das überhaupt funktionieren kann.
Habe jetzt nämlich etwas verändert und PayPAl leitet zurück in den Shop und es kommt eine Hinweis, daß die Zahlung bearbeitet wird und um Geduld gebeten wird.

Im Browser header steht was von../kasse/complete.html?=UID....... die URL wird dann ein paarmal aufgerufen und endet mit der Fehlermeldung, daß die Zahlung nicht ausgeführt werden kann und man eine andere Zahlungsmethode wäheln soll, allerdings wurde der Betrag richtig abgebucht und auf dem Empfängerkonto richtig im Guthaben verbucht. Also Zahlung wird bei PayPal nach wie vor mit den korrekten Beträgen abgerechnet, nur der Shop will von alldem nichts wissen und speichert auch nichts.

Habe hier jetzt auch noch den Sandbox Moduls aktiviert und an allen Einstellungen rumgefummelt (bei PAyPAl) die so gehen allerdings ohne irgendeinen prostivien Effekt. Die URL mit www.eigeneDomain.de/kasse/complete.html gibt es in der gesamten Shopstrucktur nicht, denke aber daß das über das Isotope Modul lasse gesteuert wird.

Also leider kann ich im Netz auch keine Tips finden, jedenfalls nicht mit meiner Installation : Isotope 2.1.4 Contao 3.3.3

Du hast exakt das gleiche Problem wie ich.
Hast Du irgendwelche Templates verändert?

[Paradroid]

Ist vermutlich was anderes denn ich nutze kein https

Doch tust Du, denn das PayPal-Modul von Isotope baut von sich aus die 'rausgehende https-Verbindung zu PayPal auf, um die instant payment notification zu verifizieren. Nur wenn die funktioniert, ist die "Nachladeschleife" letztlich erfolgreich, und die Zahlung wird Dir auch im Backend angezeigt.

'rausgehende https-Verbindungen müssen also zwingend freigegeben sein. Nicht dass ich das gut finden würde, denn PayPal hätte das echt eleganter lösen können, aber das steht hier leider nicht zur Diskussion.

Jens

[giorgiojob]

Doch tust Du, denn das PayPal-Modul von Isotope baut von sich aus die 'rausgehende https-Verbindung zu PayPal auf, um die instant payment notification zu verifizieren. Nur wenn die funktioniert, ist die "Nachladeschleife" letztlich erfolgreich, und die Zahlung wird Dir auch im Backend angezeigt.

'rausgehende https-Verbindungen müssen also zwingend freigegeben sein. Nicht dass ich das gut finden würde, denn PayPal hätte das echt eleganter lösen können, aber das steht hier leider nicht zur Diskussion.

Jens

Hallo Jens, ich denke, du hast doch Recht mit der erzwungenen rausgehenden HTTPS Verbindung. Ich kann auf dem Server eigentlich alles machen. kannst Du mir da die entsprechenden Anweisungen geben, was jetzt zu tun ist?
Liege ich richtig damit, daß an der php.ini auf dem Server etwas zu ändern ist? Also da komme ich überall ran.

Vielen Dank

Giorgio

[Paradroid]

kannst Du mir da die entsprechenden Anweisungen geben, was jetzt zu tun ist?

Nein, denn ich kenne Deine Hardware nicht, und ich kenne die Firewall(s) nicht, die drumherum konfiguriert sind. Bei mir war es "außerhalb" des virtuellen Servers, auf dem mein Contao/Isotope-System läuft: Der hardwaremäßige Server fährt ein Linux, und in diesem Linux fahren mehrere virtuelle Maschinen. Diese VMs sind über einen software-switch miteinander verbunden, und dort gibt es Firwall-Regeln für die Kommunikation mit der Außenwelt. Das ist ein Standard-Konstrukt, das Dir sicher auch von großen Hostern angeboten wird.

Möglicherweise hast Du aber nur eine VM gemietet, so dass Du an das "Mutterschiff" gar nicht herankommst. Wenn Du auch eine VM benutzt, kann's sein, dass Du sowohl "innen", als auch "außen" Hand anlegen musst. "außen" wäre hier das Linux, auf dem wiederum die VM läuft.

Ich bin selbst kein Admin, sondern beschäftige die richtigen Leute. Ich habe zwar eine sehr genaue Vorstellung was da abgeht, kenne aber als Geschäftsführer die Details nicht. Da ich meine Grenzen kenne, hat mein Admin die Anweisung, mir das Root-Passwort gar nicht erst zu geben. Meine Anweisung an ihn lautete: "Setz' mal alle Loglevels hoch und beobachte, was da schief läuft". Nach Ausführen einer Zahlung in der Sandbox hatte er sehr schnell die Lösung. Dein Admin müsste mit dieser Anweisung ebenfalls etwas anfangen können.

Liege ich richtig damit, daß an der php.ini auf dem Server etwas zu ändern ist? Also da komme ich überall ran.

Ich kann daraus nicht ableiten, dass Du vollen Zugriff auf diese Maschine hast.

Jens

[danielm]

Gibt es zu diesem Problem inzwischen neue Lösungsansätze??

[doescher]

Hallo zusammen,

ich habe nun leider exakt das Problem, welches einige hier schon verzweifeln lässt.
Auch bei mir wird nach erfolgreicher Zahlung bei PayPal angezeigt, dass der Bestellvorgang fehlgeschlagen ist.

Es hat aber schon einmal funktioniert, daher bin ich nun völlig perplex, dass dieses Problem auftaucht.

Hier der Log, fall der noch benötigt wird...

[2015-03-02 22:51] Isotope\Model\Payment\Paypal did not return a valid order
Löschen Anzeigen
[2015-03-02 22:51] New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=2
Löschen Anzeigen
[2015-03-02 22:43] Payment could not be processed.
Löschen Anzeigen
[2015-03-02 22:41] A new version of record "tl_iso_payment.id=2" has been created
Löschen Anzeigen
[2015-03-02 22:41] PayPal IPN: data rejected (INVALID)
Löschen Anzeigen
[2015-03-02 22:41] New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=2

Es läuft bei mir Contao 3.4.4 und Isotope 2.2.2 (musste heute schon von 2.2.1. updaten, vielleicht liegt hier der Fehler?).

Ich habe zwar einige Templates etwas angepasst, aber nicht viel geändert, da ich da nicht viel Ahnung von habe.

Was kann ich hier machen, brauche dringend Hilfe.

Gruß
Jan-Dirk

[doescher]

Ich habe mein Problem gelöst. Fehler lag natürlich bei mir, weil ich in meinem PayPal Konto noch nicht die Übertragung per IPN ausgewählt hatte.
Das brauchte ich bisher bei meinem alten Shop nicht, daher kannte ich es auch nicht...
Aber vielleicht hilft diese Info auch noch anderen.
Gruß
Jan-Dirk

[Kahmoon]

Sorry wenn ich mich hier mal einklinke. Wo aktiviere ich denn IPN?

VG
Frank

[doescher]

Sorry wenn ich mich hier mal einklinke. Wo aktiviere ich denn IPN?

VG
Frank

Hallo,
das ist eine Einstellung, die Du in Deinem PayPal-Konto machen musst, nicht bei Contao.
Dort findest Du es unter "Sofortige Zahlungsbestätigung". Du musst dann Deine Website dort eintragen und es aktivieren, glaube ich.
Viele Grüße

[andreas.schempp]

Google ist dein Freund, z.B. hier schön beschrieben: http://www.shoppilot.net/pf/aktuelle...atigung-(ipn)/

[Kahmoon]

Ja, das war mir klar das es eine Paypaleinstellung ist. Habe aber auch bei Google nix gefunden. Sorry

Die Anleitung schaut gut aus. Thx

Als URL Trage ich nur die Shopdomain ein oder muss ich eine spezielle Unterseite verwenden?

[quenn]

Ich hatte auch dieses Problem, im Log die Meldung

Isotope\Model\Payment\Paypal did not return a valid order

Ansonsten alles richtig eingestellt, IPN bei Paypal aktiviert und identische Emailadressen.

Dann hab ich es bei einem anderen Hoster probiert und nun läuft es. Das Problem ist bei Strato aufgetaucht, bei Domainfactory funktioniert es. Ich konnte keine speziellen Threads zu Isotope auf Strato finden, gibt es da etwas zu beachten oder weiß jemand, woran es ungefähr liegen könnte (Kunde hat natürlich alles bei strato...)?

Danke und Gruß

EDIT 29.04.15

Ich konnte das Problem nun endlich lösen. Ich glaube, im Forum steht noch nichts dazu, deshalb habe ich diesen Thread erstellt:

https://community.contao.org/de/show...119#post368119

Es war im Strato Backend ein Filter gegen Gästebuch Spam aktiviert, diesen habe ich ausgeschaltet und nun läuft alles.

[cs1982]

Hallo Zusammen,

leider beschäftigt mich mit der aktuellen Isotope-Version auch ein Problem mit Paypal. Im System-Log von Contao habe ich ziemlich viele Fehlermeldungen in der Art:

• Invalid post-sale request (param error): system/modules/isotope/postsale.php
• Isotope\Model\Payment\Paypal did not return a valid order

Seltsamerweise kommen schon ab und an Bestellungen auch über Paypal an. Und wenn ich es mit einer Gastbestellung und einem echten (eigenen) PayPal-Konto teste, geht es auch. Ich habe sowohl von einem Win10 mit Firefox als auch von einem Adroid-Tablet probiert - ohne Probleme.

Ich bin allen Forenhinweisen und was mir sonst noch so einfiel nachgegangen, denke ich. Folgenden Stand habe ich:

• PayPal: "Zahlungseingänge in einer nicht unterstützten Währung zulassen" habe ich auf "Ja, akzeptieren und umrechnen in Euro" umgestellt von "Nein, Zahlungen ablehnen". Ich kann mir aber nicht vorstellen, dass das Problem hier liegt, da der Versand nur in Länder mit EUR zulässig ist.
• PayPal: "Doppelte Zahlungen unterbinden" habe ich von "ein" auf "aus" gestellt.
• PayPal: IPN war und ist aktiv. Folgende Änderung habe ich gemacht: in Benachrichtigungs-URL auf https umgestellt, da nun die gesamte Site auf https läuft. Mit Isotope 1.4.8 lief nur der Shop via Erweiterung Redirect auf https -> https://www.meineURL.de/system/modules/isotope/postsale.php
• Isotope: wenn ich https://www.meineDomain.de/system/mo...e/postsale.php aufrufe kommt "Bad Request". Ich vermute, das ist normal, wenn man blind stochernd die postsale.php direkt aufruft? ;-)
• PayPal/ Isotope: Paypal-Email-Adresse (nur 1) entspricht der in der Zahlungsmethode angegebenen Adresse
• Isotope: Template-Anpassung in iso_document_invoice.html5 gibt es. Die Rechnung wird aber ganz problemlos ausgegeben, mit Bild und allem drum und dran.
• Isotope: Seit einiger Zeit habe ich die Benachrichtigungskonfig geändert, da es zu doppelten Benachrichtigungen bei der Bestellbestätigung kam: Benachrichtigung im Kassen-Modul aus, nur noch Benachrichtung am Status "Neue Bestellung" ein. Die Mail da ist natürlich auch über das Notification Center gepflegt. Kann hier ein Problem liegen?
• Contao: .htaccess-Schutz: Da weis ich nicht, was gemeint ist. Ich nutze die mitgelieferte Contao-htaccess mit umleitung auf http -> https und domain.de auf www.domain.de. Das funktioniert alles wunderbar.
• Hosting: Seit 29.10.15 setze ich erneuertes SSL-Zertifikat von Comodo (über alfahosting.de) ein. Das ist das gleiche wie vorher und es gab auch schon Fehlermeldungen vor der Erneuerung. Also scheidet die Fehlerursache aus?
• PayPal: Website-Zahlungszertifikate von PayPal nutze ich nicht.
• Isotope: die beiden aktiven Gutscheine (x% Rabatt auf Warenkorbwert, nur für Mitglieder (Neukunden)) habe ich getestet - gehen. Dadurch habe ich auch die Bestellung als registriertes Mitglied erfolgreich getestet.

Ich bin mit meinem Latein am Ende und hoffe auf eure Unterstützung!

VG
Chris

[cs1982]

Hallo noch mal,

kann es ggf. mit einem Affiliate-Tracking zusammenhängen? Der Tracking-Code ist in einer separaten php-Datei via Insert-Tag in die Seite eingebunden. Kann es da Seiteneffekte geben? Laut den Tracking-Test-Möglichkeiten, die ich habe, sind meine Testbestellungen getrackt worden.

Vielen Dank für jede Unterstützung!

Chris

[andreas.schempp]

Hast du denn ein konkretes Problem? Hat sich ein Kunde gemeldet? Oder vermutest du nur ein Problem wegen der entsprechenden Log-Meldungen?

[cs1982]

Nein, Kunden haben sich nicht gemeldet, das etwas nicht geht. Aber trotzdem ja, ich habe ein relativ konkretes Problem. Die Fehlermeldungen kommen sehr gehäuft vor u nach meinen kleinen Änderungen vor. Und es gibt viele Carts, die nicht zu Orders wurden. Nicht bestellte Carts sind natürlich alleine noch kein technisches Problem.
Wenn ich davon aus gehe, dass das Logging funktioniert, sieht es aber schon so aus, als wäre da ein Problem. Nur leider fehlen mir weitere Ansätze, den Meldung nach zu gehen.

Sind Gründe für Falschmeldungen im Log in der Richtung bekannt/ denkbar?
Ist es hilfreich, zu versuchen die offenen Carts in tl_iso_product_collection mit den Postsale-Fehlermeldungen zeitlich in Verbindung zu bringen? Ggf ergibt sich ein Muster. Ist tstamp dazu geeignet? Ein Join wird nicht funktionieren, aber ein sortiertes Nebeneinanderstellen ggf. schon.

Vielen Dank für jeden Fingerzeig.
Chris

[cs1982]

Eine Quelle für diese Fehlermeldungen konnte ich klären:

Invalid post-sale request (param error): system/modules/isotope/postsale.php

Über den Abgleich des Contao Logs mit dem Paypal-Transaktions-Log (Zahlungsverlauf von IPN) bin ich drauf gekommen. Wir nutzen das PayPal-Konto für zwei Vertriebskanäle. Immer dann, wenn eine Zahlung über den anderen Vertriebskanal ankommt, meldet IPN in Standard-Konfig auch diese Zahlung an die Benachrichtigungs-URL unseres Isotope-Shops. Darauf hin habe ich mit PayPal telefoniert. Es gibt nach deren Aussage Möglichkeiten, die IPN abhängig vom Auslöser der Zahlungsanfrage zu steuern. Diese Infos führen in das Thema ein: https://developer.paypal.com/docs/cl...mplementation/

Die umfassenden Infos des Developer-Portals zeigen meine Grenzen auf. Und es ergibt sich die Frage, ob es nicht möglich ist, die Quelle von IPN-Requests zu erkennen und nur wenn Sie vom Shop ausgelöst werden, eine nicht verarbeitbare Info als Fehler ins System-log zu schreiben? Ich kann mir vorstellen, dass das generell nützlich wäre.

Lt. Paypal-Kundendienst ist eine zweite Lösungsmöglichkeit, pro Vertriebskanal ein separates PayPal-Konto zu betreiben. Das würde aber die Notwendigkeit nach sich ziehen, ein zweites (anderes) Geschäftskonto im neuen Konto zu hinterlegen, da eine Bankverbindung immer nur mit einem PayPal-Konto verknüpft werden kann.

Für folgende Fehlermeldung konnte ich auf genanntem Weg keinen zeitlichen Zusammenhang herstellen:

Isotope\Model\Payment\Paypal did not return a valid order

Direkt davor wird ein neues Post-Sale-Request als Info geloggt:

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

Kann es sein, dass hier vielleicht doch noch ein Problem in der Kommunikation von Isotope und Paypal besteht? Wie könnte man das weiter analysieren?
Wäre es denkbar, die NachrichtenID und/ oder den Transaktionscode der IPN Zahlungsbenachrichtigung mit zu loggen?

Es hat auch wieder neue Carts, die nicht zu einer Order geführt haben gegeben, diese passen zeitlich aber nicht zu den Fehlermeldungen. Da gibt es also augenscheinlich keinen Zusammenhang.

Danke für weitere Unterstützung.

[briun]

Hi Chris,
ich beschäftige mich mit einer ähnlichen Sache. und habe die selben Fehlermeldungen im Log
Ich setzte das Paypal-Konto für Isotope und ebay ein.

Ich bekomme jeden Morgen die Fehlermeldung von Paypal:
PayPal-Warnung "Sofortige Zahlungsbestätigung"
Bitte überprüfen Sie den Server, der für sofortige Zahlungsbestätigungen von PayPal zuständig ist. Sofortige Zahlungsbestätigungen an den/die folgende(n) URL(s) sind fehlgeschlagen:
.....postsale.php?mod=pay&id=2

Nachdem ich Paypal Technical Support kontaktiert habe gab es folgende Erkenntnisse bzw. Antworten:

PayPal sendet bei jeder Kontobewegung, also auch wenn Geld von Ebay kommt, eine IPN an der Server des Händlers. Es gibt Händler die zum Beispiel auf diese Weise die Verfügbare Menge in Ihrem Shop reduzieren.

Und so wie ich das sehe wird es mehrmals versucht, auch wenn der erste Versuch fehlgeschlagen ist. Deshalb auch manchmal kein Zusammenhang zwischen den Zahlungen und den Einträgen im Log.
Ich gehe davon aus, dass mit den Isotope Transaktionen alles reibungslos funktioniert. Habe auch noch kein negatives Feedback von Kunden.
Ist also kein akutes Problem aber nervt halt und irgendwann wird die Sofortige Zahlungsbestätigung dann auch deaktiviert und man muss es wieder manuell aktivieren.
Von Paypal kam dann noch folgender Lösungsvorschlag:

euer Server gibt uns nun einen Fehler ( HTTP Response 424 ) zurück. Dieser Fehler lautet: Die Anfrage konnte nicht durchgeführt werden, weil sie das Gelingen einer vorherigen Anfrage voraussetzt.

Da es eBay Transaktionen sind kann der Shop nichts damit anfangen.
Im Grunde ist die Fehler-Handhabung korrekt aber das Skript sollte den Fehler einfach ignorieren und an PayPal ein OK ( HTTP 200) zurück geben.
Um das Problem zu beheben muss die Fehler-Handhabung geändert werden. Es sollte ausreichen wenn im Script die Zahl "424" gegen die "200" ausgetauscht wird.

Ich vermute das es die datei "postsale.php" im Verzeicheniss "/system/modules/isotope/" editiert werden muss.

in der Zeile 172 findet sich folgendes: $objResponse = new Response('Failed Dependency', 424);

Wenn man das so ändert : $objResponse = new Response('OK', 200);

Sollte es trotz Fehler ein OK bestätigen. Ich bin nicht der Entwickler und kann daher keine Garantie übernehmen.
Eventuell ist es am besten den Entwickler zu kontaktieren und mit ihm das Problem zu besprechen.

Kann jetzt aber nicht beurteilen ob dies Sinn macht.

Vielleicht helfen die Infos weiter.

[andreas.schempp]

Ha! Ja das ist natürlich klar, PayPal sendet für jede Transaktion eine Meldung.
Die Lösung dafür dürfte aber recht einfach sein: Bei der PayPal IPN Konfiguration in deren System kannst du die Ziel-URL konfigurieren. Dort steht jetzt vermutlich deine Domain + postsale.php drin. Die solltest du auf irgend etwas anderes ändern… Isotope sendet die korrekte URL für seine Transaktionen mit, das heisst die Einstellung ist für Isotope egal. Aber das sollte dazu führen dass die nicht-Isotope-Zahlungen nicht mehr an der entsprechenden URL ankommen.

[briun]

Danke für deine Antwort Andreas.
Es ist mir bekannt dass die URL dort für Isotope nicht relevant ist.
Wenn ich dort was anderes eintrage löst es das Problem PayPal-Warnung "Sofortige Zahlungsbestätigung" aber nicht, da paypal ja irgendwie eine korrekte Antwort erwartet.

Gäbe es denn Bedenken wenn ich das so umsetzte wie von Paypal vorgeschlagen. (Änderung in postsale.php)

[andreas.schempp]

Es ist nicht update-sicher…

PayPal erwartet eine HTTP 200 Antwort. Das kriegen sie von jeder statischen Seite, aber du kannst natürlich auch ein PayPal-Dummy als HTML-Datei anlegen.

<body>
<h1>Dear PayPal</h1>
<p>You just got pranked.</p>
</body>

[cs1982]

Hallo Andreas, danke für den Hinweis:

Die solltest du auf irgend etwas anderes ändern… Isotope sendet die korrekte URL für seine Transaktionen mit, das heisst die Einstellung ist für Isotope egal.

Ich habe in der IPN-Benachrichtigungs-URL heute Mittag "/system/modules/isotope/postsale.php" entfernt. Seit dem ist es deutlich ruhiger geworden im System-Log. Die folgende Fehlermeldung tritt nicht mehr direkt hintereinander (durch mehrere PayPal-Meldeversuche) auf:

Invalid post-sale request (param error): system/modules/isotope/postsale.php

Sie Meldungen treten offensichtlich im Zusammenhang stehend auch bei einer eBay-Zahlung nicht auf. Ich konnte die Meldungen auch durch eine Zahlung von meinem privaten PayPal-Konto auf unser Shop-PayPal-Konto provizieren. :-)

ABER: die obigen Meldungen treten weiterhin sporadisch aber mehrfach an einem Nachmittag auf.
Die Contao-Seiten "Kasse" und "Bestellbestätigung haben aktuell die Robot-Tags "noindex, follow". Zudem waren die Seiten nicht von der Contao-Suche ausgeschlossen. Zumindest die nicht deaktivierte Suche scheint keinen Einfluss zu haben. Können Crawler die Fehlermeldungen verursachen?

Zusätzlich gibt es immer noch mehrfach folgende Meldungen direkt nacheinander:

[2015-11-04 19:43] New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=3
[2015-11-04 19:43] Isotope\Model\Payment\Paypal did not return a valid order

In tl_iso_product_collection gibt es dazu aber keinen Cart oder eine verwaiste Order in der Zeit. Wo könnte das denn noch her kommen?

Und zu guter letzt kam heute eine Rückmeldung von einem Kunden rein, das er eine Bestellung nicht per PayPal bezahlen konnte. Folgenden Ablauf konnte ich telefonisch rekonstruieren:

• Warenkorb über Android-Tablett zusammengestellt, keine Regeln angewendet
• als registriertes Mitglied
• Check Out mit Zahlungsoption Pay Pal
• Weiterleitung zur PayPal-Site hat funktioniert
• Beim Einloggen des Kunden kam die Fehlermeldung "Wrong Site" (Beim Googeln danach kommt man eher auf sowas wie "Wrong Page". Der Erfahrung nach können die Fehlermeldungsberichte aus dem Gedächtnis schon in die Richtung "streuen")
• Fehlerbild mit gleichen Bedingungen mehrfach auf. in tl_iso_product_collection sehe ich die Carts des Members direkt hintereinander.
• letztendlich bestellte der Kunde mit Vorkasse

Daraufhin habe ich mit meinem Adroid-Tablett als Mitglied via Pay Pal eine Bestellung ausgelöst und bezahlt. Wie immer bei meinen Tests ohne Probleme. Verdammich ;-)
Eines habe ich noch nicht erfragt: ob das PayPal-Konto des Kunden überhaupt funktioniert. Aber davon würde ich momentan noch ausgehen.

Der Kunde hat im Telefonat sich auf meine Frage, ober man sich das ggf. mal per Fernwartung ansehen könnte, nicht verweigert. Die Chancen stehen ganz gut, das ich ihn mit der ein oder anderen Gratisbestellung überzeugen kann.
Andreas, wäre soetwas aus deiner Sicht sinnvoll und machbar? Die Koordination würde ich natürlich übernehmen. z.B. TeamViewer gibt es auch für Android.

Vielen Dank für weitere Rückmeldungen!

[andreas.schempp]

Die Invalid-Meldungen können gut noch auftreten, weil PayPal einige male versucht die URL aufzurufen bevor aufgegeben wird.

Direkten (Kunden-) Support bieten wir (lediglich) für Mitglieder des Isotope Circle an: https://circle.isotopeecommerce.org

[cs1982]

Invalid post-sale request (param error): system/modules/isotope/postsale.php

... Ich konnte die Meldungen auch durch eine Zahlung von meinem privaten PayPal-Konto auf unser Shop-PayPal-Konto provizieren.

Mh, hier muss ich mich korrigieren. Es tritt doch noch eine Fehlermeldung auf im Log und zwar die, zu der ich vorhin noch keinen Zusammenhang herstellen konnte:

Isotope\Model\Payment\Paypal did not return a valid order
New post-sale request: system/modules/isotope/postsale.php?mod=pay&id=3

Hat jemand eine Idee, wie das sein kann, obwohl die IPN-Benachrichtigungs-URL nicht auf "https://meinedomain.de/ .../postsale.php" verweist sondern nur auf "https://meinedomain.de".

Nagut, zumindestens die so häufig auftretenden Fehlermeldungen scheinen damit geklärt.

Die nicht einfach reproduzierbaren fehlerhaften Paypal-Zahlungen werden wohl erstmal ungeklärt bleiben.

[cs1982]

Hallo Zusammen,

ich habe dem Zitat entsprechend eine Paypal-Dummy-Seite bei PayPal konfiguriert. Ich habe dazu einfach eine leere Seite ohne weitere Textausgabe unter die Kassenseite neben die Bestellbestätigungsseite angelegt und darauf verwiesen. Trotzdem kommt immer noch die PayPal-Warnung bzgl. der "Sofortigen Zahlungsbestätigung".

Es ist nicht update-sicher…

PayPal erwartet eine HTTP 200 Antwort. Das kriegen sie von jeder statischen Seite, aber du kannst natürlich auch ein PayPal-Dummy als HTML-Datei anlegen.

<body>
<h1>Dear PayPal</h1>
<p>You just got pranked.</p>
</body>

Mache ich was falsch oder funktioniert das so nicht? Da ich PayPal für den Shop und für Ebay verwende, bekomme ich bei Verwendung der Bestellbestätigungseite bei jeder Paypal-Zahlung von Ebay Fehler im Shop. Daher wollte ich ja versuchen auszuweichen.

Danke für Hinweise und seinen schönen 1. Advent!

Chris

[andreas.schempp]

Nach meinen Vorstellungen müsste das funktionieren, ich kann dir leider nicht sagen warum es bei dir nicht geht. Du müsstest wohl einen Entwickler darauf ansetzen, der die PayPal-Anfragen analysiert und herausfindet woher sie kommen.