Obgleich auf dem amerikanischen Markt schon lange im Einsatz, ist das Konzept der Scheme-Token-Technologie vielen deutschen Händlern noch unbekannt. Anlässlich des diesjährigen europaweiten Roll-outs von Scheme Tokens seitens Visa, Mastercard, AMEX & Co. gibt Computop in einer zweiteiligen Reihe einen Überblick über bereits bestehende Verfahren der Tokenisierung von Kartenzahlungen und wirft einen näheren Blick auf die Scheme Token Services innerhalb der EMVCo-Architektur.

Hier geht es zu Teil 2: Das Scheme Token-Konzept

Zur Auffrischung: Tokenisierung kurz erklärt

Allgemein bezeichnet der Prozess der Tokenisierung den Austausch eines einzelnen Datenfeldes (z.B. eine Kreditkartennummer bzw. „PAN“) oder eines Datensatzes (z.B. alle einer Kreditkarte zugehörigen Daten wie PAN, Ablaufdatum, Inhabername) gegen eine bedeutungslose, willkürliche Reihung von Zahlen oder Buchstaben. Diese zufällige Zeichenfolge wird als „Token“ bezeichnet.

Der Token dient als Pseudonym für die eigentlichen zu schützenden Daten (z.B. Kartendaten). Ein mathematischer Zusammenhang (z.B. auf Grundlage eines Algorithmus) zwischen Originaldaten und Token besteht in der Regel nicht, bzw. ist den Teilnehmern im Zahlungsfluss nicht bekannt. Somit ist auch keine rechnerische Rückwandlung des Tokens möglich.

Zuständig für die Generierung, Verteilung und Verwaltung von Tokens innerhalb eines Token-Systems ist ein sogenannter Token Service. Die Rolle eines Token Services können verschiedene Akteure übernehmen, wie zum Beispiel ein Payment Service Provider (PSP) oder eine Kartengesellschaft (in diesem Fall handelt es sich um Scheme Tokens, siehe unten).

Der Token Service kontrolliert den Token Vault, das Herzstück des Systems. Im Kern ist der Token Vault eine auf einem sicheren Server liegende Datenbank, in der die Originaldaten und die zugehörigen Tokens gespeichert sind. Hier erfolgt das sogenannte „Mapping“, also die Zuordnung von Originalwert und Token.

Wie aus der untenstehenden Grafik hervorgeht, werden beim Prozess der Tokenisierung keine Karten-Klardaten zwischen Absender und Empfänger übermittelt, sondern immer nur die jeweiligen Tokens.

Tokenisierung vs. Verschlüsselung (Encryption)

Sowohl Tokenisierung als auch Verschlüsselung (Encryption) sind effektive Werkzeuge zum Schutz sensibler Zahlungsdaten. Jedoch beruhen sie auf unterschiedlichen Prinzipien.

Beim Prozess der Tokenisierung wird der ursprüngliche, zu schützende Wert vom zuständigen Token Service gegen einen neuen, zufälligen Wert (den Token) ausgetauscht. Am Ende der Datenübertragung erfolgt der Rücktausch des Tokens in den Originalwert und dessen Ausgabe an den berechtigten Empfänger der Daten.

Bei der Verschlüsselungsmethode wird der Originalwert nicht willkürlich gegen einen Alias-Wert getauscht, sondern gezielt vom Datenabsender in einen für Dritte unlesbaren Wert chiffriert. Diese Transformation beruht auf einem mathematischen Algorithmus und ist reversibel, d.h. sie wird vom Datenempfänger beim Erhalt der Daten mithilfe eines erforderlichen Entsperr-Schlüssels (Key) rückgängig gemacht.

Bei der Übermittlung von Kartendaten im Netz kommt die Verschlüsselungstechnik grundsätzlich an mindestens einer oder mehreren Stellen zum Einsatz. Sie erfolgt zum einen in Form der gängigen SSL-Verschlüsselung des Übertragungswegs zwischen Browser und Webserver. Zum anderen werden (wenn keine Tokenisierung Anwendung findet) zusätzlich die sensiblen Transaktionsdaten (wie z.B. Informationen zum Zahlungsmittel) durch den zuständigen Payment Service Provider zur Weiterleitung an den Acquirer verschlüsselt.

