Banking-Apps um HCE Payment Wallets entwickeln – auch Banken können mobile Payment

Die Kreditkartenbranche hat beim kontaktlosen Bezahlen mittels der NFC-Technologie Pionierarbeit geleistet. Bereits 2007 haben VISA und Mastercard ihre Kontakt­los-Verfahren payWave und PayPass gestartet. Die Akzeptanzinfrastruktur steigt stetig – Ende 2016 waren bereits über 200.000 der insgesamt 784.000 Bezahlterminals in Deutschland NFC-fähig. Aber auch Banken können HCE. Jonas Dortmund von visco consulting sagt, was zu beachten ist.

von Jonas Dortmund, technischer Projektleiter Mobile Payments visco consulting

Binnen weniger Jahre hat sich die HCE-Technologie zu einem weltweiten Standard für mobile Bezahlverfahren insbesondere auf Android Smartphones entwickelt.

Seit ihrer Einführung mit dem Android-Release 4.4 im Oktober 2013 sind NFC-basierte Lösungen auf Android Smartphones nicht mehr auf die Existenz eines Secure Elements angewiesen, da sicherheitsrelevante Daten verschlüsselt auf dem Endgerät abgelegt werden.

Die bestehende Banking App wird hierbei um eine Payment-Komponente erweitert, welche die Kommunikation mit dem NFC Controller des Smartphones übernimmt sowie die digitale Karte gespeichert hat. Der Payment Application Server ist die Schnittstelle zum Tokenization Service Provider (TSP). Dieser kann von Kartennetzwerken oder von einem Drittanbieter bereitgestellt und betrieben werden. Er stellt das digitale Kartenprofil inklusive des sogenannten Tokens zur Verfügung.

Bei dem Token handelt es sich nicht mehr um die originären Zahlungsdaten der ursprünglichen Karte, sondern um neue, ausschließlich digitale Kartendaten. Bei jedem Bezahlvorgang am Terminal übersetzt der TSP den Token in die dahinterliegenden Zahlungsdaten, z.B. die originäre Kartennummer (auch als De-Tokenization bezeichnet). Darüber hinaus validiert der TSP auch das Tokenkryptogramm – ein transaktionsspezifisches Sicherheitsmerkmal.

Vom Design zum Produkt

Üblicherweise werden beim Product Design die erwarteten Funktionalitäten mit den Verantwortlichen der kartenherausgebenden Bank abgestimmt. Wichtig ist, dass dabei neben den fachlichen und technischen Projektleitern das Produktmanagement sowie Vertreter des Zahlungsverkehrs einbezogen werden. Auf folgende fachliche und technische Kernpunkte des Product Designs sollte geachtet werden:

1. User Experience und Design
Bereits in einer frühen Projektphase ist es empfehlenswert, sich mit der Nutzererfahrung (UX), sowie ersten Ideen zur grafischen Benutzeroberfläche (UI) der Payment-Funktionalität in der Banking App zu beschäftigen. So sollten bei täglicher Nutzung neben der Zuverlässigkeit auch „kurze Wege“ für den Nutzer realisiert werden – und insbesondere beim Bezahlvorgang die Anzahl der Nutzerinteraktionen auf ein Minimum reduziert werden. Der Faktor Zeit ist in der Bezahlsituation an der Kasse knapp bemessen.

2. Digitalisierung
Für die Identifikation der zu digitalisierenden Karte und Authentifizierung des Karteninhabers existieren grundsätzlich zwei Ansätze: i) das manuelle Hinzufügen von kartenidentifizierenden Merkmalen durch den Benutzer mit nachgelagerter Authentifizierung sowie ii) das Bereitstellen verfügbarer Kartendaten aus dem Backend nach erfolgreicher Authentifizierung.
Ersteres wird bei vielen OEM-Wallets (bspw. Apple Pay) umgesetzt. Hier kann die Kartennummer abgetippt und die Eingaben mittels eines separat versendeten Codes (z.B. per SMS) bestätigt werden.
Die manuellen Schritte entfallen beim zweiten Ansatz. Bei diesem kann der Kunde sich z.B. mit seinem Bank-Login in der App anmelden und die zur Digitalisierung verfügbaren Karten zur Auswahl angezeigt bekommen. Dies ist ein Alleinstellungsmerkmal einer bankeigenen Wallet App, bei dem der Kunde nach dem Login in der Banking App bereits ausreichend authentifiziert wurde.

3. Payment
Den Kern des Wallet stellt die Bezahlfunktion dar. Hier sind sowohl die Interaktionspunkte des Endnutzers als auch die technischen Hintergrundprozesse entscheidend. Ersteres wird insbesondere darüber definiert, ob die Zahlungsautorisierung (Cardholder Verification Method kurz CVM) auf dem Smartphone oder auf dem Terminal erfolgt. Klassischerweise erfolgt bei kontaktlosen Zahlungen die PIN-Eingabe auf dem Bezahlterminal des Kassensystems. Transaktionen unter einer länderspezifischen Betragsgrenze (in Deutschland z.B. 25 Euro) benötigen in der Regel keine CVM.

