Wenn Sie Ihr eigenes Tool entwickeln, das mit Zahlungen in Berührung kommt: Wer trägt das Compliance-Risiko?

Sie selbst. Nicht die KI, die den Code generiert hat, nicht Ihr Hosting-Anbieter und auch nicht Ihr Zahlungsdienstleister. In dem Moment, in dem ein von Ihnen entwickeltes Tool mit Zahlungen in Berührung kommt, liegt das Compliance-Risiko bei Ihrem Unternehmen – und dort bleibt es auch, egal wie viele konforme Drittanbieter Sie einbinden. Was Sie jedoch beeinflussen können, ist die Höhe dieses Risikos. Der Unterschied zwischen einem gut durchdachten, maßgeschneiderten Tool und einer unvorsichtigen Lösung ist enorm.

Warum liegt das Risiko bei Ihnen und nicht bei Ihren Anbietern?

Die Kartenakzeptanz basiert auf einer Vertragskette. Die Kartennetzwerke stellen die Regeln auf, Ihr Acquirer (die Bank, die die Kartenumsätze für Sie abwickelt) setzt sie durch, und Ihr Händlervertrag gibt sie an Sie weiter. Das Regelwerk ist PCI DSS, der Datensicherheitsstandard der Kreditkartenindustrie. Er gilt für jedes Unternehmen, das Karteninhaberdaten (Kartennummern und die damit verbundenen Daten) speichert, verarbeitet oder überträgt. Die aktuelle Version ist 4.0.1. (Versionsnummern und Programmdetails entsprechen dem Stand bei Veröffentlichung; betrachten Sie diese Angaben als Momentaufnahme.)

Ihre Anbieter haben Verpflichtungen für ihre eigenen Systeme, und ein konformer Zahlungsdienstleister reduziert Ihren Arbeitsaufwand drastisch. Aber keine Maßnahme eines Anbieters überträgt die Verantwortung. Das PCI Security Standards Council stellt unmissverständlich klar, dass die Entscheidung, ob Sie die Compliance nachweisen müssen, bei den Kartenmarken und Ihrem Acquirer liegt – und deren Antwort, die in Ihrem Händlervertrag verankert ist, lautet: Ja. Jedes Jahr unterzeichnet jemand in Ihrem Unternehmen eine Konformitätserklärung (Attestation of Compliance), die bestätigt, dass Ihre Umgebung dem Standard entspricht. Diese Unterschrift ist Ihre eigene, nicht die Ihres Anbieters.

Was ändert sich in dem Moment, in dem Ihr eigener Code mit Kartendaten in Berührung kommt?

Der Scope (Geltungsbereich). Der Compliance-Aufwand bemisst sich nach dem Scope: Jedes System, das mit Karteninhaberdaten in Berührung kommt, sowie alle damit verbundenen Systeme fallen unter den Standard.

Ein Händler, dessen Zahlungen vollständig von einem konformen Anbieter und dessen zertifizierten Geräten abgewickelt werden, erbringt den Nachweis über einen kurzen Selbstauskunftsfragebogen (eine jährliche Checkliste) mit wenigen Dutzend Fragen. Ein Händler, dessen eigene Software Kartennummern verarbeitet, fällt in die anspruchsvollste Kategorie, die fast den gesamten Standard widerspiegelt: weit über zweihundert Anforderungen, darunter vierteljährliche Schwachstellenscans, Penetrationstests, Zugriffskontrollen, Protokollierung und formelle Sicherheitsrichtlinien¹.

Das Checkout-Formular, das eine KI an einem Nachmittag für Sie geschrieben hat? Wenn es Kartennummern erfasst, fallen Ihr Webserver, Ihre Datenbank, Ihr Admin-Laptop und Ihr Laden-WLAN potenziell in den Scope. Und Sie können nicht einfach heimlich den kurzen Fragebogen ausfüllen. Die Wahl einer Kategorie, für die Sie nicht qualifiziert sind, verringert Ihr Risiko nicht – es bedeutet lediglich, dass das von Ihnen unterzeichnete Dokument fehlerhaft ist. Das kommt meist im schlimmsten Moment ans Licht: direkt nach einer Datenpanne.

