Probleme mit sofortuberweisung.de: oxpaid leer, Bestllg. trotz Abbruch?!

Hallo zusammen,

bei einem kleinen Bruchteil der Bestellungen, die über sofortueberweisung.de bezahlt werden (oder bezahlt werden sollten), kommt es zu folgendem Ergebnis:

Der Auftrag des Kunden wird als bezahlt verarbeitet, inklusive Bestätigungs-E-Mail etc. Auffallendes Merkmal: Das “bezahlt”-Datum (Spalte oxpaid in der Datenbank) ist nicht korrekt gefüllt, sondern hat den Wert "0000-00-00 00:00:00"
Die Bezahlung kommt nie auf unserem Konto an.

Auf Nachfrage bei sofortueberweisung.de hiess es, in allen untersuchten Fällen hätten die Kunden den Bezahlvorgang abgebrochen. Trotz allem schienen sie aber anschliessend auf den Link für “Bezahlung abgeschlossen” weitergeleitet worden zu sein.

Wir benutzen seit Mitte Oktober das Tronet-Modul für Sofortüberweisung in der Version 4.0.1 in der Kombi mit Oxid CE 4.2.0_23610.
Der Fehler trat sowohl vor als auch nach der Installation der neuen Modulversion auf.

Einer der Kunden behauptete sogar, der Betrag sei von seinem Konto abgebucht worden, obwohl er bei uns nie eingegangen ist. Ein anderer hat dagegen bestätigt, dass nichts abgebucht worden ist.

Hat jemand etwas Ähnliches im Zusammenhang mit sofortüberweisung.de beobachtet?

Viele Grüße
floko

und was sagt Tronet dazu?

Hi,

kenne nur den Fall, dass bei SÜ Zahlungen in seltenen Fällen die Zahlung durchgeführt wird, aber die Bestellung nicht erfolgreich abgeschlossen wird.

Das Die Version 4.0.1 der SÜ Moduls mit der 4.2.x Probleme machen kann ist klar. Die 4.0.1 kam mit / wegen der 4.3.x raus. Da mit der 4.3.x sToken Variablen hinzukamen war das Update auf die 4.3.x ja problematisch. Die alten Module klappen definitiv nicht mit den Shop-Versionen nach 4.3.x , wie groß die umgekehrten Probleme mit aktuellen Modulen und veraltetem Shop (vor 4.3.x) sind kann ich aber nicht beurteilen.

Ansonsten läuft das aktuelle tronet SÜ Modul mit einer 4.3.2 problemlos.

Danke für Eure Beiträge!

Von Tronet erwarte ich keine grosse Unterstützung, da sie das Modul ja schon kostenlos anbieten und sicher nicht jede exotische Versionskombinationen “supporten”, falls überhaupt.

Nach Hinweisen von sofortueberweisung.de habe ich allerdings ein paar Einstellungen überarbeitet, z.B. gab es hier ein neues Passwort-Feld im Backend, das einfach noch leer war. Das Modul hatte trotzdem in den knapp drei Monaten seit dem Update prinzipiell funktioniert. Mal sehen, ob der Fehler noch mal auftritt oder ob es da einen Zusammenhang gibt…

Viele Grüße
floko

Update:
Der Fehler trat danach noch mehrfach auf, darunter einmal auch mit PayPal.
Somit liegt die Ursache offenbar weder bei sofortueberweisung.de noch beim Modul von tronet, sondern irgendwo in der Shopsoftware selbst.