SaferPay nur Reservation

[SlowChecker]

Hallo zusammen,

habe das SaferPay -Modul installiert und aktiviert alles eingetragen etc ...

In der Konfiguration unter Einstellungen/Zahlungsweise..., habe ich auch bei "Nur Authorisieren" = false eingestellt aber trotzdem werden meine Bestellungen alle nur Authorisiert :-(

Kann mir einer Helfen, bzw. hat einer eine idee ? :D:D

In den Logs habe ich 2 Einträge zur Bestellung!

Einmal denke cih die Reservation wo alles ok ist und einmal einen Eintrag mit einem Error:

TransaktionID = leer

Text_CALLBACK_DATA = leer

Klasse = error

Fehlermeldung = verification error

FehlerdatenERROR: ERROR: Missing DATA attribute

[bisping]

...Problem haben wir auch - und bisher scheint sich (wie offenbar üblich) hier bei xtCommerce keiner diesem Problem anzunehmen, oder gibt's dazu schon weitere Informationen?

Die Einstellung "nur Authorisieren" bewirkt leider rein gar nix bei der Zahlung.

Sind hier noch weitere Parameter notwendig, die angegeben werden müssen?

Im übrigen: Wer mal Probleme hat, Parameter in diesem Modul an Saferpay zu übergeben, die nicht über die Maske abgefragt werden, kann das einfach & dirty lösen:

Einfach im letzten Feld zur Farbdefinition den Parameter mit "&blablabla=blabla" reinschreiben - ihr werdets nicht glauben...aber das geht! (Prima programmiert im übrigen...wenn das mal keine Sicherheitslücke ist...)

[SlowChecker]

Habe leider zu diesem Problem immer noch kein Feedback ...

Aber gut das ich nicht der einzigste bin, dachte schon das nur cih dieses Problem hätte :-)

[Ranger-Shop.de]

Hallo,

ich habe zur Zeit dasselbe Problem: Im Callback-Log taucht zu SaferPay Zahlungen immer der folgende Eintrag auf:

error_msg: verification error

error_data: a:1:{s:5:"error";s:29:"ERROR: Missing DATA attribute";}

Zum Testen habe ich einen Veyton-Shop komplett neu aufgesetzt, NUR das SaferPay-Plugin installiert und alle notwendigen Daten eingegeben und auch bei SaferPay konfiguriert, aber das Ergebnis ist dasselbe.

Warum schlägt die Verifikation des IPN Callbacks fehl? Die Callback Funktion wird ausgeführt - von SaferPay kommt also die IPN per Callback rein. Das bestätigt auch das Access-Log des Servers. Aber was läuft da im Modul schief? Man kann da ja leider nicht rein schauen - die Dateien sind ja alle verschlüsselt.

Wäre wirklich toll, wenn sich dem Problem mal jemand vom XTC-Support annehmen könnte. Vielen Dank!

[Matthias]

Vermutlich meldet sich der Saferpay Server mal wieder mit ner neuen IP Adresse die das Modul nicht kennt. Somit werden die Daten im Callback vom Shop gekillt weil die Daten die da von Saferpay zurückkommen als Hackversuch vom Shop eingestuft werden.

[Ranger-Shop.de]

