Nachdem die Basis des Bestellprozesses steht, Bestellungen verschiedene Status haben können und auch das Notification Center 2 integriert ist, beschäftigt mich noch ein fast philosophisches Problem: bestellt oder nichtbestellt, das ist hier die Frage.
Gemäss der Button-Lösung heisst der letzte Schritt im Bestellprozess ja meist Kostenpflichtig bestellen. Nach Klick dieses Buttons werden Käufer:innen zum Zahlungsanbieter weitergeleitet. In Isotope war es bisher so, dass Bestellungen nur dann gespeichert wurden, wenn diese Zahlung auch erfolgreich war, obwohl im Prinzip bereits einem rechtlich bindender Kaufvertrag zugestimmt wurde. Bei Zahlungsabbruch wurde die Bestellung verworfen, es war selber für Shop-Betreiber:innen nicht nachvollziehbar, welche Bestellungen nicht abgeschlossen wurden.
Aktuell überlege ich mir, ob das so bleiben soll, oder wie eine Alternative aussehen würde. Für das (neue) System wäre es einfacher, wenn eine Bestellung einfach da ist, sobald man den Button klickt (bzw. eben dann, wenn sie per PHP erstellt wird). Es würde ausserdem die Möglichkeit schaffen, nicht-abgeschlossene Bestellungen bei den Kunden nachzufassen und vermutlich einiges noch zu verkaufen. Ob manuell oder irgendwann automatisiert, ist dann eine andere Frage.
Allerdings gibt es auch einige potenzielle Probleme: wenn viele Kund:innen den Zahlungsprozess abbrechen, ergibt das viele Leichen im Backend. Meist vermutlich unnötiger Mehraufwand für Betreiber:innen, insbesondere von kleinen Shops. Auch eine Bestellungs-Mail (an den/die Betreiber:in) bedeutet dann ja nicht automatisch, dass ein Produkt versendet werden kann. Das war bisher auch so, wenn man z.B. Vorkasse anbot, aber nur mit Kreditkarten halt eben nicht. Würde man die Mail erst bei Bezahlung senden, erfährt man wiederum nicht mehr, was alles bestellt wurde.
Ein weiteres Problem ist die Bestellnummer in Isotope. Einige werden wissen, dass man im Backend die Datenbank-ID und die Bestellnummer sieht. Vor allem, weil die Bestellnummer erst bei Zahlungsabschluss generiert wird – und somit an Drittsysteme (z.B. PayPal) nicht als Referenznummer übermittelt werden kann. Dort braucht es die Datenbank-ID, was schon eher unschön ist. Wäre die Nummer bereits vor dem Zahlungsabschluss vorhanden, könnte diese überall genutzt werden. Aber es führt dazu, dass die fortlaufende Nummerierung für nicht-bezahlte (und ggf. später stornierte) Bestellungen generiert wird. Falls die Buchhaltung eine fortlaufende Belegnummerierung verlangt, müsste man alle fehlgeschlagenen Bestellungen auch ein- und ausbuchen.
Eine mögliche Lösung wäre, eine Bestellnummer für die Bestellung und z.B. eine Rechnungsnummer für eine Rechnung zu generieren. Letzteres natürlich erst bei Bezahlung. Das wäre eigentlich richtig – aber Isotope kennt bisher keine Belege zu einer Bestellung oder dergleichen. Ein Konzept, welches man erst entwickeln und umsetzen müsste.
Was denkst du darüber? Teile es mir gerne in einem Kommentar mit.
