Neues bei Paypal - Paypal Checkout in Gambio

Mal eben wieder ein Stand der Dinge am Ende eines weiteren Tages:

Alle genannten Probleme betrachten wir nach jüngstem Erkenntnisstand als erfolgreich gelöst, die Fixes sehen erfolgreich aus.

Noch ungelöst ist:

Es gibt dazu inzwischen regen Austausch mit Paypal, aber Stand jetzt noch keine Lösung.

Eine andere Anekdote: Wir haben heute auf unsere Pilothändler den Lastschrift Bugfix ausgerollt und bei allem ausser einem klappte es, da hing die Zahlungsweisenseite danach. Nach einem Haufen Debugging fanden wir irgendwann heraus, dass das Angebot von SEPA Lastschriften bei gleichzeitiger Auswahl von blauen Paypal Buttons das Ganze zu Fall brachte, alle anderen Händler hatten andere Button Farben eingestellt. Wir hatten durchaus mal baue Buttons getestet und SEPA, aber scheinbar nicht gleichzeitig. Das Javascript von Paypal fällt bei SEPA mit blauem Knopf still auf die Klappe, nichts geht mehr. Wir haben nach Erkenntnis einen Bugfix gebaut, der bei Auswahl blauer Buttons die Anwendung der Farbe auf den SEPA Button ausschliesst, und dann dort, nur für den einen Button, Silber als Farbe setzt. Dann läufts.

Aber: darauf musste man erstmal kommen... Die Lösung ist im internen Test und schon beim betroffenen Händler.

Das passiert also niemandem mehr, um sowas zu entdecken bevors alle haben, hat man eine Pilotphase. Ansonsten hatten wir einen ganzen Haufen schön schmerzfreier Zahlungsvorgänge, im Kern also alles gut und auf dem Weg.
Stand heute betrachten wir unsere Integration damit als "RC"-Kandidat. Es ist alles drin was drin sein soll, Probleme eher nur noch in Einzelfällen statt in der Masse, das ist ein guter Stand. Das beobachten wir jetzt nochmal etwas weiter und bilden noch mehr Erfahrungen, dann sind wir gut präpariert.

Was ausserdem heute von Paypal kam war die Info, dass es einen neuen Launchtermin gibt, den 15.03.2022. Gambio wird dann auf jeden Fall bereit sein, wahrscheinlich schon ein paar Tage vorher das allgemeine Go für unsere Händler geben, das dürfen wir hier. Wann das exakt genau ist, ist noch nicht hart bestimmt und wird sich in den nächsten Tagen erst festzurren, aber so haben alle einen groben Überblick über den Stand der Dinge.

 

Sehen wirs an.

Das ist quasi nicht umsetzbar. Wir haben da schon relativ viele konfigurable Freiheiten, aber ab einem gewissen Punkt sind und bleiben das Pakete. Du wirst auch wie bisher als Händler oft nicht unterscheiden können, welche Paypal Zahlungsweise ein Kunde exakt benutzt hat, weil sich vieles aus Händlersicht immer gleich anfühlt.

Das ist seitens Paypal nicht durchgängig gewollt. Das Paypal Branding tritt teilweise absichtlich stark in den Hintergrund. Es ist so egal ob ein Kunde denkt "Ich will mit Paypal zahlen" oder "Ich will mit Kreditkarte zahlen", er wird in jedem Fall direkt und quasi einzeln bedient.

Das ist nicht so einfach, aus Copyright- und Konformitätsgründen. Das schauen wir uns beizeiten nochmal an.

 

Hab mir schon gedacht, dass es um die "zusätzlichen alternativen Zahlungsmethoden" geht.

Und diese Liste ist "Subject to change", das heisst da können (und werden recht sicher..) weitere dazukommen oder irgendwann auch mal eins entfallen. Wir zeigen die maximale Auswahl für den jeweiligen Kunden in seinem jeweiligen Land mit seinem jeweiligen Warenkorbbetrag.

 

Nochmal ein kleiner Zwischenstand:

