Zahlungstokenisierung

Was ersetzt wird und was ein Token tatsächlich ist

Das zu schützende Element ist die primäre Kontonummer — die PAN, die lange Nummer auf der Vorderseite der Karte — zusammen mit dem Ablaufdatum und, zum Zeitpunkt der Eingabe, dem Sicherheitscode. Diese drei Werte sind Karteninhaberdaten, und deren Speicherung zieht ein Unternehmen in den teuren Bereich des PCI DSS.

Ein Token ersetzt die PAN durch einen Wert, der keine mathematische Beziehung zu ihr hat. Das ist der Unterschied zur Verschlüsselung, und es ist kein pedantischer Unterschied: Ein Chiffretext kann von jedem, der den Schlüssel erhält, umgekehrt werden, während ein Token nur von dem Vault aufgelöst werden kann, der die Zuordnung enthält. Das Stehlen einer Token-Datenbank bringt nichts, ohne auch den Vault zu kompromittieren, der ein separates System unter separater Kontrolle ist.

Tokens gibt es in zwei Formen, und sie werden ständig verwechselt. Format-erhaltende Tokens sehen aus wie Kartennummern — gleiche Länge, bestehen die gleiche Prüfsumme — sodass sie durch Systeme reisen können, die für die Übertragung einer PAN gebaut wurden. Opake Tokens sind beliebige Identifikatoren, die `tok_`- und `pm_`-artigen Zeichenketten, die aus modernen APIs bekannt sind, und sie können nirgendwo als Karte auftreten.

Die wichtigere Verwechslung ist die zwischen Einmal- und Mehrfachnutzung. Der Wert, den ein clientseitiges Zahlungsfeld Ihrem Server übergibt, ist normalerweise ein Einmal-Token: Er dient dazu, eine Karteneingabe vom Browser zum Prozessor zu übertragen, ohne Ihre Infrastruktur zu berühren, und er stirbt bei der ersten Verwendung. Der Wert, den Sie für zukünftige Abrechnungen speichern, ist ein völlig anderes Objekt — eine dauerhafte Vault-Referenz, die bewusst erstellt wurde und die überlebt, um erneut belastet zu werden. Das Behandeln des ersten als das zweite ist, wie Teams bei der ersten Verlängerung feststellen, dass sie nie etwas gespeichert haben.

Drei Arten von Tokens, und sie sind nicht austauschbar

Das Wort umfasst mehrere Vereinbarungen, die sich darin unterscheiden, wer die Zuordnung hält, und diese einzige Tatsache bestimmt alles über Portabilität, Ausfallsicherheit und was passiert, wenn die Karte neu ausgestellt wird.

Ein Gateway- oder PSP-Vault-Token ist der häufigste Fall und der am stärksten eingeschränkte: Die Zuordnung lebt in der Datenbank eines Anbieters und bedeutet außerhalb davon nichts. Ein unabhängiger Token-Dienstanbieter ist ähnlich aufgebaut, wobei sich der Vault unter einem anderen Dach befindet, genau deshalb gewählt, damit der Vault nicht dem Anbieter gehört, den Sie möglicherweise verlassen möchten. Ein Netzwerk-Token, in einem eigenen Eintrag beschrieben, wird vom Kartennetzwerk ausgestellt und ist der einzige der drei, den die Netzwerke selbst pflegen.

Wie es den PCI-Geltungsbereich reduziert und wo der Geltungsbereich nicht verschwindet

Der PCI DSS-Geltungsbereich folgt den Karteninhaberdaten. Systeme, die eine PAN speichern, verarbeiten oder übertragen, fallen in den Geltungsbereich; Systeme, die nur Tokens halten, nicht, da ein Token keine Karteninhaberdaten ist. Tokenisierung ist daher in erster Linie eine Technik zur Geltungsbereichsreduzierung.

Die Reduzierung materialisiert sich nur, wenn die Kartennummer Ihre Server tatsächlich nie erreicht. Das ist es, was Hosted Fields, ein Iframe vom Prozessor, clientseitige Tokenisierung und vollständige Weiterleitungen alle erreichen sollen. Eine Integration, die die Karte an Ihr Backend sendet und dort tokenisiert, hat die Speicherung aus dem Geltungsbereich verschoben, während Verarbeitung und Übertragung fest darin verbleiben, was eine viel kleinere Einsparung ist, als das Architekturdiagramm vermuten lässt.

