2026 Autor: ZCS
Ein Treueprogramm scheitert auf einem Kassenterminal aus einem Hauptgrund: Die Hardware ist nicht für die Integration externer Software ausgelegt. Einzelhändler erwerben eine Treueprogramm-Plattform, unterzeichnen den Vertrag, planen das Budget für die Einführung ein – und stellen dann fest, dass das Betriebssystem, das SDK oder die Zahlungszertifizierung des Terminals die Integration vollständig blockiert. Dies ist kein Softwareproblem, sondern ein Problem der Hardwarearchitektur. Es tritt fast immer dann auf, wenn ein Händler versucht, ein Kassensystem mit Treueprogramm-Funktionalität auf einem Terminal zu installieren, das als geschlossenes Zahlungsgerät und nicht als offenes Computersystem konzipiert wurde.
Bevor man eine Plattform bewertet, ist es hilfreich, die folgenden Punkte zu klären: Die grundlegende Frage lautet: Was kann ein Kassenterminal mit Prämiendaten tun und was nicht? — weil die Antwort ausschließlich von der zugrunde liegenden Hardware abhängt, nicht vom Funktionsumfang der Loyalitätssoftware.
Dieser Artikel erläutert die spezifischen technischen Gründe, warum in Kundenbindungsprogramme integrierte Kassensysteme auf abgesicherter Hardware scheitern, was „abgesichert“ auf Betriebssystem- und Zertifizierungsebene tatsächlich bedeutet und wie eine Evaluierungscheckliste für Händler aussieht, die ein Kundenbindungsprogramm benötigen, das tatsächlich im Produktivbetrieb funktioniert.
Geschützte POS-Hardware ist ein Terminal, bei dem der Hersteller die Ausführung von Anwendungen und den Zugriff dieser Anwendungen auf Systemressourcen einschränkt. Dies ist eine bewusste Designentscheidung und kein Fehler. Traditionelle Kartenzahlungsterminals – die Thekengeräte, die primär für EMV- und PIN-Transaktionen entwickelt wurden – sind nach dem PCI PTS POI-Standard zertifiziert, der das gesamte Gerät als eine einzige vertrauenswürdige Zahlungsumgebung behandelt. Die Integration einer Kundenbindungs-App in diese Umgebung bedeutete bisher, dass ein nicht verifizierter Codepfad neben den Karteninhaberdaten hinzugefügt wurde, was von Zahlungsanbietern und Acquirern nicht zugelassen wird.
Drei Hardwaremerkmale definieren ein gesperrtes Terminal:
Keine dieser Eigenschaften ist an sich schlecht. Spezielle Kartenterminals etablierter Hersteller sind so konzipiert, dass der Umfang von PCI-DSS-Audits minimiert wird. Das Problem tritt erst auf, wenn ein Händler erwartet, dass dasselbe Terminal auch ein Kassensystem mit Kundenbindungsprogramm, CRM-Synchronisierung oder Marketing-App unterstützt – Funktionen, für die die Hardware weder zertifiziert noch konzipiert wurde.
Die Integration von Loyalitätsprogrammen scheitert auf geschlossenen Architekturen aus drei immer wiederkehrenden technischen Gründen: Sandboxing-Regeln schränken den Datenzugriff ein, proprietäre SDKs blockieren die Installation und Firmware-Update-Zyklen verzögern die Einführung neuer Funktionen.
Die vom PCI Security Standards Council veröffentlichte Version 7.0 des PCI PTS POI erlaubt nun die Ausführung von Drittanbieteranwendungen, wie z. B. Apps aus App-Stores, auf zertifizierten POI-Geräten. Der Standard schreibt jedoch vor, dass diese Anwendungen … sicher von sensiblen Zahlungsfunktionen isoliert und mittels kryptografischer Kontrollen authentifiziert.Eine neuere Anforderung in derselben Version verhindert, dass Drittanbieteranwendungen PAN- oder PIN-Daten im Klartext lesen können, selbst wenn die Anwendung auf einer genehmigten Whitelist steht. Für ein Loyalty-System ist dies von direkter Bedeutung: Jedes Integrationsmuster, das davon ausgeht, dass die Loyalty-App den Transaktionsbetrag, das Kartentoken oder die Kunden-ID direkt aus dem Zahlungsprozess auslesen kann, ist auf einem nach Version 7.0 zertifizierten Gerät nicht konform. Die Loyalty-App muss diese Daten über einen genehmigten, isolierten Kanal empfangen – und auf vielen gesperrten Terminals existiert kein solcher Kanal.
Eine Kundenbindungsplattform muss Kunden registrieren, Punktestände abrufen, Einlösungen verarbeiten und Prämien am Point of Sale ausdrucken oder anzeigen können. Jede dieser Aktionen benötigt einen SDK-Hook. Terminals mit einem geschlossenen, herstellereigenen Betriebssystem stellen diese Hooks in der Regel externen Entwicklern nicht zur Verfügung. Der Anbieter der Kundenbindungsplattform muss die Integration über einen Payment-Gateway-Webhook erst nach Abschluss der Transaktion durchführen, was zu spät ist, um einen Echtzeitrabatt anzuwenden oder eine In-Session-Prämie auszulösen. Dies ist das häufigste Problem, das Händler beim Umstieg von herkömmlichen Kassenterminals auf POS-basierte Kundenbindungsprogramme melden: Die Integration funktioniert zwar technisch als Synchronisierung nach der Transaktion, kann aber während der Interaktion selbst keine Aktionen ausführen.
Selbst wenn ein gesperrtes Terminal nur ein eingeschränktes SDK bereitstellt, werden Firmware-Updates auf spezialisierten Zahlungsgeräten in der Regel langsam und zertifizierungsabhängig durchgeführt, da jede Firmware-Änderung eine erneute PCI-Zertifizierung auslösen kann. Ein Anbieter von Kundenbindungsprogrammen, der eine neue Einlöseregel, einen neuen Registrierungsprozess oder eine neue Prämienstufe einführen möchte, muss den Veröffentlichungszyklus des Hardwareherstellers abwarten – nicht seinen eigenen. Auf einem offenen Android-POS-Terminal hingegen aktualisiert sich die Kundenbindungs-App unabhängig über ihr eigenes App-Paket und ist dabei völlig unabhängig von der Terminal-Firmware.
Die direkten Kosten einer fehlgeschlagenen Integration sind ein verzögerter oder rückgängig gemachter Rollout, doch die weitaus größeren Kosten sind strategischer Natur: Einzelhändler kaufen immer mehr Loyalitätssoftware, während die Hardwarekompatibilität vernachlässigt wird. Der globale Markt für Loyalitätsmanagement erreichte 2026 ein geschätztes Volumen von 17.38 Milliarden US-Dollar und soll bis 2034 jährlich um über 14 % wachsen. Jeder Dollar, der für eine Loyalitätsplattform ausgegeben wird, die nicht auf der Kassenhardware läuft, ist doppelt verloren – einmal für die Software und ein zweites Mal für eine Hardware-Aktualisierung, die eigentlich zuerst hätte erfolgen sollen.
Es fallen auch Kosten für die Einhaltung der Vorschriften an. Treueprogramme erfassen und verarbeiten personenbezogene Kundendaten – Namen, Telefonnummern, Kaufhistorie, manchmal auch biometrische Daten für Programme zur kontaktlosen Identifizierung. Gemäß EU-Verordnung 2016/679 (DSGVO)Diese Verarbeitung erfordert eine dokumentierte Rechtsgrundlage und einen gesetzeskonformen Einwilligungsprozess bei der Registrierung. Eine durch einen inoffiziellen Workaround erzwungene Loyalitätsintegration – etwa durch ein manipuliertes Endgerät, eine nicht unterstützte, per Sideloading installierte APK-Datei oder eine Screen-Scraping-Bridge – erschwert die Erstellung dieser Compliance-Dokumentation im Rahmen eines Audits erheblich, da der Datenpfad selbst nie für eine Überprüfung konzipiert wurde.
Eine Architektur, die Loyalität zuverlässig unterstützt, weist drei gemeinsame Merkmale auf: ein offenes SDK, Softwareverteilung auf App-Store-Ebene und Hardware-Identitätsfunktionen, die über das einfache Durchziehen einer Karte hinausgehen.
Android-basierte POS-Terminals mit einem veröffentlichten SDK ermöglichen es Anbietern von Kundenbindungsprogrammen, direkt auf Basis dokumentierter APIs für Drucker, Scanner, Kundendisplay und Zahlungskern zu entwickeln – ohne für jede neue Funktion auf den Hardwarehersteller warten zu müssen. Dieses offene Plattformmodell wurde von Square mit seiner Terminal-API für die eigene Hardware eingeführt und ist mittlerweile Standard bei den meisten Android-POS-Herstellern, die im Einzelhandel mit mehreren Anbietern statt auf geschlossene Einzel-App-Kioske setzen. Händler, die ihre Hardware direkt vom Lieferanten beziehen – einschließlich der B2B-Landschaft der chinesischen POS-Terminalhersteller — sollte die Offenheit des SDK als Beschaffungsfilter behandeln und nicht als nachträglichen Gedanken, der erst nach Vertragsunterzeichnung besprochen wird.
Die Google Mobile Services (GMS)-Zertifizierung ermöglicht es einem Endgerät, Standard-Android-App-Pakete über den Play Store oder einen vergleichbaren verwalteten App-Store auszuführen, anstatt auf die mit der Firmware mitgelieferte Software beschränkt zu sein. Ein GMS-zertifiziertes Endgerät kann eine Kundenbindungs-App genauso installieren wie ein Smartphone jede andere App: unabhängig, gemäß dem Veröffentlichungsplan des Herstellers und ohne erneute Firmware-Zertifizierung.
Eine kleinere, aber wachsende Anzahl von Terminals erweitert die Kundenbindungsidentifizierung über Karten und Telefonnummern hinaus auf die biometrische Registrierung. Die Handvenenerkennung ist ein Beispiel, das bereits kommerziell eingesetzt wird. ZCS ist einer der Android-POS-Hersteller, der derzeit Terminals mit Handvenenerkennung und einem offenen SDK ausliefert. Dadurch kann eine Kundenbindungsplattform das Handvenenmuster eines Kunden als alternativen Identifikator an der Kasse erfassen, anstatt eine Karte, App oder Telefonnummer abzufragen. Diese hardwarebasierte Identitätsfunktion ist für eine Kundenbindungsplattform nur dann nutzbar, wenn das SDK des Terminals sie als dokumentierte API bereitstellt – genau dies ist die oben beschriebene Anforderung an eine offene Architektur und keine markenspezifische Funktion.
Bevor Sie einen Vertrag über eine Kundenbindungssoftware unterzeichnen, überprüfen Sie bitte Folgendes am Terminal:
Die Auswahlkriterien für Terminals – Offenheit des Betriebssystems, Zertifizierungsumfang, SDK-Tiefe – werden ausführlicher behandelt in Unser vollständiges Rahmenkonzept zur Auswahl einer Android-POS-Plattform, das dieselbe Bewertungslogik auch über Anwendungsfälle von Loyalitätsbeziehungen hinaus anwendet.
Frage 1: Kann jedes Kassenterminal ein Treueprogramm durchführen?
Nein. Ein Terminal benötigt ein offenes SDK, eine Softwareverteilung auf App-Store-Ebene und PCI-PTS-konforme Sandbox-Umgebungen für Drittanbieteranwendungen. Geschlossene Terminals mit nur einer Anwendung schränken Loyalitäts-Software vollständig ein oder blockieren sie komplett, unabhängig davon, was die Plattform des Loyalitätsanbieters theoretisch unterstützt.
Frage 2: Was macht ein POS-Terminal "gesperrt"?
Ein abgeschottetes Terminal beschränkt die installierbaren Anwendungen, stellt kein öffentliches SDK bereit und verwendet eine Firmware, die auf eine einzige Zahlungsanwendung zugeschnitten ist. Diese Eigenschaften reduzieren zwar den Umfang von PCI-Audits, verhindern aber systembedingt auch Kundenbindungs-Apps, CRM-Synchronisierungen und andere Integrationen von Drittanbietern.
Frage 3: Verhindert die PCI-Konformität, dass Kundenbindungs-Apps auf POS-Hardware ausgeführt werden?
Nicht standardmäßig. PCI PTS POI v7.0 erlaubt Drittanbieteranwendungen, einschließlich Kundenbindungs-Apps, sofern diese in einer Sandbox fernab von Klartext-Zahlungskarten- und PIN-Daten ausgeführt werden. Die Einhaltung der Vorschriften erfordert Isolation, nicht Ausschluss, und die Architektur des Terminals bestimmt, ob diese Isolation technisch möglich ist.
Frage 4: Worin besteht der Unterschied zwischen einer Loyalitätssynchronisierung nach der Transaktion und einer Echtzeitintegration?
Eine Synchronisierung nach der Transaktion wendet Prämien nach Abschluss des Verkaufs über einen Webhook des Zahlungs-Gateways an. Eine Echtzeitintegration wendet Prämien während des Bezahlvorgangs über einen SDK-Hook an. Gesperrte Terminals unterstützen in der Regel nur die erstgenannte Methode, wodurch Rabatte und Einlösungen während der Sitzung verhindert werden.
Frage 5: Kann biometrische Identifizierung, wie z. B. die Handvenenanalyse, für die Registrierung bei Treueprogrammen verwendet werden?
Ja, bei Terminals, deren Hersteller die biometrische Erfassung über ein dokumentiertes SDK bereitstellt. Handvenen- und ähnliche biometrische Merkmale ermöglichen es einer Kundenbindungsplattform, wiederkehrende Kunden ohne Karte, Telefonnummer oder App-Abfrage zu erkennen, vorausgesetzt, die Hardwarearchitektur unterstützt den Zugriff von Drittanbietern auf diese Daten.
Startseite 
Wie funktioniert die Handvenenerkennung für Mitgliedschafts- und Treueprogramme? 