Was kostet es eigentlich, wenn man es falsch macht?

Die Durchsetzung erfolgt vertraglich, sodass sich Verstöße meist auf Ihrer Abrechnung bemerkbar machen. Viele Zahlungsabwickler stellen so lange eine monatlich wiederkehrende Gebühr wegen Nichteinhaltung (Non-Compliance Fee) in Rechnung, bis Sie den Nachweis erbringen. Nach einer Datenpanne summieren sich die Kosten: eine obligatorische forensische Untersuchung, die Sie selbst bezahlen müssen, Kosten für die Kartenneuausstellung und eskalierende Strafen, die über Ihren Acquirer weitergegeben werden – üblicherweise im Bereich von 5.000 bis 100.000 US-Dollar pro Monat (basierend auf den von PCI-Compliance-Prüfern veröffentlichten Strafgebührenkatalogen). In schweren Fällen kann ein Unternehmen die Berechtigung zur Kartenakzeptanz komplett verlieren.

Für eine kleinen Händler sind die schwerwiegendsten Kosten oft unauffälliger als jede Geldstrafe: Der Betrieb eines echten Sicherheitsprogramms kostet Zeit, die eigentlich für die Führung des Geschäfts eingeplant war.

Wie baut man maßgeschneiderte Tools, ohne in den Scope für Kartendaten zu fallen?

Halten Sie Ihren Code aus dem Zahlungsweg heraus. Ihr maßgeschneidertes Tool sollte lediglich den Verkauf koordinieren: den Warenkorb erstellen, Rabatte anwenden, die Gesamtsumme berechnen und den zu belastenden Betrag übermitteln. Die Karte selbst sollte ausschließlich mit einem zertifizierten Terminal (einer für die Verarbeitung von Karten validierten Hardware) oder der gehosteten Zahlungsseite Ihres Anbieters in Berührung kommen. Beide leiten die Daten direkt an einen Zahlungsabwickler (das Unternehmen, das das Geld bewegt) weiter. Ihr Tool erhält lediglich ein Ergebnis zurück – genehmigt oder abgelehnt – sowie einen Token (eine Referenznummer, die für Datendiebe völlig nutzlos ist).

Diese Trennung ist das Hauptargument für eine Headless-POS-Architektur: maßgeschneiderte Benutzeroberflächen oben, zertifizierte Zahlungsinfrastruktur darunter. Es ist auch der Grund, warum KI-generierte Checkouts in Demos fantastisch aussehen, in der Praxis jedoch scheitern, und warum ein Webformular die falsche Lösung für Präsenzzahlungen mit Debitkarten wie Interac ist: Vor-Ort-Zahlungen gehören sowohl technisch als auch vertraglich auf zertifizierte Hardware.

Final ist genau um diese Grenze herum aufgebaut. Die Flows, die Sie erstellen – egal, ob Sie sie selbst per Prompt generieren oder Ihre eigene KI über MCP anbinden –, steuern Bildschirme, Warenkörbe und Kataloge. Die Kartendaten gelangen von der zertifizierten Terminal-Hardware über Final Pay direkt an einen Zahlungsabwickler und kommen mit dem von Ihnen erstellten Flow nie in Berührung. Individuell, wo es sicher ist; standardisiert, wo die Haftung liegt.

Wer trägt also das Compliance-Risiko?

Sie selbst, und das wird auch immer so bleiben. Die eigentliche Entscheidung liegt darin, wie viel Scope Sie in Kauf nehmen – und das ist eine Frage der Architektur, nicht des Papierkrams. Bevor Sie ein Tool einführen, das mit Zahlungen interagiert, stellen Sie sich eine Frage: Kann mein Code jemals eine Kartennummer sehen? Wenn ja, liegt die Durchführung des Compliance-Programms bei Ihnen. Wenn nein, behalten Sie die Flexibilität einer maßgeschneiderten Lösung bei einem Bruchteil des Aufwands. Wenn Sie derzeit über eine solche Lösung nachdenken, lesen Sie zuerst unseren Artikel über die Anzeichen dafür, dass Sie aus Ihrem Standard-POS herausgewachsen sind.