# Online-Shop mit KI bauen: Zahlungen und Sicherheit

URL: https://agentvera.dev/de/blog/build-ecommerce-store-with-ai/ · Veröffentlicht: 2026-10-11

Online-Shop mit KI bauen: Shopify oder Eigenbau, Next.js mit Stripe, Warenkorb, Preise auf dem Server, Webhooks, Bestand, E-Mails, Rechtstexte und PCI-Regeln.

**Kurz gesagt:**

- Eine gehostete Plattform wie Shopify ist oft die sicherere und schnellere Wahl; ein Eigenbau lohnt sich, wenn du einen Ablauf, ein Design oder eine Kostenstruktur brauchst, die die Plattform nicht bietet.
- In einem eigenen Shop enthält der Warenkorb nur Produkt-IDs und Mengen, Preise sind Ganzzahlen in der kleinsten Währungseinheit, und die Summe wird immer auf dem Server berechnet.
- Markiere eine Bestellung nur über einen signaturgeprüften, idempotenten Webhook als bezahlt, verringere den Bestand mit einer atomaren Abfrage und speichere oder erfasse nie selbst Kartendaten.

Um einen Online-Shop mit KI zu bauen, lässt du einen Coding-Agenten Schritt für Schritt Produktkatalog, Warenkorb und Checkout schreiben; ein typisches Setup ist Next.js, eine Datenbank und ein Zahlungsanbieter wie Stripe. Der Agent schreibt schnell Code, aber die Regeln musst du setzen: Preise werden auf dem Server berechnet, Zahlungen per Webhook bestätigt und Kartendaten nie gespeichert. Vorher zu entscheiden, ob eine gehostete Plattform wie Shopify deinen Bedarf schon abdeckt, gehört zur Arbeit.

Diese Anleitung beginnt mit dieser Entscheidung und führt dann der Reihe nach durch den Bau eines eigenen Shops mit einem Agenten: Datenmodell, Warenkorb, Checkout, Webhooks, Bestand, E-Mails, Rechtstexte und Deployment. Jeder Schritt hat Prompts zum Kopieren. Am Ende steht eine Liste der Fehler, die KI im E-Commerce am häufigsten macht, und eine Sicherheits-Checkliste.

## Erste Entscheidung: gehostete Plattform oder Eigenbau?

Die ehrliche Antwort lautet oft „gehostete Plattform“. Shopify, WooCommerce und ähnliche Plattformen übernehmen Zahlungen, Lagerverwaltung, Versandanbindungen, Steuern und Sicherheitsupdates für dich.

| | Gehostete Plattform | Eigenbau (mit Coding-Agent) |
| --- | --- | --- |
| Zeit bis zum ersten Verkauf | Tage | Wochen |
| Zahlungen, Sicherheit, Updates | Aufgabe der Plattform | Deine Aufgabe |
| Freiheit bei Design und Ablauf | So weit Themes und Apps reichen | Unbegrenzt |
| Kostenstruktur | Monatsgebühr, manchmal Transaktionsgebühren | Hosting + Gebühren des Zahlungsanbieters + deine Zeit |
| Portabilität | An die Plattform gebunden | Du besitzt den Code |

Ein Eigenbau lohnt sich, wenn dein Verkaufsablauf nicht unterstützt wird (etwa Abos plus ein Konfigurator für Maßanfertigungen), wenn du einen Shop in eine bestehende App einbauen willst oder wenn du lernen und die volle Kontrolle behalten möchtest. Diesen Weg behandelt diese Anleitung. Willst du lieber mit einer einfachen Marketing-Seite beginnen, lies zuerst [Website mit KI bauen](/de/blog/build-website-with-ai/).

## 1. Stack und Einrichtung

Für ein [Vibe-Coding](/de/glossary/vibe-coding/)-Projekt empfehle ich einen Stack, den Agenten gut kennen und der stark dokumentiert ist:

