Echte Screens, Demo-Daten.
Keine Mockups — das System läuft. Der Shop und das Käufer-Portal sind serverseitig gerendert (schnell, ohne App-Zwang), der Türscanner ist eine PWA fürs Handy, das Organizer-Backend passwortlos. Die Screens unten zeigen die öffentliche Live-Demo mit fiktiven Seed-Daten — keine echten Kundendaten. Selbst durchklicken →
Vier Säulen, ein Datenmodell.
Alles greift ineinander: der Verkauf bucht die Kapazität atomar ab, die Zahlung kommt idempotent per Webhook rein, das Ticket wird signiert und zugestellt, der Einlass schreibt ins Check-in-Journal — append-only, nachvollziehbar, in Cent gerechnet.
01 Verkaufen
- Oversell-sichere Holds: ein atomares UPDATE, DB-Constraint als Backstop
- Stripe & PayPal über Hosted-Checkout — PCI-Scope SAQ-A, keine Kartendaten im System
- Idempotente Webhook-Erfassung auf der echten PSP-Event-ID
- Promo-Codes, Bundles/Pakete, Mehrtages-Pässe, Altersfreigabe
- Warteliste mit fairer Re-Offer und Frei-Kapazitäts-Engine
- Gästeliste/Comps: kapazitäts-echte Freitickets ohne Geldfluss
- §312g-Widerrufshinweis + Consent, am Kauf eingefroren
- Optionale Buchungsgebühr: PAngV-All-in-Preis, §270a-konform
02 Einlass
- Offline-Türscanner als PWA — funktioniert ohne Netz, synct nach
- Ed25519-signierte QR-Tickets, pro Event ein eigener Schlüssel
- Scanner bekommt nur den Public-Key — nie ein Geheimnis
- Doppel-Scan-Schiedsspruch serverseitig (gleiches Gerät lokal)
- Transfer dreht den QR-Nonce — altes Ticket stirbt, online & offline
- Onboarding per Invite-Link/QR mit Gerätenamen, mit Admin-Freigabe
- IN/OUT-Scans mit Live-Belegung; harte Belegungsgrenze
- Tür-Aktionen: schließen, Gast (€0), manueller Override — als Journalzeile
- Gemeinsame Kapazitätspools über mehrere Tarife hinweg
03 Abrechnen
- Vier append-only Ledger (Order, Payment, Ticket, Check-in)
- Zustand = Projektion über das Journal, Korrektur = neue Zeile
- Auswertungen reconciliation-exakt: deduplizierter Brutto, Disputes
- CSV-Exporte: Sales, Tarife, Umsatz, Promos, Check-in
- Auto-Refund mit Refund-/Dispute-Kappung je Bestellung
- Refund-Reason-Codes, Pro-rata & cent-exakte Teil-Refunds
- §14-Rechnung: eingefrorener USt-/Aussteller-Snapshot, IDOR-sicher
- Geld als Integer-Cent, USt in Basispunkten — keine Floats, EUR
04 Zustellen
- Bestätigungs-Mail mit serverseitig gerendertem PDF-Ticket
- Kalender: ICS-Anhang (RFC 5545) + „zu Google Kalender"
- Apple PKPass & „Save to Google Wallet" — optional, config-gated
- Magic-Link-Käufer-Portal: Bestellung verwalten, neu laden, übertragen
- Mail-Vorlagen pro Organisator, lokalisiert (de/en), injection-sicher
- Operator-eigener Absender Pflicht — kein Gmail-/Default-Fallback
+ Lebenszyklus
- Event-Absage & Verlegung mit Massen-Refund und Benachrichtigung
- Ticket-Transfer/Verschenken mit Halter-Wechsel und QR-Rotation
- Cancelled-Event-Gate: Einlass an der Tür wird verweigert
- Mehrtages-/Festival-Pässe mit Tages-Logik am Einlass
+ Betrieb
- Ein statisches Binary (CGO off) + PostgreSQL, distroless Image
docker compose up— zwei Container, fertig- Migrationen beim Start unter Advisory-Lock; In-Process-Worker
- Tickets/Pässe werden on-demand regeneriert — Postgres ist das Backup
- Schlanke Abhängigkeiten: 7 Runtime-Module, harte Obergrenze
Sicherheit & Pflichten als Architektur.
Nicht als Aufkleber, sondern eingebaut: jedes Ticket kryptografisch signiert, jeder Cent ein Journaleintrag, jede Korrektur ein neuer Eintrag, jeder Mandant am DB-Level getrennt. Konkret benannt — kein pauschales „rechtssicher"-Versprechen.
Was wir bewusst anders machen.
Keine Show-Logos, keine erfundenen Zahlen, keine KI-Versprechen. qognitix zeigt, was schon läuft — und sagt offen, wo Pilotphase ist.
01 Dir gehören die Daten
Selbstgehostet, kein SaaS-Lock-in — bei EU-Hosting bleiben die Daten in der EU (so der qognio-Pilotbetrieb). Ein Binary plus PostgreSQL — kein Redis, kein Kafka, keine Cloud-Abhängigkeit. Mandanten am DB-Level per Row-Level-Security getrennt.
02 Echte Oberfläche
Die Screens oben zeigen die Demo-Umgebung mit Seed-Daten, nicht nachgebaute Marketing-Mockups. Der ganze Buchungs-, Einlass- und Abrechnungspfad ist end-to-end getestet.
03 Pflichten zuerst
Signierte Tickets, append-only Ledger, DSGVO-Löschkonzept und Mandanten-Trennung sind keine Zusatzfolie, sondern Teil des Datenmodells — und namentlich benannt statt pauschal versprochen.
Häufige Fragen.
Die Fragen, die vor einer Pilot-Anfrage wirklich zählen: Hardware, Offline-Einlass, Ticket-Sicherheit, Zahlung, Datenhaltung und Einstieg — ohne Vertriebsnebel.
Brauche ich besondere Hardware?
Nein. Der Shop läuft im Browser, der Türscanner ist eine Web-App (PWA) auf modernen Smartphones und Tablets mit Kamera und aktuellem Browser — nichts zu installieren, kein App-Store. Ein Scanner wird per Invite-Link oder QR beigetreten und benannt; die Kamera des Geräts liest den Ticket-QR.
Funktioniert der Einlass auch ohne Internet?
Ja. Der Türscanner verifiziert Tickets offline mit dem öffentlichen Schlüssel des Events und verhindert Doppel-Scans auf demselben Gerät lokal. Sobald wieder Netz da ist, synchronisiert er — und der Server ist der Schiedsrichter, der geräteübergreifende Doppel-Scans erkennt und meldet.
Wie sicher sind die Tickets gegen Kopien?
Jedes Ticket ist mit Ed25519 signiert, mit einem pro Event eigenen, abgeleiteten Schlüssel; der private Master-Key verlässt den Server nie, Scanner bekommen nur den Public-Key. Wird ein Ticket übertragen, dreht sich der QR-Nonce — der alte Code stirbt, online wie offline. Ein abfotografierter oder zurückerstatteter QR wird an der Tür erkannt.
Stripe oder PayPal — und wie steht es um die Kartendaten?
Beide, hinter einem austauschbaren Port; beide sind optional und per Konfiguration zuschaltbar. Bezahlt wird im Hosted-Checkout des Zahlungsdienstleisters (PCI-Scope SAQ-A) — die Anwendung sieht, verarbeitet und speichert nie eine Kartennummer. Wahrheit der Zahlung ist der signatur-geprüfte Webhook, nie der Browser-Redirect.
Wo liegen meine Daten?
Bei dir — selbstgehostet; mit EU-Hosting (wie im qognio-Pilotbetrieb) bleiben sie in der EU. Jeder Veranstalter ist per Row-Level-Security strikt vom nächsten getrennt — eine Query, die je ihren Mandanten-Filter vergisst, fällt am DB-Level geschlossen aus statt zu leaken. Das DSGVO-Löschkonzept ist eingebaut: mutable PII wird pseudonymisiert, die append-only Finanz-Ledger bleiben nach §147 AO erhalten.
Was kostet es und wie läuft die Pilotphase?
Es gibt aktuell keine öffentliche Preisliste. qognitix ist Open Source und selbstgehostet; den Einstieg — Stammdaten, Events, Tarife, Zahlungsanbindung, Scanner-Onboarding — richten wir gemeinsam ein. Umfang, Betrieb und Eignung klären wir direkt. Kontakt über qognio.
Für wen?
Für Veranstalter mit echtem Einlass, begrenzter Kapazität und prüfungsrelevanten Pflichten — nicht für Konzern-Rollouts mit Saalplan-Reservierung, nicht für reine Spendenseiten.