Geh mal auf die Zahlungsweisen Seite im Adminbereich. Du verwendest dort jetzt PayPal2 Hub? Was sieht man wenn du dort rechts auf das kleine i-Symbol tippst im sich dann öffnendn Statusfenster? Gerne zeigen.
Das sieht alles sehr gut aus. Hast du irgendwelche externen Module im Shop, die die Zahlungsweisen Seite überladen und dadrin irgendwas machen? Eventuell blockieren die dann was. Wenn du das nicht klären kannst, mach bitte ein Ticket.
Wir aber Du hast Connector Version 1.16.x, du bräuchtest 1.21.x oder neuer. Das Kapitel im Handbuch und die Hinweise hier, dass der Connector im Shop unbedingt aktualisiert werden muss um an die neuen Sachen zu kommen, muss dir irgendwie entgangen sein.
Zwischendrin nochmal ein Hinweis, für tiefe Mitleser eine kleine Wiederholung: Wenn man mit den neuen Zahlungsmethoden von PayPal arbeitet, gibt es Stand heute einen signifikanten Unterschied zu vorher: Nicht jede Bestellung im Shop ist bezahlt. Man muss also den Bestelllstatus im Auge behalten. Springt der nicht auf bezahlt, gibts hochwahrscheinlich ein Problem. Ohne weitere Kontrolle dann keine Ware versenden! Schaut dann auch in der Infobox vom Hub in der Bestellung auf den Order Status. "Completed" ist gut. "created", "approved", "declined" oder jeder andere sind kein Abschluss sondern Absprünge und Ablehnungen. Wir haben PayPal in der Vergangenheit so konstruieren können, dass eine Bestellung im System quasi immer auch einer erfolgreichen Bezahlung entsprach. Man konnte Daten sammeln, vorab an PayPal schicken, hatte eine recht gute Vorabprüfung durch PayPal, damit waren die Betriebsrisiken in späten Stadien einer Bestellung ziemlich minimal. Das war richtig gut, geht so in der neuen Welt aber nicht mehr durchgängig. Damit steigt zwangsweise die Zahl der Einzugsfehlschläge, wenn beim Kunden entsprechende Probleme vorliegen. Die sieht man jetzt zu grösseren Anteilen als Bestellungen ohne Zahlungseingang. Etwas Hintergrund: Wir sind in manchen Fällen technisch darauf angewiesen Bestellungen vor dem Versuch eines Geldeinzugs im Shop zu speichern. Klappt der Einzug ist alles gut, schlägt der Einzugsversuch beim Zahlungsdienstleister jedoch fehl, ist dann trotzdem eine Bestellung im System. Das Kernproblem ist dabei, dass einige Zahlungsweisen, die PayPal nun integriert, zu einem sofortigen Geldeinzug beim Kunden führen, vor Rückkehr in den Shop. Gelingt die Rückleitung aus irgendeinem Grund zwischen Himmel und Erde nicht (kunde klickt Browsertab zu bevor Seite lädt, Virenscanner oder Adblocker macht magische Sachen,etc....), hätten wir dann ein Problem: Geld (vorübergehend..) im Niemandsland, Kunde motzt, Händler weiss von nichts. Wir wollen also immer etwas da haben, wo wir noch nachträglich Daten dranhängen können. Logisch betrachtet ist das eine Kundenbestellung. Das wäre alles schön, würde es nicht ein anderes Problem aufmachen: Es bleiben auch Bestellungen zurück, für die kein Geld mehr kommen wird. Diese Bestellungen werden, solange man die nicht storniert, Ware aus dem Lager blockieren, die solange nicht verkauft werden kann. Wenn wir die beiden Probleme gegeneinander abwägen ist uns keins davon lieb, aber das zweite ist kleiner und landet vor allem weniger auf dem Rücken eurer Kunden. Was wir in der nächsten Zeit machen werden, ist Muster zu suchen, wann wir tote Bestellungen automatisch abräumen können und für neue Shops einen Prozess dazu anzustreben. Das wird deutliche Eingriffe in den Checkout brauchen, damit gründlich durchdacht und vorbereitet werden müssen. Wenn zum Beispiel früh genug im Prozess logisch klar wird, dass es ein Problem beim Kunden gibt, dann kann man sich technische Reaktionsmister ausdenken und die darauf packen um den neu einzutüten. Zu 100% und für wirklich alle Bestellungen wird das nicht klappen können, aber für doch viele solcher Fälle irgendwie sicher. In manchen Fällen kommt das nötige Wissen nur stark verzögert beim Shop an oder der Shop müsste das irgendwann schlussfolgern, weil gar nichts bei ihm mehr ankommt, da wirds dann schon echt schwieriger. Das wird also alles etwas Arbeit brauchen, aber in das Problem abzutauchen steht auf unserer Agenda für bald ziemlich weit oben.
Da stimme ich (seit Jahren) zu 100% zu. Danke dass Ihr diesen Schritt nun wieder geht - auch wenn das nun anscheinend der Möglichkeiten seitens Paypal geschuldet ist. Rückmeldung aller unserer Shopbetreiber-Kunden: Lieber eine Bestellung im System bei der die Zahlung nicht geklappt hat wie keine Bestellung im System. Wenn die Bestellung zumindest da ist besteht die Möglichkeit mit dem Kunden Kontakt aufzunehmen, auf eine andere Zahlungsweise umzusteigen etc. Ist die Bestellung nicht im System habe ich keinerlei Chance nachzuhaken. Grüße Walter
Heute, drei Tage später, ist eine Mail von Ratenpay endlich gekommen. Nur diese Mail macht es nicht besser. Warum? Ganz einfach, der Text in der Mail ist für eine Stornierung/Fehlerfall sehr unglücklich gewählt. Dort wird dem Kunden gesagt, dass seine Bestellung bezahlt ist und er nichts mehr machen muss. Der ein oder andere Kunde wird sich keine Gedanken machen, sondern jetzt seine Bestellung erwarten. Also da sollte Ratenpay nachbessern, finde ich. Zitat aus der Mail:
Na, du wirst nicht so glücklich sein wenn ich das folgende beantworte.... Wir wollen das wieder loswerden. Wir wollen wieder dahin, wo wir in den letzten Jahren waren. Wir wollen so gut es irgend geht dafür sorgen, dass erfolglose Bestellungen selbstständig wieder abgeräumt werden, nichts soll davon bleiben. Wir müssen uns nur noch einige Dinge einfallen lassen, um da wieder näher hinzukommen.
Warum? Mir ist es lieber ich sehe eine Bestellung die nicht komplett durchgelaufen und offen ist. Da kann man evtl. selber reagieren und den Kunden informieren bevor mich ein Kunde anruft und nach seiner Bestellung/Lieferung fragt und man erstmal alles durchsuchen muss um eine Erklärung für den Kunden zufinden warum seine Bestellung nicht im Shop gelandet ist!
Dahinter stecken folgende Denkansätze: Jede Bestellung, die auf normalen Pfad zuende zu bringen ist, soll berechenbar zuende zu bringen sein. Jede Bestellung, die am vom Kunden gewählten Zahlungsmittel scheitert, sollte den Kunden an einen Ort bringen, an dem er mit einem neuen Regelzahlunsgmittel doch noch zu einem Erfolg kommen kann. Das heisst der Kunde muss möglichst sanft gefangen werden, die Ware darf nicht in irgendeinem Prozess blockiert sein der einen neuen Versuch verhindert, etc. Nötige Vorabchecks, die das so gut wie möglich sicherstellen, sind so früh wie möglich auszuführen. Jede Bestellung die nicht abzuschliessen ist, weil der Kunde einfach nicht zahlen kann, soll keine Ware für andere Kunden blockieren. Lieber eine Folgebestellung eines solventen Kunden, als eine warenblockierende Bestellleiche eines Kunden, der nie bezahlen wird oder nur mit viel manuellem Aufwand durch den Händler. Das heisst ganz klar Bestellleichen müssen sterben, die sollen wann immer möglich aktiv weg. Der Kunde hat wann immer möglich frühzeitig zu erfahren, dass seine Bestellung gescheitert ist, ohne dass ein Eingriff nötig ist. Alle Prozesse, die diese Kriterien nicht erfüllen, sehen wir als Bug. Die sind nicht immer ganz einfach oder schnell zu beseitigen, aber sobald eine Lösungschance entsteht die berechenbar ist, die keine unvorstellbaren Monsteraufwände macht oder andersrum neue, garstigere Probleme aufmacht, gehen wir dem Weg nach.
@Wilken (Gambio) Informationen über am Zahlungsmodul gescheiterte Bestellungen sind für die Händler wichtig. Wie wäre es, derartige Dinge in Form eines Reportings zur Verfügung zu stellen?
Das werden wir alller Vorraussicht nach nicht bauen. Das heisst nicht, dass ich deinen Gedanken nicht verstehen würde, aber ohne Monsteraufwand nützt das alles sehr wenig. Deine Ziele würde ich wie folgt einschätzen: Du willst wissen wie oft es schiefging und warum. Du willst versuchen Schlappen doch noch in Verkäufe umzusetzen. Das Problem: Du musst dazu einen grossen Berg an Informationen wegschreiben und aufbereiten, die an verschiedenen Orten liegen. Da brauchste Kontext vom Zahlungsanbieter zu irgendwelchen Sachen im Shop, sonst haste zum Beispiel vielleicht mal keine Lieferadresse oder kein Zahlungsmittel, wenn du das detailliert überhaupt irgendwann hast.... Willst du die Bestellung später gar rekonstruieren, musst du auch viele Informationen festhalten, die es jetzt nicht dauerhaft gibt und shopgerecht wieder aufbereiten, so dass ein neuen Zahlungsversuch an den Kunden zu richten denkbar ist. Beispiel: Hm, da steht der hatte 10 Euro Rabatt, warum hatte der die? Hatte der irgendeinen Coupon und wenn ja welchen? Oder: Ah ja, der hatte einen Kugelschreiber mit Gravur bestellt, aber welche Gravur wollte der? Wo ist der Inhalt? Oder: Paypal sagte vorab ja, aber für welche Lieferadresse und für welches Zahlungsmittel bei PayPal? etc, etc, etc... Wenn du nicht viel weisst, nur weisst da ist irgendwas, dann wirst du sagen irgendwas ist kaputt! Das muss anders! Meine Preise sind bestimmt nicht zu hoch und der Kunde hatte bestimmt Geld, also muss der Shop schuld sein... dann sagt der eine A und der andere B und du landest da, dass du schon wieder alles brauchst um zu einem brauchbaren Urteil zu kommen was wirklich war. Sonst kannst du nur auf der Stelle rumhüpfen, aber niemand kann dir helfen. Und dann landen wir wieder bei Monsterjobs und Fundamentalumbauten, die in keinem Verhältnis zum erwartbaren Nutzen stehen... Es gibt aus guten Gründen kein Shopsystem, dass das als designtes Feature hat. Du wirst durchaus auch andere finden, die Bestelleichen hinterlassen, die dann auch kein Mensch anständig weiterverarbeitet bekommt, weil die dann dieselben Probleme haben wie wir in unserem Universum, aber das hilft keinem echt. Also nochmal: Wir verstehen den Fundamentalwunsch nach Wissen und Rettungsankern und Doch-noch-Conversions die man hin und wieder irgendwie mit "so hats der Jupp doch noch hingekriegt" bekommen will und das ist ehrbar. Sachlich ist das Kind aber tot, nicht skalierbar würde man heute sagen. Wir wollen dann die Situation, die unter Abwägung von Risiken und Chance die besten Umsätze bietet und dabei am wenigsten Flurschaden im Portemonnaie hinterlässt, betrachtet auf die Händler Gesamtheit. One Size has to fit all. Das ist mehr wegwerfen, weniger Alchemie, die Vermeidung von Leichen bevor sie passieren und die schnelle geräuschlose Abräumung von Leichen, wenn sie trotzdem auftauchen, der absehbar gewinnträchtigste Weg. Und was im Hub immer passiert: Wir überwachen die Quoten gestarteter Transaktionen zu Erfolgen. Verschiebt sich da am Gesamtbild etwas, forschen wir schnell gezielt was los ist. Wir bauen dafür was nötig ist, aus Eigenantrieb. Sind unsere Händler nämlich nicht erfolgreich, sind wir es nicht. Du hast da so oder so rational schon alle Leute auf deiner Seite.
Also ungefair so: Hallo Kunde, mit diesem Zahlungsmittel kannst du gerade nicht bezahlen, ich nehm dich aber mal eben an die Hand und zeige dir weitere Zahlungsmöglichkeiten im Shop, ohne den Warenkorb zu verlieren?
Ok, schade. Dann wird eben weiterhin, wo es geht und gewünscht ist, auf Fremdanbieter für Paypal gesetzt bei denen der Ablauf ein anderer ist. Wir werden es auf jeden Fall testen - wenn abgebrochene oder fehlgeschlagene Zahlungen im Shop als Bestellungen wieder nicht mehr auftauchen wird nach Alternativen geschaut. Wenn Ihr intelligentere Lösungen findet, auch gut. Grüße Walter
Es gibt immer 2 Seiten. Mag sein, dass es für einige Shops passen würde, wenn die Bestellungen erhalten bleiben. Aber für Shops mit kleinem Lager oder bei z.B. Restposten mit wenig Bestand wäre das unter Umständen eine Katastrophe. Kunden bestellen nicht nur einmal, wenn die Zahlung nicht geht, sondern versuchen es mehrmals. Man hat dann ganz schnell mal 5 oder mehr Bestellungen im Shop - die von Hand storniert werden müssen. Der Artikel ist nicht mehr im Shop bestellbar, obwohl man nicht einen verkauft hat und der Kunde ist weg. Genau deshalb hat Steffen (indiv-style) 2014 ein Modul geschrieben, um die Bestellungen zu löschen, wenn keine Zahlung zustande kam. Es ist also egal wie das gelöst wird, es wird immer eine Hälfte an Shopbetreibern geben, für die das nicht passt. Optimal wäre natürlich, wenn die Kunden gleich wieder zur Zahlartenseite geleitet würden, mit dem Hinweis eine andere Zahlart zu wählen weil die Gewünschte gerade nicht geht.
Wie gesagt, genau das ist unser Ziel. Wir werden nur einen Moment brauchen etwa 8 Hindernisse nacheinander abzuräumen, bevor wir "den Schalter" grob durchgängig umlegen können. Auf ersten Massnahmen plane ich die Tage schon herum und versuche da eine Linie reinzubringen. Dazu noch ein Hinweis: Du hast dann auch jetzt schon ein Problem, weil sich die PayPal Zahlungsweisen zueinander unterschiedlich verhalten. Du wirst zum Beispiel schon jetzt genau wie bisher nie eine Leiche für PayPal Wallet Zahlungen (also klassische PayPal Zahlungen) haben. Hier kann PayPal dem Shop frühzeitig zu 99% sicher sagen obs klappt, da können wir schon jetzt alles ziemlich 100% fangen und machens aktiv. "Später Bezahlen" Zahlungen verhalten sich analog. Bei Kredit und Debitkartenzahlungen geht das nicht, da kann der Prozessor (Master, Visa,..) spät doch Nein sagen, die Vorabchecks sind nicht wasserdicht. Da kann es also gerade Leichen geben, aber man kriegt das recht schnell abgefragt. Dort gibts also einen Plan, wie wir das mit hoher Sicherheit wegebekommen sollten, also dann irgendwann keine Leichen mehr, Kunde landet wieder auf Zahlungsseite und kann was neues machen. Bei den APM Zahlungsweisen ist die Lage ähnlich: Auch wirklich einige Arbeit nötig, aber Stand heutigen Wissens keine auf alle Zeit unlösbaren Logikfragen. Eine echt harte Nuss werden wohl nur Rechungszahlungen, weil das Feedback über Erfolg oder Misserfolg oft so lange auf sich warten lässt, dass man den kaufenden Kunden da nicht so lange in einer Schleife halten kann. Kein Mensch starrt 2 Minuten einen "Bitte Warten"-Kringel an, um dann eventuell zu den Zahlungsweisen zurückgeworfen zu werden. Das haben wir als Kritik an PayPal durchgegeben, und wir wissen PayPal fummelt an der Rechnungszahlung dieser Tage noch fleissig herum, die läuft einfach jetzt noch nicht gut. Wenn wir da neue Stände durchgegeben bekommen, werden wir das in unsere Pläne einbeziehen.