Wir hätten gerne einen Ladenhüter verkauft aber...

Bist Du sicher?
Der Kunde geht erst zu PayPal und klickt danach auf kostenpflichtig Bestellen - und erst dann wird der Artikel abgezogen, nicht vorher. Wenn die Daten falsch waren, hätte er gar nciht bestellen können und die Ware wäre nciht abgezogen worden....
Es sei denn, du hast ein altes PP, was erst nach dem Bestellen-Button kommt. Da gab es das öfter.

 

Irgendeiner muss doch den Laden hüten.

 

Das was hier gewollt wird, an den Reihenfolgen herumdrehen, ist ein Monster. Die ganzen Prozesse am Ende einer Bestellung gehen nicht gleichzeitig, sondern nur schnell nacheinander. Und egal wie man das dreht, wenn einer der Subprozesse schief geht hat man ein Problem.

Hier:
Dieser Kunde hat die PayPal Vorabprüfung bestanden, damit ist relativ sicher dass die Zahlung erfolgreich sein wird, wenn auch nicht perfekt sicher. Das sieht man hier. Man kann aber sicher sagen, dass die Trefferwahrscheinlichkeit für einen Erfolg drastisch höher ist, als sie es bei jeglichen früheren Integrationen mit "mehr nachgelagertem PayPal" je war, um Lichtjahre, aber eben nicht 100% perfekt.

Was man auch wissen muss, was es vor 10 Jahren nicht gab: asynchron arbeitende Zahlungsweisen.

Das meint im Kern das Prozesse losgelöst vom klickenden Kunden ohne diesen warten zu lassen im Hintergrund ausgeführt werden. Das wird auch immer mehr. Das bedeutet für Zahlungsweisen wie PayPal, Klarna, Amazon Payments ist zum Checkout Zeitpunkt oft nicht bekannt, ob die Zahlung erfolgreich war. Der Shop weiss das im Bereich von Millisekunden bis mehrere Minuten später, je nach Anbieter und Tageszeit. Transaktionen die schon beim Versuch den Hintergrundprozess Zahlung anzustossen scheitern sind die allerwenigsten aus der Gesamtmenge, ein Edge Case.

Das bedeutet: würde man immer auf die Zahlung warten wollen, müsste man den Kunden teilweise minutenlang auf Warteposition halten. "Nur noch einen Moment!". Das wäre grosser technischer Käse.

Zweite Problemstellung: Wenn man immer erst die Zahlung buchen würde, könnte bei kleinen Lagerbeständen schnell Überverkauf entstehen, man verkauft mehr Ware als man hat. Wenn 2 Bestellungen für einen einmal lagernden Artikel parallel laufen gewinnt eine, die andere ist eine Zahlung ohne Ware und ein ebenso genervter Kunde. "Sorry, doch nicht! Dein Geld kommt die nächsten Tage zurück!"

Das ist genauso kaputt, 0 besser. Darum machen wir das nicht.

Der einzige echte Ausweg: Man erfindet eine extra Parkposition für schwebende Bestellungen, mit einer Prozesskette um ganze Bestellungen da reinzubewegen, und sie nach Zeit oder externem Signal zu persistieren oder rückwärts abzuwickeln. Der Aufwand wäre für uns vergleichsweise gigantisch, wir würden sicher einen Monat mit echt vielen Leuten dransitzen, die Kompatibilität zu allem möglichen wieder mal komplett brechen, von Zahlungsmodulen die garantiert alle sterben bis zu allen möglichen anderen Integrationen die irgendwie am Checkout hängen. Das liefe auf einen nötigen einigermassenen Komplettabriss hinaus. You don't mess with that old code, or you pay lots of grey hair.

Das ist das Problem: Das ist kein zwischendurch Problem. Das ist sogar soviel, das ich mir nicht sicher bin obs bei einem Checkout 2 in der Agenda bleibt. Das steht alles normal in keinem gesundem Verhältnis zum zu erwartenden Nutzen, und es gibt meiner Kenntnis nach kein System am Markt, dass das gebaut hätte.

Und solange wir nicht dergleichen haben, müssen wir eine Reihenfolge wählen. Und da buchen wir solange erst Bestand, dann Zahlung. Das tut allen viel weniger weh und klappt öfter gut als andersherum.

 

Nein, eher nicht.