Wir haben weiterhin eine eher ruhige Pilotphase. Es passt noch nicht alles, aber es läuft insgesamt weiter tendenziell recht geräuschlos.

Von unserer Seite der Gleichung haben wir in den letzten Arbeitstagen Feintuning betrieben. Es gab Layout Probleme auf schmalen Displays, die wir gelöst haben. Wir haben die Begriffe in der Konfiguration nochmal leicht überarbeitet und die Doku etwas angepasst, damits noch mehr Fragen erschlägt.

Eine signifikante Sache gibts aber:
Der Shop überträgt bei Zahlungen die Bestellnummer an PayPal. PayPal hat dafür kein ganz genau passendes Feld, bisher wurde immer das Feld für die Rechnungsnummer genommen. Dort gibt es das Problem, dass Paypal jede Rechnungsnummer (hier: Bestellnummer) für ein Händlerkonto immer nur genau ein einziges mal akzeptiert. Das ist alles ok, solange niemand Bestellungen manipuliert (zum Beispiel löscht..) oder an seinen Nummernkreisen bastelt, so dass eine irgendwann mal verwendete Nummer erneut an PayPal gesendet wird. Passiert das, hat man einen 100% sicheren Zahlungsabbruch, Paypal bricht mit einem Fehler ab. Betroffen sind hier auch Leute, die schon mal andere Systeme benutzt haben, und dann vielleicht wieder bei 0 beginnen... Das ist schon sehr sehr sehr oft ein Quell grosser Frustation bei Händlern gewesen, die dann Fälle bei uns aufgemacht haben und manchmal auch nicht recht glauben wollten, dass ihre Nummernkreise ein Problem sind.
Was wir jetzt machen ist, dass wie die Bestellnummer in einem Freifeld von Paypal an Paypal übertragen, das schimpft sich in der PayPal API schlicht "custom_id". Dieses Feld hat den Vorteil, dass sich dort auch Nummern wiederholen dürfen, damit ist das alte Problem ausgeschlossen. Man sieht diese ID als Händler auch genauso in seinem PayPal Konto, alles gut. Das einzige Problem hier: Manche Buchhaltungslösungen lesen und zeigen diese ID nicht, wie z.B Lexoffice. Wir sind darum dabei in den Expertenoptionen des Moduls eine neue Option einzuführen, die eine Auswahl erlaubt in welches Feld die Bestellnummer bei PayPal geschrieben wird. Wir werden standardmässig und anders als früher "custom_id" befüllen, wer stattdessen die "invoice_id" füllen will, muss dann umstellen.

Wir sollten so einigen Frust vermeiden können, aber trotzdem niemanden unnötig ärgern.

Auf Seiten von PayPal wird hingegen Stand jetzt noch eher fleissig geschraubt:

Wir stellten fest, dass weniger Händler als erwartet den Rechnungskauf anbieten können, relativ viele Händler bekommen die Berechtigung von PayPal nicht. Wir haben das gesehen und moniert, PayPal hat das untersucht und einen Fehler bei sich festgestellt. Der ist dort nun auf dem Weg der Behebung. Für die Zeit hat PayPal den Rechnungskauf in PayPal Checkout aber komplett abgeschaltet, um unnötige Leichen sicher zu vermeiden. Man kann davon ausgehen, dass mit Nachdruck daran gearbeitet wird, das letzte Feedback dazu kam heute morgen bei uns an.

Ein zweites Thema ist die Händleranmeldung und Händler, die dort im Prozess Mails bekommen sollen, aber nie kriegen. Man weiss inzwischen schon, dass PayPal einen Positiv-Fall wohl nicht erkennt, also manche Händler bei denen alles schon grün ist nicht immer zum korrekten Abschluss führt. Auch da muss PayPal noch selbst arbeiten, das Problem liegt dort, ist aber ebenfalls platziert. Wir erwartet dort Nachricht, haben jetzt aber noch keine.

