Ich habe den max. Warenkorbwert einfach etwas erhöht und dann neu gespeichert. Der Kunde bei dem es zum Abbruch kam, lag aber deutlich unter dem voreingestellten Wert. Daran lag es also nicht. Ggf. hat sich das System durch das erneute Speichern wieder geheilt? Aber das sind alles nur Vermutungen.
Software heilt sich im Allgemeinen nicht selbst. Eine Option "maximaler Warenkorbwert" gibt es bei uns im Paypal2Hub-Modul nicht. Es gibt "erlaubter Bestellwert", das ist leer.
Nochmal zur Sicherheit eine Wiederholung: Mit dem derzeitigen PayPal ist es normal, dass es Abbrüche gibt. Das liegt direkt an den Zahlungsweisen selbst und gehört zu denen, wenn man das ganze Portfolio nutzt. Direkte Kreditkartenzahlungen, ausserhalb eines PayPal Kontos, liefern harte Abbrüche, wenn da beim Kunden was mit der Karte nicht stimmt oder ein Kunde seine Daten nicht beisammen hat. Rechnungszahlungen sind genauso ein Bonitätsding, die werden nie nie nie für alle Kunden freigegeben, da fallen immer auch welche runter. Wer das ausschliessen will, muss sein Zahlungsweisenangebot zusammenstreichen, und dann entgehen einem die Geschäfte mit den Leuten, die solche Zahlungsweisen suchen. Und da gibts auch genug, die sowas gerne wollen und auch können. Man wähle seinen "Tod", aber einen stirbt man immer. Grosse Vorsicht mit so Pauschalglauben zu irgendwas, das ist allermeistens nicht sachgerecht. Da rufen dann mal 2 Kunden an oder mailen und sagen alles ist kaputt. Natürlich macht eine generelle Überprüfung des eigenen Setups dann Sinn, aber nicht immer ist das kaputt. Es gibt Kunden, die schaffen es nicht 3 Formularfelder ohne Fehler auszufüllen. Es gibt Kunden, die haben einfach keine Knete. Die fallen immer, man kriegt die nicht. Und die werden einen Teufel tun anstatt ein Problem bei sich zu vermuten... Das ist auch bei uns so, in unserer ureigenen Kundschaft. Man sollte meinen, dass Leute die selber Händler sind eine hohe Kompetenz besitzen die Probleme bei eigenen Zahlungen zu erkennen, trotzdem erleben wir bei einer gewissen, kleinen Menge ständig die dollsten Dinger, die nicht unbedingt an technischen Problemen bei uns oder unseren Zahlungsdienstleistern liegen... Leute, die dann noch ausserhalb der Bubble hier sind, da wirds immer noch etwas mehr sein. Ein blindes um sich schlagen, weil da doch bestimmt etwas im argen sein muss, macht da noch weniger Sinn. Das wirst du auch nie rauskriegen, es gibt keine Tools dafür. Aber mit Tools wie Google Analytics kannste eine Näherung hinkriegen und dann approximieren. Das macht total Stinn den Weg zu gehen, ist nur auch Arbeit. Was hast du denn da getan? Das wird wahrscheinlich nicht als universeller Tipp brauchbar werden, aber vielleicht hilfts ja irgendwas zu verstehen. Was das wirklich nicht können wird... ... ist den Zufall ausschliessen. Ein menschliches Muster: Ich fahre mit meinem Auto und etwas geht dabei kaputt. Beispiel 1, eine Lampe geht kaputt. Ich würde dann nicht anfangen zu überlegen was ich zuletzt am Auto getan habe, weil egal was es sein wird, die Lampe ist wahrscheinlich einfach so kaputtgegangen. Beispiel 2: Ich fahre, es knallt, der Motor platzt und ist kaputt. Vor einem Monat habe ich einen Ölwechsel gemacht, das war die letzte Tätigkeit da. Ist dann der Ölwechsel schuld? Ist das Korrelation oder Koinzidenz? Nichtmal dann ist was sicher, aber wir sind immer geneigt vorherige Aktionen als Ursache für Entwicklungen zu sehen. Stimmen muss das nicht, aber wir versuchen das alle. Das muss nicht klappen oder richtig sein. Kannste nicht. Wenn zum Beispiel im PayPal Popup etwas nicht vorwärtsgeht, oder auf einer PayPal Seite nach Weiterleitung, dann weiss der Shop 0 darüber und PayPal mit Pech selbst auch genau 0. Da weiss dann auch ein Analytics nichts, es kann höchstens zählen wie oft Leute ohne Wiederkehr dahin verschwinden. Ist die Quote dann höher als immer zu erwarten, muss man härtere Methoden ergreifen. Was immer hilft, nur manchmal schwer einzutüten ist, sind Kundenberichte. Hey Kunde, was GENAU hast du gesehen. Was stand oder steht da? Oder hattest du einfach keine Lust mehr und dein Passwort fiel dir auch gerade nicht ein? Wenn man solche Berichte dann an einer sachlichen Wahrheit messen kann, dann kriegt man überhaupt mal irgendwie Informationen... Aber nochmal: Es wird da nie eine 100% Erfüllungsquote geben, das ist illusorisch, aus besagten Gründen. Da weisste aber auch nicht ob jemand nur einfach mal kucken wollte, oder echt kaufen und konnte nicht. Ich selbst klicke mir auch öfter Warenkörbe irgendwo zusammen, starre dann etwas ob ich wirklich kaufen will und entscheide mich, von mir aus, dass jetzt doch nicht bestellen zu wollen. Ohne dass der Shop etwas falsch macht, aber ach, ich brauch jetzt doch keine neue Küchenwaage, sind auch 40 Euro. Zack, weg. Das Problem ist vereinfacht: Du hast einen Artikel, der hat eine Option "Grösse" und ein Kunde bestellt "XL". Dann steht genau das in der gespeicherten Bestellung "Grösse: XL". Jetzt kannst du aber die Option Größe mehrfach im Shop erstellen, vielleicht weil verschiedene Artikelkategorien da unterschiedliche Auswahlen haben. Es ist maschinell unmöglich da dann die richtige Option zu finden, um den Bestand wieder hochzusetzen. Es würde gehen, wenn in einer Bestellung stünde für Option mit ID 31 wurde Wert 6 bestellt, dann kommst du zurück. Dann musste zwar trotzdem auch reinschreiben, dass das "Grösse: XL" bedeutet, damit das noch lesbar ist wenn die Option in Zukunft mal gelöscht wird und man das nicht mehr über die IDs auflösen kann, aber dann biste besser. Das haben wir nicht, das ist mit den alten Attributen hart komplex gewesen das zu bauen, obwohls so einfach klingt. In die Richtung müssen wir sicher kommen, das bedingt nur eben auch, dass die alten Attribute auf keinen Fall bleiben konnten wie sie waren, egal was das an Kompatibilität kaputt macht... Das lässt dann übrigens auch noch aus, dass sich das Setup eines Artikel wegen Datenpflege zwischen Verkauf und Storna ändern könnte, aber das blenden wir mal aus... Was der Mensch nun kann: Wenn jemand, der sein Sortiment kennt in einer Order bei einem Artikel "Grösse: XL" liest, dann wird der wissen wo genau der Bestand wieder nach oben zu korrigieren ist. Der Mensch kanns, die Maschine nicht. Doch. Gerade hier. Das System ist komplex. Wir könnten aufgrund von Meldungen etwas bugfixen, PayPal könnte das bei sich. Vielleicht sind da Server gerade mal kaputt, vielleicht läuft was nicht wie geplant. Vielleicht ist im Internet irgendwo eine Route kaputt und ein Netzwerker auf der Tastatur eingeschlafen. Da wirken in diesem Fall immer viele Faktoren von extern, die niemand sehen kann, aber einen Einfluss haben können.
hm. Leer würde ich mit "unbegrenzt" interpretieren. Ich würde da auch ungern einen Wert für vergeben.
nö, aber ich sehe, wo der Kunde ausgestiegen ist und kann da ggf. Rückschlüsse ziehen. Klar, das Allheilmittel ist es auch nicht, aber es erlaubt einen sehr schönen Einblick in unvollständige Bestellungen, zusammengeklickte Warenkörbe etc. Das sind externe Faktoren, klar. Das meinte ich aber nicht (Bezug auf "Settings nochmal gespeichert, und dann ging es plötzlich").
Leer bedeutet real unbegrenzt, zumindest von Shopseite her. Wenn PayPal für ne Summe sagt ist nicht, dann gibts auch von da eine Bremse. Wäre der Wert in der Modulkonfiguration zu kleine für einen Warenkorb, würden die PayPal Zahlungsweisen nicht angezeigt werden. Wenn die nicht angezeigt werden, kann niemand berichten bei PayPal zu scheitern... Also eher Koinzidenz, keine Korrelation. Zufall.
Bei mir hat ein Österreicher etwas mit Kreditkarte kaufen wollen (KK mache ich über Mollie). Da hat was nicht funktioniert und das System steht auf "Storniert", ohne dass ich es gemacht habe. In der Info dahinter ist ein Briefumschlag, wo bei Mouseover angezeigt wird, dass die Bestellbestätigung nicht versendet wurde. Dann ein paar Minuten später hat der selbe Kunde die KK-Zahlung ausführen können und die Bestätigung ging raus. Das ging alles ohne mein Eingreifen oder Nachbessern. rot= Storniert, grau = Auftrag abgeschlossen / ausgeliefert Ich kann nun nicht nachvollziehen, ob das Storno auch die Bestände zurückgebucht hat, wenn sie überhaupt schon reduziert waren, weil ich bei dem Artikel keinen Bestand pflege. Ich kann aber ganz deutlich sehen, dass der Vorgang automatisch den Status "Storniert" bekommen hat und kurz danach ein neuer Auftrag korrekt durchlief. Egal ob mit Mollie oder HUB. So sollte es eigentlich immer abgefangen werden: Geht keine Bestellbestätigung raus sollte der Auftrag den Status "Storniert" bekommen und der Kunde eine Info.
Diesem Wunsch schliesse ich mich an. Und ja, eine Rückbuchung der Bestände ist hier zwingend erforderlich.
Externe Module können manchmal Dinge, die nicht gehen. Nicht selten fegen wir hinterher die Scherben auf, weil es zu "kleinen Ungenauigkeiten" kam. Da einfach nen Storno Status schreiben wäre billig, könnten wir auch. Es sind die Prozesse drumherum, von denen wir finden Sie gehören unbedingt zu "vollständig" und "verlässlich", die uns aufhalten.
Danke, genau so sehe ich das auch. Und mache die gleichen, überaus positiven Erfahrungen mit Mollie. Jedes Mal, wenn über deren Zahlungsarten bezahlt werden soll und ein Fehler auftritt ist automatisch Storno. Und auch wir haben viele Kunden, die es dann ein weiteres Mal versuchen und dann klappt's. Man kann bei Mollie übrigens sehr gut erkennen, was falsch gelaufen ist. Bei Kreditkartenabbrüchen sind es fast immer Probleme mit 3-D-Secure, sprich: der Kunde hatte entweder seine notwendigen Daten und sein Smartphone nicht parat (heutzutage nun mal zur Zahlungsfreigabe nötig) oder hatte bisher noch gar nicht realsiert, dass es einen weiteren Bestätigungsschritt gibt. Dann greift meist ein time out, Abbruch -> und, yes, STORNO! Geht also (auch bei anderen Zahlungsmitteln übrigens) … Wior haben dann schon oft Kunden kontaktiert und ihnen den Zahlungsablauf erläutert. Da waren nicht wenige dankbar, weil sie das so bisher gar nicht wussten.
Es gibt aber kurzfristig glücklich und nachhaltig glücklich. Kurzfristiges Glück, das dann schnell umschlägt weil genug dafür da ist, können andere machen. Das wollen wir nicht.
Falsch. Das macht viele Support-Tickets. Das sind dann die Sachen, wo wir uns sagen lassen müssen, wir hätten die Sache nicht bis zu Ende durchdacht. Nicht zu Ende durchdacht. Hier ein Fall, den ich schon ein paar Mal beobachtet habe: Kunde bestellt via Sofort. Er führt die Zahlung aus, schliesst aber den Tab im Browser, bevor die Rückleitung in den Shop erfolgen kann. Damit wird der Versand der Bestellbestätigung verhindert, obwohl es eine erfolgreiche Bestellung und Zahlung gibt. Die wäre jetzt storniert und als Kunde würde ich einen Riesenrabatz veranstalten. Andersrum gibt es den Fall auch: Dder Kunde hat ein Problem bei der Zahlung, kommt aber über den Zurück-Button im Browser oder einen Rückleitungslink zurück in den Shop. Dann würde die Bestellbestätigung versendet, obwohl es keine erfolgreiche Zahlung gibt. Wat nu? Stornieren, weil Abbruch oder nicht stornieren, weil die Bestellbestätigung versendet wurde? Es gibt hier keine Methode, die ein "macht das doch einfach" erlaubt. Hier geht es um Geld, euer Geld. Werden die Fälle nicht genau erkannt, kommt es zu falschen Stornierungen. Falsche Stornos kosten Geld.
Mag sein, dass das nicht gut ist, ich zeige hier ja nur einen Lösungsansatz auf, der bei Mollie-Zahlungsfehler wirklich gut funktioniert. Besser 90% geht automatisch, als 100% der Fehler manuell erledigen... Ich bin jedenfalls glücklich damit und wollte nur Kund tun, dass es zumindest bei Mollie mit Kreditkarte "bisher" sehr gut automatisch läuft. Das Geld ist gegenüber K auch schon ca. 1-2 Wochen früher auf meinem Konto, so als i-Tüpfelchen obendrauf.
Ihr könnt auch nicht einfach mal Kundenmeinungen und -erfahrungen einfach so akzeptieren, oder? Wenn doch etliche gute Erfahrungen mit dem Mollie-Setupo machen, warum muss man dann ständig dagegen argumentieren? Das klingt irgendwann ziemlich arrogant. Oder mag es daran liegen, dass ihr mit Mollie bezüglich einer Integration im Hub nicht zusammenkommen konntet?
Gambio sagt "wir können das nicht so umsetzten, weil...." Es gibt hier 5 oder secht User, die schreiben, dass sie mit Molli gute Erfahrungen haben. Dagegen Spricht nichts. Dann haben die vielleicht keine Zusatzoptionen oder keine Bestandspflege bei den Zusatzoptionen, oder eine hohe Stückzahl, wo das nicht gleich auffällt, oder.... Wenn bei einem Shop mit vielen Zusatzoptionen, aber nur geringen Stückzahlen je Zusatzoption, die Bestände nicht mehr passen und man alle paar Wochen Inventur machen muss um das zu berichtigen, ist das sicher nicht prickelnd. Und was macht ein User, der das feststellt? Er schreibt Gambio "da stimmt etwas nciht..." Keiner hier (außer dem Gambio-Support) weiß wie viele User ein Ticket aufmachen und hilfe brauchen. Es sind ja nicht alle User im Forum unterwegs und schreiben hier etwas. Wenn also Gambio schreibt, dass sie da einige Fälle haben, wo es Probleme gibt und dass sie das deshalb nicht mal eben einfach genauso umsetzen können, dann sollte man das auch so akzeptieren.