dafür gibts keine “die eine wahre Lösung”, weil es zig Wege gibt und so gut wie jeder Shopbetreiber da seine eigene Vorstellung hat, wie diese Preisgestaltung im Detail ablaufen sollte.
Beispiel:
Kunde kauft 4 Hosen für je 100€, storniert dann aber zwei.
Theoretisch sollte er jetzt nur 200 bezahlen, was aber wenn er einen Mengenrabatt oder Reduzierung durch Staffelpreise hatte?
Hier wäre Preisaktualisierung richtig, weil wenn er von Anfang an nur 2 gekauft hätte, hätte er 125€ pro Hose bezahlen müssen. Das wären dann 250€.
Und was ist, wenn er einen Gutschein mit 350€ Mindestbestellwert eingelöst hat? Durch die Änderung wäre sein Gutschein nicht mehr gültig, also sollte der Preis eigentlich wieder aktualisiert werden.
Und was ist mit Währungen? Bei extremen Schwankungen kann der Preis paar Tage später völlig wo anders rauskommen, weil der Shop keine historischen Wechselkurse speichert.
Der Shop speichert aber auch nicht, wie der bezahlte Produktpreis zustande kam, z.B: Staffelpreis X - Rabatt Y - Gutschein Z = 100€, deswegen muss der Shop später den gesamten Preis erneut ausrechnen, was eben dazu führen kann, dass bestimmte Rabatte nicht mehr gültig sind.
Und zu guter Letzt ist die Stelle im Code, wo das alles passiert, auch nicht leicht mit einem Modul erweiterbar.
Deswegen steht man vor einem Dilemma:
Auf einer Seite ist eine universelle Lösung, falls machbar, so kompliziert und zeitaufwändig, dass niemand das einfach so machen wollen würde.
Und auf der anderen Seite wäre eine kundenspezifische Lösung für das bestimmte Szenario des Kunden durchaus machbar, allerdings wiederum so speziell, dass man es nicht im voraus einfach so programmiert.