Letztes dickes Thema ist weiterhin das bei einem Händler festgestellte Klemmen der Zahlungsweisen Seite bei Anwesenheit des Rechnungskaufs und für eine Submenge von Kunden. Paypal ist, wie wir wissen, mit dem Händler in direktem Kontakt, auch dort scheint die Ursache und Lösung auf der anderen Seite zu liegen.

Wenn ich das so zusammenfassen darf, dann klingt das vielleicht kurz nach vielen Problemen, aber da haben wir auch ehrlicherweise schon ganz andere Produktstarts erlebt, die viiiiiel holpriger waren. Stand jetzt hätten die allermeisten ziemlich sicher schon ruhiges Wasser, ich sehe daher recht gelassen auf die Situation und den kommenden allgemeinen Start.

Warum schreibe ich das alles dann trotzdem hier:
Erstens schadet es keinem. Es wird 1-2 Kandidaten geben, die "Oh Gott" denken werden, aber vielleicht kriegt man beim Lesen auch raus, dass einfach viel geprüft, aufgepasst und gelöst wird, bevor alles auf die grosse Reise geht. Es wird gehört und gelesen was Leute melden, dann wird das irgendwie verarbeitet. Es gibt ja immer auch Leute, die in irgendwelche Probleme mit irgendwas rennen und dann sagen "Hättet ihr das nicht testen können, ich bin hier wieder der Betatester, ihr seid doch alle doof und praxisfern..." Zeigt man seine Vorarbeit und sein Wissen nicht transparent, und mangelt es gleichzeitig an der Vertrauensbasis, könnte man das auch glauben. So ist es nur halt nicht, es wird immer viel geschaut und gemacht. Das führt oft zu guten Ergebnissen und nur ganz manchmal gehts trotzdem mehr oder minder in die Hose... meistens aber nicht.

Mir ist hier also bewusst, dass das alles ganz durchgängig klingt wie ein sagen wir Marketingtext, dafür ist es eben ein Transparenzangebot und ich hab gedacht probieren wir es hier einmal so.

 

In einer idealen Welt ja. Praktisch glaube ich die müssten mehr tun und es würde darum mindestens dauern. Lexoffice bindet PayPal per PayPal API an, aber so wie es aussieht mithilfe einer betagten PayPal API. Ich hab die starke Vermutung aus dem alten Ding kommt das Feld nicht raus. Das würde bedeuten die müssten erst die Ecke kernsanieren, dann Optionen schaffen. Das braucht dann schon ein bisschen mehr Problembewusstsein...

 

Das ist korrekt. Es ist noch nicht für alle verfügbar, wir sind immernoch in der Pilotphase.

Das ist dann wahrscheinlich verfrüht.

 

Super Frage. Klär ich.

 

Wir sind uns noch nicht ganz sicher, wie wir da verfahren wollen. Bisher "scheren" wir uns nicht um Cookies von Zahlungsdienstleistern, das ist rechtliche eine Grauzone (wirklich weder schwarz noch weiss...). Egal was man empfiehlt, irgendwer fände es falsch (und irgendwer richtig...).

Die Cookies im Fall von Paypal werden vom Paypal Javascript SDK gehandelt, das ist immer ein und dasselbe Ding, egal ob man direkt zu PayPal Buttons einblenden will, Später bezahlen Banner oder die Zahlungsweisen der Zahlungsweisenseite, immer genau dasselbe Ding, eins für alles. Für die neuen PayPal Checkout Zahlungsweisen ist das SDK spätestens weitgehend unabdingbar.

Mit Hubconnector 1.21, also dem noch den Pilothändlern vorbehaltenen Ding, gibts erstmals eine Teilunterstützung das mit dem Cookie Consent Tool zu verdongeln. Wer einen Zweck mit Titel "PayPal" im shopeigenen Consent Tool anlegt, kann den Zwischenstand ansehen, aber das ist weder final noch aktuell von uns offiziell unterstützt. Ich bezweifele auch, dass wir an der Stellle vor Produktstart noch tiefere Dehnübungen machen. Nur so ganz bei 0 sind wir da auch nicht.