Hallo zusammen, ich hatte vorhin folgendes Problem (und diese Unklarheit darüber, wann ich wie stornieren muss, habe ich schon länger): 1) Kunde bestellt einen Artikel und wählt Paypal 2) Paypal Zahlung wird abgebrochen 3) Trotz abgebrochener Paypal Zahlung wurden Gesamtlagerbestand des Artikels und der des betrofenen Attributs verringert, Kunde hat den Artikel aber immer noch im Warenkorb 4) Kunde wählt nun SOFORT Überweisung 5) Zahlung ebenfalls nicht erfolgreich 6) Trotz abgebrochener / nicht erfolgreicher Zahlung wurden Gesamtlagerbestand des Artikels und der des betrofenen Attributs erneut verringert 7) Kunde verschwindet 8) Kunde hat also einen Artikel im Warenkorb gehabt, diesen Artikel letztlich gar nicht gekauft/bezahlt, dafür aber gleich zwei mal vom Gesamtbestand bzw. Attributsbestand abgezogen. Wenn ich jetzt beide fehlgeschlagenen Zahlungen jeweils storniere und den Artikelbestand korrigieren lasse, wird der Bestand bei jeder Stornierung um 1 erhöht (weil er ja vorher zwei mal verringert wurde - obwohl der Kunde nur einen Artikel im Warenkorb hatte). Habe ich Paypal und/oder SOFORT falsch konfiguriert oder ist es normal, dass ich immer kontrollieren muss, wann ich wie oft beim Stornieren den Lagerbestand korrigieren lassen kann oder muss? Bin für jeden Tipp dankbar! LG, Chris
Hallo Chris, danke für deinen Beitrag, das würde vieles erklären. Ich stehe hier auch immer wieder vor dem problem, dass Produkte gekauft werden können, bei denen der Bestand im Lager auf 0 ist. Wenn der Bestand im Shop durch das Stornieren (was bei uns häufig vorkommt, da wir relativ viele PP-Abbrecher haben) nicht stimmt, dann weiß ich ja, woran es liegt. Jetzt brauchen wir nur noch eine Lösung.
Hallo, ich möchte mal kurz anmerken, dass dieses Problem nicht PayPal-spezifisch ist, sondern alle Zahlungsmodule betrifft, die temporäre Bestellungen verwenden. Dieses Verfahren ist tief im Checkout-Ablauf verankert und nicht so leicht zu verändern. Man kann so eine abgebrochene Bestellung in einem Gambio-Shop mit einem im Laden stehengelassenen, beladenen Einkaufskorb vergleichen. Wenn man so einen findet, muss man auch erst mal herausfinden, ob der Kunde wirklich den Laden verlassen hat, und dann ggf. die ganzen Artikel wieder in die Regale räumen. Wir hatten schon einmal kurz angedacht, die temporären Bestellungen separat zu führen und erst dann in „richtige“ Bestellungen zu überführen, wenn der Vorgang wirklich abgeschlossen wurde. Das Risiko, dass man sich dabei größere Inkompatibilitäten mit den bestehenden Zahlungsmodulen einhandelt, ist aber zu hoch, als dass man so etwas mal eben übers Knie brechen könnte.
Hi Marco, danke für das Statement. Ich komme noch nicht ganz mit, aber fast Dass ein Kunde innerhalb einer Sitzung mehrere Anläufe für eine Zahlung braucht, kommt häufiger vor. Gibt es denn bestimmte Fälle bei denen man vorhersagen kann, dass die abgebrochene Zahlung immer MIT Neuberechnung des Artikelbestands erfolgen sollte und andere, wo man das immer lassen sollte? Ich habe durchaus Fälle, bei denen ich einfach den Zahlungsabbruch storniere, den Artikelbestand im selben Zug korrigieren lasse und hinter stimmt auch wirklich alles. Ich habe nur noch nicht herausgefunden, wann welcher Weg der Richtige ist - und damit bleibt mir nur, jedesmal den tatsächlichen Bestand mit dem im Shop zu vergleichen, was sehr zeitaufwändig und lästig ist. LG, Chris
Guten Tag, ich habe mit beiden Zahlungsmodulen (Paypal, Sofortüberweisung) das Problem, dass beim Abbruch der Bezahlung keine Stornierung des Auftrages durchgeführt wird. Da unser Shop viele Artikel nur 1x vorrätig hat, sind diese Artikel deaktiviert und auf Menge 0. Wenn der Kunde solche Artikel im Warenkorb habt und am Ende des Bestellprozesses auf "zahlungspflichtig bestellen" klickt, wird der Artikel schon deaktiviert und die Menge auf z.B. 0 gesenkt. Er wird dann zwar zur PAYPAL-Seite geleitet, sollte er dann aber auf der Paypal Seite auf "abbrechen und zurück zum Shop" klicken (z.B. weil er eine andere Zahlungsweise wählen will, oder noch weitere Artikel kaufen möchte), dann landet der Kunde im Warenkorb, der eine Meldung ausgibt, dass der Artikel nicht bestellbar ist, weil nicht verfügbar. Der Bestellprozess ist damit für den Kunden nicht mehr durchführbar, weil die Menge des Artikels nicht ausreicht. Kann man das irgendwo einstellen, dass beim Paypal Abbruch oder einer Ablehnung der Artikel wieder mengenmäßig gutgeschrieben wird, und aktiviert wird??? Gleiches gilt für Sofortüberweisung natürlich auch. Da passiert das Gleiche. MfG Maxwell
Das mit den Beständen ist wirklich übel. Bei uns stimmen insbesondere die Sonderangebote so gut wie nie, was sehr ärgerlich ist. Die Kunden bestellen und erst im Lager stellen wir fest.... nicht da oder nicht in der gewünschten Menge da. Das ist sehr nervig.
Ich bin auch noch nicht weiter und mich betrifft das Problem ebenso stark wie Maxwell, weil auch ich viele Artikel in einzelnen Größen nur ein mal auf Lager habe. Wenigstens für klar reproduzierbare Fälle, wie den Paypal Abbruch oder den SOFORT Abbruch sollte das doch lösbar sein? So kostet das schlicht Geld, weil Kunden mit Kauf-Absicht genervt abhauen.
Ich sehe das genauso. Wenn das Shop-Sytem merkt, dass es sich um einen Paypal Abbruch handelt, dann kann es auch weitere Schritte durchführen. Da ist schlicht Programmierungssache und fertig. Uns gehen täglich Kunden flöten, die den Artikel nicht kaufen können, weil Sie bei Paypal nochmal zurück wollten oder was auch immer. Ganz ehrlich, wenn jemand mal Spaß in den Backen hat, legt er bei uns 100 versch. Artikel in den Warenkorb und geht bis Paypal und zurück und davon sind bestimmt 80 Stk. mit Menge 1, die dann zwar durch Auftragsstornierung auf den alten Lagerbestand gesetzt werden, aber manuell von uns aktiviert werden müssen. Das ist absolut nicht akzeptabel!!! Andere Shops können das auch und ich denke, es handelt sich hier um eine Fehlfunktion, auch dann wenn die noch aus alten osc-Zeiten stammt. Wir zahlen hier Support, damit solche Dinge behoben werden. Gruß Maxwell PS.: Meine Support-Anfrage wurde übrigens so in etwa "geht nicht gibts nicht" geschlossen. Wäre keine Fehlfunktion. Hmmm....
Hallo, es gibt unter den Shopbetreibern unterschiedliche Ansichten, zu welchem Zeitpunkt eine Bestellung als abgeschlossen gilt. Entsprechend ist auch ein sinnvoller Zeitpunkt der Lagerbestandsreduzierung unterschiedlich. Ist man der Ansicht, dass eine Bestellung seitens des Käufers verbindlich ist, sobald auf "Kaufen / zahlungspflichtig bestellen" geklickt wird, ist es natürlich sinnvoll sofort den Lagerbestand zu reduzieren, ganz egal, ob eine eventuell folgende Zahlung erfolgreich ist oder nicht. Durch die sofortige Lagerreduzierung ist das Produkt für den Käufer gesichert und kann bei eventuellen Zahlungsproblemen nicht mehr von jemand anderem weggeschnappt werden. So verhält es sich aktuell für die meisten Zahlungsweisen im Shop. Ist man hingegen der Ansicht, dass eine Bestellung erst dann verbindlich ist, wenn die Zahlung erfolgt ist, ist natürlich eine sofortige Lagerbestandsreduzierung nach Klick auf "Kaufen / zahlungspflichtig bestellen" nicht sinnvoll. Es böte sich an den Lagerbestand auf der checkout_success-Seite ("Vielen Dank für Ihre Bestellung"-Seite) zu reduzieren, was jedoch Fragen aufwirft: Wie lange werden die bestellten Produkte reserviert, so dass sie nicht während des Zahlungsvorgangs von anderen bestellt werden können. Was passiert mit dem Lagerbestand, wenn der Versuch die Zahlung abzuschließen abgebrochen wird? Soll in diesem Fall eine Bestellbestätigung verschickt werden? Ist überhaupt eine Bestellung zustande gekommen? Mich würde eure Meinung zum Thema mit konkreten Vorschlägen zur Umsetzung interessieren! Übrigens: Dass Problem, dass man einen Shop leer kaufen kann, ist über eine Bestellung mit Vorkasse immer möglich.
Also das nenn ich mal ein ganz wichtiges Thema! Wie Moritz es schon schreibt, liegt es am Händler , wann für ihn eine Bestellung zustande kommt! Um dieses Problem zu lösen, müsste man dies optional in den Checkout einbauen. Das heist das man im Admin die Vorgehensweise einstellen könnte. So weit so gut! ABER!!!! Ich hatte letztens das Vergnügen, die Gratisartikel fertig zu machen. Schon nach kurzen Test stand fest, den Checkout nur im äussersten Notfall anzufassen. Ich schätze den Aufwand für soetwas genauso hoch ein wie die Entwicklung der Filter oder Eigenschaften, da man in alle Bereiche des Checkoutes eingreifen und verändern muss. Bei uns hab ich das mit 2 if-Abfragen gelöst. Eine in der checkout_process.php und eine in der checkout_success.php! ich frage die Zahlungsweise ab und dann wird entschieden wo der Bestand wech kommt! Bei PayPal und Sofort erst in der checkout_success.php, da bei uns der Vertrag erst mit Zahlungseingang, zustande kommt. Und auch das ist net 100%ig!!! PS: Sicher gäb es eine Notlösung mit etwas scrippting hier und da aber was richtiges ist das nicht, da der Checkout an sich mal ne Runderneuerung vertragen könnte! Aber das wird sicher noch etwas dauern.
Eigentlich kann man das immer in der checkout_success machen (den Warenbestand verminden). Wenn man die Logik der out_of_stock-Bestimmung etwas anpasst. Den realen Warenbestand vor erfolgreicher Bestellung zu vermindern, und sei es auch nur temporär, kann für Leute mit angeschlossener WaWi fatal sein. Allerdings werden die Warenkörbe eh schon in der DB gespeichert, man müsste also die out_of_stock-Prüfung dahingehend erweitern, dass offene Warenkörbe jünger als x Stunden ebenfalls berücksichtigt werden und es ein out_of_stock==true geben kann, obwohl der Bestand > 0 ist, eben weil die restlichen Artikel in einem Warenkorb liegen. So, wie in einem "echten Laden" halt auch: Ware im Regal + Ware im Lager + Ware in den Einkaufskörben = Bestand. Bis der Warenkorb auf der anderen Seite der Kasse ist. Wenn man dann bei out_of_stock==true keinen BuyButton anzeigt, wie das aktuell von Trusted-Shops auch schon vorgeschrieben wird, sollte alles in Butter sein. Oder hab ich hier irgendwo einen Denkfehler drin? bye Volker
Natürlich sind verschiedene Ansichten vorhanden. Ich denke aber die Änderungen sind nicht so tiefgreifend, dass die Prozesse sich entscheidend ändern, sondern nur verschieben. Eine Bestellung wird mit Klick auf "Kaufen / zahlungspflichtig bestellen" nicht verbindlich. Der Käufer gibt ja nur ein Angebot ab. Ich als Verkäufer kann die Bestellung ja auch ablehnen, solange ich nicht bestätigt habe. Nochmal zur Verdeutlichung mein Problem: Der Käufer kauft nun fröhlich ein und will bezahlen und wählt z.B. Paypal. Auf der Paypal Seite merkt er dann: "Hä? Wasn das? Mit Registrierung??? Son Scheiß." und bricht ab. Abbruch Variante 1: Schließt die Seite, oder gibt die Shop URL wieder direkt in die Adresszeile ein oder nutzt den zurück-Button. Abbruch Variante 2: Klickt freundlicherweise auf den Abbrechen Button auf der Paypal Seite und wird von Paypal zurückgeleitet. Bei Variante 1 steigt der Kunde ja wieder neu ein. Die Session ID inkl. Login sollte den Kunden dann wieder erkennen und den offenen Warenkorb laden. Bei Variante 2 landet der Kunde doch heute schon automatisch wieder auf der checkout_payment.php, oder?? Nur dass dort dann Paypal fehlt und eine andere Zahlungsweise genutzt werden muss. Einziges Problem bei uns ist: Der Lagerbestand wurde schon reduziert und da der Artikel nur 1x auf Lager war oder der Lagerbestand vom Kunden aufgekauft wurde, sind die Artikel weg und der Kauf kann nicht fortgesetzt werden. Für den Kunden ist das doof, weil er ohne Bezahlung abhaut und wahrscheinlich auch nicht mehr kaufen will, weils nicht klappte oder er dann woanders kauft. Diese Ansicht ist absolut richtig. Die Bestellung ist abschließend durchgeführt, wenn die Zahlung durchgeführt wurde, bzw. eine Zahlungsweise ohne direkter Zahlung über einen Anbieter gewählt wurde (z.B. Vorauskasse). Die Produkte müssen nicht reserviert werden. Kauft das gleiche Produkt ein anderer Kunde zum gleichen Moment, dann ist der Artikel verkauft und weg. Der Lagerbestand wird ja am Ende in der checkout_success.php erst reduziert. Damit ist der Artikel durch Kunde 2 gekauft. Jetzt haben wir ja immernoch Kunde 1, der den Artikel kaufen will. Ist er schon beim Bezahlanbieter, wird natürlich keine Lagerbestandsprüfung mehr durchgeführt. Das ist ein Problem. Kann man da nicht mit einem Frame arbeiten, der parallel den Lagerbestand in regelmäßigen Abständen prüft? Ändert sich der Bestand und reicht nicht auf, wird der Kunde zurück zum Shop geholt mit dem Hinweis, dass der Artikel zwischenzeitlich nicht mehr verfügbar ist. So spart man sich die Reservierung für z.B. die Zeit des Aufenthaltes beim Zahlungsanbieter (zudem man nichtmal weiß, ob der Kunde dort überhaupt noch ist). Nix, der Lagerbestand wird erst am Ende in der checkout_success.php reduziert, wenn der Zahlungsanbieter Erfolg meldet. Vorher bleibt er unverändert. Auch die wird am Besten im gleichen Prozess verschickt, zusammen mit der Reduzierung des Lagerbestands. Bei Nutzung eines Zahlungsanbieters erst mit Erfolgsmeldung, bei Vorkasse natürlich sofort. Also quasi immer dann wenn die checkout_success.php angezeigt wird. Auch hier sollte erst die Bestellung offiziell angelegt und im Admin sichtbar sein. Alles andere ist temporär und nicht abgeschlossen. Es gilt nur ganz oder gar nicht! Ich hoffe, ich habe einige Anregungen geben können. Ich denke, es reicht eine Prozessverschiebung von Lagerbestandspflege + Bestellbestätigung in die checkout_success.php aus. Der Kunde sollte anhand seines Logins und seiner Session-ID identifiziert werden, damit eine Änderung der Zahlungsweise möglich wird, auch nachdem der Zahlungsanbieter besucht wurde und abgebrochen wurde. Mit freundlichen Grüßen Maxwell
Mal unabhängig davon, wie man das Problem am besten lösen kann, finde ich noch mal sehr wesentlich, dass das alles andere als eine Kleinigkeit ist. Offenbar sind nur Minderheiten (nämlich Leute wie Maxwell und ich, die viele Artikel nur ein mal auf Lager haben) sehr massiv betroffen, für alle anderen ist es ein sehr lästiges Phänomen, dass aufwändig manuell korrigiert werden muss - dass aber offenbar in Kauf genommen wird. Ich habe anfangs angenommen, schlicht einen Konfigurationsfehler fabriziert zu haben. Dass dieses Problem "normal" ist und es keine Lösung dafür gibt, finde ich geradezu abenteuerlich. Immerhin ist es durch die richtige Kombination von Abbrüchen möglich, negative Artikelbestände zu produzieren. Das kann doch nicht als "Kavaliersdelikt" durchgehen? Ist der Fall "Variante 2" nicht auch schon ein kleines Desaster? Passiert natürlich nur in Ausnahmefällen - aber es passiert. Und zwar auch, wenn jemand z.B. Paypal wählt, feststellt dass er nicht per Lastschrift zahlen kann (Passiert Paypal Kunden öfter mal, die das erste mal im Ausland bestellen), dann abbricht, um eine Alternative Zahlmethode auszuwählen - und dann merkt, dass es keine bessere Alternative gibt. Dann will er doch (trotz des manuellen Abbruchs) Paypal wählen, kann aber nicht mehr. Und das Produkt ist ja nicht mehr verfügbar. Kunde weg, Geschäft geplatzt ...
Das Thema Lagerbestand steht gerade auf unserer Tagesordnung. Wir haben überlegt was der richtige Weg ist, wann der Lagerbestand reduziert werden sollte. Variante 1: Der Lagerbestand wird dann reduziert, wenn der Kunde auf "Jetzt Kaufen" klickt, denn dann möchte er verbindlich bestellen. Unabhängig ob er die Zahlung abschließt oder aus irgendwelchen Gründen nicht. Variante 2: Der Lagerbestand wird erst reduziert wenn die Bestellung UND die Zahlung erfolgreich waren, da auch erst dann der Shopbetreiber die Bestellung als Verbindlich ansieht. Wir sind zu dem Ergebnis gekommen, dass beide Varianten unter Umständen korrekt sein können. Der eine Shopbetreiber nimmt die Bestellung sofort an und der andere eben nicht. Würden wir uns nun für eine Variante entscheiden, wäre das für einen Teil der Shopbetreiber nicht in Ordnung. Unsere Idee: Wir koppeln die Anpassung des Lagerbestandes an den Bestellstatus. In den Lagerverwaltungsoptionen erhaltet Ihr eine Liste mit allen im Shop vorhandenen Bestellstatus und könnt dann je Status festlegen, ob der Lagerbestand bei erreichen dieses Status angepasst werden soll oder nicht. Das geht sehr schnell und jeder von Euch kann dann selbst bestimmen wann die Anpassung erfolgen soll. In jeder Bestellung seht Ihr dann, ob für diese Bestellung der Status bereits angepasst wurde und könnt mit dem Stornieren einer Bestellung den bestand wieder gutschreiben. Soweit unsere Überlegung. Was haltet Ihr davon? Ist das ein gangbarer Weg? Falls nein, wieso nicht, was sollte verändert werden? Zukunft: Grundsätzlich denken wir darüber nach in Zukunft mit zwei Status-Arten zu arbeiten: 1. Bestellstatus, 2. Zahlungsstatus. Eigentlich handelt es sich nämlich um unterschiedliche Dinge die derzeit vermischt werden und zu Problemen führen können. In dem Zuge müssen wir dann auch darüber nachdenken, den Ablauf im Bestellvorgang grundsätzlich eindeutiger zu gestalten. Also wann gilt eine Bestellung als erfolgt, auch wenn die Zahlung evtl. noch nicht abgeschlossen ist, wann werden dann die Bestellbestätigungen verschickt. Welche Möglichkeiten werden geschaffen, dass eventuell abgebrochene Zahlungen trotzdem zu einer Bestellung führen und der Kunde eine Nachricht erhält, dass die Bestellung zwar erfolgte, aber die Zahlung nicht, so dass er auch nachträglich noch zahlen und ggf. die Zahlungsweise ändern kann, ohne dafür eine neue bestellung durchzuführen (Vermeidung von Bestell-Leichen.). Das wird aber etwas größeres, beginnen wollen wir erst einmal mit der Lagerbestandsgeschichte, um hier schnell eine gute Lösung für Euch zu schaffen. Feedback erwünscht.
Zu Lagerbeständen kann ich noch nix sagen, Nutzen wir ja nicht. Bei den Zahlungssachen aber wäre es wirklich gut das getrennt zu haben. Gerade bei Zahlung auf Rechnung ist es tewilweise sonst etwas unschön. Man sieht nicht wirklich das die Ware schon verschickt wurde und man nur noch aufs Geld wartet. Auch gut wäre in dem Zuge wenn Kunden dann nach abbruch die BEstellung in ihrem Kunden-ACC sehen und dort eine andere Zahlart wählen können. z.B. falls einer dann statt Überweisung doch lieber schnell per PP zahlen will weils schneller geht als Vorkasse. Die überlegung fänd ich gut. (Auch wenn wohl nur 10% der Kunden überhaupt merken das sie das später ändern könnten)
@Daniel, wenn das so geht wie du schreibst, wäre es optimal! So kann jeder seine eigene Config machen. Sehr gute Idee.....
Ich sehe es genauso, das sind die beiden möglichen Varianten. Reduzierung bei Bestellung oder Reduzierung bei Bezahlung. Wenn ich das richtig sehe, wird also nach der Bestellung ein Status vergeben, bei den Zahlungsdienstleistern dann nach der Zahlung der Status entsprechend angepasst. Beispiel (PP-Zahlung): Kaufen-Button > Status "Paypal offen" > Lagerbestand unverändert Bezahlung mit PP erfolgreich > Status "Bezahlt" > Lagerbestand reduziert Bezahlung mit PP nicht erfolgreich > Status "Paypal Abbruch" > Lagerbestand unverändert etc. Beispiel (Vorlasse oder Barzahlung): Kaufen-Button > Status "Vorkasse/Barzahlung offen" > Lagerbestand reduziert Wenn gewährleistet ist, das alle Rückgabewerte von PP oder SOFORT einen Status zugeordnet bekommen können, ist das doch die perfekte Lösung. Wenn ich das jetzt richtig gesehen habe, haben die Module das schon und auch Barzahlung und Vorkasse haben einen definierbaren Status. -Ich kann also den Status am Zahlungsmodul (und dessen Zwischenschritte) frei definieren. -Ich kann dem Status eine Lagerverwaltungsoption zuordnen Auch das Stornieren liest dann diese Einstellung aus und schreibt entweder den Bestand gut oder nicht. Vielleicht schafft Ihr es bei der Gelegenheit auch, dass das Produkt wieder "aktiviert" wird, wenn der Bestand durch die Stornierung von 0 auf >1 gesetzt wird. Die automatische Bestelleingangsbestätigung sollte sich an der Lagerbestandsreduzierung orientieren. Wenn diese durchgeführt wird, ist die Bestellung erfolgreich. Heißt bei PP nach erfolgreicher Zahlung, bei Vorkasse sofort, wie eben im Beispiel oben. Die Zukunftsvision klingt auch verlockend, in der Tat sind das zwei verschiedene Prozesse, die man eigentlich trennen sollte. Die Idee von Dennis finde ich super, im Kunden-Account eine Option zu schaffen. Da sind aber massig Dinge zu beachten, das ist schon ne mächtige Lösung. Da muss geprüft werden, wurde der Bestand schon durch eine andere Zahlungsart reduziert, Statusänderungen, Mailbestätigungen müssen u.U. neu geschickt werden. Dazu muss man bedenken, dass manche Shops Paypal-Gebühren nehmen, die in der Bestätigung zur Vorkasse-Zahlung nicht drin standen, jetzt aber hinzukommen, usw. Interessant fände ich in dem Zuge auch die Schaffung von Optionen zum nachträglichen Ändern der Liefer- oder Rechnungsadresse, solange bestimmte Stati noch nicht erreicht sind. Man sieht also, da ist sehr viel Potenzial nach oben. Aber der Daniel lacht ja so schön auf seinem Profilbild, und wie sag ich da immer? Wer lacht hat noch Ressourcen
Also ich kann mir keinerlei Szenario vorstellen, in dem es irgendeinen Sinn macht, den Lagerbestand zu reduzieren, bevor das Geld in der Kasse klingelt, so dass man in der "checkout_process" das erst machen darf, wenn das gewährleistet ist.... Das kann man in der "checkout_process" lassen, nur an anderer Stelle (nämlich in dem Code-Teil, in dem dann die Bestell-Mail versendet wird). Es gibt aber Zahlarten, bei denen es ein noch grundlegenderes Problem gibt: die Zahlung erfolgt offline per Vorkasse/Nachnahme usw. In dem Fall dürfte in der "checkout_process" gar kein Lagerupdate erfolgen, sondern das müsste in den Admin verlagert werden, wenn der "Bezahlt"-Bestellstatus gesetzt wird.... Das betrifft übrigens gleichermaßen den "Kampagnen"-Update, der auch unabhängig von der Bezahlung gemacht wird, und dann ebenfalls evtl. falsch ist....