- **Next.js** (App Router): Seiten, Servercode und API-Routen in einem Projekt.
- **PostgreSQL:** ein verwalteter Dienst (Supabase, Neon und Ähnliche) oder lokal mit Docker.
- **Ein ORM** (Prisma oder Drizzle): Schema und Migrationen liegen in Dateien, sodass du und der Agent aus derselben Quelle lest.
- **Ein Zahlungsanbieter:** Stripe ist die übliche Wahl; in manchen Ländern sind lokale Anbieter Standard (in der Türkei zum Beispiel iyzico oder PayTR). Gemeinsam ist ihnen, dass die Karte im Formular des Anbieters eingegeben wird und das Ergebnis per Benachrichtigung bei deinem Server ankommt.
- **Ein Dienst für Transaktions-E-Mails:** für Bestellbestätigungen und Versandmitteilungen.

```bash
npx create-next-app@latest store
cd store
git status   # create-next-app usually initialises git; if not: git init
claude
```

## 2. Der erste Prompt: erst planen, dann Code

Sagst du einem Agenten „bau mir einen Shop“, bekommst du alles in einem Rutsch, und die kritischen Teile werden überflogen. Bitte zuerst um einen Plan:

```text
We're building a small ecommerce site with Next.js (App Router), PostgreSQL and Prisma.
Payments will use Stripe Checkout (card data must never reach our server).

Don't write code yet. First produce a plan covering:
1. Data model: product, product variant (size/colour), order, order item, stock.
2. Pages: product list, product detail, cart, checkout return pages, a simple admin.
3. Payment flow: from cart to creating a checkout session to marking the order paid via webhook.
4. Which operations must happen on the server, and why.

Rules:
- Store prices as integers in the smallest currency unit (cents), never floats.
- Never trust a price, total or discount amount sent from the client.
- Secrets live only in .env; no secret ever reaches client code.
Write the plan and wait for my approval.
```

Lies den Plan, korrigiere, was dir nicht gefällt, und setze ihn dann Stück für Stück um: erst das Datenmodell, dann der Katalog, dann der Warenkorb, zuletzt die Zahlungen. Committe nach jedem Stück.

## 3. Die Produktdatenbank

Im Datenmodell achte ich auf ein paar Dinge:

- **Geld ist eine Ganzzahl.** 14,90 $ werden als `1490` gespeichert. Stripe und die meisten Anbieter erwarten Beträge ohnehin in der kleinsten Währungseinheit.
- **Bestellpositionen kopieren den Preis.** Die Bestellung behält Namen und Preis des Produkts zum Kaufzeitpunkt, damit eine Preisänderung morgen vergangene Bestellungen nicht umschreibt.
- **Der Bestand liegt an der Variante.** „Blaues T-Shirt, Größe M“ ist eine eigene Bestandszeile.
- **Der Bestellstatus ist eine ausdrückliche Liste:** `pending`, `paid`, `shipped`, `cancelled`, `refunded` und so weiter.

Schreibt der Agent eine Migration, lies die Datei. Löscht sie eine Tabelle oder Spalte, die schon Daten enthält, halte an und frage nach.

## 4. Der Warenkorb

Der Warenkorb im Browser (oder bei angemeldeten Nutzern in der Datenbank) sollte nur **Produkt-/Varianten-IDs und Mengen** enthalten. Preise und Summen werden im Warenkorb angezeigt, aber immer vom Server gelesen.

```text
Implement the cart. Store only a list of {variantId, quantity} in localStorage.
The cart page fetches current prices and the total from the server.
Out-of-stock or deleted products show in the cart with a warning.
Limit quantity to 1–10 and enforce that on the server too.
```

## 5. Checkout: Preise werden immer auf dem Server berechnet

Regel Nummer eins im E-Commerce: **Vertraue nie einem Preis vom Client.** Jeder Wert im Browser lässt sich ändern; jeder kann die Dev-Tools öffnen und die Summe auf 1 $ setzen. Der richtige Ablauf:

1. Der Client sendet dem Server nur die Liste aus `variantId` und `quantity`.
2. Der Server liest Preis und Bestand jeder Position aus der Datenbank und berechnet die Summe selbst.
3. Der Server legt eine Bestellung mit dem Status `pending` an.
4. Der Server erstellt beim Anbieter eine Zahlungssitzung (eine Stripe Checkout Session oder das Zahlungsformular des lokalen Anbieters) und hängt die Bestell-ID daran.
5. Der Kunde wird auf die Seite oder das iframe des Anbieters weitergeleitet und gibt dort seine Karte ein.

Eine gekürzte Vorstellung des Servercodes:

```ts
// app/api/checkout/route.ts (sketch)
const items = await db.variant.findMany({ where: { id: { in: cart.map(c => c.variantId) } } })
const lineItems = cart.map(c => {
  const v = items.find(i => i.id === c.variantId)
  if (!v || v.stock < c.quantity) throw new Error('Out of stock')
  return { price: v.priceCents, quantity: c.quantity }   // price from the DB, not the client
})
```

Rabattcodes folgen derselben Regel: Der Code kommt vom Client, aber ob er gültig ist und wie viel er abzieht, entscheidet der Server.

## 6. Webhooks: bezahlt oder nicht?

Dass ein Kunde auf deiner Seite „Zahlung erfolgreich“ landet, beweist **nicht**, dass die Zahlung durchging; diese Seite kann von Hand geöffnet werden, und der Kunde hat vielleicht den Tab geschlossen. Die Wahrheit ist die Benachrichtigung, die dein Anbieter an deinen Server schickt (bei Stripe ein Webhook, bei anderen Anbietern oft Callback genannt).

Sag dem Agenten für den Webhook-Endpunkt klar, was du willst:

```text
Write the Stripe webhook endpoint (/api/webhooks/stripe):
- Verify the signature with STRIPE_WEBHOOK_SECRET; reject unsigned or invalid requests.
- Use the raw request body for signature verification.
- On checkout.session.completed, read the order ID from metadata, and inside one
  database transaction mark the order "paid" and decrement stock.
- Make it idempotent: if the same event arrives twice, the second time changes nothing.
- Compare the amount paid with the order total; if they differ, flag the order and log it.
```

Zum lokalen Testen kann die Stripe CLI Events an deinen Rechner weiterleiten:

```bash
stripe listen --forward-to localhost:3000/api/webhooks/stripe
```

Im Testmodus von Stripe lassen dich Testkarten wie `4242 4242 4242 4242` den ganzen Ablauf ohne echtes Geld durchspielen. Auch andere Anbieter haben Sandboxes; lass den Agenten deren Doku lesen, wie die Signatur oder der Hash der Benachrichtigung geprüft wird.

## 7. Bestand

Beim Bestand können zwei Personen im selben Moment den letzten Artikel kaufen. Agenten schreiben meist „lesen, dann schreiben“, was dazwischen eine Race Condition lässt. Mach stattdessen Prüfung und Verringerung in einer atomaren Abfrage:

```sql
UPDATE variants SET stock = stock - 2
WHERE id = 'var_123' AND stock >= 2;
-- if zero rows were affected, there wasn't enough stock
```

Den Bestand erst nach bestätigter Zahlung (im Webhook) zu verringern ist die einfache Variante; bei sehr knappen Artikeln kannst du zusätzlich beim Öffnen der Checkout-Sitzung eine kurze Reservierung halten. Sag dem Agenten ausdrücklich, was du willst.

## 8. E-Mails

Du brauchst mindestens zwei: eine **Bestellbestätigung** und eine **Versandmitteilung**. Sende die Bestätigung aus dem Webhook, nicht von der Erfolgsseite, damit sie nur für tatsächlich bezahlte Bestellungen rausgeht. Der API-Schlüssel des E-Mail-Dienstes bleibt auf dem Server. Überspringst du die SPF-/DKIM-Einträge, die dein E-Mail-Anbieter für deine Absenderdomain verlangt, landen deine Mails womöglich im Spam.

## 9. Rechtstexte

Kein Code, aber Teil des Shops. Was vorgeschrieben ist, hängt davon ab, wo du und deine Kunden sitzen, aber die meisten Shops brauchen:

- **Eine Datenschutzerklärung** (was du erhebst und warum, dazu DSGVO oder lokale Entsprechungen, wo sie gelten)
- **Einen Cookie-Hinweis**, wo erforderlich
- **Verkaufsbedingungen**
- **Eine Erstattungs- und Rückgaberegelung**, einschließlich einer gesetzlichen Widerrufsfrist
- **Verkäuferangaben:** Firmenname, Adresse und Kontaktdaten

