Multi-Vendor-Marktplatz mit Medusa und Mercur aufbauen

Ein Marktplatz ist kein großer Shop, und genau dieser Unterschied fehlt in den meisten Anleitungen. Ein Shop verkauft einen Katalog; ein Marktplatz koordiniert viele unabhängige Verkäufer über einen Checkout – mit Händlerkonten, aufgeteilten Bestellungen, Provisionsrechnung und Auszahlungen, bevor die erste Kundin überhaupt etwas Besonderes bemerkt.

Dieser Leitfaden geht den Weg auf der Open-Source-Marktplatz-Software, die ich selbst produktiv betreibe: Medusa als Commerce-Kern, Mercur als Marktplatz-Schicht darüber. Mein eigener Marktplatz bedient 10.000 Produkte von 50 Händlern auf dieser Architektur – der Abschnitt über die unterschätzten Punkte am Ende stammt also aus dem Betrieb, nicht aus der Lektüre. Alle Befehle und Editions-Angaben habe ich am 27. August 2026 mit den offiziellen Quellen abgeglichen.

Welche vier Entscheidungen kommen vor der Installation?

Die Installation dauert Minuten; ein falsch gewähltes Marktplatz-Modell zurückzubauen dauert Monate. Vier Entscheidungen prägen alles Weitere:

Schreiben Sie die vier Antworten auf, bevor Sie ein Terminal öffnen. Jeder folgende Abschnitt setzt sie voraus.

Was macht Mercur zur Marktplatz-Software auf Medusa?

Mercur ist eine MIT-lizenzierte Marktplatz-Plattform auf dem Commerce-Kern von Medusa: Katalog, Bestellungen, Zahlungen, Versand, Steuern und Bestand kommen von Medusa; Händlerkonten, Verkäufer-Panel, Multi-Vendor-Checkout mit Auftragssplitting, Provisionen und Auszahlungen von Mercur. Aus einer Codebasis entstehen drei Oberflächen: Storefront, Händler-Panel und Admin-Konsole.

Die ehrliche Editions-Landkarte gehört an den Anfang, damit Sie nicht mit Funktionen planen, die Sie nicht haben werden. Laut Editions-Seite, geprüft am 27. August 2026:

Alles, was ein erster Marktplatz-Launch braucht, steht in der MIT-Spalte. Die Enterprise-Spalte ist Finanz-Operations-Tiefe und wird relevant, sobald nennenswerte Summen durch viele Verkäufer fließen. Die Reifegrad-Abwägungen habe ich in meiner unabhängigen Mercur-Review (EN) ausführlich dokumentiert; dieser Leitfaden setzt voraus, dass Sie bauen wollen.

Wie setzen Sie die Entwicklungsumgebung auf?

Voraussetzungen laut offizieller Doku: Node.js v20+ (LTS), Bun v1.3+ als empfohlener Paketmanager, Git und PostgreSQL v14+. Keine lokale PostgreSQL-Instanz? Die Doku liefert einen Docker-Einzeiler mit postgres:16.

Danach ist es ein Befehl:

bun create mercur-app@latest

Die CLI fragt Projektnamen und Template ab (basic oder plugin), legt die Datenbank an, führt Migrationen aus, spielt Demodaten ein und startet den Dev-Server. Für Automatisierung gibt es die Flags --template, --db-connection-string, --no-deps und --skip-db. Danach laufen drei Oberflächen auf einem Port:

• API: http://localhost:9000
• Admin-Konsole: http://localhost:9000/dashboard
• Händler-Panel: http://localhost:9000/seller

Neu gestartet wird mit bun dev. Bei mir stand die Umgebung in Minuten – und weil Mercur die Betriebsform von Medusa erbt, gilt alles über Produktion (Worker-Prozesse, Redis, S3-kompatibler Storage) unverändert weiter. Ich betreibe den Stack auf Railway: Einzelne Services bauen in zwei bis drei Minuten und deployen parallel; über das Railway MCP lässt sich die Infrastruktur direkt aus dem AI-Coding-Workflow verwalten.

Wie gestalten Sie das Händler-Onboarding?

Beim Onboarding trifft Marktplatz-Theorie auf menschliche Realität. Mercur liefert die Mechanik: Registrierung, Konten, Teams, Verkäufer-Panel. Was es nicht liefern kann, ist Ihre Policy, und die ist eine Produktentscheidung:

