PayOne und Fehler in postsale.php

Ich verwende das Zahlungsmodul PayOne und habe in der PayOne-Verwaltung (PMI) als Transaktions-URL einen Link zur postsale.php angegeben (http://meineseite.de/system/modules/...e/postsale.php)
Wenn ich eine Bestellung im Testsystem ausführe, dann wird eigentlich alles korrekt durchgeführt... heißt, ich klicke auf "kaufen", gelange zur PayOne-Frontend-Schnittstelle, gebe dort z.B. meine Kreditkarten ein, klicke auf "zahlen" und gelange wieder zu Contao auf die success-Seite... und die Bestellung wird auch im Backend korrekt verbucht.

Im PMI von PayOne kann ich mir die letzten Transaktionen ansehen. Dort sehe ich auch, welche Daten von PayOne an meinen Server geschickt wurden und was PayOne als Antwort erhält. Als Antwort kommt aber von postsale.php folgender Fehler:

PHP-Code:

---

<BR><STRONG>WARNING</STRONG>: STRLEN() EXPECTS PARAMETER 1 TO BE STRING, ARRAY GIVEN IN <STRONG>SYSTEM/MODULES/ISOTOPE/POSTSALE.PHP& lt;/STRONG> ON LINE <STRONG>76</STRONG> <PRE STYLE="MARGIN:11PX 0 0"> #0 [INTERNAL FUNCTION]: __ERROR(2, 'STRLEN() EXPECT...', '/HOMEPAGES/2/D1...', 76, ARRAY) #1 SYSTEM/MODULES/ISOTOPE/POSTSALE.PHP(76): STRLEN(ARRAY) #2 SYSTEM/MODULES/ISOTOPE/POSTSALE.PHP(210): ISOTOPEPOSTSALE->__CONSTRUCT() #3 {MAIN} </PRE>TSOK 


---

Das bezieht sich auf folgende Zeile in postsale.php

PHP-Code:

---

 $this->setModuleId(strlen(\Input::post('id')) ? \Input::post('id') : \Input::get('id')); 


---

PayOne erwartet als Antwort aber nur "TSOK" ohne irgendwelche anderen Zeichen davor... solange wird die Transaktion auch nicht als "bezahlt" markiert.

Weiß jemand, was setModuleId() macht bzw. wie ich den Fehler umgehen kann?
Eigentlich müsste PayOne wahrscheinlich sowas senden : .../postsale.php?mod=pay&id=1 wobei id die Zahlungsart-ID ist. Liegt es vielleicht nur am Testsystem?

Bisschen rubber duck debugging und man kommt weiter...

Die Werte für "mod" und "id", mit denen postsale.php auch von anderen Zahlungsmodulen aufgerufen werden kann, kommen bei PayOne aus dem Parameter "param". Dieser wird von Isotope initial beim Bestellprozess an PayOne mitgesendet (z.B. param = paymentMethodPayone8) und dann von PayOne auch an postsale.php zurück geliefert. Dort wird dann über einen Hook die ModuleId 8 rausgezogen und alles läuft seinen Weg. Deshalb wurde in Contao auch die Bestellung erfolgreich aufgenommen.

Ich habe dann in den Contao-Einstellungen die Option "Fehlermeldungen anzeigen" deaktiviert und siehe da: im PMI läuft jetzt auch alles ohne Probleme, da die PHP-Warnung nicht mehr ausgegeben wird und PayOne die korrekte Antwort "TSOK" bekommt.

Hi Claus,

ich glaub ich hab dir da quatsch geschrieben. Ruf mal nicht direkt die postsale.php auf, sondern stell bei der TransactionUrl lieber mal die successurl ein. Der Fehler kommt wohl dadurch, dass in der postsale.php versucht wird die ID direkt aus den \Input::get bzw. post Parameter zu ziehen, dort gibt es aber keine.

Du musst eine Seite aufrufen die direkt vom \Frontend extendend.

Dort gibt es nämlich an Zeile 700 genau den Fall, den du beschrieben hast

PHP-Code:

---

public function setPostsaleModuleSettings(PostSale $objPostsale)
{
    // Payment method "Payone"
    $strParam = \Input::post('param');

    if (strpos($strParam, 'paymentMethodPayone') !== false) {
        $intId = (int) str_replace('paymentMethodPayone', '', $strParam);
        $objPostsale->setModule('pay');
        $objPostsale->setModuleId($intId);
    }
} 


---

Hier wird die ID sauber extrahiert aus dem übergebenen param und das entsprechende Zahlungsmodul gesetzt. Ich hab das bei mir anders gelöst. Ich hab als Returnpath eine eigene Datei angegeben die dann per curl an die postsale.php die Werte mod=pay&id= sendet. Daher erhalte ich auch keine Fehlermeldung.

Probier das mal so aus, weil nur die Fehlermeldung zu deaktivieren ist auch nicht die richtige Lösung, weil der Fehler ja immernoch da ist. Es funktioniert zwar trotzdem, weil postsale ja im nächsten Schritt trotzdem die o.g. Funktion ausführt. Ich glaub so ist das aber nicht geplant. Die Transaction muss in jedem Fall ihren Response absenden, damit die setPostsaleModuleSetting() ausgeführt wird.


Das ist Quatsch, ich lass trotzdem mal stehen....

Mist... ausblenden von Fehlern wäre so ne einfache Lösung gewesen :( ;)

Die Funktion in isotope/library/Isotope/Frontend.php hab ich dann auch gefunden und gesehen, dass die eben durch den Hook in postsale aufgerufen wird - wie du schon sagtest leider nachdem der Fehler geworfen wird ;)

