Cashback-Plattform mit Affiliate-Transaktionsverarbeitung
Eine Cashback-Plattform verspricht einen einfachen Vorgang: einkaufen, einen Teil zurückbekommen. Dahinter liegen Transaktionsmeldungen aus einer Reihe von Affiliate-Netzwerken, jede in eigenem Format und eigenem Statusmodell, die zu einem Guthaben werden müssen, das ein Nutzer nachvollziehen und ein Betreiber verantworten kann.
Der Fall in einer Minute.
- Rolle
- Batunet übernahm 2015 die Entwicklung und Betreuung der Plattform.
- Systemklasse
- Individuell entwickelte Cashback-Plattform mit eigener Transaktions-, Guthaben- und Auszahlungslogik.
- Externe Anbindung
- Historisch über zehn Affiliate-Netzwerke, angebunden über Dateiabruf, REST- und SOAP-Schnittstellen in jeweils eigenen Formaten.
- Kern der Verarbeitung
- Je Netzwerk ein eigener Importweg, der gemeldete Transaktionen in ein einheitliches internes Transaktionsmodell überführt.
- Abrechnung
- Aufteilung der gemeldeten Provision in Nutzer- und Betreiberanteil. Guthabenkonto mit vollständiger Buchungshistorie statt eines einzelnen Kontostands.
- Auszahlung
- Eigener Vorgang mit eigenem Status: Auszahlungen haben Voraussetzungen, werden geprüft und freigegeben.
- Missbrauchsabwehr
- Sperren gegen zu schnell wiederholte Weiterleitungen, Erkennung automatisierter Klicks, Auffinden von Mehrfachkonten, Sperrlisten und stufenweise Sperren bei auffälligen Anmeldeversuchen.
- Verarbeitungsmodell
- Import und Zuordnung sind als wiederkehrende Stapelverarbeitung angelegt und nicht als Verarbeitung im Anfrage-Zyklus.
Ein Versprechen, das sich einfach anhört.
Cashback ist ein Versprechen mit einem kurzen Wortlaut: Wer über die Plattform einkauft, bekommt einen Teil des Kaufpreises zurück. Der Satz braucht keine Erklärung. Das System dahinter besteht fast vollständig aus dem, was der Satz verschweigt.
Denn der Kauf findet nicht auf der Plattform statt. Er findet beim Händler statt, vermittelt über ein Affiliate-Netzwerk, das den Vorgang später meldet — in seinem Format, zu seinem Zeitpunkt, mit seinem eigenen Statusmodell. Zwischen dem Klick eines Nutzers und der Gutschrift auf seinem Konto liegen ein fremdes System, eine Wartezeit von Wochen und Zustände, die sich in dieser Zeit noch ändern können.
Batunet übernahm 2015 die Entwicklung und Betreuung der Plattform. Die Aufgabe war nicht, eine Oberfläche für Cashback zu bauen, sondern die Abrechnung dahinter belastbar zu machen: aus den Meldungen vieler fremder Systeme ein Guthabenmodell, das ein Nutzer nachvollziehen und ein Betreiber verantworten kann.
Zehn Anbieter, zehn Vorstellungen davon, wie Daten aussehen.
Ein Affiliate-Netzwerk anzubinden klingt nach einer Schnittstelle. Historisch über zehn Netzwerke anzubinden ist etwas anderes: Es sind über zehn Vorstellungen davon, wie eine Transaktion auszusehen hat.
Die Unterschiede liegen dabei nicht im Groben, sondern im Kleinen — und genau dort entstehen Abrechnungsfehler. Der eine Anbieter stellt Dateien zum Abruf bereit, der nächste eine REST-Ressource, der dritte einen SOAP-Dienst. Der eine kennt wenige Status, der andere mehr, und gleich klingende Bezeichnungen bedeuten nicht dasselbe. Der eine gibt die Kennung zurück, mit der ein Nutzer losgeschickt wurde, der andere reicht sie nur eingeschränkt durch.
Die erste Entwurfsentscheidung war deshalb, keine dieser Formen weiter ins System zu lassen. Jede Anbindung ist ein eigener Importweg mit einer einzigen Aufgabe: aus dem, was ein Netzwerk liefert, das interne Transaktionsmodell zu erzeugen. Was danach passiert, kennt kein Anbieterformat mehr.
- Transportweg
- Dateiabruf, REST-Schnittstelle, SOAP-Dienst
- Datenformat
- CSV, XML, Anbietereigene Feldnamen und Spaltenordnungen
- Statusmodell
- Unterschiedliche Statusbezeichnungen je Anbieter, Unterschiedliche Anzahl an Zuständen, Normalisierung auf ein internes Modell
- Kennungsübergabe
- Eigene Zuordnungskennung je Vorgang, Rückgabe anbieterabhängig vollständig oder eingeschränkt, Eigener Weg im Import, wo die Kennung nicht durchgereicht wird
Der Weg einer Transaktion.
Die zentrale Frage dieses Systems lautet nicht, ob eine Transaktion angekommen ist, sondern zu wem sie gehört. Das Netzwerk kennt den Nutzer nicht, und die Plattform kennt den Kauf nicht. Verbunden werden beide Seiten allein über eine Kennung, die die Plattform beim Weiterleiten vergibt und das Netzwerk später zurückmeldet.
Diese Kennung ist deshalb kein technisches Detail, sondern die Voraussetzung jeder Gutschrift. Wo ein Anbieter sie nicht vollständig durchreicht, ist das kein Randfall, den man später löst — es ist ein eigener Weg im Import, der von Anfang an vorgesehen sein muss.

