A) Im Prinzip wird eine [Session](https://www.php.net/manual/de/session.examples.basic.php) aufgebaut, die eine eindeutige ID hat, um welche man sich z.B. im Falle der Nutzung von PHP kaum kümmern muss. In dieser Session wird ein [Array](https://www.php.net/manual/de/language.types.array.php) abgelegt, welches im Prinzip eine Tabelle mit den Einkäufen darstellt. Alternativ kann man freilich die Daten nicht in der Session selbst sondern in einer Datenbank ablegen und mit der Session-ID identifizieren. [Das geht auch mit der Session selbst](http://shiflett.org/articles/storing-sessions-in-a-database). Ob das sein muss, oder sollte sei für eine Einzelfallbetrachtung dahingestellt, man kann es aber. Dabei ist zu beachten, dass z.B. der Preis stets aus der serverseitigen Datenbank stammt, den vom Browser gelieferten Daten glaubt man nur die Artikelnummer und die Anzahl. Apropos Preis: stets netto - [denn man bekommt Ärger wenn man einen Artikel mit 19% USt an einen Verbraucher in Österreich verkauft](https://europa.eu/youreurope/business/taxation/vat/cross-border-vat/index_de.htm). Beim Preis muss man auch beachten und wissen was man tun will (und darf), wenn ein Artikel um 23:55 in den Warenkorb aufgenommen wurde und um 00:15 gekauft wird - wenn sich z.B. zwischenzeitlich der geforderte Preis geändert hat. oder B) Das gleiche geschieht (abgesehen von der Session) im Browser z.B. in einem Cookie oder Storage, also im Browser des Benutzers. Beim Kauf muss dann ein Abgleich der nunmehr gesendeten Daten mit den auf dem Server vorhandenen stattfinden - sonst (ver)kauft (man) nach einer Datenmanipulation jemand ein iPhone für 7,99€ statt 799 €. * Wenn der Warenkorb angezeigt wird, werden alle Summe durch subraketenwissenschaftliche Methoden (Multiplizieren und Addieren) errechnet. * Man sollte bei einer Erhöhung der Anzahl der Einzelpostionen durch den potentiellen Käufer vielleicht auf prüfen ob der Artikel in der erhöhten Anzahl überhaupt verfügbar ist. **Hinweis:** Einen Webshop sollte man nur selbst programmieren wenn man sowas kann und auch in der Lage ist, Sicherheitsrisiken und juristische Aspekte zu beachten. Insgesamt ist es fast einfacher eine Rakete zu bauen.

A) Im Prinzip wird eine [Session](https://www.php.net/manual/de/session.examples.basic.php) aufgebaut, die eine eindeutige ID hat, worum man sich z.B. im Falle der Nutzung von PHP nicht kümmern muss. In dieser Session wird ein [Array](https://www.php.net/manual/de/language.types.array.php) abgelegt, welches im Prinzip eine Tabelle mit den Einkäufen darstellt. Alternativ kann man freilich die Daten nicht in der Session selbst sondern in einer Datenbank ablegen und mit der Session-ID identifizieren. [Das geht auch mit der Session selbst](http://shiflett.org/articles/storing-sessions-in-a-database). Ob das sein muss, oder sollte sei für eine Einzelfallbetrachtung dahingestellt, man kann es aber. Dabei ist zu beachten, dass z.B. der Preis stets aus der serverseitigen Datenbank stammt, den vom Browser gelieferten Daten glaubt man nur die Artikelnummer und die Anzahl. Apropos Preis: stets netto - [denn man bekommt Ärger wenn man einen Artikel mit 19% USt an einen Verbraucher in Österreich verkauft](https://europa.eu/youreurope/business/taxation/vat/cross-border-vat/index_de.htm). Beim Preis muss man auch beachten und wissen was man tun will (und darf), wenn ein Artikel um 23:55 in den Warenkorb aufgenommen wurde und um 00:15 gekauft wird - wenn sich z.B. zwischenzeitlich der geforderte Preis geändert hat. oder B) Das gleiche geschieht (abgesehen von der Session) im Browser z.B. in einem Cookie oder Storage, also im Browser des Benutzers. Beim Kauf muss dann ein Abgleich der nunmehr gesendeten Daten mit den auf dem Server vorhandenen stattfinden - sonst (ver)kauft (man) nach einer Datenmanipulation jemand ein iPhone für 7,99€ statt 799 €. * Wenn der Warenkorb angezeigt wird, werden alle Summe durch subraketenwissenschaftliche Methoden (Multiplizieren und Addieren) errechnet. * Man sollte bei einer Erhöhung der Anzahl der Einzelpostionen durch den potentiellen Käufer vielleicht auf prüfen ob der Artikel in der erhöhten Anzahl überhaupt verfügbar ist. **Hinweis:** Einen Webshop sollte man nur selbst programmieren wenn man sowas kann und auch in der Lage ist, Sicherheitsrisiken und juristische Aspekte zu beachten. Insgesamt ist es fast einfacher eine Rakete zu bauen.

A) Im Prinzip wird eine [Session](https://www.php.net/manual/de/session.examples.basic.php) aufgebaut, die eine eindeutige ID hat, worum man sich z.B. im Falle der Nutzung von PHP nicht kümmern muss. In dieser Session wird ein [Array](https://www.php.net/manual/de/language.types.array.php) abgelegt, welches im Prinzip eine Tabelle mit den Einkäufen darstellt. Alternativ kann man freilich die Daten nicht in der Session selbst sondern in einer Datenbank ablegen und mit der Session-ID identifizieren. [Das geht auch mit der Session selbst](http://shiflett.org/articles/storing-sessions-in-a-database). Ob das sein muss, oder sollte sei für eine Einzelfallbetrachtung dahingestellt, man kann es aber. Dabei ist zu beachten, dass z.B. der Preis stets aus der serverseitigen Datenbank stammt, den vom Browser gelieferten Daten glaubt man nur die Artikelnummer und die Anzahl. Apropos Preis: stets netto - [denn man bekommt Ärger wenn man einen Artikel mit 19% USt an einen Verbraucher in Österreich verkauft](https://europa.eu/youreurope/business/taxation/vat/cross-border-vat/index_de.htm). Beim Preis muss man auch beachten und wissen was man tun will (und darf), wenn ein Artikel um 23:55 in den Warenkorb aufgenommen wurde und um 00:15 gekauft wird - wenn sich z.B. zwischenzeitlich der geforderte Preis geändert hat. oder B) Das gleiche geschieht (abgesehen von der Session) im Browser z.B. in einem Cookie oder Storage, also im Browser des Benutzers. Beim Kauf muss dann ein Abgleich der nunmehr gesendeten Daten mit den auf dem Server vorhandenen stattfinden - sonst (ver)kauft (man) nach einer Datenmanipulation jemand ein iPhone für 7,99€ statt 799 €. * Wenn der Warenkorb angezeigt wird, werden alle Summe durch subraketenwissenschaftliche Methoden (Multiplizieren und Addieren) errechnet. * Man sollte bei einer Erhöhung der Anzahl der Einzelpostionen durch den potentiellen Käufer vielleicht auf prüfen ob der Artikel in der erhöhten Anzahl überhaupt verfügbar ist. **Hinweis:** Einen Webshop sollte man nur selbst programmieren wenn man sowas kann und auch in der Lage ist, Sicherheitsrisiken und juristische Aspekte zu beachten. Insgesamt ist fast einfacher eine Rakete zu bauen.

A) Im Prinzip wird eine [Session](https://www.php.net/manual/de/session.examples.basic.php) aufgebaut, die eine eindeutige ID hat, worum man sich z.B. im Falle der Nutzung von PHP nicht kümmern muss. In dieser Session wird ein [Array](https://www.php.net/manual/de/language.types.array.php) abgelegt, welches im Prinzip eine Tabelle mit den Einkäufen darstellt. Alternativ kann man freilich die Daten nicht in der Session selbst sondern in einer Datenbank ablegen und mit der Session-ID identifizieren. [Das geht auch mit der Session selbst](http://shiflett.org/articles/storing-sessions-in-a-database). Ob das sein muss, oder sollte sei für eine Einzelfallbetrachtung dahingestellt, man kann es aber. Dabei ist zu beachten, dass z.B. der Preis stets aus der serverseitigen Datenbank stammt, den vom Browser gelieferten Daten glaubt man nur die Artikelnummer und die Anzahl. Apropos Preis: stets netto - [denn man bekommt Ärger wenn man einen Artikel mit 19% USt an einen Verbraucher in Österreich verkauft](https://europa.eu/youreurope/business/taxation/vat/cross-border-vat/index_de.htm). Beim Preis muss man auch beachten und wissen was man tun will (und darf), wenn ein Artikel um 23:55 in den Warenkorb aufgenommen wurde und um 00:15 gekauft wird - wenn sich z.B. zwischenzeitlich der geforderte Preis geändert hat. oder B) Das gleiche geschieht (abgesehen von der Session) im Browser z.B. in einem Cookie oder Storage, also im Browser des Benutzers. Beim Kauf muss dann ein Abgleich der nunmehr gesendeten Daten mit den auf dem Server vorhandenen stattfinden - sonst (ver)kauft (man) nach einer Datenmanipulation jemand ein iPhone für 7,99€ statt 799 €. * Wenn der Warenkorb angezeigt wird, werden alle Summe durch subraketenwissenschaftliche Methoden (Multiplizieren und Addieren) errechnet. * Man sollte bei einer Erhöhung der Anzahl der Einzelpostionen vielleicht auf prüfen ob der Artikel in der erhöhten Anzahl überhaupt verfügbar ist. **Hinweis:** Einen Webshop sollte man nur selbst programmieren wenn man sowas kann und auch in der Lage ist, Sicherheitsrisiken und juristische Aspekte zu beachten. Insgesamt ist fast einfacher eine Rakete zu bauen.

A) Im Prinzip wird eine [Session](https://www.php.net/manual/de/session.examples.basic.php) aufgebaut, die eine eindeutige ID hat, worum man sich z.B. im Falle der Nutzung von PHP nicht kümmern muss. In dieser Session wird ein [Array](https://www.php.net/manual/de/language.types.array.php) abgelegt, welches im Prinzip eine Tabelle mit den Einkäufen darstellt. Alternativ kann man freilich die Daten nicht in der Session selbst sondern in einer Datenbank ablegen und mit der Session-ID identifizieren. [Das geht auch mit der Session selbst](http://shiflett.org/articles/storing-sessions-in-a-database). Ob das sein muss, oder sollte sei für eine Einzelfallbetrachtung dahingestellt, man kann es aber. Dabei ist zu beachten, dass z.B. der Preis stets aus der serverseitigen Datenbank stammt, den vom Browser gelieferten Daten glaubt man nur die Artikelnummer und die Anzahl. Apropos Preis: stets netto - [denn man bekommt Ärger wenn man einen Artikel mit 19% USt an einen Verbraucher in Österreich verkauft](https://europa.eu/youreurope/business/taxation/vat/cross-border-vat/index_de.htm). Beim Preis muss man auch beachten und wissen was man tun will (und darf), wenn ein Artikel um 23:55 in den Warenkorb aufgenommen wurde und um 00:15 gekauft wird - wenn sich z.B. zwischenzeitlich der geforderte Preis geändert hat. oder B) Das gleiche geschieht (abgesehen von der Session) im Browser z.B. in einem Cookie oder Storage, also im Browser des Benutzers. Beim Kauf muss dann ein Abgleich der nunmehr gesendeten Daten mit den auf dem Server vorhandenen stattfinden - sonst (ver)kauft (man) nach einer Datenmanipulation jemand ein iPhone für 7,99€ statt 799 €. * Wenn der Warenkorb angezeigt wird, werden alle Summe durch subraketenwissenschaftliche Methoden (Multiplizieren und Addieren) errechnet. * Man sollte bei einer Erhöhung der Anzahl der Einzelpostionen vielleicht auf prüfen ob der Artikel in der erhöhten Anzahl überhaupt verfügbar ist.

A) Im Prinzip wird eine [Session](https://www.php.net/manual/de/session.examples.basic.php) aufgebaut, die eine eindeutige ID hat, worum man sich z.B. im Falle der Nutzung von PHP nicht kümmern muss. In dieser Session wird ein Array abgelegt, welches im Prinzip eine Tabelle mit den Einkäufen darstellt. Alternativ kann man freilich die Daten nicht in der Session selbst sondern in einer Datenbank ablegen und mit der Session-ID identifizieren. [Das geht auch mit der Session selbst](http://shiflett.org/articles/storing-sessions-in-a-database). Ob das sein muss, oder sollte sei für eine Einzelfallbetrachtung dahingestellt, man kann es aber. Dabei ist zu beachten, dass z.B. der Preis stets aus der serverseitigen Datenbank stammt, den vom Browser gelieferten Daten glaubt man nur die Artikelnummer und die Anzahl. apropos Preis: stets, netto - [denn man bekommt Ärger wenn man einen Artikel mit 19% USt an einen Verbraucher in Österreich verkauft](https://europa.eu/youreurope/business/taxation/vat/cross-border-vat/index_de.htm). oder B) Das gleiche geschieht (abgesehen von der Session) im Browser z.B. in einem Cookie oder Storage, also im Browser des Benutzers. Beim Kauf muss dann ein Abgleich der nunmehr gesendeten Daten mit den auf dem Server vorhandenen stattfinden - sonst (ver)kauft (man) nach einer Datenmanipulation jemand ein iPhone für 7,99€ statt 799 €. * Wenn der Warenkorb angezeigt wird, werden alle Summe durch subraketenwissenschaftliche Methoden (Multiplizieren und Addieren) errechnet. * Man sollte bei einer Erhöhung der Anzahl der Einzelpostionen vielleicht auf prüfen ob der Artikel in der erhöhten Anzahl überhaupt verfügbar ist.