Verkaufst du in der Türkei, erwarte eine KVKK-Datenschutzerklärung, einen Fernabsatzvertrag und ein Vorabinformationsformular, das der Kunde vor der Bestellung bestätigt. Du kannst den Agenten die Zustimmungs-Checkboxen im Checkout ergänzen und die Zustimmung mit der Bestellung speichern lassen. KI kann diese Texte entwerfen, aber lass sie vor dem Livegang von einer Anwältin, einem Anwalt oder der Buchhaltung prüfen und frage dort auch nach Rechnungsstellung und Steuerpflichten.

## 10. Deployment

Die Next.js-App auf Vercel und die Datenbank auf einem verwalteten PostgreSQL-Dienst zu betreiben ist der kürzeste Weg. Vor dem Start:

- Trage die Umgebungsvariablen (Datenbank-URL, Zahlungs- und E-Mail-Schlüssel, Webhook-Secret) im Dashboard deines Hosts ein.
- Registriere die Live-Webhook-URL im Dashboard deines Zahlungsanbieters; verwechsle Test- und Live-Schlüssel nicht.
- Führe Migrationen bewusst gegen die Produktion aus und mach vorher ein Backup.
- Gib in der Produktion eine kleine echte Bestellung auf, erstatte sie und prüfe den ganzen Ablauf (E-Mail, Bestand, Bestellstatus) mit eigenen Augen.

## Was die KI im E-Commerce falsch macht

- **Die Summe im Client berechnen und an den Server senden.** Der gefährlichste Fehler. Suche im Code nach einem `price` oder `total`, das vom Client kommt, und entferne es.
- **Die Bestellung auf der Erfolgsseite als bezahlt markieren.** Ohne Webhook sollte sich der Bestellstatus nicht ändern.
- **Die Prüfung der Webhook-Signatur überspringen** oder den Body vor der Prüfung als JSON parsen und die Prüfung dann abschalten, weil „es nicht funktioniert“.
- **Floats für Geld.** Das `0.1 + 0.2`-Problem landet auf Rechnungen.
- **Keine Idempotenz.** Derselbe Webhook kommt zweimal an, der Bestand sinkt zweimal, zwei E-Mails gehen raus.
- **Ein ungeschütztes Admin-Panel.** Es baut eine `/admin`-Seite, vergisst aber die Autorisierungsprüfungen an den API-Routen. Stelle sicher, dass jede Admin-API die Rolle auf dem Server prüft.
- **Mit Test-Schlüsseln live gehen** oder umgekehrt in der Entwicklung Live-Schlüssel benutzen.

## Sicherheit

- **Speichere, logge oder erfasse nie Kartendaten mit einem eigenen Formular.** Nutze die gehostete Zahlungsseite oder das Formular des Anbieters; so bleibt dein PCI-DSS-Umfang so klein wie möglich.
- **Secrets in `.env`**, und `.env` in `.gitignore`. Lege nie einen geheimen Schlüssel (wie `sk_...`) in Client-Code oder in öffentliche Umgebungsvariablen (in Next.js die mit dem Präfix `NEXT_PUBLIC_`).
- **Füge API-Schlüssel nie in den Chat ein.** Nenne dem Agenten den Variablennamen, nicht den Wert.
- **Lies, was der Agent ausführt.** Bestätige in einem Terminal, das mit einer Produktionsdatenbank verbunden ist, Migrationen, `DROP`s oder massenhafte `UPDATE`s nicht automatisch.
- **Lies jeden Diff, besonders Zahlungs- und Auth-Code.** Hier ist ein zweites Augenpaar unverzichtbar; wie du das einrichtest, steht unter [KI-Code-Review](/de/blog/ai-code-review/).
- **Erhebe so wenig personenbezogene Daten wie möglich** und halte, was du erhebst, hinter eingeschränktem Zugriff.

## So mache ich das mit AgentVera

Bei einem Shop-Projekt hilft es, mehrere Agenten getrennt zu halten, und das mache ich mit [AgentVera](/de/download/):