Die technischen Möglichkeiten von Smartphone Hardware, Sensoren und Betriebssystemen eröffnen neue Möglichkeiten zur Autorisierung von Transaktionen. Die als „on-device“ bezeichneten Verfahren erlauben neben der Eingabe einer PIN auf dem Smartphone vor oder während des Bezahlvorgangs auch die Nutzung von Wischgesten (Patterns), Passwörtern oder biometrischen Sensoren wie z.B. dem Fingerabdrucksensor.

Allerdings ist zu beachten, dass die Verlagerung der Autorisierung von Zahlungen weg vom „sicheren“ Terminal auf das Smartphone Risiken mit sich bringt. So ist das Risiko durch potenziell schadhafte Software, die z.B. über das Internet auf das Gerät gelangen kann, grundsätzlich höher als auf geschlossenen und kontrollierten Terminals.

Zur Adressierung von Sicherheitsrisiken sind Maßnahmen zu ergreifen, die sicherstellen, dass die auf dem Smartphone vorhandenen Informationen ausreichend geschützt sind. Dies kann z.B. durch die Verwendung von White Box Cryptography (WBC) Komponenten und geschützten (Biometriesensor-) Schnittstellen vom Betriebssystem selbst erfolgen.
Bei der Autorisierung von Zahlungen durch den Kartenherausgeber sind entsprechende Regeln zu erstellen, um Betrugsprävention auf heuristischer Basis zu ermöglichen.

Insgesamt sind bei HCE-Wallets neue und innovative Möglichkeiten der Kundenauthentifizierung denkbar, die ein Differenzierungsmerkmal zur klassischen Karte sind und einen Mehrwert darstellen können. Neue funktionale Möglichkeiten sollten stets mit entsprechenden Sicherungsmaßnahmen einhergehen.

4. Replenishment und Lifecycle
Mit dem Replenishment wird die Bereitstellung von sogenannten Einmalschlüsseln auf dem Endgerät bezeichnet. Diese kommen zum Einsatz, um jeder Transaktion – neben dem Token – einen einmaligen Schlüssel in Form eines Kryptogramms zuzuweisen. Um sicherzustellen, dass Zahlungen auch möglich sind, wenn das Smartphone keine Online-Verbindung hat, werden vorab mehrere Einmalschlüssel an das Gerät gesendet. Weitere Lifecycle-Events können z.B. die temporäre oder dauerhafte Löschung eines Tokens sein, entweder angestoßen durch den Nutzer oder durch den Kartenherausgeber.

Security und Zertifizierung

Die Einführung von HCE und die damit einhergehend gestiegenen Sicherheitsanforderungen an die Banking App, das Smartphone und nachgelagerte Systeme haben dazu geführt, dass seitens der Kartennetzwerke Mindeststandards definiert wurden. Diese adressieren zum einen funktionale Anforderungen an die Banking App, die Payment-Komponente, den Payment Application Server sowie die Integration mit dem Tokenization Service Provider und zum anderen Qualitätsanforderungen hinsichtlich einer sicheren Implementierung sowie des Betriebs. Kartennetzwerke wie VISA oder Mastercard definieren die Mindestanforderungen und nehmen die HCE-Lösungen ab, teilweise mit Unterstützung von externen Auditoren.

Weiterhin werden auch Anforderungen an die IT-Sicherheit gestellt. Der Fokus liegt hierbei sowohl auf dem Endgerät, dem Payment Application Server und dem Token Service Provider wie auch auf dem Autorisierungssystem des Kartenherausgebers. Bei allen Komponenten muss gewährleistet sein, dass benutzer- und transaktionsbezogene sowie andere identifizierende Informationen sicher gespeichert, verarbeitet und transportiert werden.
Die Prüfung erfolgt dabei meistens durch akkreditierte Dienstleister und ist regelmäßig sowie bei größeren Anpassungen zu erneuern.

Die erstmalige Zertifizierung einer Gesamtlösung kann mitunter mehrere Monate in Anspruch nehmen. Die Verwendung von vorzertifizierten Komponenten – sowohl für die App als auch für den Payment Server – kann für ein Projekt daher erhebliche Zeitvorteile bedeuten.

Was bei einer bankeigenen HCE-Lösung wichtig ist

Die Einführung einer bankeigenen HCE Wallet bringt Herausforderungen mit sich. Die Wallet muss den Endnutzer in punkto User Experience überzeugen, gleichzeitig den hohen Sicherheitsanforderungen an kartenbasierte Bezahlverfahren standhalten. Bei der Realisierung von HCE-Wallets im Kreditkartenumfeld sind Zertifizierungsaufwände nicht zu unterschätzen. Die Tokenisierung entwickelt sich zu einem Standard, gleichwohl interpretieren Tokenization Service Provider diese Architektur unterschiedlich, was die Wiederverwendung von Komponenten erschwert.

Es ist empfehlenswert, sich zu Beginn einer HCE-Implementierung mit den am Markt verfügbaren Komponenten vertraut zu machen und Eigenentwicklungen auf die differenzierenden Bausteine zu fokussieren.aj