Durch Zufall entdeckte ich bei meinem Kreditkartendienstleister Secupay, das dort eine Buchung vorhanden war, welche im Shop als Warenkorb oder Bestellung nicht vorhanden war. In der Timeline von Secupay sah man die Buchung zunächst als abgelehnt, etwa 4 Stunden später als bestätigt. Im Gambioshop war jedoch nur der Kunde als neu angelegt zu erkennen. Eine Bestellung war nirgends ersichtlich.Bei Secupay wurde der Warenkorb abgespeichert, leider ohne Artikelattribute, ich könnte also nur fast ratend anhand des Preises (der unterschiedlich war) erkennen, was bestellt wurde. Ich habe bei Ticket aufgemacht, Gambio hat aber keinerlei Hilfe gewährt und schrieb Beim Zahlungsmodul von Secupay gibt es eine optionale und nicht voreingestellte Möglichkeit, einen Warenkorb wohl vorher zwischenzuspeichern. Dies erklärt jedoch nicht den Fehler. Und so antwortete auch Secupay Ist das jemanden auch schon einmal passiert? Soll ich jetzt als Verantwortlicher Schuld sein? Hier zeigt ja wohl jeder auf den anderen. Der (US-)Kunde fragte natürlcih heute sofort nach, was passiert sei. Richtig beantworten konnte ich es nicht.
Klingt nach einer Umschreibung des TmpOrders-Modus. Wenn der abgeschaltet war und das Modul wegen der nicht sofort erfolgten Autorisierung der Zahlung die Bestellung irgendwie abgebrochen hat, würde das das beschriebene Verhalten erklären. Das bestätigt aber die Aussage von unserem Support: Das ist ein Bug im Secupay-Modul, und das wird von Secupay selbst gepflegt.
Wie ich hier schon geschrieben habe, die Technik von Secupay zeigt auch auf Gambio. Und ich verstehe es nicht, wie ein Warenkorb erst abgelehnt und dann 4 Stunden später genehmigt wird und dann verschwindet.
Wie geht das Modul denn mit normalen abgebrochenen Bestellungen um? Löscht es die gleich wieder? Denn so wie das klingt, macht es das oder etwas in der Richtung. Warum die Zahlung später autorisiert wurde, kann auch nur Secupay beantworten. Gambio kann halt bei einem Modul das Standardabläufe ändert nicht wirklich viel machen.
Bei Modulen, die wir mit unseren Partnern pflegen haben wir immer eine faire Chance direkt mit den jeweiligen zu reden und Probleme auszuräumen. Unter unseren Partnern sind auch viele, die Krediktkarten verarbeiten. Secupay ist aktuell nicht in unserem Partnernetzwerk, das heisst wirklich: für das was das Modul tut oder nicht tut ist allein Secupay verantwortlich. Wir haben keinen Hebel und keinen Einblick.
Ich finde es schade, das Secupay nicht dazu gehört. Eine direkte Kontaktaufnahme wäre am sinnvollsten. Secupay hat mir nun etwas ausführlicher geantwortet. Anscheinend ist ein Problem die Laufzeit einer Session von 24 Minuten. Zusätzlich kann diese Laufzeit auch durch den Installations-Server begrenzt sein. Anscheinend ist die Laufzeit der Session im Secupay nicht so begrenzt und war in meinem Fall mehrere Stunden lang aktiv. Auch wurde diese Session aktiv gehalten, obwohl zunächst eine Ablehnung durch die Kreditkartenbank kam. Secupay machte auch verantwortlich, das der Kunde bei einem Gastkonto nicht gespeichert würde, bei mir hat dieser Kunde jedoch ein Konto eingerichtet. Aktuell klopfe ICH devot wieder bei Secupay an um zu erfragen, ob den Version 2.7.3 von Gambio funktioniert. Kann man irgendwo die Mitglieder des Partnernetzwerkes einsehen?
Secupay wird hier das Modul umschreiben müssen, so dass es temporäre Ordern schreibt, bevor der Kunde zu Secupay geht. Das ist der einzig brauchbare Weg eine Order über einen Kontextwechsel (aus dem Shop zu anderer Webseite und dann irgendwann wieder zurück) aufrecht zu erhalten. Sich da auf eine Session im Shop zu verlassen ist keine gute Taktik.
Bei einem Session-Ende nutzt aber auch das nichts, weill die temporäre Order-ID ja in der Session gespeichert wird....
Das ist Unfug, da das Speichern so oder so erst nach dem Klick auf den Button geschieht, mit dem die Bestellung rechtsverbindlich abgesendet wird. Umentscheiden ist an dem Punkt nicht mehr möglich.
Die Bestellung an sich ist aber vollständig gespeichert. Wenn man das entsprechend implementiert, kann das trotzdem noch ziemlich rund funktionieren.
Könnte es daran liegen, dass beim Logout die Gastkonten gelöscht werden, so dass die Zahlungsbestätigung diese nicht mehr findet und deshalb nicht durchgeführt werden kann?
Ich kenne den Code, und beim Logout werden die Gastkonten gelöscht, wenn so konfiguriert. "LogoffContentControl.inc.php" Code: public function proceed() { //delete guests from database if(!isset($this->v_data_array['GET']['logoff'])) { if(is_numeric($_SESSION['customer_id']) && (int)$_SESSION['customer_id'] == (double)$_SESSION['customer_id'] && $_SESSION['customer_id'] > 0) { $this->delete_guest_account($_SESSION['customer_id']); $this->reset_session(); } $redirectUrl = $this->_buildRedirectUrl(); if(isset($_SESSION['language_code'])) // Keep language selection after logout. { $redirectUrl .= '&language=' . $_SESSION['language_code']; } $this->set_redirect_url($redirectUrl); } else { $this->_resetNotificationsStatus(); } /* @var LogoffContentView $logoffContentView */ $logoffContentView = MainFactory::create_object('LogoffContentView'); $this->v_output_buffer = $logoffContentView->get_html(); return true; } Hier wird ein Gastkonto gelöscht, und die Session zurück gesetzt. Wenn danach versucht wird, eine Zahlung zu bestätigen, wird der Auftrags- und Kunden-Context nicht mehr gefunden. Der Kontext ist ja i.d.R. die Bestellnummer./Kundennummer.
Ich meinte den Code des Zahlungsmoduls. Wenn das die Zahlung an die customers_id bindet statt an die orders_id, dann ist das einfach grundsätzlich falsch.