- **Backend und UI in getrennten Worktrees.** Ein Claude-Code-Agent arbeitet an Zahlungen, Webhooks und Datenmodell, während ein Codex-Agent Produktseiten und die Warenkorb-Oberfläche baut. Jeder sitzt in einem eigenen [Git-Worktree](/de/glossary/git-worktree/), alle in einem [Workspace](/de/features/workspace/).
- **Datenbank-Manager.** Sieh dir Tabellen, Bestellungen und Bestand, die der Agent angelegt hat, im [Datenbank-Manager](/de/features/database-manager/) an, ohne ein anderes Tool zu öffnen; er unterstützt PostgreSQL, MySQL und SQLite.
- **DB Guard.** Er scannt Migrationen, die der Agent geschrieben hat, am Ende eines Turns; [DB Guard](/de/features/db-guard/) zeigt Risiken wie ein `DROP` oder ein `UPDATE` ohne `WHERE` gleich vorab.
- **Code-Review und Previews.** Endet ein Turn, lässt das [Code-Review](/de/features/code-review/) ein zweites Modell darüberschauen; [Preview-Umgebungen](/de/features/preview-environments/) betreiben den Dev-Server jedes Worktrees unter einer eigenen Adresse. Den Zahlungs-Diff liest du vor dem Merge trotzdem selbst.

Nichts davon macht die Dinge für dich richtig; es macht nur leichter sichtbar, was sich geändert hat.

## Kurze Checkliste

- [ ] Gehostet oder Eigenbau bewusst entschieden
- [ ] Preise sind Ganzzahlen in der kleinsten Einheit; Bestellpositionen kopieren den Preis
- [ ] Der Warenkorb enthält nur IDs und Mengen; die Summe wird auf dem Server berechnet
- [ ] Bestellungen werden nur über einen signaturgeprüften Webhook „bezahlt“; der Webhook ist idempotent
- [ ] Der Bestand wird mit einer atomaren Abfrage verringert
- [ ] Die Bestätigungs-E-Mail kommt aus dem Webhook; SPF/DKIM eingerichtet
- [ ] Datenschutz, Bedingungen, Erstattungsregelung und Verkäuferangaben sind live und geprüft
- [ ] Nirgends Kartendaten; Secrets nur auf dem Server
- [ ] In der Produktion eine echte Bestellung aufgegeben und erstattet

## Fazit

Du kannst einen Online-Shop mit KI bauen, und ein Agent schreibt das meiste schnell. Doch was einen Shop vertrauenswürdig macht, tut der Agent nicht von allein: Preise auf dem Server berechnet, Zahlungen per Webhook bestätigt, Bestand atomar verringert, keine Kartendaten gespeichert und die richtigen Rechtstexte. Lege diese Regeln in deinen ersten Prompt, teste jeden Schritt im Testmodus und lies den Zahlungscode immer, bevor du ihn mergst.

## Häufige Fragen

**Kann ich einen Online-Shop mit KI von Grund auf bauen?** Ja. Ein Coding-Agent kann die Produktseiten, den Warenkorb, die Zahlungsanbindung und Admin-Bildschirme schreiben. Die Teile für Zahlung, Bestand und Recht musst du trotzdem verstehen und testen, denn dort kosten Fehler, die nur so aussehen, als funktionierten sie, echtes Geld.

**Soll ich Shopify nutzen oder einen eigenen Shop bauen?** Wenn du schnell ein paar Produkte verkaufen willst, ist eine gehostete Plattform meist sicherer und deutlich weniger Arbeit. Ein Eigenbau lohnt sich, wenn du einen Ablauf, ein Design oder eine Kostenstruktur brauchst, die die Plattform nicht bietet.

**Darf ich Kartendaten in meiner eigenen Datenbank speichern?** Das solltest du nicht. Kartendaten sollten in einem Formular oder auf einer Seite deines Zahlungsanbieters eingegeben werden und nie deinen Server berühren; so bleibt der größte Teil der PCI-DSS-Last beim Anbieter.

**Woher weiß ich, dass eine Zahlung wirklich durchgegangen ist?** Vertraue nicht darauf, dass der Kunde auf deiner „Erfolgs“-Seite landet; vertraue dem signierten Webhook, den dein Zahlungsanbieter an deinen Server schickt. Markiere eine Bestellung erst als bezahlt, nachdem du die Signatur dieses Webhooks geprüft hast.

**Welche Rechtstexte braucht ein Online-Shop?** Mindestens eine Datenschutzerklärung, Verkaufsbedingungen, eine Erstattungs- und Rückgaberegelung und meist einen Cookie-Hinweis, dazu klare Kontaktdaten des Verkäufers. Die Anforderungen unterscheiden sich je nach Land; lass sie gern von der KI entwerfen, aber von einer qualifizierten Person prüfen.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/