Engineering einer mehrseitigen Marktplatz- und Partnerbetriebsplattform

Scape verbindet einen Kundenmarktplatz zum Durchstöbern, einen Buchungspfad ohne Konto, ein rollenabgesichertes Partnerportal und eine Administrationskonsole. Es sind ergänzende Ansichten desselben Geschäftszustands, keine nachträglich zusammengefügten Produkte.

Kundinnen und Kunden wechseln von Kategorie- und Datumsfiltern zu einer Erlebnisdetailseite, der Verfügbarkeit von Terminen, einem begrenzten Sitzplatz-Hold und einem vom Anbieter gehosteten Checkout, ohne ein herkömmliches Konto anzulegen. Partner erhalten die betriebliche Transparenz, die sie für ihre Angebote brauchen. Plattformverantwortliche behalten die Autorität, die für Finanzentscheide, Ausnahmen und Compliance-Arbeit erforderlich ist.

Eine mehrseitige Plattform muss unterschiedliche Verantwortlichkeiten zusammenführen, ohne jeder Rolle dieselbe Kontrolle zu geben. Kundenvertrauen muss ohne dauerhaftes Konto funktionieren. Kapazität muss konkurrierenden Hold-Anfragen standhalten. Zahlungseingang darf nicht mit dem durch Erfüllung verdienten Wert verwechselt werden. Und unterschiedliche Geschäftsmodelle erzeugen unterschiedliche Rechnungspflichten.

Die Engineering-Aufgabe war daher nicht eine Sammlung von Seiten. Es war ein Transaktionsmodell, das konsistente Informationen in Kunden-, Partner- und Administrationsabläufe projizieren kann und dabei die Entscheide bei der Plattform belässt, zu der sie gehören.

Kundenmarktplatz, Partnerbetriebsportal und Scape-Administrationskonsole liegen über einem gemeinsamen transaktionalen Kern. Dieser Kern verwaltet Holds, Buchungsstatus, Erfüllung, Rückerstattung und Compliance-Dienste. Die finanzielle Nachweisbasis liegt darunter: erfasste finanzielle Tatsachen, unveränderliche Buchungskontexte und Erfüllungsnachweise stützen die betrieblichen Ansichten, ohne zu einem vierten Silo zu werden.

Scape nutzt eine Buchungsmaschine mit neun Zuständen und abgesicherten Übergängen. So durchläuft eine Buchung definierte betriebliche Zustände statt informeller Statusänderungen. Zeilengesperrte Kapazitäts-Holds verhindern, dass konkurrierende Anfragen dieselbe Sitzplatzzuordnung beanspruchen. Effekte sind über Buchung, Hold, Rückerstattung, Ledger, Zahlungsausgang und Benachrichtigung hinweg idempotent, während Geld als ganzzahlige HUF-Beträge mit konsistenten Summen abgebildet wird.

Anbieter-Callbacks werden serverseitig erneut geprüft. Bestätigung und das dauerhafte Einreihen in die Outbox erfolgen in derselben Transaktion: Die Buchung ist nie von einer E-Mail abhängig.

Der Hauptpfad hält Kundenaktivität nachvollziehbar, während der Kern die betrieblich relevanten Zustände erfasst. Stornierung, Rückerstattung und Umbuchung liegen auf einem gesteuerten Ausnahmepfad. Eine von der Administration genehmigte Rückerstattungsausnahme wird nach der Genehmigung automatisch ausgeführt. Die T-72-Regel ist ein Bestätigungsfenster und eine administrative Routing-Regel, kein Anspruch auf Rückerstattung. Administrative Umbuchungen sind heute in der Engine vorhanden; ein kundenorientiertes Reschedule-first-Modell bleibt konzipierte Arbeit.

Das Partnerportal ist die Grundlage einer Betriebskonsole, nicht die Behauptung, jede Partneraufgabe sei im Selbstservice verfügbar. Rollenabgesicherte Benutzerinnen und Benutzer sehen aus ihren eigenen Buchungen berechnete Dashboard-Kennzahlen: GMV, einen Provisionsparameter von 15 % und Nettowert, kommende Termine und Historie. Sie können Buchungen auf Teilnehmendenebene einsehen, Holds bestätigen, die Nichtdurchführung für die administrative Genehmigungskette melden, Angebotsdetails pflegen und die Inanspruchnahme je Angebot prüfen.

Auch die Geldansicht ist bewusst gestaltet: Partner können Brutto, Provision und Netto in einem fortlaufenden Ledger einsehen, ihre Daten als CSV exportieren und die Historie von Zahlungsausgängen, Provisionsrechnungen, Rückerstattungen und Buchungs-Compliance prüfen. Zudem erhalten sie eine öffentliche Präsenz über eine Markenseite.