Danke für die Antwort - wäre eine plausible Möglichkeit, wenn das denn so ist. Leider läßt sich da von meiner Seite aus ja nichts korrigieren :-(

Eine Bestätigung vom Support wäre daher hilfreich...

Hat denn sonst jemand solche Probleme? Kann ja nicht sein, dass nur ich und eine Handvoll anderer das Problem haben. Ich denke mal das SaferPay-Modul wird bei einer größeren Zahl an Shopbetreibern eingesetzt.....?

[Ranger-Shop.de]

---

Wir setzen mittlerweile eine neue Version des Saferpay-Moduls ein, bei der die einzelnen PHP Skripte nicht mehr verschlüsselt sind. Am Problem hat sich aber nichts geändert. Nun bin ich dem Ganzen mal etwas weiter nachgegangen. Ich habe in die PHP Datei vom Saferpay-Modul (class.callback.php), die vom Callback aufgerufen wird, einen Dump der Variablen $_GET und $_POST in eine Datei eingebaut. Dort landet jetzt das hier:

[2012-07-16 15:24:55]

GET: Array

(

    [orders_id] => '356958'

    [/page][page] => 'callback'

    [page_action] => 'xt_saferpay'

)

POST: Array

(

    [DATA] => ''

    [SIGNATURE] => '2fc4037af74182e34255228fd6b927c1c163e6cdd0fc3c6054dbe1cd88aac9ac4cb49eefdfb97121dba21fa1af4089e665cd1e24b837896714381851bb49909b'

)

Der Inhalt des Array-Feldes $_POST['DATA'] ist leer. Wenn ich die Notify-URL in der Datei class.saferpay.php auf ein eigenes Skript umleite, welches einfach nur die beiden Variablen $_GET und $_POST wieder in eine Datei ausgibt, dann bekomme ich diese Ausgabe:

[2012-07-16 15:55:23]

GET: Array

(

    [orders_id] => '356961'

)

POST: Array

(

    [DATA] => '<IDP MSGTYPE=\"PayConfirm\" TOKEN=\"(unused)\" VTVERIFY=\"(obsolete)\" KEYID=\"1-0\" ID=\"xxx\" ACCOUNTID=\"xxx\" PROVIDERID=\"xxx\" PROVIDERNAME=\"xxx\" ORDERID=\"356961\" AMOUNT=\"1948\" CURRENCY=\"EUR\" IP=\"xx.xx.xx.xx\" IPCOUNTRY=\"DE\" CCCOUNTRY=\"DE\" MPI_LIABILITYSHIFT=\"yes\" MPI_TX_CAVV=\"xxx=\" MPI_XID=\"xxx=\" ECI=\"1\" CAVV=\"xxx=\" XID=\"xxx=\" />'

    [SIGNATURE] => '09b2fc4037af74182e34255228fd6b927c1c163e6cdd0fc3c6054dbe1cd88aac9ac4cb49eefdfb97121dba21fa1af4089e665cd1e24b837896714381851bb499'

)

Vom Saferpay-Server kommt also ein gefülltes DATA-Feld, über den herkömmlichen Weg ist das Feld im Callback-Skript vom Saferpay-Modul aber leer. Die Frage ist nun, wo und warum wird das Feld geleert? Greift da irgendwo eine Funktion, die HTML- oder XML-Tags herausfiltert? Welchen Weg gehen die Daten überhaupt, wenn ein Callback über einen Link hereinkommt, der so generiert wurde:

$xtLink->_link(array('page'=>'callback', 'paction'=>'xt_saferpay','params'=>'orders_id='.$data['orders_id']));

Der generierte Link sieht dann ja so aus:

http://www.domain_vom_shop.de/callback/xt_saferpay.html[/code]

Wäre schön, wenn sich das mal jemand anschauen könnte, der sich mit diesem Teil auskennt - am Besten vom XTC-Support. Vielen Dank!

[/page]

[Ranger-Shop.de]

Nachtrag: Selbst wenn ich den Dump der Variablen in der Datei /shop/xtCore/pages/callback.php mache, ist das Feld $_POST['DATA'] leer.

Welche Skripte durchläuft ein Seitenaufruf an die Adresse http://www.domain_vom_shop.de/callback/xt_saferpay.html denn noch alles VOR dieser callback.php?

[Ranger-Shop.de]

Weiterer Nachtrag: Nun habe ich die folgende URL über den Browser manuell aufgerufen:

http://www.shop-url.de/callback/xt_saferpay.html?orders_id=123456&DATA=<IDP/>&SIGNATURE=0123456789ABCDEF

Im Dump ist das DATA-Feld wieder leer. Wenn ich allerdings die folgende URL aufrufe, steht in dem DATA-Feld korrekt "IDP" drin:

http://www.shop-url.de/callback/xt_saferpay.html?orders_id=123456&DATA=IDP&SIGNATURE=0123456789ABCDEF[/code]

Es wird also in der Tat das XML-Tag <IDP ... /> herausgefiltert und somit kommen keine Daten im Saferpay-Callback-Skript an. Nur WO wird diese Filterung durchgeführt?

Ich werde das mal weiter verfolgen, vielleicht finde ich die Stelle. Wäre aber schön, wenn jemand einen Tipp hätte . . .

[mzanier]

neue IP adressen von saferpay in plugins/xt_saferpay/classes/class.ip_restriction.php aufnehmen.

[Ranger-Shop.de]

Vielen Dank für die Antwort. Leider bestand darin nicht das Problem. In der Datei /shop/plugins/xt_saferpay/allowed_ip.php war die IP, von der der Callback-Prozess von Saferpay aus aufgerufen wurde, bereits eingetragen. Ich habe die Ips aus underem Access-Log des Servers mit denen aus der Datei verglichen.

Was mich ja wundert ist, dass das DATA Feld $_POST['DATA'] bereits ganz zu Beginn des Skriptes /shop/xtCore/pages/callback.php leer ist - dort das XML-Tag bereits rausgelöscht wurde. Wenn ich das richtig sehe, werden die allowed IPs aber erst nach diesem Skript durchlaufen, oder sehe ich das falsch?

Im DATA-Feld kommt aber definitiv etwas auf unserem Server an - wenn ich die Callback-Adresse (notify-url) bei einer Testzahlung auf ein anderen Skript umleite, funktioniert alles wunderbar. Nur eben nicht, wenn das Callback über die Adresse http://www.shop-url.de/callback/xt_saferpay.html hereinkommt - dann ist das XML-Tag aus $_POST['DATA'] leer!!!

[mzanier]

Vielen Dank für die Antwort. Leider bestand darin nicht das Problem. In der Datei /shop/plugins/xt_saferpay/allowed_ip.php war die IP, von der der Callback-Prozess von Saferpay aus aufgerufen wurde, bereits eingetragen. Ich habe die Ips aus underem Access-Log des Servers mit denen aus der Datei verglichen.

Was mich ja wundert ist, dass das DATA Feld $_POST['DATA'] bereits ganz zu Beginn des Skriptes /shop/xtCore/pages/callback.php leer ist - dort das XML-Tag bereits rausgelöscht wurde. Wenn ich das richtig sehe, werden die allowed IPs aber erst nach diesem Skript durchlaufen, oder sehe ich das falsch?

Im DATA-Feld kommt aber definitiv etwas auf unserem Server an - wenn ich die Callback-Adresse (notify-url) bei einer Testzahlung auf ein anderen Skript umleite, funktioniert alles wunderbar. Nur eben nicht, wenn das Callback über die Adresse http://www.shop-url.de/callback/xt_saferpay.html hereinkommt - dann ist das XML-Tag aus $_POST['DATA'] leer!!!

wenn die IP nicht übereinstimmt dann wird es geleert.

-> ip nochmals überprüfen.

der callback ist übrigens auch nicht http://www.shop-url.de/callback/xt_saferpay.html sondern

index.php?page=callback&page_action=xt_saferpay

[Ranger-Shop.de]

Hallo,

ich habe die IPs nochmals überprüft und keinen Fehler festgestellt - die IPs sind korrekt eingetragen.

Nun habe ich mir die Datei /shop/xtFramework/security_handler.php vorgenommen, in der der $_POST Filter angewandt wird und festgestellt, dass das Callback dort zwar ankommt, aber dort das Feld $_POST['DATA'] bereits schon leer ist.

Daraufhin habe ich mir die Datei /shop/plugins/xt_saferpay/classes/class.saferpay.php noch einmal angeschaut und für die Generierung der NOTIFY-URL das hier vorgefunden:

$this->NOTIFY_URL  = $xtLink->_link(array('page'=>'callback', 'paction'=>'xt_saferpay','params'=>'orders_id='.$data['orders_id']));

Daraus wird dann letztendlich das hier gegeriert:

http://www.shop-url.de/callback/xt_saferpay.html?orders_id=123456[/code]




Nun haben Sie geschrieben, dass die NOTIFY-URL so aussehen sollte:

[code]http://www.shop-url.de/index.php?page=callback&page_action=xt_saferpay[/code]

Jetzt habe ich die Zeile von oben in das hier geändert:

[code]$this->NOTIFY_URL = "http://www.shop-url.de/index.php?page=callback&page_action=xt_saferpay&orders_id=" . $data['orders_id'];[/code]

Und siehe da: Jetzt funktioniert der Callback! Erst jetzt ist das Feld $_POST['DATA'] nicht mehr leer und es wird der Status korrekt in der Bestell-Historie eingetragen und auch der korrekte Eintrag in die DB-Tabelle xt_callback_log eingetragen! Demnach ist in der Version des Saferpay-Plugins, die ich am 30.01.2012 das letzte mal aus dem XTC-Store heruntergeladen habe, ein Fehler, durch den das Callback garnicht funktionieren kann. Leider kann ich mir jetzt keine aktuelle Version mehr herunterladen, weil in meinem Account nur steht, dass der Download nicht freigeschaltet sei. FAZIT: Damit das SaferPay-Plugin richtig funktioniert, muss in der Datei /shop/plugins/xt_saferpay/classes/class.saferpay.php diese Zeile hier:

[code]$this->NOTIFY_URL = $xtLink->_link(array('page'=>'callback', 'paction'=>'xt_saferpay','params'=>'orders_id='.$data['orders_id']));[/code]

durch diese Zeile hier ersetzt werden:

[CODE]$this->NOTIFY_URL = "http://www.shop-url.de/index.php?page=callback&page_action=xt_saferpay&orders_id=" . $data['orders_id'];[/code]

Dabei muss halt "shop-url.de" durch die entsprechende Domain des Shops ersetzt werden oder aber eine passende Konstante verwendet werden, die die aktuelle Shop-Domain enthält.

@MZANIER: Wäre schön, wenn Sie das im Modul beheben könnten und uns den Download der aktuellen Version noch einmal zur Verfügung stellen könnten. Vielen Dank!

[AxelB]

Um an das Fazit von Ranger-Shop anzuschließen:

Wir hatten das gleiche Problem dass das DATA bei Ankunft in der Datei innerhalb der GET Variablen leer war. Dies liegt nicht am Saferpay-Plugin, sondern am Thema URL-Umschreibung in der .htaccess. Wird die Einstellung innerhalb des Shops beim Thema Suchmaschinen auf Mod Rewrite URL: true gestellt funktioniert der Callback nicht mehr. Stellt man es auf false geht es wieder. Dies hat uns veranlasst noch etwas zu suchen, denn die Änderung der Notify-URL funktiniert bei einem Multishop nicht mehr ganz so einfach wie beim einem Einzel-Shop.

Des Rätsels Lösung:

In den Shop-Einstellungen bei den Suchmaschinen folgenden Einstellung ändern:

SEO-URLs für Seiten (pages): auf false setzen

Somit kann man wieder mit Mod Rewrite URL: true arbeiten und hat schöne Suchmaschinenoptimierte Links innerhalb des Shops und beim Saferpay-Callback ist die Funktion gegeben.

Dann wird das gleiche erreicht wie beim harten Programmieren der Zeile in den Sourcecode des Plugins, jedoch mit dem Vorteil das die URLs vom Shop generiert werden und so das ganze für Multi-Shops auch händelbar wird.

Viele Grüße

Axel