Der Zwang des Makers.
Handgefertigte Waren aus der Ukraine, Versand in sieben Länder. Die finanzielle und logistische Infrastruktur, auf der dieser Markt läuft — Monobank für Zahlungen, Nova Post für Fulfilment, die täglichen FX-Kurse der Nationalbank der Ukraine für die Preisgestaltung — hat kein Gegenstück in einem generischen europäischen E-Commerce-Stack.
Allein das Zahlungsmodell schließt Stripe aus. Das Anzahlungsmodell von Monobank erhebt eine Anzahlung bei Bestellbestätigung und löst die Restzahlung aus, sobald die Bestellung den Status „versandbereit“ erreicht. Das sind zwei Zahlungsabschnitte, getaktet nach dem Produktionsstatus, mit ECDSA-Webhook-Signaturen bei jedem Übergang. Stripe hat dafür kein Primitive. Man müsste es mit zwei voneinander unabhängigen Buchungen vortäuschen und den Status selbst abgleichen — und jede Abgleichslücke ist eine Betrugsfläche.
Das Logistikmodell schließt Shippo aus. Nova Post, der dominierende Zusteller der Ukraine, stellt ein Verzeichnis von Städten, Filialen und Klassifikatoren bereit, das lokal synchronisiert und abgefragt werden muss. Frachtbriefe werden zum Versandzeitpunkt programmatisch erzeugt, und das resultierende Label-PDF muss an einem abrufbaren Ort liegen. Nichts in der Welt der generischen Zusteller-Abstraktionen lässt sich darauf sauber abbilden.
Das Preismodell schließt regionsbasierte Währungseinstellungen aus. Der Maker verkauft einige Produkte global in EUR, andere nur in UAH, weil die Lieferkette lokal ist. Einige wenige Produkte tragen explizite UAH- oder USD-Überschreibungen, die vom FX-konvertierten Basispreis abweichen. Regelwerke pro Region können nicht ausdrücken: „Dieses spezifische Produkt hat seinen eigenen UAH-Preis, unabhängig vom Sprachraum des Käufers.“ Überschreibungen pro Produkt können das.
Ein Setup aus Stripe + Shippo + WooCommerce kann „Anzahlung jetzt in UAH, Restzahlung bei Versandbereitschaft in EUR, Fulfilment durch Nova Post“ nicht abbilden, ohne an jeder Naht eigenen Code zu erfordern. Der Eigenbau war keine Vorliebe — er war eine Anforderung des Markts.
Was wir gebaut haben.
Eine Plattform: ein kundenorientierter Storefront in 7 Sprachen, ein Produktionslebenszyklus (Entwurf → in Arbeit → fertig → versendet) und ein Ops-Dashboard, das die Gründerin allein betreibt.
Die Zahlungsschicht wickelt den vollständigen Anzahlungs-Workflow von Monobank ab. Anzahlung erhoben bei Bestellbestätigung. Restzahlung ausgelöst, wenn der Bestellstatus auf „versandbereit“ wechselt. Jeder Webhook wird gegen einen zwischengespeicherten öffentlichen Monobank-PEM-Schlüssel mittels ECDSA SHA256 mit Rotation verifiziert. Zahlungsabschnitte sind Datensätze in der Datenbank, verknüpft mit dem Bestellstatus — nicht nachträglich abgeglichen.
Die Preisschicht liest Währungsüberschreibungen pro Produkt, bevor sie auf den FX-konvertierten Basispreis zurückfällt. Jede Produktzeile hat einen EUR-Basispreis und optionale UAH- und USD-Überschreibungsspalten. Liegt eine Überschreibung vor, verwendet der Storefront sie. Fehlt sie, konvertiert der tägliche FX-Kurs der Nationalbank der Ukraine den EUR-Basispreis. Der NBU-Kurs wird täglich per Cron synchronisiert.
Die Logistikschicht läuft auf einem synchronisierten Nova-Post-Verzeichnis. Städte, Filialen und Klassifikatoren werden paginiert aus der Nova-Post-API eingelesen und lokal gespeichert — die Adressauswahl im Checkout fragt die lokale Kopie ab, nicht die Live-API. Zum Versandzeitpunkt erzeugt die Plattform über die Nova-Post-API einen Frachtbrief und speichert das resultierende Label-PDF als vorsigniertes Objekt in Cloudflare R2.
Der Produktionslebenszyklus ist das Gerüst, das die Zahlungsabschnitte und den Versand zusammenhält. Die Zustandsmaschine der Bestellung — fünf Zustände, ein Ereignisprotokoll, eine Fortschrittsfoto-Leiste — existiert, damit der Übergang von Anzahlung zu Restzahlung einen definierten Auslöser und die Frachtbrieferzeugung einen definierten Moment hat. Die Zustandsmaschine ist nicht das Produkt. Sie ist der tragende Rahmen für die finanziellen und logistischen Abläufe.
- F · 01Monobank-Anzahlung
- Anzahlung erhoben bei Bestellbestätigung; Restzahlung feuert bei „versandbereit“. Zahlungsabschnitte sind Datenbankdatensätze, verknüpft mit dem Bestellstatus. ECDSA-SHA256-Webhook-Verifizierung mit PEM-Schlüsselrotation.
- F · 02Mehrwährung pro Produkt
- EUR-Basispreis mit optionalen UAH- und USD-Überschreibungsspalten pro Produkt. Der Preis-Resolver liest die Überschreibung, bevor er auf den täglichen NBU-FX-Kurs zurückfällt. Steuerung auf Maker-Ebene, nicht auf Regionsebene.
- F · 03Nova-Post-Integration
- Verzeichnis von Städten und Filialen lokal über geplanten Job synchronisiert. Frachtbriefe zum Versandzeitpunkt über die Nova-Post-API erzeugt. Label-PDFs als vorsignierte Objekte in Cloudflare R2 gespeichert.
- F · 04Produktionslebenszyklus
- Fünf-Zustands-Bestellmaschine (Entwurf → in Arbeit → fertig → versendet → storniert) mit Ereignisprotokoll und Fortschrittsfoto-Leiste. Gerüst für die Zahlungsabschnitte und die Frachtbrieferzeugung — nicht das zentrale Objekt.
- F · 05Storefront in 7 Sprachen
- Kundenorientierter Store in sieben Sprachen. Währungsüberschreibungen pro Produkt und NBU-FX-Fallback bedeuten, dass jeder Sprachraum kontextuell korrekte Preise sieht — ohne Konfiguration pro Region.
- F · 06Zweckgebautes Ops-Dashboard
- Produktions-Kanban, 30-Tage-EUR-Umsatz-Sparkline, Integrations-Health-Pills (Monobank / Nova Post / R2 / E-Mail), Cron-Aktualitätsanzeige und ein Aufmerksamkeitsband. Ein Bildschirm für den gesamten Betrieb.
Die Fintech-Engineering-Entscheidungen.
ECDSA-Webhook-Verifizierung. Monobank signiert Zahlungs-Webhooks mit einem privaten Schlüssel; der Empfänger muss gegen einen zwischengespeicherten öffentlichen Schlüssel verifizieren, den Cache rotieren, sobald Monobank einen neuen veröffentlicht, und jeden Webhook ablehnen, der die Signaturprüfung nicht besteht. Eine Spielzeug-Authentifizierung wäre ein geprüfter Header-Wert. Echte Authentifizierung ist ECDSA SHA256 gegen einen PEM-Schlüssel mit Rotation.
Zahlungsabschnitte auf der Datenebene. Das Anzahlungsmodell ist keine Konfiguration eines Zahlungs-Gateways. Es ist ein Datenmodell: Eine Bestellung hat einen oder mehrere Zahlungsabschnitte, jeder mit einem Betrag, einer Währung, einem Status und einem Auslöser. Der Anzahlungsabschnitt feuert bei Bestellbestätigung. Der Restzahlungsabschnitt feuert beim Statusübergang. Das Ereignisprotokoll trägt den Audit-Trail. Zwei voneinander unabhängige API-Buchungen im Nachhinein abzugleichen würde bedeuten, dass die Quelle der Wahrheit das Dashboard von Monobank ist, nicht die eigene Datenbank. Diesen Kompromiss haben wir abgelehnt.
Währungsüberschreibungen pro Produkt. Die Preistabelle hat über den EUR-Basispreis hinaus drei optionale Preisspalten: UAH, USD und ein „Preis auf Anfrage“-Flag. Der Preis-Resolver liest sie in Prioritätsreihenfolge: explizite Überschreibung → FX-konvertierter Basispreis → Anfrage. Der Maker steuert die Preise auf Produktebene, nicht auf Regionsebene.
Die Spezifik des lokalen Markts ist der Burggraben. Ein Wettbewerber kann das Storefront-Design kopieren. Er kann nicht dasselbe Zahlungsmodell betreiben, ohne die Zahlungsschicht für die spezifische API von Monobank neu zu schreiben.
Nova-Post-Verzeichnissynchronisation. Die Live-API von Nova Post bei jeder Adresseingabe im Checkout aufzurufen würde den Kaufablauf an eine externe Abhängigkeit koppeln, für die die Plattform kein SLA kontrolliert. Die Verzeichnissynchronisation läuft als geplanter Job: Seiten von Städten, Filialen und Klassifikatoren werden lokal geschrieben, der Checkout fragt die lokale Kopie ab. Der einzige Live-Aufruf von Nova Post im kritischen Kaufpfad ist die Frachtbrieferzeugung zum Versandzeitpunkt — und die erfolgt, nachdem die Bestellung bereits bezahlt ist.
Das Ergebnis.
Die Gründerin betreibt den gesamten Betrieb von einem Bildschirm aus. Produktions-Kanban nach Bestellstatus, eine 30-Tage-Umsatz-Sparkline in EUR, Integrations-Health-Pills für Monobank, Nova Post, R2 und E-Mail, eine Cron-Aktualitätsanzeige und ein Aufmerksamkeitsband, das alles hervorhebt, was eine Aktion erfordert. Rund 1–2K Zeilen Dashboard-Komponente — zweckgebaut, nicht generisch.
145 Commits in 3 Wochen. 659 Testdateien, die den Monobank-ECDSA-Pfad, den Nova-Post-Verzeichnisabgleich, die Warenkorb-Bundle-Semantik, das Währungs-Snapshotting und die Statusübergänge der Zahlungsabschnitte abdecken. Sentry-Traces zu 5 % in Produktion mit einem PII-Scrubber. Axiom für strukturierte Cron-Heartbeat-Ereignisse. Produktionsreife Observability wurde nicht nachgerüstet — sie war Teil des ersten Sprints.
Der Stack ist nicht maßgeschneidert, weil wir maßgeschneiderten Code schreiben wollten. Er ist maßgeschneidert, weil der Markt keine fertigen Schienen hat.