Korrekt, in aller Regel eine Zeit x nach Bestellabschluss als Callback. Sehr selten gibts das auch beim Versuch die Zahlungsausführung anzustossen direkt als Response zurück, wie in deinem Beispiel.

Das setzt aber immer vorraus, dass eine Bestellung existiert. Die spanende Frage ist dabei dann immer: Wo und in welchem Zustand existiert die Bestellung gerade? Bei einem Statusupdate auf eine regulär-gespeicherte-finale-Bestellung ist das noch fast(!) deterministisch, wenn auch nicht ganz.

Das wollen wir nicht. Weil der Status nur "fast deterministisch" ist birgt das Gefahr gut daneben zu gehen. Da kommen dann neben Checkoutaltstrukturen mitm mal auch noch Nondeterminismen bei Attributartikeln u.ä. hinzu. Man kann zum Beispiel aus einer Artikelnummer nicht deterministisch rausbekommen welche Attribute eventuell rückgebucht werden müssen. Man kommt also von einem Artikel mit Attributen zu einer Artikelnummer, aber nicht rückwärts, nur vielleicht. Es gibt da noch mehr so Kalauer. Das Fass wollen wir nicht aufmachen. Wir tauschen nicht einen Edge Case gegen einen noch schlimmeren ein, das bringt niemanden voran.

Oh doch, in heftigem Umfang. Der Anfang aller Automatismen ist eine gesicherte Ausgangslage. Wenn es funktionieren soll, muss man die vorher schaffen, die haben wir da nicht ausreichend um das irgendwie zu lösen, so dass es nicht beknackter ist als vorher. Und für halbe Sachen auf die Schnelle alles kaputtzumachen was es draussen gibt wollen wir auch nicht. Einigermassen ganz oder gar nicht.

Ja. Wir vermeiden so gut es geht dass es zu Bestellungen in dem Status kommt, wenn das nicht klappt liegt aber Handarbeit an. Der Shopbetreiber weiss immerhin genau was er tun muss, das kann ein Automatikprozess beim jetzigen Zustand der Daten nicht sicher leisten, darum finden wir Handarbeit bereiten in dem Fall den besseren Weg für den Moment.

Wird nicht kommen, solange nicht grundsätzlich neue Strukturen an anderer Stelle da sind, keine Chance.

 

@L&B

weiter gedacht und kommt in der Praxis oft vor: die Kundenzahlung per PayPal scheitert. Der Kunde hat den Artikel aber dennoch gekauft. Er überweist dir anschließend das Geld.

 

Irgendwie ein beknacktes Käuferverhalten. Wir sind doch auch ab und an mal Kunde. Und wenn mir das in einem Shop passieren würde, würde ich mich schon sehr wundern, wenn der Artikel auf einmal nicht mehr verfügbar ist. Ich würde denken, hups jetzt hab ich den gekauft, aber Papyal hat nicht funktioniert. Ich würde den Shopbetreiber anschreiben und fragen was los ist und ob er mir einen Paypalzahlungslink schicken kann. Ich würde nicht einfach dann was anderes kaufen. Hätte dann viel zu viel Bammel, dass ich dann zwei Artikel hätte. Bei mir gibt es auch sehr viele Einzelstücke (an dieser Stelle würde ich nicht von Ladenhüter sprechen, sondern eher von Unikaten) aber mir ist das zum Glück noch nicht aufgefallen.

Kommt das denn bei dir häufiger vor, so dass Gambio was ändern sollte? Ist das anderen auch schon aufgefallen in ihrem Shop?

 

Hmmm ich habe das Problem nicht wirklich weil Wawi, aber ich erinnere mich daran, dass ich zufällig (weil zeitgleich) meine Bestellungen aktualisierte während der Kunde noch in der Zahlungsphase? war.

Bei der Bestellposition stand: "noch nicht bestätigt" oder so ...
... und wenige Sekunden später kam "offen".

Warum nicht erst in diesem Moment wenn "offen" an den Shop gemeldet wird, den Bestand buchen?

 

Eine Wawi schützt dich 0 vor dem Thema. Im Gegenteil: Deine Wawi scheint ja auch noch nicht finale Bestellungen abzuholen, das ist dann eine Verschärfung.

