Status "not_finished" bei Zahlung

Hallo,

es kommt leider immer wieder vor, dass Kunden ordnungsgemäß bezahlen, der Status aber auf “not_finsihed” steht. Somit wird die Bestellung nicht beachtet und rutscht durch.
Früher hatten wir eine direkte Anbindung an Sofortüberweisung, da trat es ab und zu auf. Aktuell wickeln wir fast alles über Mollie ab (anderes Modul, andere Anbindung) und auch hier passiert es bei Sofortüberweisung, Klarna Rechnungskauf und ab und an mit Giropay. Mittlerweile ist fast täglich ein Fall dabei.
Hat jemand dasselbe Problem? Weiß jemand, ob das an OXID liegt oder am User (Browser, Verbindung usw.) oder am Zahlungsanbieter?
Ist ziemlich nervig und natürlich auch ärgerlich für den Kunden.

Grüße

Chris

Haben wir auch gelegentlich bei Klarna, wir benutzen nur Klarna, das die Geschichte durchrutscht und dann im Klarna System als storniert steht. Wir haben das mal versucht zu untersuchen und es dann aufgegeben da es offenbar an Klarna liegt es dort aber niemanden gibt der es wirklich erklären kann. Es ging da immer hin und her liegt an euch, Nein, doch, der Kunde wurde nicht akzeptiert oder der Kunde hat nicht nochmal bestätigt während der Kaufabwicklung, aber ne richtig Erklärung gibt es leider nicht bzw. haben wir keine finden können und keine bekommen. 99,9% der Zahlungen funktionieren, der Rest wird informiert und kauft zu 95% nochmal. Ist nicht optimal aber so wenig das es zu vernachlässigen ist.

Das kann daran liegen, wie die Zahlungsverarbeitung im Bestellprozess von Statten geht. Wenn der gesamte Zahlungsprozess (also bei CC z.B. die Reservierung bis zur Buchung und Freigabe an den Shop) zwischen den Bestellschritten 4 und 5 passiert, kann es schon mal vorkommen, dass ein Timeout oder Fehler in der Kommunikation zu unvollständiger Bearbeitung auf Seiten des Shops führt. Beim Zahlungsanbieter wird die Zahlung zwar final bearbeitet. kann dann aber z.B. nicht mehr in den Shop zurückgemeldet werden.

Für unseren Fall (Unzer) arbeiten wir aus solchen Gründen mit Webhooks. Die melden unabhängig des Kundenbrowsers oder der Kundensession auftretende Statusänderungen im Nachgang an den Shop. Abbrüche aus den o.g. Gründen stellen damit dann kein echtes Problem mehr dar.

Voraussetzung dafür ist natürlich, dass der Paymentanbieter und das OXID-Modul solche nachträglichen Statusmitteilungen unterstützt.

1 Like

Ich würde das Thema gerne wieder hochholen. Leider passiert der Fehler nach wie vor in aller Regelmäßigkeit. Kunde drückt auf “Kostenpflichtig bestellen”, bezahlt und wenn er wieder in den Shop zurückkommt, sind die Produkte noch im Warenkorb. Die Bestellung wird angelegt, ist bezahlt, im Status steht aber not_finished.
Wir haben uns jetzt mal die Tabellen angeschaut und es gibt für diese Bestellungen einen Zeitstempel für die Bezahlung. D.h. OXID erhält die Info über den webhook von Mollie, dass die Zahlung funktioniert hat. Aber der Status wird nicht von not_finished auf OK gesetzt.
Bei den betroffenen Fällen ist auffällig, dass bei vielen (ob es alle sind kann ich nicht sagen), der Zeitraum zwischen Bestellung und Bezahlung mehrere Minuten oder länger auseinander liegt. Also z.B. Bestellung 19.02 Uhr, Bezahlung 19:06 Uhr.
Vielleicht kann jemand was mit dieser Schilderung anfangen.
Ist es im OXID Shop überhaupt möglich, dass der Status von not_finished natchträglich auf ok gesetzt wird?

Grüße

Ich kann nicht für das Mollie Plugin sprechen, jedoch aus unserer Erfahrung mit Unzer berichten:

Die Transaktion läuft meist dann ab, wenn der Kunde im Browser seine Aktionen tätigt, also die Bestellung abschließt. Während der Zeit gibt es eine Session, mit der die Zahlungsanbieter mit dem Shop kommunizieren können. Läuft die Session irgendwann ab oder wird ungültig, kann der Payment Provider darüber keine Veränderungen mehr vornehmen, da der Shop die entsprechende Bestellung nicht zuordnen kann. Das passiert z.B., wenn die Zahlungsabwicklung länger dauert, als der Checkout des Kunden.

Aber ja, es ist im OXID auch nachträglich möglich, z.B. den Status einer Bestellung anzupassen. Dazu muss das dann aber über andere Wege als die aktuelle Session laufen. Wie ich weiter oben schon schrieb, arbeiten wir hierfür mit Webhooks, die zur Identifikation der jeweiligen Bestellung keine Session brauchen. Das System ist deutlich weniger störanfällig und kann sich auch eine lange Zeit später immer noch beim Shop für Statusänderungen melden.

Hallo Daniel,

danke für die Ausführungen. Ist das mit dem webhook eine individuelle Programmierung oder kann man das käuflich erwerben? Doofe Frage, aber ich kenne mich da nicht aus.

Grüße

Das ist eine Funktion, die vom Zahlungsanbieter angeboten werden muss. Dann kann die ggf. ins Modul integriert werden.

Dazu wendest Du Dich am Besten an den Modulautor. Er/sie sollte die Möglichkeiten am ehesten kennen.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.