Source Code einer iGaming-Plattform.
Kein Zugang zu einer Plattform. Eine Kopie des Codes, und sie gehört Ihnen.
Diese Seite legt dar, was ein Quellcode-Kauf von Callisto umfasst: was geliefert wird, was Ihr Team damit tun darf, was in Ihrer Verantwortung bleibt und wie der Code vor einer Entscheidung geprüft werden kann.
Alles, um es ohne uns zu bauen.
Bei einer Quellcode-Lieferung zählt nicht der Umfang, sondern die Vollständigkeit: ob Ihr Team die Plattform ohne Mitwirkung des Anbieters bauen, ausrollen und ändern kann.
Eine vollständige Kopie, samt gemeinsamer Bibliotheken
Alle Services und die darunterliegenden serviceübergreifenden Bibliotheken — Messaging-Contracts, Datenzugriff, Logging, Authentifizierung — werden als Quellcode übergeben und nicht als kompilierte Pakete aus einem Feed, den wir betreiben. Ihr Build hat damit keine Abhängigkeit von Infrastruktur, die wir kontrollieren.
Jeder Service baut für sich allein
Jeder Service bringt sein Dockerfile mit, seine Datenbankmigrationen, seine Unit- und Integrationstests und sein eigenes README. Ein einzelner Service lässt sich eigenständig nehmen und betreiben — so wird die Vollständigkeit der Dokumentation überprüft.
Deployment über Ihr eigenes CI/CD
GitHub-Actions-Workflows und Docker-Compose-Dateien gehören zur Lieferung. Richten Sie sie auf Ihre Registry und Ihre Server — nichts läuft über Infrastruktur, die wir kontrollieren, und es gibt keinen Build-Schritt, den nur wir ausführen können.
Ab da gehört die Historie Ihnen
Die Kopie wandert in Ihr eigenes Git, und ab diesem Punkt gehört das Commit-Log Ihrem Team: Ihre Branches, Ihre Reviews, Ihre Releases. Callistos eigenes Repository bleibt bei uns, denn Callisto ist ein Produkt, das weiterentwickelt wird — auf demselben Weg erreichen Sie Verbesserungen, solange Sie Support halten, als Änderungen, die Sie übernehmen, und nicht als Version, auf die Sie geschoben werden.
Die gesamte laufende Plattform.
Ungefähr das, was ein Käufer beim ersten technischen Rundgang sieht. Der genaue Umfang steht in Ihrem Vertrag — er ist das, wofür Sie tatsächlich zahlen, und gehört nicht auf eine Marketingseite.
Für Spieler
- Casino-Weboberfläche
- Spieler-Wallet und Kasse
- Registrierung, Login und KYC-Strecken
- Agenten-Portal
Betrieb
- Callisto Operator OS (Backoffice)
- Spieler-, Kunden- und Skin-Verwaltung
- Zahlungsprüfung und manuelle Buchungen
- Support-Desk
- Reporting und Dashboards
- Abrechnungen, Rechnungen und Billing
Kernservices
- Spieler, Wallet, Zahlungen, Transaktionen
- Kunden, Währungen, Benutzer und Rollen
- Spiele, Spiel- und Casino-Provider
- Agenten, Agenten-Wallet, Affiliate
- Boni und Bonus-Engine
- Progressive Jackpots
Compliance und Risiko
- Responsible-Gaming-Service
- KYC und Dokumentenprüfung
- Compliance- und Risikoalarme
- Audit-Trails
- Konfigurierbare Risikoregeln
- Compliance-Prüfungsfälle
Engagement
- Communication Hub (In-App, E-Mail, Push)
- Marketingkampagnen und Zielgruppen
- Site Builder
- Ausgehende Webhooks
- Web Analytics und Segmente
- Telegram Mini App je Skin
- Content Studio
Engineering-Unterbau
- Datenbankmigrationen je Service
- Unit- und Integrationstest-Suites
- CI/CD-Workflows
- Provider- und Zahlungssimulatoren zum Testen
Besonders erwähnenswert sind die Simulatoren: Einzahlungen, Wetten und Auszahlungen lassen sich durchgängig testen, bevor ein Providervertrag unterschrieben ist — üblicherweise Monate früher, als eine solche Prüfung sonst möglich wäre.
Lesen, ändern, betreiben.
Die drei Fragen, die technische Entscheider am häufigsten stellen — beantwortet vor dem ersten Gespräch.
Alles ändern, ohne zu fragen
Jede Regel, die Geld berührt, ist für Ihr Team lesbar und änderbar. Es gibt keinen Feature-Request einzureichen und keinen fremden Release-Zyklus abzuwarten.
Beliebig viele Marken betreiben
Genau dafür ist das Skin-Modell gebaut: ein Backend, viele Marken, jede mit eigener Domain, eigenem Theme, eigenen Währungen, Zahlungsmethoden und Responsible-Gaming-Vorgaben. Die Architektur sieht keine Gebühr pro Marke vor.
Weiterlaufen, wenn wir getrennte Wege gehen
Sie haben den Quellcode, die Container und die Dokumentation. Support und Updates sind eine Leistung, die Sie abbestellen können; sie sind keine Lizenzprüfung, die die Plattform anhält. Das ist der wesentliche Unterschied zu einem White-Label-Vertrag, und wir empfehlen, ihn schriftlich festzuhalten — bei uns wie bei jedem anderen Anbieter.
Die Grenzen stehen im Vertrag
Quellcode zu besitzen ist nicht dasselbe wie das Recht, die Plattform als Konkurrenzprodukt weiterzuverkaufen. Was eingeräumt wird und was vorbehalten bleibt, steht im Vertrag — in klaren Worten, vor der Unterschrift.
Was nicht enthalten ist.
Jeder Punkt unten wird für den Betrieb benötigt und gehört nicht zur Lieferung — weder bei uns noch bei anderen Plattformanbietern. Wir führen sie hier auf, damit sie in der Planung berücksichtigt und nicht erst in der Umsetzung entdeckt werden.
Die Glücksspiellizenz
Die Lizenz für jeden Markt halten Sie. Wir liefern die Kontrollen, Sperren und Audit-Trails, nach denen eine Aufsichtsbehörde fragt; wir vergeben, sponsern oder teilen keine Lizenz — das kann kein Softwareanbieter.
Spielinhalte
Die Plattform ist eine Aggregationsschicht mit Provider-Integrationen. Die Spiele selbst lizenzieren Sie bei den Studios, die sie herstellen, zu Ihren eigenen kommerziellen Konditionen.
Verträge mit Zahlungsanbietern
Anbieter docken über eine gemeinsame Schnittstelle an, aber Händlerkonto, Underwriting und Rolling Reserve liegen zwischen Ihnen und dem Anbieter. Das ist meist der längste Posten im Startplan.
Hosting und Betrieb
Selbst gehostet bedeutet, dass der Betrieb bei Ihnen liegt: Server, Backups, Monitoring und die Rufbereitschaft. Wir helfen beim Aufsetzen; Ihre Infrastruktur bleibt es dennoch.
Rechts- und Regulierungsberatung
Welche Kontrollen Ihr Markt verlangt, beantwortet Ihre Compliance-Beratung. Wir können Ihnen genau sagen, wie jede Kontrolle umgesetzt ist — weil Sie es nachlesen können.
Wir empfehlen, dieselbe Aufstellung von jedem Anbieter zu verlangen, den Sie vergleichen.
Prüfen Sie den Code, bevor Sie ihn kaufen.
Quellcode lässt sich vollständig prüfen, bevor eine Entscheidung fällt. Wir betrachten das als normalen Teil der Bewertung und nicht als Zugeständnis; die folgende Reihenfolge schlagen wir vor.
- 1
Technische Demo der laufenden Plattform
Ein laufendes System statt Folien: Backoffice, Casino-Frontend und eine durchgängig verarbeitete Einzahlung.
- 2
Code-Review mit Ihren Ingenieuren
Wir führen Ihr technisches Team durch die Architektur und öffnen die Dateien, nach denen es fragt: das Wallet unter Nebenläufigkeit, die Zahlungs-Callbacks, die Durchsetzung der Responsible-Gaming-Regeln. Wir empfehlen, sich auf diese drei Stellen zu konzentrieren: dort liegt das größte operative Risiko.
- 3
Ihre eigene Due Diligence beim Wesentlichen
Testabdeckung, Migrationshistorie, Umgang mit Secrets, wie Services sich gegenseitig authentifizieren, was passiert, wenn ein Provider-Callback zweimal ankommt. Zu jedem dieser Punkte stellen wir auf Anfrage Belege bereit.
- 4
Umfang und Konditionen schriftlich
Welche Repositories, welche Rechte, wie Support danach aussieht und was gilt, wenn Sie aufhören. Vor der Unterschrift vereinbart, nicht danach entdeckt.
Weg vom Revenue Share.
Der häufigste Grund, aus dem Betreiber hier landen. Die Plattform ist selten der schwierige Teil — die Daten und die Verträge sind es.
Die kaufmännische Rechnung
Ein Revenue Share wächst mit Ihnen und hört nie auf. Die Software zu besitzen verwandelt einen offenen Prozentsatz in Fixkosten plus eigenes Engineering — bei kleinem Volumen schlechter, oberhalb eines Punktes oft deutlich besser. Wir empfehlen, den eigenen Break-even zu bestimmen, bevor Angebote bewertet werden.
Ihre Spieler und deren Guthaben
Spielerkonten, Guthaben, Transaktionshistorie und KYC-Status lassen sich migrieren; wie sauber, hängt ganz davon ab, was Ihr jetziger Anbieter exportiert. Diese Frage sollte früh geklärt werden: sie prägt den Zeitplan stärker als die technische Arbeit.
Provider müssen neu vertraglich gebunden werden
Spiel- und Zahlungsintegrationen laufen nach dem Wechsel auf Ihren Namen. Manche Anbieter ziehen problemlos mit, andere verhandeln neu. Das ist Vertragsarbeit parallel zur technischen Migration — und sie bestimmt meist den Starttermin.
Beides eine Zeit lang parallel betreiben
Nichts erzwingt einen Stichtag. Häufig starten Betreiber zuerst eine neue Marke auf der eigenen Plattform, lernen daran und migrieren die bestehende, wenn der Betrieb sich bewährt hat.
Fragen zum Quellcode.
Diese Fragen kommen auf, sobald es um den Code selbst geht und nicht mehr um die Plattform im Allgemeinen.
Echte Übergabe. Escrow heißt, ein Dritter verwahrt den Code und gibt ihn heraus, falls der Anbieter ausfällt — Sie bekommen nichts, bis etwas schiefgeht, und haben nie gesehen, was Sie bekämen. Hier wird die Kopie zu Beginn der Zusammenarbeit übergeben: auf Ihrer Infrastruktur, in Ihrem Git und Ihren Ingenieuren sofort zugänglich. Wenn Ihre Rechtsabteilung darüber hinaus Escrow-Klauseln möchte, ist das eine Vertragsfrage und kein technisches Hindernis.
Ja, und das ist so entworfen und kein Zugeständnis. Support, Fixes und neue Module sind eine Leistung, die Sie abbestellen können. Nichts funkt nach Hause, kein Lizenzschlüssel läuft ab, und kein Build-Schritt läuft auf unserer Infrastruktur — es gibt also keinen Hebel, an dem sich nach Ihrem Weggang ziehen ließe.
Es ist eine echte Plattform: 35+ Services, und niemand hat sie vollständig im Kopf, wir eingeschlossen. Tragbar wird sie dadurch, dass die Services klein, gleichförmig und unabhängig deploybar sind — dieselbe Architektur und derselbe Aufbau in jedem, sodass wer einen versteht, die Form aller kennt. Ein Team aus mehreren Ingenieuren trägt sie; eine einzelne Person nicht — und wir sagen das lieber, bevor die Frage praktisch wird.
Callisto ist ein Produkt und keine Auftragsentwicklung, derselbe Code kann also an mehr als einen Käufer gehen — nichts an der Art, wie er verkauft wird, reserviert ihn für einen. Jede Installation läuft auf eigener Infrastruktur mit eigenen Daten, und keine Installation sieht eine andere. Exklusivität in einem Markt ist eine kommerzielle und keine technische Frage; ist sie Ihnen wichtig, sprechen Sie sie vor der Unterschrift an, statt eine der beiden Antworten anzunehmen.
Es ist die Plattform, die wir betreiben, keine Referenzimplementierung zum Verkaufen. Das hat Folgen in beide Richtungen: einerseits echte Last und echte Zahlungsanbieter, andererseits Bereiche in aktiver Entwicklung, die im Code sichtbar sind. Im Review sehen wir uns an, worum Sie bitten.
Das hängt vom Umfang ab — einzelne Module, die ganze Plattform oder die Plattform samt unseren Ingenieuren neben Ihrem Team — eine Zahl auf einer Webseite wäre für die meisten Leser also erfunden. Ein Gespräch genügt, um den Umfang zu bemessen, und wenn Callisto nicht passt, sagen wir es Ihnen.
Bringen Sie Ihre Ingenieure mit.
Eine Source-Code-Plattform beurteilt man am schnellsten, indem Ihr technisches Team sie gemeinsam mit unserem liest. Sagen Sie uns, was Sie heute betreiben und was Sie ändern wollen.
Wir antworten binnen eines Tages, meist noch am selben.