Weil der ganze Prozess Bestellung abschliessen, Bestellung speichern, Bestand buchen, Mail absenden im Prinzip atomar ist, also unteilbar. Dazwischen ist logisch nichts an Stufen vorhanden, es verlässt sich unglaublich viel darauf, dass das alles atomar ist.
Das heisst auch man kann die Bestandsbuchung auch nicht wirklich allein starten, ohne den ganzen Rest drumherum auch zu triggern: Kundenmail, Zahlung,etc., es sei denn man kopiert sehr viel Code und wartet dann alles doppelt.
Allein das kopieren und lauffähig machen von den alten Codepassagen wäre eine Mammutaufgabe, nicht weniger komplex als ein Neubau. Kopieren würde nicht genügen, weil man dem alten Code ein Wohlfühlambiente (eine Datenwelt auf der er operieren kann) um ihn herum bauen müsste, eine simulierte halbabgeschlossene Bestellung, damit der ohne Checkoutgeklicke funktioniert...

Egal wie man das sieht, das ist ekelhaft und wiegt den möglichen Erfolg nicht auf. Das wird so mal eben sicher nichts.

 

Das ist nicht richtig, Vario holt nur Bestellungen ab die den Status "offen" haben und die sind dann tatsächlich final.

In der Wawi habe ich meine Bestände die in den Shop repliziert werden. Ohne das ich im Shop irgendwas buchen/stornieren oder was auch immer muss, kann ich meine tatsächlichen Lagerbestände jederzeit wieder in den Shop stellen.

Einen ähnlichen Fall wie L&B den schildert hatte ich bisher 2mal. Beide Kunden hatten mehrere Versuche mit Paypal-Abbrüchen. Im Shop steht dann ein kleiner Briefumschlag mit dem Text "keine E-Mail versendet" o.s.ä., aber der Bestand wurde jedesmal abgebucht. Glücklicherweise haben beide Kunden dann noch eine finale Bestellung auf Vorkasse ausgelöst und damit war zumindest der Bestand wieder korrekt, denn die Vario lasse ich automatisch buchen wenn ein Auftrag abgeholt und der daraus resultierende, tatsächliche Lagerbestand (in der Vario) wieder in den Shop gestellt wird.

Es gibt also tatsächlich nur den Time Gap WANN eine autom. Replikation stattfindet. Wenn diese auf 1 Minute steht ist spätestens nach 2 Minuten wieder der tatsächliche Bestand im Shop bzw. in allen angeschlossenen und replizierten Portalen.

 

Das passiert folgendermaßen:
du schreibst den Kunden an, ob er den Artikel weiterhin kaufen möchte.
Dein Schreiben enthält einen PayPal Zahlungslink und deine Bankverbindung.
Wenn der Kunde innerhalb von 5 Tagen nicht antwortet oder er an einem
Kauf nicht mehr interessiert ist, DANN stornierst du die Bestellung und setzt
den Bestand wieder hoch und aktivierst den Artikel.

 

Man darf, dürfte im vorliegenden Fall unproblematisch sein.

 

Schönes Beispiel: Der Kunde hat bei PayPal eine Kreditkarte hinterlegt. Es konnten in der Vergangenheit damit Geldbeträge eingezogen werden, der Kunde ist bei PayPal in einer Positivliste, die Karte sollte noch gültig sein. Beim Versuch Geld zu holen sagt der Kreditkartensystemanbieter dann aber trotzdem nee, weil die Karte aus anderen Gründen nicht mehr gilt. Das kriegt PayPal vorher nicht raus. Zack, Problem.

Genauso ist es aber in unserer Welt. Lieber ehrlich als das blaue vom Himmel lügen, dann weiss man wenigstens womit man arbeiten muss.

Ich glaube auch nicht, dass die Wawi das ehrlich lösen kann. Falls doch, muss dahinter ein Datenunfall mit positiver Auswirkung stecken, das ist kaum planbar sicher möglich.

Jein. Bei einfachen und bei Eigenschaftenartikeln geht das. Bei Attributartikeln geht es nicht, da kann ich das nicht. Das ist eine der Macken von Attributen, warum die irgendwann weg müssen. Wenn das ginge wäre es schonmal ein gutes Stück einfacher, ist es aber nicht.

Sorry, du irrst hier.

Es geht nicht um Datenbankzugriff. Es geht einfach darum, dass aufgrund der Datenspeicherform in Bestellungen dadrin Artikel mit Attributen so landen, dass es keinen eindeutigen Weg zurück zu de Artikeln mit Attributen gibt, auch wenn du alle Informationen der Bestellung lesen kannst. Völlig abgefahren, aber wahr.