Warum wird Tokenisierung zum Schutz von Kartendaten eingesetzt?

Auch wenn sich Verschlüsselungstechnologien bereits als bewährter Schutz gegen den Diebstahl von Kartendaten im Online- und Offlinehandel erweisen, bietet die alternative bzw. ergänzende Verwendung von Payment Tokens eine Reihe von zusätzlichen Vorteilen für Händler:

• Tokens lassen sich an einen konkreten Verwendungszweck binden. So kann der zuständige Token Service beispielsweise die Gültigkeit eines Tokens auf eine bestimmte Shop-Domain oder ein bestimmtes Endgerät beschränken oder ein Ablaufdatum festlegen. Herausgelöst aus seinem definierten Geltungsbereich lässt sich der Token somit nicht mehr nutzen – anders als gestohlene Kartendaten.

• Händler können Karten-Tokens im Gegensatz zu Karten-Klardaten in ihren eigenen Systemen speichern, ohne eine vollumfängliche PCI DSS-Zertifizierung erfüllen zu müssen. Dies birgt insbesondere für Stammkunden erhebliche Vorteile: Durch den hinterlegten Karten-Token im Kundenkonto müssen die echten Karten-Daten bei Anschlusskäufen nicht erneut eingegeben werden.

• Tokenisierte Kartendaten müssen nicht in Gänze unkenntlich sein. So ist es z. B. möglich, die letzten 4 Ziffern der PAN im Original zu belassen. Die Frontend-seitige Präsentation des Tokens in Gestalt von z.B. **** **** **** 1234 ermöglicht dem Käufer im Kundenkonto die Wiedererkennung seiner Karte und erhöht das Vertrauen in den Bezahlvorgang.

• Unter Einsatz von Tokenisierung werden bei der Datenübertragung niemals Originaldaten übermittelt. Statt mit allen im Übertragungsweg eingebundenen Akteuren teilt der Besitzer seine Daten nur mit dem zuständigen Token Service sowie dem finalen Empfänger.

• Ein Token-System ist zentral organisiert. Während für die Datenverschlüsselung die technischen Grundlagen dezentral von jedem einzelnen Glied in der Übertragungskette umgesetzt werden müssen, erfolgt die Ausgabe, das Management und der Eintausch von Tokens durch den Token Service zentral an einer Stelle. Dies verhilft dem Verfahren zu mehr Einheitlichkeit und Effizienz.

Wie kommt Tokenisierung zum Einsatz?

Credential on File (COF) via Gateway Tokens

Die meisten Payment Service Provider (PSP) bieten ihren Händlern eine sogenannte Credential on File (COF)-Funktionalität. Hierbei übernimmt der PSP die Funktion des Token Services.

Führt ein Käufer im Onlineshop eine Erstbestellung per Kredit- oder Debitkarte durch, werden die Kartendaten im Checkout zunächst über eine gesicherte Zahlungsseite (Payment Page) an den PSP übergeben.

Handelt es sich um einen Einmalkauf (ohne Registrierung als Kunde im Shop), leitet der PSP die Kartendaten in verschlüsselter Form direkt an den Acquirer weiter.

Legt der Käufer beim Kauf auch ein Kundenkonto an, übergibt der PSP zusätzlich einen Token an das Shop-Backend. Der Shop kann auf diese Weise die Karte im Konto des Käufers speichern, ohne mit den Karten-Echtdaten in Berührung zu kommen. Der Käufer kann im Gegenzug Folgekäufe und Abonnementzahlungen durchführen, ohne mit jeder Zahlung seine Kartendaten erneut eingeben zu müssen.

