Hi,
nach dem Update auf 6.2. haben wir sporadisch den Fall, dass Zahlungen bei uns eingehen, jedoch im Shop keine Bestellung angelegt wurden. Gerade hat sich wieder eine Kundin gemeldet. Die Kreditkarte ist belastet, eine Bestellung nicht zu finden. Auch mit Paypal ist das schon mehrmals vorgekommen.
Hat noch jemand diese Erfahrung machen müssen?
Viele Grüße
Alex
sind diese Bestellungen in der Datenbank vorhanden, werden aber im Admin nicht angezeigt?
Ja, das Verhalten normal.
Bei PayPal gibt es zwei Varianten:
Das mit PayPal Login und Bestätigung die Bestellung abschlossen und Kunde landet auf Thankyou Seite
Das nach PayPal Login und Bestätigung bei PayPal der Kunde nochmal auf der Überprüfungsseite landet und im Shop die Bestellung abschließen muss
Seit einer neueren PayPal Version gibt es dafür eine Checkbox in den Moduleinstellungen, welcher Fall verwendet werden soll.
Wenn die Checkbox aktiv dann Variante 1 und bei deaktiviert Variante 2.
Bei Variante 2 findet eine Vorab Authorisierung der Kreditkarte statt, dies heißt der Bestellbetrag wird auf der Kreditkarte des Kundens reserviert aber noch nicht abgebucht. Für die Abbuchung ist es erforderlich das der Kunde die Bestellung noch im Shop abschließt.
Sollte der Kunde die Bestellung nicht mehr im Shop abschließen, dann verfällt die Authorisierung der Kreditkarte irgendwann und es wird auch nichts abgebucht.
Dies verwirrt aktuell viele Kunden, da Sie denken das Geld bereits abgebucht. Dies aber meist nicht der Fall, sondern das der Kunde einfach vergessen hat Bestellung abzuschließen.
Viele Grüße,
Tim
Dort am besten über Sandbox Modus testen ob es irgendwo Schwachstellen gibt, wo die Bestellung nicht gespeichert wird. Neben den Bestellabschluss ist die Konfiguration des PayPal Moduls als Zahlungsart sehr komplex und bietet viele potenzielle Fehlerquellen.
Was es auch noch zu beachten gibt, dass PayPal Modul nach Device Desktop und Mobile unterscheidet bei der Versandkosten Übermittelung. Dies aber häufiger Grund für Kaufabbruch über Mobile wenn nicht korrekt konfiguriert.
Sorry hatte die Überschrift überlesen mit PayOne. Bei PayOne gibt es gute Möglichkeiten eine Transaktion zu debuggen. Über das Portal von PayOne die Transaktionen mit Shop vergleichen. Wo Lücken sind dann eventuell mal in den Serverlogs nach potenziellen Fehlern suchen oder vielleicht wurden auch Fehler in die OXID Framework Log Dateien geschrieben. Ansonten das Error Handling für LIVE hochdrehen, dass auch Warnings etc. mitgeloggt werden. Oder das PayOne Logging aktivieren und beobachten.
Hi,
danke schon einmal für die Hinweise. Also die Bestellungen sind tatsächlich nicht in der Datenbank gespeichert. Ich hab jetzt mal in den PayOne-Logs nachgesehen und die letzte fehlende Bestellung per Kreditkarte rausgesucht.
API-Logs: ein Eintrag um 14:33 Uhr einen API-Request
Transaktionen: um 14:43 Uhr einen appointed und um 14:51 Uhr einen “paid”-Eintrag.
Könnte es sein, dass die Kundin einfach zu lange gebraucht hat?
Ich weiß im Detail nicht wie dies bei Deiner Kundin abgelaufen. Dort wird etwas in der Kommunikation zwischen Shop und PayOne nicht geklappt haben.
Ich würde wie folgt vorgehen in den Server Access Logs zwischen Deinen Zeitfenster mir die Aufrufe zwischen 14:30 bis 14:55 Uhr angucken. Dann könnte man evtl. besser verstehen was bei Deinem genannten Beispiel passiert ist. Welche Requests im Shop stattgefunden haben ob z.B. die Thankyou Seite erreicht wurde etc.
Was anscheinend funktioniert hat, dass der Shop nach PayOne die Bestellung übermitteln konnte, aber die Zurückleitung zum Shop aus irgendeinen Grund nicht funktioniert hat. Was dazu geführt hat, dass die Bestellung nicht abgeschlossen werden konnte.
Da würde ich auch nach gucken ob im Shop in der entsprechende Datenbanktabelle nicht doch eine Bestellung vorliegt, aber diese halt im Admin-Bereich nicht auftaucht weil nicht abgeschlossen…
Hintergrund häufig wird die Bestellung bereits im Shop angelegt bevor diese nach PayOne gemeldet wird. Aber dies hängt von vielen Faktoren ab wie z.B. Zahlungsart, Einstellungen beim Shop, Einstellungen bei PayOne etc.
Im Prinzip gilt es nun herauszufinden ob es am Shop oder PayOne liegt. Wenn PayOne dann kann nur dort der Support helfen, wenn es am Shop liegt kannst es selber lösen. Es gibt in seltenen Fällen auch Probleme weil PayOne gerade nicht erreichbar. Da vielleicht bei PayOne nachfragen ob deren Schnittstelle genau zu Deinen genannten Zeitpunkt down war.
Die stellen grad alle wie verrückt auf 2FA um.
Ich hatte so ähnliche Fälle neulich ausserhalb des OXID-Umfeldes auch schon: 2FA = SMS mit PIN auf’s Handy funktioniert nicht, weil irgendein Mobilfunkanbieter aussteigt. Ergebnis: Betrag war im KK-Konto vorgemerkt, Bestellung nicht beim Onlinehändler angekommen, vorgemerkter Betrag verfällt irgendwann wieder. Mit anderen Worten: Das kann alles mögliche sein, falls irgendeine Komponente dazwischen grad nicht funktioniert, wenn just im Moment der möglicherweise positiven Rückmeldung vom PSP an den Shop irgendein Netzelement aussteigt oder wasweissich…
Genau dasselbe Problem hatte ich mit Payone-PayPal über 7 Jahre lang immer wieder mal.
Nach mehrfachen Diskussionen mit dem Payone-Service stellte sich letztendlich heraus, dass Payone nur 1-mal versucht die Verbindung zum Shop aufzubauen und wenn das fehlschlägt, folgt kein weiterer Verbindungversuch. Der Fehler wird vom Payone-System ignoriert und nicht protokolliert. Hauptsache Payone hat seine Transaktion mit PayPal erfolgreich abgeschlossen und bekommt dafür seine Gebühr - was im Shop fehlt ist Payone offenbar egal, weil das Problem nie gelöst wurde !
Seit OXID 6.x läuft bei mir mit den OXID/PayPal-Modulen alles 100% korrekt.
Hallo,
ich habe jetzt doch mal einige Hunderter in die Hand genommen und den Fall direkt von Fatchip überprüfen lassen. Hier ein Auszug aus der Antwort:
Wie den Protokollen zu entnehmen ist, war die Kommunikation mit Payone erfolgreich, aber der Rücksprung zum Shop schlug fehl, was die Speicherung der Bestellung verhindert. Sehr wahrscheinlich war der Grund für diesen Fehler, dass die Session verloren ging. Einen Fehler im Modulcode können wir ausschließen. Ein weiterer Hinweis aus das Sessionproblem war der Browser-Agent, der in den Protokollen als “PrivacyBrowser” identifiziert wurde, wie hier gezeigt:
[95.163.XXX](http://95.163.XXX/) - - [03/Jan/2021:15:47:35 +0100] "GET /index.php?cl=order&fcposuccess=1&ord_agb=1&stoken=E7XXX&force_sid=XXXX&refnr=XXX&fnc=execute&sDeliveryAddressMD5=XXX&rtoken=daee23f9 HTTP/2.0" 302 - "-" "PrivacyBrowser/1.0" 428 282
[95.163.XXX](http://95.163.XXX/) - - [03/Jan/2021:15:47:35 +0100] "GET /index.php? HTTP/2.0" 200 10814 "-" "PrivacyBrowser/1.0" 39 10963
Hier ist der erwähnten Browser und die Tatsache, dass die Weiterleitung auf die Dankeseite nicht wie erwartet erfolgte, zu sehen.
Wir empfehlen Ihnen die Option „Bestellung vor Authorisierung speichern“ zu aktivieren. Die Bestellung wird dadurch schon vor der Authorisierung als unvollständige Bestellung abgespeichert. Dadurch steht die Bestellnummer auch PAYONE zur Verfügung. Sobald der Transaktionsstatus von Payone kommt, wird dann diese Bestellung in den korrekten Status gesetzt.
Des Weiteren sollte ein Hinweis erfolgen, dass die Nutzung von Privacy Browsern oder Privacy Tabs einen korrekten Bestellabschluss verhindern kann.
Vielleicht kann ich damit ja anderen helfen.
Gruß
Alex
Hey danke für das Feedback. Das in der Tat interessant. Die erwähnte Einstellung sicherlich die Beste Lösung um sicherzugehen, dass vor Request an PayOne die Bestellung im Shop bereits gespeichert wird.
Der Browser selbst “PrivacyBrowser/1.0” scheint ein ziemlicher Exot zu sein User agent string “PrivacyBrowser/1.0” bzw. https://www.stoutner.com/privacy-browser/
Das Kernproblem sollte hier dabei liegen, dass anscheinend JavaScript gar nicht unterstützt wird bzw. bewusst deaktiviert ist. Dies kann das Checkout Verhalten des kompletten Shops sehr stark einschränken.
Update: Am praktikabelsten wäre daher im Checkout eine Prüfung ob JavaScript aktiviert bzw. unterstützt wird. Wenn deaktiviert oder nicht unterstützt eine Warnung als Hinweis anzeigen.
Viele Grüße,
Tim
Die Option „Bestellung vor Authorisierung speichern“ hatte ich Anfang Dezember mal aktiviert. Problem war dann jedoch unserer Wawi, die die Aufträge trotz unvollständigem Zahlungsstatus abgeholt und weiterverarbeitet hatte. So kam es, dass Aufträge doppelt oder unbezahlt geliefert wurden.
Dafür gibt es das Feld oxorder.oxpaid wenn dies okay dann sollte WaWi Datensatz abholen dürfen vorher nicht.
In der Regel sollten so auch 2 Einträge in oxorder entstehen (durch die Einstellung), weil die Zuordnung nicht ganz sauber. Aber über oxorder.oxpaid sollte sichergestellt sein, dass nur Einträge übernommen in WaWi die auch bezahlt.
@ Hupi, die Aussage von Fatchip stammt von Protokollen eines Falls im Zusammenhang mit einer Kundenbestellung. Wurde der Ablauf auch mal mit einem sog. Privacy Browser (z.B. Opera) selbst getestet, um zu sehen ob das Problem wirklich am Browser liegt?
Der Ablauf ist nach meiner Kenntnis so: 1. Shop “zahlungspflicht bestellen” > 2.Shop sendet Zahlungsrequest an Payone > 3.PayPal > 4.Payone erhält Zahlungsbestätigung von PayPal > 5.Payone sendet nur einmal an Shop, protokolliert aber keine Fehler und macht keine neuen Versuche > 6.Shop Bestellung nicht in der Datenbank gespeichert, weil Zahlungsvorgang nicht abgeschlossen werden konnte.
Ist dann wirklich der Browser des Kunden oder Payone das erste Problem?
Es handelt sich um ein Sessionproblem. Die Session ist im Browser des Kunden hinterlegt. Was man festhalten kann, ist dass die Session im Browser verloren gegangen ist und so der 5. PayOne sendet nur einmal an den Shop erfolgt ist. Aber der Shop beim Abgleich keine gültige Session gefunden hat.
Die oben genannte Einstellung verhindert, dass die Bestelldaten aus Shopsicht nicht verloren gehen in so einem Fall. Daher stellt dies aus meiner Sicht die beste Lösung dar.
Klar könnte man analyiseren wie häufig die Session verloren geht ob es sich dabei um Einzelfälle handelt oder ob es doch häufiger vorkommt.
Update: Selbst ein mehrfacher Request von PayOne an Shop würde daher das Problem nicht lösen, weil PayOne könnte soviele Requests an den Shop senden wie es wollte. Wenn die Seesion einmal “verloren”, dann wird der Shop den Request nie richtig einordnen können.
Gerade hab ich schon wieder eine Rückmeldung bearbeitet. Damit ware es 3 Kunden an einem Tag. Diese spezielle Kundin war mit nem iPhone und Safari unterwegs und hat per Visa bestellt. Hier können wir also Datenschutz-Browser etc. ausschließen. Ich denke auch, dass einfach die Session verloren geht und der thankyou-Controller dann auf die Startseite weiterleitet.
Dass die Session verloren geht ist ja schon klar aber weshalb bleibt immer noch fraglich.
Wie schon gesagt konnte dasselbe Payone-PayPal-Problem bei mir auch nicht gelöst werden aber ohne Payone funktionieren Transaktionen mit dem PayPal-Modul in Oxid 6.1 fehlerfrei, seitdem gibt es keine einzige Kunden-Reklamation mehr.
Die Browser werden immer strikter bezüglich Third-Party Cookies und dann kommt jetzt noch hinzu das 2-Auth zur Pflicht geworden ist für die Zahlungsanbieter.
Das die Session verloren geht kann am Browser liegen, aber möglich ist dies auch wenn beim Hoster ein Caching System greift oder die Last verteilt wird bei der Antwort der PayOne Request nicht auf demselben Server landet wo die Session hinterlegt.
Das sind leider alles nur Spekulationen, mit denen das Problem seitens Shopbetreiber nicht gelöst werden kann und Payone kümmert sich selbst auch nicht um eine Lösung, sondern schiebt es auf den Modulprogrammierer Fachtchip.
Dann bleibt doch nur noch Payone kündigen und stattdessen direkte Anbindung an PayPal und andere Zahlungsarten.
Mit Hilfe eines netten Kunden haben den Fall nachgestellt und eine (von evtl. mehreren) Ursachen gefunden. Der Kunde hat Kasperski “Sicherer Browser” installiert. Durch dieses Programm öffnet sich das Paypal-Login in einem neuen, sicheren Browserfester. Nach Durchführung der Transaktion landet der Kunde erwartungsgemäß auf der Startseite. Eine Bestellung wird nicht gespeichert.
