Engineering a Multi-Sided Marketplace and Partner Operations Platform

Scape brings together a browsable customer marketplace, an account-free booking path, a role-guarded partner portal and an administration console. These are complementary views of the same business state, not separate products joined after the fact.

Customers can move from category and date filtering to an experience page, session availability, a bounded seat hold and provider-hosted checkout without establishing a conventional account. Partners receive the operational visibility needed to run their offerings. Platform operators retain the authority required for financial decisions, exceptions and compliance work.

A multi-sided platform must make different responsibilities work together without giving every role the same control. Customer trust has to work without a standing account. Capacity must withstand competing hold requests. Payment collection cannot be confused with value earned through fulfilment. And different business models create different invoicing obligations.

The engineering task was therefore not a set of pages. It was a transaction model that could project consistent information into customer, partner and administrative workflows while preserving the decisions that belong with the platform.

The customer marketplace, partner operations portal and Scape administration console sit above a shared transactional core. That core manages holds, booking state, fulfilment, refund and compliance services. Financial evidence is the foundation beneath it: recorded financial facts, immutable booking context and fulfilment evidence support the operational views above without becoming a fourth silo.

Scape uses a nine-state booking machine with guarded transitions, so a booking moves through defined operational states rather than informal status changes. Row-locked capacity holds prevent competing requests from taking the same seat allocation. Effects are idempotent across booking, hold, refund, ledger, payout and notification work, while money is represented as integer HUF with consistent totals.

Provider callbacks are re-verified server-side. Confirmation and durable outbox enqueue occur in the same transaction: the booking is never hostage to an email.

The main path keeps customer activity legible while the core records the states that matter operationally. Cancellation, refund and rescheduling sit on a governed exception branch. An administrator-approved refund exception executes automatically after approval. The T-72 rule is a confirmation window and administrative routing rule, not a refund entitlement. Administrative rescheduling exists in the engine today; a customer-facing reschedule-first model remains designed work.

The partner portal is an operating-console foundation, not an assertion that every partner task is self-service. Role-guarded users can see dashboard economics computed from their own bookings: GMV, a 15% commission parameter and net value, upcoming sessions and history. They can inspect attendee-level bookings, confirm holds, report non-occurrence for the administration approval chain, maintain offering details and review per-offering take-up.

The money view is equally deliberate: partners can inspect gross, commission and net in a running ledger, export their data to CSV, and review payout, commission-invoice, refund and booking invoice-compliance history. They also receive a public brand-page presence.

Partners do not decide refunds. That action was intentionally removed so transparency remains with the partner while money-deciding authority remains with Scape. Designed beyond today: self-onboarding, publishing, session creation and editing, availability tools, attendance export and persistent branding.

Collection is automated through the verified sandbox payment path. Earning recognition begins only with fulfilment. The core records append-only financial evidence, immutable booking-context snapshots, exactly-once fulfilment evidence and the resulting eight-day invoice obligation. Refund evidence records the reversal semantics of an approved exception.

Monthly settlement is designed as the next cycle, not presented as an automated payout or invoicing system. The distinction protects an essential business truth: receiving a payment is not the same as recognizing earned value.

Scape administration is the counterpart to partner visibility: two consoles, one core, separated authority. The 41-endpoint administrative surface supports financial booking reporting and CSV export, payout approval as mark-paid bookkeeping with a bank reference, refund override and post-approval execution, and cancellation-report approval or rejection.

Administrators also validate, deliver or waive invoice-compliance records; operate a VAT monitoring view, acknowledging its derivation caveat; curate editorial content; and use supervisory read views across bookings, ledger and invoice work. The payout model records an offline bank transfer decision; it does not claim banking automation.

Barion — Sandbox: Hungarian payment-provider integration for hosted collection, HMAC-signed callbacks and refund calls; the path is sandbox-verified.

Billingo — Bounded: Commission-invoice adapter with retry and correction handling. Scape-Direct invoicing is designed rather than delivered.

Resend via durable outbox — Bounded: Transactional email uses a provider-neutral pipeline with retry and dead-letter semantics.

WordPress — Bounded: A headless content plane supplies blog and legal-content surfaces with fallback handling.

Selected interface captures show the customer booking path, partner booking visibility, ledger transparency and administration-side compliance work. Each capture is framed as a local demo-data surface, redacted before publication, and used only where it substantiates a defined platform capability. If a capture does not retain that clarity, the surface inventory remains the appropriate evidence.

Scape was developed through SALVOC’s governed AI engineering approach: architecture, implementation, independent technical review, deterministic validation and human authority were kept separate. The method is documented in the Governed AI Engineering case study; here, the focus remains the multi-sided business platform it made possible.

Scape is presented in a governed local-development and sandbox posture, using seeded demonstration data; these statuses describe system capability, not commercial operation or business outcomes.

The delivered, designed and roadmap rows below distinguish established capability from the next operational increments without inflating either.