Was bleibt, ist die Zahlungsseite selbst. Sie kontrollieren immer noch die Seite, die das Zahlungsfeld lädt, und ein in diese Seite injiziertes Skript kann eine Karte lesen, bevor der Prozessor sie überhaupt sieht. PCI DSS v4 adressiert dies direkt mit Anforderungen, die die Verwaltung von Skripten auf Zahlungsseiten und die Manipulationserkennung auf diesen Seiten abdecken — 6.4.3 und 11.6.1. Keines davon wird durch Tokenisierung aufgehoben.

Die ehrliche Zusammenfassung ist, dass die Tokenisierung einen Händler von der Notwendigkeit, die Sicherheit eines Karten-Vaults zu beweisen, zur Notwendigkeit, die Integrität einer Checkout-Seite zu beweisen, verschiebt. Das ist ein viel besserer Tausch, und es ist nicht dasselbe wie keine Verpflichtungen zu haben.

Die Portabilitätsfalle: Ein Gateway-Token ist nicht übertragbar

Die Eigenschaft, die einen Token sicher macht, ist, dass er außerhalb des Kontextes, in dem er ausgestellt wurde, bedeutungslos ist. Diese Eigenschaft unterscheidet nicht zwischen einem Angreifer und Ihrem nächsten Zahlungsanbieter.

Die Migration eines Bestands an gespeicherten Zahlungsdaten erfordert daher einen Vault-zu-Vault-Transfer: Der abgebende Anbieter exportiert die Kartendaten unter PCI-konformen Bedingungen an den aufnehmenden Anbieter, der sie erneut tokenisiert. Dies ist ein etabliertes Verfahren, beide Parteien können es durchführen, und es erfordert die Zusammenarbeit eines Unternehmens, dessen kommerzielles Interesse darin besteht, dass der Transfer nicht stattfindet. Die Alternative ist, jeden aktiven Abonnenten aufzufordern, eine Karte erneut einzugeben, und ein erheblicher Teil von ihnen wird es einfach nicht tun — das ist kein Churn, den Sie zurückgewinnen, sondern Churn, den Sie verursacht haben.

Die zu sichernde Klausel ist ein Recht, gespeicherte Zahlungsdaten auf Anfrage, innerhalb einer angegebenen Frist und zu angegebenen Kosten an einen benannten alternativen Anbieter zu exportieren. Es kostet nichts, dies zu verhandeln, bevor Sie eine Abonnentenbasis haben, und ist nahezu unmöglich zu erhalten, sobald die Basis existiert.

Speichern einer Zahlungsreferenz für wiederkehrende Abrechnungen

Ein Token allein reicht nicht aus, um einen Kunden erneut zu belasten. Was eine spätere Belastung gültig macht, ist die daneben liegende Einverständniserklärung, und diese Erklärung hat mehrere Teile, die eine naive Migration zurücklässt.

Die gespeicherte Zahlungsreferenz benötigt das Mandat: Was der Kunde zugestimmt hat, wann er zugestimmt hat, die Version der akzeptierten Bedingungen sowie die Frequenz und den Betrag, denen er zugestimmt hat. Sie benötigt den Transaktionstyp — wiederkehrend, Ratenzahlung oder unplanmäßig — da die Netzwerke diese unterschiedlich behandeln. Und sie benötigt den Netzwerk-Transaktionsidentifikator, der von der ursprünglichen kundeninitiierten Autorisierung zurückgegeben wurde, auf den sich nachfolgende händlerinitiierte Belastungen beziehen müssen, um als autorisierte Fortsetzungen und nicht als unverbundene Belastungen einer Karte anerkannt zu werden.

Dieses letzte Feld ist das, das oft fehlt. Eine Migration, die Token, aber nicht die ursprünglichen Netzwerk-Transaktions-Identifikatoren verschiebt, führt dazu, dass der empfangende Zahlungsabwickler Verlängerungen nicht als gültige, vom Händler initiierte Transaktionen präsentieren kann. Das Ergebnis ist eine Autorisierungsrate, die im ersten Abrechnungszyklus nach dem Umzug sinkt, aus Gründen, die niemand im Projektplan vorhergesehen hat.

Neben den Zugangsdaten selbst ist es sinnvoll, das zu speichern, was Sie zur Anzeige und Vorhersage behalten dürfen: Kartenmarke, die letzten vier Ziffern und das Ablaufdatum. Diese Informationen ermöglichen es einem Kunden, zu erkennen, welche Karte hinterlegt ist, und Ihnen, die Zugangsdaten zu identifizieren, die vor der nächsten Verlängerung ablaufen, und diese Kunden zu kontaktieren, bevor die Abbuchung fehlschlägt.