Die successurl (also .../kasse/complete.html) kann ich doch aber auch nicht ohne weiteres angeben. Auf der Seite muss ich ja noch irgendwie die Funktion setPostsaleModuleSetting anstoßen (auch durch nen Hook?)
Sorry, ich blick da nicht ganz durch bei den Zahlungsmodulen :o

Tatsächlich, du hast recht.

Die Methode setPostsaleModuleSettings() wird nur über die postsale.php aufgerufen, aber erst nachdem die Fehlermeldung überhaupt entstanden ist. Der nachfolgende Hook ruft diese Methode im Frontend auf. Also wird der Fehler in jedem Fall produziert. Das scheint dann wohl ein Bug zu sein. Entweder man holt den HOOK vor die Zuweisung der ID, oder man sollte prüfen ob die Parameter mod und id überhaupt gesetzt sind anstatt sie einfach zuzuweisen.

Ich schau mal auf Github und erstell ggf. ein Ticket

"nur" den Hook vor die Zuweisung holen funktioniert auch nicht, da der Fehler von strlen() kommt (siehe oben), sprich deine zweite Lösung wäre besser.

Danke, dass du dich bei Github darum kümmern würdest :)


edit: hier das ticket

Code:

---

Details:        Isotope\Model\Payment\Payone did not return a valid order
Funktion:        Isotope\PostSale::run

---

Code:

---

Details:        PayOne order data mismatch for Order ID ""
Funktion:        Isotope\Model\Payment\Payone::processPostsale
IP-Adresse:        xxxxxxxxxxxxxxxx
Browser:        PAYONE FinanceGxxate

---

FAILED DEPENDENCY auf Seiten von Payone in der Transaktionsübersicht.

Nach einiger Zeit taucht die Bestellung im BE auf - sollte das nicht mit 2.1.10 behoben sein? Habe 2.1.13 in Betrieb.


EDIT: Auch ein Update auf Contao 3.5.24 und Isotope 2.4 brachte bei mir nichts. Payone Frontend Version weiterhin ohne Funktion:

Code:

---

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

---

EDIT 2:

Neuen Key generiert und auf MD5 + SHA eingestellt brachte bei mir Erfolg mit 2.4 und 3.5.24!