Die Kasse — und alles, was dahinter liegt.
Konfigurieren Sie Zahlungsanbieter je Marke und verfolgen Sie jeden Schritt des Zahlungsablaufs.
Diese Seite beschreibt, wie Zahlungen in Callisto funktionieren: wie der Zahlungsanbieter für Marke und Methode ermittelt wird, was zwischen dem Klick auf „Einzahlen“ und der Bewegung eines Saldos passiert, wie Auszahlungen zurückgehalten und freigegeben werden, wie Krypto nach dem tatsächlichen Eingang gutgeschrieben wird und wie der gesamte Ablauf getestet wird, bevor ein einziger Anbietervertrag unterschrieben ist.
Von der Anfrage zum Wallet-Guthaben.
Vier Schritte, von denen jeder scheitern kann und jeder festgehalten wird. Nichts an diesem Weg ist vor dem Betreiber verborgen, der ihn später erklären muss.
Der passende Zahlungsanbieter wird ausgewählt
Eine Einzahlung nennt Marke und Zahlungsmethode, und die Plattform ermittelt, welcher Prozessor diese Kombination für diese Marke bedient. Zwei Marken auf einer Installation können für dieselbe Methode völlig unterschiedliche Prozessoren nutzen.
Der Spieler wird zum Prozessor geführt
Der Anbieter liefert eine Weiterleitung, die die Kasse öffnet — eine gehostete Seite oder ein Frame, je nachdem, was der Prozessor unterstützt. Karten, Wallets, lokale Methoden, Gutscheine, agentengestützte Zahlungen und manuelle Buchungen folgen jeweils der Form, die ihre Methode zulässt.
Das Urteil kommt über einen signierten Webhook
Der Prozessor meldet an einen Endpunkt zurück, dessen Grenze eine Signatur über den rohen Body ist und kein Plattformschlüssel — ein externes Unternehmen hält nie eine Zugangsberechtigung zu internen Services. Wiederholungen sind der Normalfall, deshalb erkennt ein Index die Zustellung und nicht ein Lesevorgang, den zwei parallele Callbacks beide bestehen würden.
Der Kontostand wird genau einmal aktualisiert
Eine abgeschlossene Zahlung veröffentlicht ein Saldo-Ereignis, und das Wallet wendet es unter optimistischer Nebenläufigkeit an. Dieselbe Zustellung zweimal schreibt nicht zweimal gut; diese Garantie liegt in der Datenbank und nicht in einem Codepfad, an den sich jemand erinnern muss.
Methoden in der Form, die sie wirklich haben.
Methodentypen sind plattformweit und einmal nummeriert, damit derselbe Wert im Backoffice, in der Kasse und in den Berichten dasselbe bedeutet. Welche davon eine Marke anbietet und in welcher Reihenfolge, ist ihre Konfiguration.
Gehostete Seiten oder eine serverseitig geöffnete Sitzung, damit eine Marke den Spieler in der eigenen Kasse halten kann, wo der Prozessor das erlaubt.
Auf eine Adresse mit Frist fakturiert und dann on-chain beobachtet.
Die Wallets, die ein Markt erwartet, je hinter ihrer eigenen Prozessor-Integration.
Einschließlich der lokalen Zahlwege, die eine reine Kartenkasse verpasst.
Für Märkte, in denen ein Agentennetz den Spieler versorgt — mit eigenem Wallet und eigener Abrechnung.
Manuelle Buchung ist rein administrativ, nie für Spieler sichtbar, und jede trägt die Person, die sie vorgenommen hat.
Die Methoden einer Marke, ihre Reihenfolge in der Kasse und ihre Limits werden je Skin konfiguriert — eine Methode hinzuzufügen ist Konfiguration, einen Prozessor hinzuzufügen eine Klasse hinter einer Schnittstelle plus eine Zeile.
Jede zurückgehaltene Auszahlung hat einen nachvollziehbaren Grund.
Bei Auszahlungen hat eine Plattform entweder eine Richtlinie oder improvisiert eine. Callisto hat eine: Eine Auszahlung kann in dem Moment beurteilt werden, in dem der Spieler sie beantragt, und die Antwort wird auf die Zahlung selbst geschrieben.
Beurteilt beim Antrag, nicht nachdem das Geld weg ist
Die Risiko-Engine erst bei der Abrechnung zu fragen ist zu spät — die Auszahlung, die sie verhindern sollte, ist bereits erfolgt. Deshalb wird der Antrag im Moment der Stellung bewertet, und die Zurückhaltung wird auf der Zahlung vermerkt statt später aus einem Status erschlossen.
Der Grund ist eine Spalte, kein Status
Eine zurückgehaltene Auszahlung trägt mit, was sie zurückhält. Wer die Warteschlange öffnet, sieht den Grund, statt ihn aus der Reihenfolge der Zeilen zu erraten.
Unbekannt hält zurück statt freizugeben
Lässt sich eine Prüfung nicht abschließen — ein Service nicht erreichbar, ein Status nicht lesbar —, wartet die Auszahlung auf einen Menschen. Eine unbeantwortete Frage als Zustimmung zu werten ist genau der Fehler, den diese Regel verhindert.
Die Freigabe ist jemandes Entscheidung, und sie ist unterschrieben
Manuelle Freigaben, Ablehnungen und Korrekturen halten fest, wer sie wann getroffen hat, in einem unveränderbaren Protokoll. Eine Auszahlung, die sich ohne Urheber bewegt hat, ist genau das, wonach eine Prüfung fragt.
Gutgeschrieben wird, was ankam — nicht, was gefordert war.
Eine Krypto-Einzahlung wird auf eine Adresse mit Frist fakturiert und dann beobachtet. Gutgeschrieben wird, was tatsächlich on-chain angekommen ist, denn nur diese Zahl stimmt: Rechnungen werden unterbezahlt, überbezahlt und verspätet bezahlt, und wer den Rechnungsbetrag gutschreibt, schreibt einen Wunsch gut. Unter- und Überzahlung haben deshalb definierte Ergebnisse statt ein Support-Ticket zu werden, und die Einzahlung wird gegen die Chain abgeglichen, nicht gegen die Absicht.
Die Kasse testen, ohne etwas zu unterschreiben.
Ein Zahlungssimulator kommt mit der Plattform, und er ist kein Stub, der Erfolg zurückgibt: Er nutzt denselben Webhook-Pfad wie ein echter Prozessor, sodass Ihr Code das zu hören bekommt, was ein Anbieter geantwortet hätte.
Ein- und Auszahlungen von Anfang bis Ende
Ein vollständiger Zyklus — Antrag, Weiterleitung, Callback, Saldobewegung — bevor ein PSP überhaupt ausgewählt, geschweige denn integriert ist. Üblicherweise Monate früher, als solche Tests sonst möglich wären.
Auch die Fehlerfälle, nicht nur der glückliche Pfad
Ablehnungen, Timeouts, fehlerhafte Callbacks und gefälschte Signaturen sind Szenarien, die Sie anfordern können. Eine gefälschte Signatur wird wirklich abgewiesen, weil der Simulator durch die echte Prüfung geht und nicht daran vorbei.
Sicher neben einem echten Anbieter
Eine Marke bekommt den Simulator nur, indem sie dafür konfiguriert ist, und der Webhook-Pfad weist eine Zustellung ab, deren Anbieter nicht der dieser Marke ist. Eine Marke, die auf einen echten Prozessor zeigt, lässt sich von hier nicht steuern.
Prozessoren ergänzen, ohne die Plattform umzubauen.
Ein Prozessor ist eine Implementierung hinter einer Schnittstelle plus seine Konfigurationszeile: Zugangsdaten je Marke, verschlüsselt, von der API nie zurückgegeben. Oberhalb dieser Naht ändert sich nichts — genau das macht „unser Acquirer in diesem Markt“ zu einer Konfigurationsfrage statt zu einer Roadmap-Frage. Ihr Team kann einen Prozessor auch ohne uns ergänzen: Der Quellcode gehört Ihnen, und die vorhandenen Implementierungen sind die ausgearbeiteten Beispiele.
Wir zeigen keine Logo-Wand. Eine Integration geschrieben zu haben und mit ihr echtes Geld für Ihre Marke abgerechnet zu haben, sind zwei verschiedene Aussagen, und welche Prozessoren eine Marke nutzt, ist ihr eigener Vertrag. Fragen Sie uns direkt, und Sie bekommen eine klare Antwort, was live gelaufen ist und was nicht — auch dort, wo die Antwort „noch nicht“ lautet.
Fragen zu Zahlungen.
Was aufkommt, sobald die Kasse kein Diagramm mehr ist.
Integrationen für eine Reihe von Prozessoren liegen im Code — Karten, Krypto, E-Wallets und lokale Methoden — und einen weiteren zu ergänzen ist eine Klasse hinter einer Schnittstelle plus eine Konfigurationszeile, keine Plattformänderung. Wir veröffentlichen die Liste nicht als Logo-Wand, weil „die Integration existiert“ und „sie hat für Ihre Marke Geld abgerechnet“ zwei verschiedene Aussagen sind und nur die zweite für Sie zählt. Nennen Sie uns Ihre Acquirer und PSPs, und wir sagen Ihnen klar, was bereits implementiert ist, was live gelaufen ist und was die Anbindung des Rests bedeutet.
Ja, und das ist die normale Konfiguration. Der Anbieter wird je Marke und je Zahlungsmethode ermittelt, sodass eine Installation eine europäische Marke über den einen Acquirer und eine lateinamerikanische über einen anderen bedienen kann, mit unterschiedlichen Methoden in jeder Kasse. Zugangsdaten gehören der Marke, liegen verschlüsselt und werden von der API nie zurückgegeben.
Eine Auszahlung wird beurteilt, wenn der Spieler sie beantragt, und nicht nachdem das Geld geflossen ist; die Zurückhaltung wird mit ihrem Grund auf die Zahlung geschrieben. Lässt sich eine Prüfung nicht abschließen, wartet die Auszahlung auf einen Menschen, statt standardmäßig durchzugehen. Manuelle Freigaben und Korrekturen halten fest, wer sie vorgenommen hat, in einem unveränderbaren Protokoll.
Gutgeschrieben wird, was tatsächlich on-chain ankam, nicht der Rechnungsbetrag. Unter- und Überzahlung haben definierte Ergebnisse statt ein Support-Ticket zu werden, und die Einzahlung wird gegen die Chain abgeglichen — die einzige Aufzeichnung, die keine Absichtserklärung ist.
Ja, und das ist eines der nützlicheren Dinge in der Lieferung. Ein Zahlungssimulator kommt mit der Plattform und nutzt denselben Webhook-Pfad wie ein echter Prozessor — inklusive Ablehnungen, Timeouts, fehlerhafter Bodys und gefälschter Signaturen. Ihr Team kann einen vollständigen Ein- und Auszahlungszyklus Monate vor jedem Anbietervertrag durchspielen, und eine Marke, die auf einen echten Prozessor zeigt, lässt sich davon nicht steuern.
Nein, und das mit Absicht. Wallets sind mehrwährungsfähig und jeder Betrag bleibt in der Währung, in der er entstanden ist; es gibt keine Kursquelle auf der Plattform, denn eine Umrechnung zum heutigen Kurs würde denselben Betrag an zwei Tagen unterschiedlich beurteilen lassen. Wo ein Schwellenwert oder ein Bericht eine Währung braucht, wird er je Währung gesetzt statt in eine umgerechnet.
Behalten Sie die Acquirer und PSPs, mit denen Sie bereits arbeiten.
Sagen Sie uns, mit welchen Prozessoren Sie Verträge halten und welche Märkte Sie öffnen. Wir sagen Ihnen, was bereits implementiert ist, was live gelaufen ist und was die Anbindung des Rests tatsächlich bedeutet.
Wir antworten innerhalb eines Tages, meist noch am selben.
Zur Plattform