Partner entscheiden nicht über Rückerstattungen. Diese Aktion wurde bewusst entfernt, damit Transparenz beim Partner bleibt, während die Entscheidungsautorität über Geld bei Scape liegt. Über den heutigen Stand hinaus konzipiert sind Selbst-Onboarding, Publikation, Erstellung und Bearbeitung von Terminen, Verfügbarkeitstools, Teilnehmendenexport und persistente Markenführung.

Der Zahlungseinzug ist über den verifizierten Sandbox-Zahlungspfad automatisiert. Die Ertragsrealisierung beginnt erst mit der Erfüllung. Der Kern erfasst append-only finanzielle Nachweise, unveränderliche Momentaufnahmen des Buchungskontexts, genau-einmalige Erfüllungsnachweise und die daraus folgende Rechnungspflicht innerhalb von acht Tagen. Rückerstattungsnachweise erfassen die Umkehrsemantik einer genehmigten Ausnahme.

Die monatliche Abrechnung ist als nächster Zyklus konzipiert und wird nicht als automatisiertes System für Zahlungsausgänge oder Rechnungsstellung dargestellt. Diese Trennung schützt eine zentrale Geschäftswahrheit: Eine Zahlung zu erhalten ist nicht dasselbe wie verdienten Wert zu realisieren.

Die Scape-Administration ist das Gegenstück zur Partnertransparenz: zwei Konsolen, ein Kern, getrennte Autorität. Die administrative Oberfläche mit 41 Endpunkten unterstützt Finanzbuchungsberichte und CSV-Export, die Genehmigung von Zahlungsausgängen als «als bezahlt markieren»-Buchhaltung mit Bankreferenz, Rückerstattungs-Overrides und die Ausführung nach Genehmigung sowie die Genehmigung oder Ablehnung von Meldungen zur Nichtdurchführung.

Administratoren validieren, übermitteln oder erlassen zudem Rechnungskonformitätsdatensätze; sie nutzen eine Umsatzsteuer-Monitoringansicht unter Anerkennung ihres Herleitungsvorbehalts, kuratieren redaktionelle Inhalte und verwenden übergreifende Leseansichten für Buchungen, Ledger und Rechnungsarbeit. Das Modell für Zahlungsausgänge erfasst einen Entscheid über eine Offline-Banküberweisung; es beansprucht keine Bankenautomatisierung.

Barion — Sandbox: Ungarische Zahlungsanbieterintegration für gehosteten Zahlungseinzug, HMAC-signierte Callbacks und Rückerstattungsaufrufe; der Pfad ist in der Sandbox verifiziert.

Billingo — Begrenzt: Adapter für Provisionsrechnungen mit Wiederholungs- und Korrekturbehandlung. Die Rechnungsstellung von Scape-Direct ist konzipiert, nicht bereitgestellt.

Resend via dauerhafte Outbox — Begrenzt: Transaktionale E-Mails nutzen eine anbieterneutrale Pipeline mit Wiederholungs- und Dead-Letter-Semantik.

WordPress — Begrenzt: Eine Headless-Inhaltsebene versorgt Blog- und Rechtsinhaltsoberflächen mit Fallback-Behandlung.

Ausgewählte Interface-Aufnahmen zeigen den Kundenbuchungspfad, die Buchungstransparenz für Partner, Ledger-Transparenz und Compliance-Arbeit auf Administrationsseite. Jede Aufnahme ist als lokale Oberfläche mit Demo-Daten gerahmt, vor der Publikation redigiert und nur dort eingesetzt, wo sie eine definierte Plattformfähigkeit belegt. Falls eine Aufnahme diese Klarheit nicht wahrt, bleibt das Oberflächeninventar der angemessene Nachweis.

Scape wurde mit SALVOCs gesteuertem Ansatz für KI-Engineering entwickelt: Architektur, Implementierung, unabhängige technische Prüfung, deterministische Validierung und menschliche Autorität blieben getrennt. Die Methode ist in der Case Study Governed AI Engineering dokumentiert; hier bleibt der Fokus auf der mehrseitigen Geschäftsplattform, die sie ermöglicht hat.

Scape wird in einer gesteuerten Local-Development- und Sandbox-Posture mit bereitgestellten Demonstrationsdaten dargestellt; diese Status beschreiben Systemfähigkeiten, nicht kommerziellen Betrieb oder Geschäftsergebnisse.

Die folgenden Zeilen für Geliefert, Entworfen und Roadmap unterscheiden etablierte Fähigkeiten von den nächsten betrieblichen Schritten, ohne einen der beiden Zustände aufzublähen.