OK, das war mir nicht klar und ich bin auf Nummer sicher gegangen. Dann knipse ich es wieder an. Hier gibt's noch nen Bug - das Pay Later Banner wird bei uns vehement im Warenkorb angezeigt, obwohl dies ausgestellt ist. Ich mach ein Ticket.
Wenn man die Einstellung ändert kann es einige Minuten dauern bis die zieht. Du speicherst da im Prinzip eine Einstellung im Hub, die der Shop durchaus regelmässig von dort neu zurück liest, aber eben nicht absolut ständig. Da wird gecached. Das senkt Latenzen für Kunden und senkst auch Last und Abhängikeit vom Hub.
OK, dann schaue ich nachher mal. Jetzt nach ca. 10 Minuten isses immer noch da... Wobei der Button im Warenkorb schon vorher ausgeknipst war, ich habe nur Pay Later bei den Paypal-Zahlweisen wieder angeschalten, sprich, an der Einstellung für den Button wurde nichts geändert.
GIROPAY läuft auch nicht. Das haben wir aber in allen Shops, auch außerhalb Gambio. Das Geld geht auf das Zwischenkonto, dann aber nicht weiter zu PayPal. Die Kunden sind in Aufregung, weil Geld vom Konto weg und keine Ware.
Normal ist das nicht mehr möglich, es war aber mal möglich. Für welchen Zeitraum hast du das bei dir beobachtet? Reden wir von einem aktuellen Fall, oder über etwas vor 3 Monaten? Von wievielen Kunden bei dir weisst du von dem Problem? UNd hast du das jetzt nur in anderen Systemen beobachtet, oder auch in Gambio? Für aktuelle Fälle in Gambio Shops gerne ein Ticket. Ich müsste jetzt etwas ausholen was PayPal bei sich verändert hat um solche Fälle zu 99% zu eliminieren, aber da ist vor ner Weile mal was dort geändert worden, nachdem unter anderem wir Dinge moniert hatten, die uns abstellbar erschienen. Was aber allgemein bei den alternativen Zahlungsweisen gilt: PayPal führt die mit eigenen Partnern durch. Wenn ein Zahlung durch einen PayPal Partner belastet wird, aber nicht zu vollständigem Abschluss kommt, geht das Geld normal zurück an den Kunden. Je nachdem welche alternative Zahlungsweise das ist, dauert das üblicherweise 3-5 Tage. Verschwunden ist da unseres Wissens nach noch nie was.
Was denn für ein Zwischenkonto? Ich dachte, all diese alternativen Zahlweisen seien für den Händler komplett transparent - sprich, es sieht bei Zahlungserfolg immer so aus wie eine Paypal-Zahlung. Ich muss glatt mal nachsehen, welche PP-Zahlweisen die Kunden bei uns so benutzen.
Das funktioniert wie folgt: Ein Kunde wählt eine alternative Zahlungsweise. Dafür hat PayPal Abwicklungspartner, bei Giropay ist es glaub ich PPro, an die gibt PayPal den Job ab. Ppro macht dann den Einzug beim Kunden und reicht das Geld im Hintergrund an PayPal weiter. PayPal weiss unmittelbar, dass das Geld von ihrem Partner kommt und schreibt es vorab dem Händler gut. Am Ende ist das dann für den Händler eine ganz normale PayPal Zahlung, nicht zu unterscheiden von anderen. Der Einzug beim Kunden passiert dabei unmittelbar, wenn sich der Kunde auf der Zahlunsmittelwebseite aufhält und sich da durchklickt, noch bevor er in den Shop zurück kehrt. Das ist bei Giropay, Sofort und weiteren unverrückbar so. Ein funktionales Risiko entsteht dann, wenn PayPal nicht mitbekommt, dass das alles final gelaufen ist. In den Anfangszeiten der alternativen Zahlungsweisen war es zum Beispiel so, dass der Shop noch ein Signal an PayPal senden musste, um das finalisieren. Das hat der Shop sofort nach Rückleitung des Kunden abgesendet, aber wenn Kunden das zugeklicht haben, noch bevor der Shop wieder geladen war, konnte das nicht passieren. Zuerst haben wir das von unserer Seite abgestellt. Wir haben uns von PayPal Signale über den Prozessfortgang ans Hub senden lassen. Wann immer da für eine alternative Zahlungsweise das Signal eines Prozesses in der Schwebe kam, haben wir das Abschlusssignal von dort gesendet. Die erfolgreiche Rückleitung in den Shop wurde damit zur Nichtbedingung. Es war ein Benefit der Existenz des Hubs, aus den Shops heraus hätten wir das nicht mal eben lösen können. Eine Weile später hat PayPal dann begonnen jede schwebende APM Zahlung von selbst als abgeschlossen zu markieren. Das wurde nicht kommuniziert und hat uns auch überrascht, verringerte aber immerhin auch irgendwie das Problem. Andere Systeme hatten vermutlich noch mehr Probleme das Thema zu lösen und waren schlechter aufgestellt als wir... Und das ist nach unserem Stand immer noch der Status Quo. Wir haben soweit keine Indizien für neue Probleme und betrachten die alternativen Zahlungsweisen für den Moment als stabil. Das was Angelina sagt passt nicht dazu, darum hab ich nachgehakt ob das aktuell ist und wirklich Gambio betrifft, das konnte ich da nicht eindeutig lesen. Wenn wir doch was neues lernen sollten, werden wir das aufgreifen und einen Schlachtplan machen, aber ich wäre überrascht wenn wir das müssen. Wir denken die alternativen Zahlungsweisen sind solide einsetzbar. Es war ein kleiner Weg dahin, aber wir sind eigentlich da.
Hallo zusammen, wir hatten 8 Tage im Shop keinen Verkauf mit Paypal. Heute rief ein Kunde an und sagte, dass der Bestellvorgang gestern beim Anwählen von PayPal einfach abgebrochen wäre. Wo kann man im Mietshop (Gambiocloud) solche Fehler in Statistiken einsehen? Ich habe Sorge, dass mir unbemerkt über Tage Umsatz verloren geht weil irgend etwas klemmt und ich es nicht mitbekomme.
Bis zum Ende konsequent funktioniert das gar nicht. Das Zauberwort ist Tracking, aber dazu muss etwas wie Google Analytics eingebunden sein, der Kunde muss der Benutzung zustimmen und jemand muss die Daten dort dann auch verfolgen. Man muss das nehmen so gut es geht, und dazu Werkzeuge wie Nutzertracking zu verwenden kann ich nur raten. Wir holen uns da auf unseren Seiten auch viele Daten über unsere Nutzer heraus.
Wir hatten dieser Tage auch diverse Abbrüche und Mehrfachversuche von Kunden, eine Bestellung zu platzieren. Immer Paypal. Anscheinend schrauben diese noch am Checkout herum. Dabei sind das keine Zahlungsweisen mehr, die eine Bonitätsprüfung nach sich ziehen - gestern betraf es bei einem Kunden die Sofortüberweisung. Das ist eben so, aber was stört, sind die daraus resultierenden Bestellungsleichen, die man dann manuell stornieren muss. Grade bei niedrigem Bestand befördern diese ein Produkt temporär gern mal in den Zustand "nicht am Lager" und halten so andere Kunden vom Kauf ab. Keine Ahnung, ob Gambio hier entgegenwirken kann oder ob das nicht möglich ist.
Wir überlegen seit längerem, wie wir diesem Problem beikommen können. Eine Lösung muss ja nicht nur realistisch umsetzbar sein, idealerweise macht sie an anderer Stelle auch nichts kaputt. Geht schon los mit Fragen wie: an welchem Merkmal kann ich erkennen, wann und wo meine Lösung greifen soll? Und ist das Merkmal zuverlässig oder kommt das mal so und mal so, kann also auch zu falsch-positiven führen? Reden wir vielleicht sogar von einer Kette von Merkmalen, die nur unter bestimmten Umständen in bestimmter Abfolge kommen und nur dann ein Eingreifen erfordern? Wie setze ich eine Lösung dann so um, dass sie möglichst viele realistisch vorkommende Szenarien abdeckt? Wem jetzt schon der Kopf raucht - danke für euer Mitgefühl. Schokolade und andere Nervennahrung gern an die bekannte Adresse senden.
danke! Was spricht gegen ein automatisches Storno bei nicht-Erfolg der Zahlung? Letztlich ist es genau das, was ich hier mache. Bestellung nicht bezahlt worden, keine Bestellbestätigung versendet - Storno. Wenn schon allein das automatisch laufen würde, super. Bei uns dürfte da auch kein falsch-positiver Fall auftreten. Ob das bei anderen Setups der Fall sein kann, weiß ich natürlich nicht.
genau das passiert bei Zahlungen über Mollie einwandfrei und ohne mein Dazutun. Sollte also auch im HUB möglich sein.
Zum Beispiel das Lagerrückbuchungen nicht automatisch möglich sind. Bei einfachen Artikeln ja, bei Artikeln mit Varianten ists auch lösbar, aber nicht bei Artikeln mit Zusatzoptionen. Das ist noch ein Überbleibsel der verkorksten Architektur der alten Artikelattribute und einer der vielen Gründe, warum die dringend mal wegmussten. Die Aufräumarbeiten da dauern nur halt noch an. Nein, das kann auch Mollie für die fraglichen Fällen zu 200% sicher nicht. Das ist immer nur genau dann ein Problem, wenn die Asynchronität der spezifischen PayPal Subzahlungsweise für Verzüge beim Erhalten des Erfolgsstatus sorgt, und da kann das externe Molliemodul eher weniger als wir. Man verwechsle da bitte keine PayPal Wallet Zahlungen (das ganz klassiche PayPal-PayPal) mit den etwas komplexeren PayPal- Zahlungsweisen. Mit den Wallet Zahlungen haben weder wir noch Mollie Probleme.
Also ich muss sagen, dass Paypal sich als Anbieter jeden Tag schlechter macht. Ich habe häufig Probleme im Shop mit abgebrochenen Zahlungen. Aber höre noch häufiger, dass Kunden die Bestellung gar nicht ausführen können. Also somit taucht Sie bei mir auch nicht als offen auf. Das ist noch viel schlimmer für mich als Zahlungen die nicht durchgeführt werden können. Da ich nciht weiß, wie viele Bestellungen gar nicht ausgeführt werden.
Hallo Barbara, ich habe dann gestern im Zahlungsmodul nochmal eine kleine Änderung vorgenommen und damit neu gespeichert. Und siehe da, nun gehen wieder Bestellungen ein und auch der Kunde mit dem Abbruch vom Vortag konnte bestellen. 8 Tage völlig tot und dann geht wieder etwas mit gleich mehreren Bestellungen. Das kann Zufall sein, aber es hinterlässt bei mir ein flaues Gefühl. Es wäre echt super wenn es außerhalb von Analytics einen kleinen Monitor bzw. ein Log geben würde, in das man reinschauen kann ohne gleich ein Ticket zu eröffnen.
@Marcel-H: Das Modul "Offene Warenkörbe" von Xycons hilft... Die besten 99 EUR, die wir je investiert haben. @Wilken (Gambio): hm, aber ich kann doch wunderbar beim Storno manuell in's Lager zurückbuchen, auch bai Varianten-Artikeln? Oder benutzen wir da irgendwelche Features nicht, die hakelig sind? Vorgestern hat mir so eine Rückbuchung eines Artikels bei Storno allerdings ein Sonderangebot deaktiviert. Muss man sich wohl merken, dass das passieren kann, warum auch immer.
Das hat mein Kunde auch berichtet. Es bricht einfach ab. Er hat es mehrfach versucht und dann zunächst aufgegeben.