Ein AI Marketplace ist kein Onlineshop mit einem zusätzlichen Chatbot. Er verbindet Käufer, mehrere Anbieter, Produkte oder Services, Zahlungen, Auszahlungen, Fulfillment und den Betreiber. Dazu kommen Website, Mobile App, Desktop-App, Suche, Empfehlungen und Administration. Wenn diese Teile ohne gemeinsames Zustandsmodell gebaut werden, entstehen schnell doppelte Bestellungen, unklare Gebühren und nicht nachvollziehbare Lieferprobleme.
Die wichtigste Architekturarbeit passiert deshalb vor der Oberfläche: Wer verkauft? Wer nimmt die Zahlung an? Wer erhält welche Auszahlung? Wer besitzt den Kundenkontakt? Und welcher Zustand ist führend, wenn Payment, Händlerportal und Fulfillment unterschiedliche Informationen melden?
Betreiber-Software und Marketplace-Geschäft unterscheiden
TEX8 kann die Software für einen Marketplace entwickeln und betreuen. Der Auftraggeber bleibt jedoch Betreiber seines Geschäftsmodells und schließt eigene Verträge mit Händlern, Zahlungsanbietern, Hosting- und Fulfillment-Partnern. Diese Trennung ist wichtig, weil Technik allein weder Merchant-of-Record-Fragen noch Steuern, KYC, Verbraucherrechte oder Produktverantwortung entscheidet.
| Ebene | Typische Verantwortung | Technische Abbildung |
|---|---|---|
| Marketplace-Betreiber | Geschäftsmodell, Händlerverträge, Provisionen, Support und Regeln | Rollen, Konfiguration, Freigaben, Abrechnung und Audit |
| Zahlungsanbieter | Payment-Verarbeitung nach Vertrag und Provider-Modell | Connected Accounts, Zahlungsreferenzen, Webhooks und Auszahlungsstatus |
| Anbieter | Produkte, Preise, Bestand, Leistung und je nach Modell Versand | Seller-Portal, Katalog, Bestellungen und Fulfillment-Übergabe |
| Fulfillment-Partner | Lager, Pick-and-Pack, Versand und Statusereignisse | Auftragsvertrag, Bestand, Tracking, Retoure und Fehlerqueue |
| TEX8 | vereinbarte Softwareentwicklung und technischer Betrieb | Web, App, Desktop, Rust-Dienste, Integrationen, Tests und Monitoring |
Die vier Kernobjekte eines Multi-Seller-Marktplatzes
Ein robustes Modell trennt mindestens Warenkorb, Käuferbestellung, Verkäuferauftrag und Fulfillment-Auftrag. Eine Käuferbestellung kann Positionen von drei Händlern enthalten. Daraus entstehen drei Verkäuferaufträge und möglicherweise mehrere Sendungen. Rückerstattung, Provision und Auszahlung müssen deshalb bis auf Positionsebene nachvollziehbar bleiben.
- Warenkorb: noch veränderbarer Kaufwunsch mit Preis- und Verfügbarkeitsprüfung.
- Käuferbestellung: ein konsistenter Beleg für Nutzer, Zahlung und Gesamtstatus.
- Verkäuferauftrag: die für einen Händler relevanten Positionen, Gebühren und Pflichten.
- Fulfillment-Auftrag: konkrete Lager-, Versand- und Tracking-Aufgaben.
Diese Trennung verhindert, dass ein verspätetes Paket den Status aller anderen Positionen verfälscht oder eine Teilrückerstattung versehentlich die gesamte Bestellung storniert.
Payment zuerst als Geldfluss zeichnen
Stripe Connect ist für Plattformen und Marketplaces konzipiert und stellt Connected Accounts, Zahlungsrouting und Auszahlungsmodelle bereit. Je nach Modell werden Zahlungen direkt einem verbundenen Konto zugeordnet oder zunächst von der Plattform verarbeitet und später übertragen. Auch ein Revolut-Merchant-Modell kann je nach Land, Konto, Händlerstruktur und verfügbaren APIs geprüft werden.
Die Framework-Entscheidung ersetzt keine Providerentscheidung. Vor der Integration muss beantwortet werden:
- Wer erscheint gegenüber dem Käufer als Verkäufer?
- Wer trägt Zahlungs-, Rückerstattungs- und Streitfallkosten?
- Wann darf eine Auszahlung an den Anbieter erfolgen?
- Wie werden Marketplace-Provision, Steuer und Providergebühr dargestellt?
- Was passiert bei Teilstorno, Teillieferung oder negativem Saldo?
Providergebühren, Merchant-Kosten, Hosting und nutzungsabhängige Dienste bezahlt der Betreiber über seine eigenen Verträge. Sie werden nicht still von TEX8 übernommen.
Gespeicherte Karten ohne eigene Kartendatenbank
Nutzer können gespeicherte Zahlungsarten erhalten, wenn der Provider und das gewählte Modell dies unterstützen. Die sensiblen Kartennummern gehören jedoch nicht in die Marketplace-Datenbank. Der Zahlungsanbieter speichert sie in seinem dafür vorgesehenen System; der Marketplace hält nur Kunden- und Zahlungsmittelreferenzen, Anzeigeinformationen und die Zuordnung zum berechtigten Nutzer.
Jeder Abruf und jede Nutzung muss an die aktuelle Session, den richtigen Tenant und den richtigen Provider-Kunden gebunden sein. Logs dürfen keine geheimen Schlüssel, vollständigen Zahlungsdaten oder ungeschützte Provider-Antworten enthalten.
USDT und USDC sind eine zusätzliche Zahlungsstrecke
Stablecoins können für bestimmte Zielgruppen interessant sein. Sie ändern aber nichts daran, dass Bestellung, Rückerstattung, Kurszeitpunkt, Netzwerk, Wallet-Zuordnung, Buchhaltung und erlaubte Länder geklärt werden müssen. Eine Stablecoin-Integration sollte daher als eigener Provider-Flow mit bestätigten On-chain-Ereignissen, Idempotenz und manueller Klärung bei Abweichungen modelliert werden.
Fulfillment braucht bestätigte Ereignisse
Ein Marketplace darf eine Bestellung nicht als versendet anzeigen, nur weil die Übergabe an eine API versucht wurde. Erst eine bestätigte Annahme oder ein späteres Fulfillment-Ereignis ändert den operativen Zustand. Wiederholte Webhooks und Timeouts sind normal; jede Verarbeitung muss deshalb idempotent sein.
- stabile externe und interne Auftrags-IDs;
- Bestand und Reservierung pro Verkäufer, Produkt und Lager;
- Übergabe nur der erforderlichen Adress- und Positionsdaten;
- getrennte Zustände für angenommen, kommissioniert, versendet, zugestellt und retourniert;
- sichtbare Queue für fehlgeschlagene oder widersprüchliche Ereignisse;
- Push und E-Mail erst auf Basis bestätigter Zustandswechsel.
Web, React Native und Electron teilen Verträge
Die Website eignet sich für öffentliche Discovery und einen Einstieg ohne Installation. React Native liefert eine gemeinsame mobile Basis für iOS und Android mit Push, Kamera, biometrischer Freigabe oder Deep Links. Electron kann einen vollständigen Desktop-Workflow für Betreiber, Händler oder Power-User bereitstellen. Entscheidend ist, dass alle Oberflächen dieselben API-Verträge, Rollen und Auftragszustände nutzen.
Geschäftslogik wie Preise, Provisionen, Auszahlungsfreigaben oder Rechte gehört nicht dreifach in die Clients. Sie bleibt in Rust-Diensten und wird über versionierte Verträge bereitgestellt. Dadurch können Oberflächen separat weiterentwickelt werden, ohne den Geldfluss neu zu erfinden.
Wo KI echten Nutzen bringt
KI kann Discovery, Onboarding und Betrieb verbessern, sollte aber keine ungeprüften finanziellen Aktionen ausführen. Sinnvolle erste Funktionen sind semantische Produktsuche, strukturierte Erfassung von Verkäuferdaten, Support mit freigegebenem Wissen, Übersetzungsentwürfe und Hinweise auf unvollständige Katalogdaten.
Empfehlungen müssen nachvollziehbare Geschäftsgrenzen beachten: Verfügbarkeit, Region, Preis, Verkäuferstatus und Zugriffsrechte gelten vor dem semantischen Ranking. Ein KI-Assistent erhält nur die Aktionen, die die Rolle des Nutzers erlaubt.
Stufenplan für einen kontrollierten Launch
- Modell: Rollen, Geldfluss, Provisionslogik und Fulfillment-Verantwortung dokumentieren.
- Pilot: eine Kategorie, wenige verifizierte Anbieter und ein Zahlungsmodell.
- Operations: Rückerstattung, Support, Bestand, Versand und Klärungsqueues schließen.
- Mobile und Desktop: Oberflächen auf den stabilen Marketplace-Verträgen ergänzen.
- KI und Skalierung: Suche, Empfehlungen und Automatisierung anhand realer Anfragen ausbauen.
Nächster Schritt
Die Seite zur AI-Marketplace-Entwicklung beschreibt den vollständigen Leistungsumfang von Web, React Native, Electron, Payment, Fulfillment und Betreiber-Backend. Die Marketplace-Fallstudie zeigt die Module an einem konkreten System. Für Discovery und KI-Agenten ist zusätzlich die semantische Suche relevant.