- 01
Kennung
Beim Weiterleiten zu einem Partnerprogramm vergibt die Plattform eine eigene Zuordnungskennung für diesen Vorgang.
- 02
Übergabe
Die Kennung wird an das Affiliate-Netzwerk übergeben und dort dem Vorgang mitgeführt.
- 03
Rückmeldung
Später meldet das Netzwerk die Transaktion — im eigenen Format, mit eigenem Status.
- 04
Vereinheitlichung
Der anbieterspezifische Importweg überführt Felder und Status in das interne Transaktionsmodell.
- 05
Zuordnung
Über die zurückgegebene Kennung wird die Transaktion einem Nutzerkonto zugeordnet.
- 06
Gutschrift
Erst danach entsteht aus der gemeldeten Provision ein Guthabenposten mit eigener Buchungshistorie.
Von der Provision zum Guthaben.
Eine gemeldete Provision ist noch kein Guthaben. Zwischen beiden liegt eine Rechnung, die nachvollziehbar bleiben muss: Aus dem Betrag, den das Netzwerk meldet, ergeben sich der Anteil des Nutzers und der Anteil des Betreibers. Diese Aufteilung gehört zur Fachlogik und nicht in eine nachgelagerte Auswertung.
Unter dem Kontostand steht deshalb keine einzelne Zahl, sondern eine Buchungshistorie. Ein Guthaben, das nur als Summe existiert, ist im Zweifelsfall nicht erklärbar; eines mit Historie lässt sich Posten für Posten aufschlüsseln — welche Transaktion, welcher Zeitpunkt, welcher Status.
Externe Statusmodelle werden dabei normalisiert. Bestätigt und storniert sind Teil des internen Transaktionsmodells und nicht Vokabeln einzelner Anbieter. Guthaben und Buchungshistorie bleiben getrennt nachvollziehbar.
Der Schritt, der bewusst nicht automatisch läuft.
Am Ende steht eine Auszahlung — der einzige Punkt, an dem Geld das System verlässt. Genau dort läuft absichtlich nicht alles von selbst.
Ein Auszahlungswunsch ist deshalb ein eigener Vorgang mit eigenem Status und nicht die Nebenwirkung einer Kontostandsänderung. Er hat Voraussetzungen, er wird geprüft, und er wird freigegeben. Zwischen ausreichendem Guthaben und tatsächlicher Auszahlung liegt eine Entscheidung, die im System sichtbar bleibt.
Das ist keine technische Bequemlichkeit, sondern eine Entwurfsentscheidung. Automatisierung ist überall dort richtig, wo ein Fehler korrigierbar ist. Eine ausgezahlte Summe ist es nicht.
Wo Geld entsteht, wird es versucht.
Sobald ein System Geld ausschüttet, wird es zum Ziel. Das ist kein Verdacht gegen Nutzer, sondern eine Eigenschaft des Geschäftsmodells: Ein Vorgang, an dessen Ende eine Gutschrift steht, lohnt den Versuch, ihn zu erzeugen, ohne ihn zu durchlaufen.
Die Gegenmaßnahmen liegen deshalb nicht an einer Stelle, sondern verteilt über den Ablauf. Weiterleitungen werden gegen zu schnelle Wiederholung gesperrt. Automatisierte Klicks werden erkannt und aussortiert. Mehrfachkonten desselben Nutzers werden auffindbar gemacht. Sperrlisten greifen dort, wo ein Muster bereits bekannt ist. Zugänge mit auffällig vielen Fehlanmeldungen werden stufenweise gesperrt statt sofort und endgültig.
Keine dieser Maßnahmen ist für sich genommen aufwendig. Zusammen sind sie der Unterschied zwischen einem Cashback-Programm, das sich rechnet, und einem, das ausgenutzt wird.
Was eine Integration über Jahre bedeutet.
Eine Affiliate-Integration ist kein Vorhaben mit Enddatum. Die Netzwerke, an die sie angeschlossen ist, gehören anderen Unternehmen: Sie ändern Felder, Formate, Statusbezeichnungen und Zugangswege, ohne zu fragen — und sie tun das nicht gleichzeitig.
Für die Plattform heißt das, dass die Arbeit an den Rändern nie aufhört, während die Mitte stabil bleiben muss. Genau dafür ist die Trennung zwischen anbieterspezifischem Import und internem Transaktionsmodell da: Ein geändertes Format berührt einen Importweg, nicht die Abrechnung.
Der Wert eines solchen Systems liegt ohnehin nicht in seiner Technik, sondern in den Regeln, die über Jahre hineingewachsen sind — Zuordnung, Aufteilung, Fristen, Eigenheiten einzelner Anbieter. Wer diese Regeln behalten will, pflegt die Ränder, statt die Mitte neu zu bauen.
Woran dieser Fall anschließt.
Fragen zu diesem Fall
Wie bindet man mehrere Affiliate-Netzwerke an ein gemeinsames Abrechnungsmodell an?
Indem man keinem Anbieterformat erlaubt, weiter ins System zu gelangen. Jede Anbindung ist ein eigener Importweg mit einer einzigen Aufgabe: Felder, Formate und Statusbezeichnungen des Netzwerks in ein internes Transaktionsmodell zu überführen. Alles danach — Zuordnung, Abrechnung, Guthaben — kennt nur noch dieses eine Modell.
Wie wird eine Affiliate-Transaktion dem richtigen Nutzer zugeordnet?
Über eine Zuordnungskennung, die die Plattform beim Weiterleiten zum Partnerprogramm vergibt und die das Netzwerk mit der gemeldeten Transaktion zurückgibt. Zwischen beiden Ereignissen können Wochen liegen. Wo ein Anbieter die Kennung nicht vollständig durchreicht, ist dafür ein eigener Weg im Import vorgesehen.
Warum wird eine Auszahlung nicht automatisch ausgelöst?
Weil sie der Schritt ist, der sich nicht zurücknehmen lässt. Eine Auszahlung ist deshalb ein eigener Vorgang mit eigenem Status: Sie hat Voraussetzungen, sie wird geprüft und sie wird freigegeben. Automatisierung ist dort richtig, wo ein Fehler korrigierbar bleibt.
Wie geht eine Cashback-Plattform mit Missbrauch um?
Über mehrere Kontrollen entlang des Ablaufs statt über eine einzelne Prüfung: Sperren gegen zu schnell wiederholte Weiterleitungen, Erkennung automatisierter Klicks, Auffinden von Mehrfachkonten desselben Nutzers, Sperrlisten für bereits bekannte Muster und stufenweise Sperren bei auffällig vielen Fehlanmeldungen.
Warum nennen Sie weder den Kunden noch die angebundenen Netzwerke?
Weil beides für die Engineering-Leistung nicht erforderlich ist. Integration, Zuordnung, Abrechnung, Auszahlung und Missbrauchsabwehr lassen sich vollständig beschreiben, ohne sie zu benennen; die Anbieterbeziehungen gehören zum Geschäft des Betreibers. Namentliche Referenzen besprechen wir im direkten Gespräch.
Setzen Sie Ihren Engineering-Weg fort.
Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.
Sprechen wir über Ihr Vorhaben.
Kein Vertrieb. Ein direktes Gespräch mit der Geschäftsführung.
