Jump to content
xt:Commerce Community Forum

Ranger-Shop.de

Members
  • Content Count

    34
  • Joined

  • Last visited

Everything posted by Ranger-Shop.de

  1. So sieht es wohl aus. Die version 2.1.2 benötigt wohl zwingend die Shop-Version 4.1, um funktionieren zu können. Sonst würde man das als Update anbieten. Ansonsten "bräuchte man nur" die Shop-Version 4.1 herunterladen und das PayPal-Plugin daraus extrahieren.
  2. Genau auf dieser Seite steht immer nur "Aktuelle Version: 2.0.2"! Nun schaut ja nicht jeder bei den Downloads nach, ob dort vielleicht eine neuere Version vorhanden ist... Version 4.1 ist bei uns noch in der Testphase, ob unsere selbst geschriebenen Plugins damit auch kompatibel sind. Da bin ich ja mal gespannt...
  3. Hallo, dann muss ich jetzt mal fragen, welche Versionsnummer das aktuelle PayPal-Modul denn hat? Sollte es nämlich die Version 2.0.2 sein, die auf der xt-commerce.com Webseite zu finden ist unter den Plugins, dann muss ich sagen: das hilft nicht. Denn diese Version habe ich bereits seit Monaten installiert und der Fehler tritt trotzdem mehrmals am Tag auf. Das habe ich aber auch schon in meinem Post vom 23.01.2013 geschrieben. Wir haben inzwischen etwa 10 bis 15 mal pro Woche im Callback-Log diesen Fehler "INVALID responce but invoice and Customer matched". Von all diesen Callbacks habe ich Logs, sowohl von den Daten, die an PayPal geschickt wurden als auch von denen, die von dort zurück kamen. Bei einigen sind tatsächlich Umlaute drin, bei denen der Eintrag in der Callback-Log Tabelle dann auch abgeschnitten wurde. Es gibt aber auch Callbacks, bei denen kommt nicht ein einziger Umlaut drin vor. Einzig und allein an Umlauten (äöüÄÖÜ und auch das ß - beliebt bei dem Wort Straße ;-) ) kann es also nicht liegen. PayPal läßt mit ihrer Antwort auf meine Anfrage, mir doch einmal die Rohdaten für die Fehlertransaktionen zukommen zu lassen, leider immer noch auf sich warten. Bis dahin bleibt uns weiterhin nur täglich unser Abfrageskript (ja, wir haben schon extra ein Skript geschrieben, das alle Bestellungen und deren Status überprüft und fehlerhafte über die PayPal-API gegencheckt) aufzurufen und die dann manuell zu korrigieren (das wollte ich dem Skript nicht auch noch überlassen ;-) ) MFG, Ranger-Shop.de PS: Bitte den Sarkasmus nicht persönlich nehmen ;-) Der spiegelt nur unseren Frust bzgl. dieses Themas wider.....
  4. Das / Zeichen ist in Textfeldern immer mal wieder ein Problem :-) Bin gespannt, ob es bei Euch zum Erfolg führt. Wir haben zwar keine Tags im Produktnamen oder in anderen Feldern, aber das Zeichen kann durchaus mal auftauchen. Danke für den Hinweis, ich schau mal, ob ich da Parallelen finden kann zwischen den betroffenen Bestellungen.
  5. Wenn klar ist, in welchem Format übermittelt wird, dann braucht man bei PayPal ja nur das gleiche einzutragen. Dann wäre die Ursache schonmal weg. Aber auch ich bin der Meinung, dass das nicht das eigentliche Problem ist. Seit der Anpassung haben die Fehler zwar bei uns abgenommen, weg sind sie aber noch nicht. Alle ein bis zwei Wochen kommt wieder mal ein Fall vor, bei dem ein INVALID zurück kommt. Ich bin noch dran das Ganze zu analysieren und melde mich wieder, wenn es etwas Neues gibt. Leider habe ich gerade ein paar wichtigere Dinge zu tun, so dass mir für das Problem nicht viel Zeit bleibt.
  6. Hallo, ich muss die Arbeit an diesem problem auf Anfang nächste Woche verschieben, da mir ein paar andere Aufträge dazwischen gekommen sind. Sobald ich mich wieder damit befasse, melde ich mich hier wieder. mfg
  7. Hmmm, Post tauchte doppelt auf nach Antworten.
  8. Hallo, wir hatten jetzt gerade auch wieder einen Fall, den ich gleich zum PayPal Support geschickt habe. Jetzt sagte man mir, es läge an dem Eintrag "DHL (DE)", den wir als Versandartikel mitschicken und zwar an den Klammern, die ja maskiert als %28 und %29 im Request-String enthalten sind. Wären die direkt als Klammer enthalten, bekäme man ein Verified zurück. Das kann aber nicht das Problem sein, weil dieser Artikel fast immer dabei ist und der Fehler nur ab und zu mal auftaucht. Ich lasse mir jetzt von PayPal mal deren Strings zu dem Problemtransaktionen schicken, so dass ich die vergleichen kann. Vielleicht finde ich dann heraus, wo das Problem liegt. Dann könnte ich das im PayPal-Modul beheben und den Bugfix dann an XTC schicken, so dass sie dann ein Update für das Modul erstellen können. Wir verwenden seit 2 Tagen die Version 2.0.2, zuvor hatten wir die 1.2.6. Shop Version ist 4.0.14. Wie ist es bei Euch?
  9. Hallo, die option findet man, indem man sich in das PayPal-Konto einloggt, dann auf "Mein Profil" geht, dort links auf "Verkauf/Händler" und dann findet man ganz unten unter "Weitere Verkaufstools" den Punkt "Sprachliche Kodierung von PayPal-Buttons". Dahinter verbirgt sich die Seite "Sprachcodierung", wo man den Button "Weitere Optionen" anklickt und so auf die Seite "Weitere Codierungsoptionen" kommt. Dort kann man dann die Codierung getrennt für die Webseite und den Datenversand per Mail oder IPN einstellen. Wünsche viel Glück, dass es weiter hilft :-) Über ein Feedback, ob es etwas gebracht hat, würden wir uns freuen.
  10. Hallo, wir hatten das Problem auch. PayPal sagte uns dann, es läge an der Codierung der IPN Nachrichten. Wenn der Shop eine andere als die voreingestellte Codierung verwendet, dann muss das bei PayPal in den Einstellungen unter API angepasst werden. Unser Shop läuft mit UTF-8, bei PayPal war aber etwas anderes eingestellt. Das Problem sollen Umlaute und Sonderzeichen auslösen. Seit der Anpassung ist der Fehler nur noch einmal aufgetreten, vorher hatten wir pro Woche mehrere mit einem Fehler, obwohl alles ok war.
  11. Vielen Dank für die Antwort! (War bis diese Woche im Urlaub, lese das also erst jetzt) Das könnte uns weiterhelfen - ich werde das mal auf unserem Testsystem ausprobieren mit einer anderen Datenbank.
  12. Hallo, danke für die Antwort. Allerdings hilft sie mir leider nicht weiter. Ich wollte wissen, ob man wie bei der Shop-Version 3 die Session Speicherung statt in der Datenbank auch als Dateien auf der Festplatte des Servers ablegen kann. Wir haben momentan Probleme mit der Datenbank und möchten das Session-Management zumindest kurzzeitig auslagern. Was die DB Hooks angeht, genau diese Beschreibung steht auch im Veyton Praxixbuch, war mir also auch schon bekannt. Ich würde aber gerne wissen, WAS GENAU diese Funktion macht, nicht, wann man sie einstellen soll und wann nicht. Unser Server ist mit 32 Kernen und 64GB Ram ausgestattet und So optimiert, dass auch eine Verteilung auf die Kerne stattfindet. Das sollte also ein "starker" Server sein ;-)
  13. Hallo, ich kann grad nicht mit Bestimmheit sagen, warum ich die Antwort auf meine Frage nirgends finden kann - aber vielleicht kann mir jemand einen Anstoß geben: Wo stelle man in Veyton ein, wo die Sessions gespeichert werden (Datenbank, Dateisystem)? In XTC3.xx ist es ja die Datei configure.php, bei Veyton kann ich es ums Verrecken nicht finden, weder in Config-Dateien noch in irgendwelchen Feldern in der Datenbank oder im Backend. Achja - bei der Suche bin ich noch auf etwas anderes gestossen: Für was genau ist die Einstellung "Datenbank Hooks verwenden"? In der Doku und im Praxisbuch steht nur, dass man das für kleine Shops aktiviert lassen soll und dass sonst irgendwo ein Verzeichnis files bei plugins erstellt wird?!?!? Irgendwie sagt das aber nicht wirklich etwas über die eigentliche Funktion aus. Wäre also dankbar, wenn das jemand erläutern könnte. Vielen Dank! Bitte helft mir, Community, Ihr seid meine letzte Hoffnung ;-)
  14. Hier ein Beispiel, wie man (mittels Javascript) dem Bestell-Button seine Aktion entnimmt, so dass man mit ihm keine weitere Bestellung abschicken kann: HTML im Template /shop/templates/xt_default/xtCore/pages/checkout/subpage_confirmation.html: . . . {literal} <script type="text/javascript"> function send_order() { document.getElementById('send_order').innerHTML = document.getElementById('send_order').getElementsByTagName('a')[0].innerHTML; document.getElementById('sendform').submit(); } </script> <style type="text/css"> #send_order {display:inline-block; cursor:pointer;} </style> {/literal} . . . {form type=form id=sendform name=process action='checkout' method=post conn=SSL} . . . <div id="send_order"> <a href="javascript:send_order();"> {button text='Kaufen' btn_template='tpl_button_1.gif' file='button-kaufen.gif'} </a> </div> {form type=formend} . . . Damit wird das um das erzeugte <img> - Tag herum liegende <a> - Tag entfernt, wodurch der Button nicht mehr als link funktioniert. Mittels CSS wird der Cursor aber trotzdem so aussehen, als wenn es noch ein Link ist und man kann beliebig oft draufklicken, ohne dass etwas passiert.
  15. Weiterer Nachtrag: Ich hatte eben solch ein Lag beobachtet. Während dieses Lags konnte man z.B. die Startseite des Shops öffnen. Produktseiten allerdings nicht. Alle Produktseiten, die ich parallel in unterschiedlichen Tabs im Browser geöffnet habe, warteten alle gemeinsam auf Antwort vom Server. Als der Lag vorbei war, wurden plötzlich alle Produktseiten gleichzeitig angezeigt. Vielleicht liegt es an einer bestimmten Tabelle in der Datenbank. Auf unserer Startseite wird nicht auf die xt_products zugegriffen (wir beziehen die Daten aus einer anderen Tabelle auf dieser Seite). Die Produktseiten hingegen greifen auf diese Tabelle zu. Allerdings ließ sich die Tabelle über ein PHPMyAdmin öffnen, wodurch schonmal eine Sperre der Tabelle ausgeschlossen ist. Vielleicht liegt es ja an einer anderen Tabelle. Ich werde die alle mal durchprobieren, sobald ich wieder ein Lag sehe.
  16. Nachtrag: Bestellungen ohne Weiterleitung an Zahlungsunternehmen (Gratis, Vorkasse, Nachnahme) lassen sich durch mehrfachen Klick auf den Bestellbutton mehrfach abesnden und tauchen dann auch mehrfach in der Bestellliste auf. Allerdings ist nur die erste mit Artikeln bestückt - die späteren sind alle leer. Bei Bestellungen über Zahlungsanbieter wie PayPal, Sofortüberweisung und Saferpay ließ sich das gerade nicht provozieren. Es wurde die Bestellung nur ein einziges mal eingetragen. Ich habe aber noch eine Vermutung: Angenommen der Server laggt gerade irgendwo. Es kommen sehr viele Anforderungen rein, die auch zwischengespeichert werden, aber noch nicht verarbeitet werden, weil z.B. der Apache Server kurzzeitig hängt. Jetzt klicken einige Kunden auch mehrfach den Kaufbutton. Sobald der Hänger vorbei ist, werden alle angestauten Anforderungen teils zeitgleich und parallel (bei uns sind gleichzeitig 32 PHP Prozesse möglich) ausgeführt. Jeder Bestellklick holt sich jetzt nahezu zeitgleich das Session Objekt mit der Bestellung aus der Datenbank - somit sind alle Anforderungen mit einem vollen Warenkorb versorgt und im weiteren Verlauf werden dann alle Anforderungen als gültige Bestellungen verarbeitet. Ich kenne mich jetzt nicht genug mit dem Apache Server aus um sagen zu können, ob dies so möglich ist - aber vielleicht kann da ja jemand vopm XTC-Team etwas zu sagen. Wir möchten wenigstens wissen, woran das liegen kann... Vielen Dank!
  17. Auch wir haben das Problem. Gestern war es besonders schlimm. Es waren sehr viele Bestellungen, die zwei- bis neunmal vorhanden waren, bei einigen wechselte dann zwischendurch auch die Zahlungsart - d.h. der Kunde hat sich dann anders entschieden, weil es wohl zu lange gedauert hat? Ich überlege mir mal etwas für den Button, so dass der deaktiviert wird, sobald man einmal draufgeklickt hat. Zwar kann der kunde die letzte Seite dann noch neu laden und er könnte dann wieder draufklicken, aber das sollte zumindest die Mehrfach-Klicker endämmen. Ich teste zudem mal aus, ob es überhaupt möglich ist, durch mehrfaches Klicken mehrfach zu bestellen.
  18. 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!
  19. 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!!!
  20. 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 . . .
  21. 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?
  22. 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]
  23. 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.....?
  24. 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!
  25. Durch ein wenig herumprobieren bin ich darauf gestossen, wie es so funktioniert, wie ich es möchte: Die folgenden Zeilen müssen noch in der "c_agb.php" Datei hinzugefügt werden: if (isset($_GET['popup'])) { $no_index_tag = true; $index_tpl = 'popup.html'; } Die gesamte Datei sieht dann so aus: <?php defined('_VALID_CALL') or die('Direct Access is not allowed.'); $template = new Template(); $tpl = 'agb.html'; $tpl_data = array('message'=>$info->info_content,'data'=>$shop_content_data, 'subdata'=>$subdata); if (isset($_GET['popup'])) { $no_index_tag = true; $index_tpl = 'popup.html'; } ($plugin_code = $xtPlugin->PluginCode('module_content.php:tpl_data')) ? eval($plugin_code) : false; $page_data = $template->getTemplate('smarty', '/'._SRV_WEB_CORE.'forms/'.$tpl, $tpl_data); ?> Jetzt wird der Content aus der Datei "agb.html" korrekt innerhalb der Index-Seite angezeigt und beim klick auf den Popup-Link wird nur der Inhalt der Datei in dem Popup-Fenster inkl. der Kopfzeile mit Schließen und Drucken-Funktion angezeigt. ==> Problem gelöst Vielen Dank!
×
×
  • Create New...