1. Bewerbung: offene Registrierung oder auf Einladung? Mein Marktplatz startete auf Einladung; fünfzig Händler später halte ich das weiter für richtig – ob das Modell bei zweihundert noch trägt, weiß ich schlicht nicht.
2. Prüfung: Wer gibt einen Händler frei, nach welcher Checkliste? In regulierten Branchen gehört hier Ihr eigener Verifizierungsschritt hin (nochmals: kein dokumentiertes KYC-Feature in beiden Editionen – Compliance ist Ihr Bauteil).
3. Erstes Listing: der entscheidende Moment. Sehen Sie vor dem Launch einer echten, nicht-technischen Verkäuferin dabei zu, wie sie im Händler-Panel ihr erstes Produkt anlegt. Wo sie hängen bleibt, entstehen Ihre künftigen Support-Tickets.
4. Aktivierung: Wann geht ein Händler live – erstes Produkt, erster Bestand, unterschriebene AGB? Bilden Sie das als expliziten Status ab; Gewohnheitsregeln vergisst der zweite Admin.

Ein Praxistest, der einen Nachmittag kostet und Wochen spart: Schicken Sie zwei Pilot-Händler durch den kompletten Ablauf – von der Registrierung bis zur ersten Auszahlung – bevor der dritte Händler an den Start geht.

Wie verdrahten Sie Provisionen und Auszahlungen?

Die Open-Source-Edition berechnet Provisionen, teilt Zahlungen auf und führt Auszahlungen und Erstattungen aus. Die Designarbeit liegt in einem Modell, dessen Ergebnis Ihre Händler selbst nachrechnen können: Ein Prozentsatz je Kategorie ist transparent; individuell verhandelte Sätze sind flexibel, machen aber jede Auszahlungsfrage zum Support-Gespräch.

Zwei Grenzen verdienen Respekt. Erstens die Editions-Linie: Erwartet Ihre Buchhaltung ein abstimmungsfähiges Hauptbuch und formale Auszahlungszyklen, ist das Enterprise-Terrain – entscheiden Sie das vor dem Launch, nicht beim ersten Audit. Zweitens die Regeln des Zahlungsanbieters: Split-Payments laufen über die Marktplatz-Funktionen Ihres PSP, und das Onboarding der Händler beim PSP (Konten, Verifizierung) ist ein eigener Workflow parallel zu Ihrem.

Testen Sie dann die hässlichen Pfade, denn Auszahlungsfehler kosten Vertrauen, das keine Gutschrift zurückholt: eine Teilerstattung über zwei Händler in einer Bestellung, eine Provisionsänderung mitten im Monat, ein ausscheidender Händler mit offenem Guthaben. Grüne Häkchen auf dem Happy Path bedeuten hier wenig.

Was unterschätzen Marktplatz-Betreiber am meisten?

Alles oben ist Infrastruktur-Arbeit; diese drei Punkte sind das Produkt, und jeder davon hat mich im Betrieb überrascht:

Moderation ist Tagesgeschäft, kein Feature. Fünfzig Händler bedeuten fünfzig Meinungen über Produktdatenqualität. Doppelte Listings, kreative Kategorisierung, Bildstandards: Die Plattform liefert Werkzeuge, aber den Standard verantwortet jemand. Budgetieren Sie wiederkehrende Stunden, keine einmalige Einrichtung.

Streitfälle haben drei Parteien. Im Shop ist eine Retoure eine Sache zwischen Ihnen und der Kundschaft. Im Marktplatz sitzen Sie, die Kundin und ein Händler mit eigener Marge am Tisch, und Ihre Plattform ist der Schiedsrichter. Schreiben Sie das Regelwerk vor dem ersten Streitfall; während des ersten geschrieben, überzeugt es niemanden.

Händler-Churn ist Ihre echte Wachstumsmetrik. Händler gewinnen ist Marketing; Händler am Verkaufen halten ist Operations. Die Dashboards, die sich früh lohnen, sind händlerbezogen: Zeit bis zum ersten Verkauf, Listing-Aktivität, Auszahlungszuverlässigkeit. Ein Marktplatz mit stillen Händlern ist ein Shop mit Umwegen.

Was kostet das – und wie geht es weiter?

Die Plattform ist der günstige Teil: MIT-Lizenz, und meine Produktionsinfrastruktur für diesen Stack kostet auf Railway 40–60 US-Dollar im Monat, die Bilder in Cloudflare R2 unter einem Dollar. Das echte Budget sind Entwicklung und die Betriebsarbeit oben – Zahlen dazu über drei GMV-Größenordnungen liefert mein Marktplatz-Plattformvergleich (EN), und der komplette Praxisbericht meines eigenen Aufbaus (Timeline, Migration von WordPress, die Fallen) erscheint als Nächstes hier im Blog.

Der kürzeste Weg zu einer belastbaren Entscheidung: ein zweiwöchiger Proof-of-Concept Sprint mit Ihrem echten Händler-Modell – Provisionsrechnung, ein voller Auszahlungszyklus, zwei Pilot-Händler. Das beantwortet mehr als jeder Artikel. Alle Marktplatz- und Commerce-Artikel sammelt der Themenbereich E-Commerce; zum Einstieg in die technische Basis lohnt auch der Vergleich Medusa vs. Shopware.