Bei der Anwendung des COF-Prinzips in seiner einfachsten Form findet keine vollständige Tokenisierung über die gesamte Payment-Prozesskette (vgl. Abbildung) statt. Der Einsatz des PSP-Tokens „überbrückt“ lediglich den Onlineshop bzw. die Systeme des Händlers, um diesem den Aufwand einer PCI DSS-Zertifizierung und die damit einhergehenden zusätzlichen Investitionen in Datensicherheit zu ersparen.

Credential on File (COF) via Scheme Tokens

Eine vollständige Tokenisierung der Payment-Prozesskette kann für Kartenzahlungen in Onlineshops oder Shopping Apps durch die Verwendung von Scheme Tokens erfolgen.

Die Rolle des Token Services wird hier von den betreffenden Kartengesellschaften (Schemes), übernommen. Eine ausführliche Beschreibung des Scheme-Token-Konzeptes erfolgt in Artikel 2 dieser Reihe.

Über die vom Payment Service Provider (PSP) gehostete Payment Page werden die Kartendaten im Shop-Checkout entgegengenommen. Der PSP übermittelt die empfangenen Kartendaten an den betreffenden Scheme Token Service. Dieser gibt in Verbindung mit der kartenausstellenden Bank (Issuer) einen Token an den PSP zurück.

Führt der Käufer einen Einmalkauf durch, hat der PSP die Möglichkeit, den Token direkt in den Zahlungsfluss zu leiten. Jedoch verlangsamt eine sogenannte „Tokenization during Transacting“ die Zahlung minimal – und kann damit zu einer nachteiligen kundenseitigen User Experience führen. Aus diesem Grund sehen viele PSPs derzeit noch von einer Verwendung von Scheme Tokens für Einmalzahlungen ab.

Verfügt der Käufer hingegen über ein Kundenkonto, übergibt der PSP den Token an das Shop-Backend. Dort wird er gespeichert und kann für erneute Käufe eingesetzt werden. In seiner Verwendung entspricht dieser Fall dem zuvor beschriebenen Credential on File-Prinzip, unterscheidet sich jedoch dadurch, dass die Händlerbank (Acquirer) nicht mit den originalen Kartendaten in Kontakt kommt.

Mobile Wallets via Scheme Tokens

Auch Mobile Wallets wie Apple Pay oder Google Pay bedienen sich der Token-Technologie, um die Kartendaten ihrer User vor Missbrauch und Diebstahl zu schützen. Nicht nur der E- und M-Commerce können in diesem Fall von den Tokens profitieren, sondern auch der stationäre Handel, da Mobile Wallets, in denen Kredit- oder Debitkarten als Zahlungsmittel hinterlegt sind, auf Grundlage von NFC oder QR-Codes auch an POS-Kartenterminals einsetzbar sind.

Die Rolle des Token Services wird auch hier von den betreffenden Kartengesellschaften (Schemes) übernommen.

Hinterlegt der Käufer eine Karte im Wallet, übergibt das Wallet die Kartendaten direkt an den Token Service der betreffenden Kreditkartengesellschaft. Der Token Service (d.h. das Scheme) gibt in Verbindung mit der kartenausstellenden Bank (Issuer) einen Token zurück, der auf dem vom Käufer verwendeten Endgerät (für gewöhnlich das Smartphone) gespeichert wird. Dieser ist fest an das Gerät gebunden und nur in dessen entsperrten Zustand einsatzfähig.

Kauft der Kunde in einem Shop, der das Wallet unterstützt, wird im gesamten Zahlungsfluss bis hin zur betreffenden Kartengesellschaft lediglich der Token übermittelt.

Interesse geweckt?

Sie interessieren sich für das Thema Payment-Tokenisierung? Erfahren Sie im zweiten Teil unserer Artikel-Reihe mehr zur Funktionsweise der Scheme Token-Technologie sowie zu den Vorteilen, die eine Integration in Ihren Shop mit sich bringen kann.

Oder haben Sie bereits konkrete Fragen? Treten Sie mit uns in Kontakt. Unsere Payment-Experten beraten Sie gerne unverbindlich zum Einsatz von Karten-Tokens in Ihrem Shop.