Online-Shop mit KI bauen: Zahlungen und Sicherheit

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.

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.

1. Stack und Einrichtung

Für ein 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.

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:

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.

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:

// 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:

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:

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:

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, DROPs oder massenhafte UPDATEs 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.
• 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:

• 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, alle in einem Workspace.
• Datenbank-Manager. Sieh dir Tabellen, Bestellungen und Bestand, die der Agent angelegt hat, im Datenbank-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 zeigt Risiken wie ein DROP oder ein UPDATE ohne WHERE gleich vorab.
• Code-Review und Previews. Endet ein Turn, lässt das Code-Review ein zweites Modell darüberschauen; Preview-Umgebungen 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.