Hallo @_MikeB ,
generell ist die Bestellung komplett losgelöst von der Zahlung. Das hat verschiedenste Gründe:
- Bestellungen werden vor der Weiterleitung ausgelöst und somit ist sichergestellt, dass das Produkt nach Zahlung auch noch verfügbar ist. Es kam in SW5 häufig zu Überverkäufen, eben weil die Bestellung und der Bestand erst nach Zahlung reserviert wurde.
- Sollte es einen Fehler im Payment-Prozess geben und der Shop bspw. temporär nicht erreichbar sein, so hat der Shopbetreiber auch immer eine Bestellung zu einer Zahlung. Wenn es die Bestellung noch nicht gibt, hätte er sonst eine Zahlung, aber keine Bestellung im System. Ebenfalls häufig vorgekommen
- In Prozessen wie bspw. „Admin Orders“ ist die Zahlung immer losgelöst von der Bestellung. Die Bestellung wird bspw. per Telefon oder einer Messe entegegen genommen, der Kunde kann dann bequem zu Hause zahlen
- Der Kunde kann so nachträglich seine Zahlungsart über das Kundenkonto ändern
- Der Shopbetreiber hat eine Übersicht über alle Bestellungen (auch jene bei denen die Zahlungen fehlgeschlagen sind) und kann die Kunden kontaktieren und auf weitere Zahlungsarten hinweisen
- Perspektivisch kann man so auch mehrere Zahlungen pro Bestellung abbilden (bspw. 50% per Gift Card, Rest per Paypal)
- Einfache realisierung von Zahlungsarten die „asynchron“ sind, bspw. ein Rechnungskauf, der durch eine Schnittstelle geprüft wird, aber erst 2-3 Stunden später die Zahlung validiert
- möglicherweise sowas wie In-App Käufe und ähnliche Konzepte, wo der Checkout nicht nachgebildet werden soll
- Übertragung von Bestelldaten (bspw. Bestellnummern) direkt an den Payment Provider
In jeder Mail ist jetzt schon ein Direktlink um direkt in diesen Prozess zu springen. Ein komplett neues, abweichendes Konzept ist das generell nicht, auch in SW5 haben wir bspw. bei Übertragung der Bestellnummer auch direkt eine Bestellung ausgelöst. Viele andere Payment Provider haben dies auch so gelöst. Wir haben uns dazu auch schon weiterführende Gedanken gemacht und es wird auch kurzfristig weitere Optimierungen in diesem Prozess geben:
- Der Shopbetreiber kann entscheiden, ob er bei Bestellung oder bei Zahlung eine Mail verschicken will und dies pro Zahlungsart definieren. Hier wird auch das Wording angepasst, damit klar ist, welche Mail für welchen Zweck gedacht ist
- Der Workflow wird angepasst, sodass man immer direkt im Änderungsprozess landet und die Zahlungsart wechseln kann
- Zahlungsarten werden direkt auf der Seite angezeigt und nicht hinter dem Ändern-Button versteckt
- Wording wird angepasst (bspw. statt „Bestellung ändern“ eher „Zahlungsart ändern“ oder „Zahlung durchführen“)
Langfristige Anpassungen:
- Cronjob der einen Reminder für die Zahlung nach x Minuten rausschickt und die Bestellung nach x Minuten storniert, falls keine Zahlung erfolgt
Generell hat ja jeder Shop Bestellungen ohne Zahlungen im System - egal ob jemand per Vorkasse bezahlt oder bspw. Ebay Bestellungen usw. importiert. In den wenigsten Fällen ist grundsätzlich jede Bestellung bezahlt, bevor sie in das System kommt. In meinen Augen überwiegen hier die Vorteile für den Shopbetreiber. Auf Seiten des Shopkunden gibt es hier noch Optimierungsschritte, die ich oben aufgeführt habe. Eine komplette Änderung des Verhaltens wird es so nicht geben, allerdings werden wir das System weiter optimieren, dass sich für den Shopkunden hier auch nichts anders anfühlt
Moritz