Zahlungsdienst-Richtlinie PSD2 und weitere rechtliche Anforderungen im Subscription Management
Die Zahlungsdienst-Richtlinie PSD2 ist ein Thema, das in der Vergangenheit auch Projekte bei doubleSlash beschäftigt hat. Aus dieser Erfahrung heraus wissen wir, wie wichtig es ist PSD2 zu verstehen und auch welche Auswirkungen eine solche rechtliche Anforderung für eine gesamte IT Architektur hat.
Immer mehr Unternehmen bieten abonnementbasierte Services an. Dazu gehört auch die Abrechnung dieser Services. Was bei Endnutzer:innen einfach zu handhaben sein soll, ist im Hintergrund oft ziemlich komplex. Denn bei der Einführung, Weiterentwicklung oder im Betrieb von Subscription-Modellen und -Systemen sind einige gesetzliche bzw. rechtliche Anforderungen zu beachten. Diese sind oft abhängig von der Domäne des Geschäftsmodells und den Märkten und Ländern, welche bedient werden sollen.
Viele rechtliche Anforderungen/Einschränkungen können einen großen Einfluss auf Prozesse, Schnittstellen oder sogar die gesamte IT-Architektur von Systemen haben. Dementsprechend ist es essentiell, sich mit den rechtlichen Anforderungen, die solche Systeme betreffen können, auseinanderzusetzen. Im Folgenden haben wir die wichtigsten und häufigsten rechtlichen Themen gelistet. Damit diese direkt von Beginn an berücksichtigt und Systeme bzgl. dieser Anforderungen überprüften werden können.
- Geoblocking
Eine Technik, die von einem Website-Anbieter eingesetzt wird, um bestimmte Inhalte regional zu blockieren. Nicht mehr Legal seit dem 3.12.2018.
- Cross-Border-E-Commerce
Problemfelder wie Datenschutz, Verbraucherrechte oder Vertragsrechte können sich je nach Markt unterscheiden.
- PCI-DSS (Payment Card Industry Data Security Standard,)
Standard der Zahlungskartenindustrie für Sicherheit.
- SPL-Check
Überprüfung von Geschäftspartnern bzgl. sanktionierten Parteien oder Anti-Terror-Listen.
- Gesetzliche Aufbewahrungsfrist von Daten
Aufbewahrungsfrist von Daten aus abgeschlossenen Transaktionen gemäß der DSGVO.
- PSD2
Was ist PSD2?
Payment Service Directive 2 (kurz PSD2) ist die zweite, erweiterte Zahlungsdienst-Richtlinie der EU. Sie kennen diese Thematik vielleicht auch unter dem Namen 3D Secure 2.0. Dies bezeichnet jedoch den Sicherheitsstandard, der von Visa entwickelt wurde um die PSD2 Richtlinie zu erfüllen. Das 3D leitet sich von der dritten, zusätzlichen Sicherheitsmaßnahme ab, die mit 3D Secure eingeführt wird. Demnach sind die Begriffe PSD2 und 3D Secure nicht als Synonyme zu verwenden. PSD2 schützt in erster Linie vor Kreditkartenmissbrauch. Doch was ändert sich eigentlich im Vergleich zu PSD1? Wer ist davon betroffen? Und wie kann die Richtlinie korrekt umgesetzt werden?
Was ändert sich durch PSD2 im Vergleich zu PSD1?
Mit der neuen PSD2 Richtlinie ändern sich zwei Anforderungen. Einerseits wird die starke Kundenauthentifizierung (engl: strong customer authentication (SCA)) Pflicht. Andererseits müssen Banken eine Schnittstelle bereitstellen, über die sowohl Drittanbieter (payment services) als auch andere Banken auf die Konten der Kunden zugreifen können. Jedoch nur solange die Kunden ihre Erlaubnis dafür geben.
Für die starke Kundenauthentifizierung, oder auch „Zwei-Faktor-Authentifizierung“ genannt wird der elektronische Zahlungsvorgang ein zweites Mal bestätigt. Das bedeutet, dass Sicherheitsmerkmale aus zwei von drei verschiedenen Bereichen abgefragt werden:
Die Kunden müssen sich hierfür bei den kartenausgebenden Finanzinstitutionen registrieren. So kann nachgewiesen werden, dass nur der Kartenbesitzer agiert.
Wer ist von PSD2 betroffen?
Folgende Gruppen sind von der Richtline betroffen:
- Kund:innen: Für das Online Banking ändert sich das Authentifizierungsverfahren beim Login und bei der Überweisung. Ausgedruckte Tan Listen sind ungültig und müssen ausgetauscht werden. Bei Online-Käufen wird ebenfalls eine 2-Faktor-Authentifizierung notwendig, wenn beispielsweise per Kreditkarte oder PayPal bezahlt wird.
- Online-Shops: Die PSD2 Richtlinien richten sich nur indirekt an Online-Shops oder andere eCommerce Anbieter. Diese müssen darauf achten, dass die eingesetzten Zahlungsdienste mit den Zwei-Faktor-Authentifizierungen kompatibel sind und diese über Plugins oder iFrames einbinden. Je nach Aufbau eines Online-Shops kann hier ein erheblicher Aufwand bei der Implementierung
- Banken: Sie müssen eine PSD2-konforme Datenschnittstelle anbieten und die entsprechende Dokumentation dazu bereitstellen.
Wie können Unternehmen die PSD2 Richtlinie umsetzen?
Grundsätzlich gibt es zwei verschiedene Arten von Transaktionen:
| Transactions Type | Beschreibung | Beispiele |
| CIT → Customer Initiated Transaction | Einmalige Transaktionen bei denen der Kunde oder die Kundin „Vorort“ auf der Website / App ist. In diesem Fall wird die Transaktion von den Kund:innen angestoßen. Es wird immer PSD2 / SCA durchgeführt. | Zalando, BMW Connected Drive, Amazon (keine Abos), usw. |
| MIT → Merchant Initiated Transaction | Die Transaktion wird für den Kunden oder die Kundin vom „Shop“ angestoßen. Kund:innen müssen initial einmal eine Transaktion per PSD2 / SCA autorisieren und später kann der Shop die Karte immer wieder belasten. Dabei gibt es wiederum zwei verschiede Transaktionen:
Recurring Payment: Belastungsbetrag und Periode kann sich unterscheiden. Subscription: Belastungsbetrag und Periode sind fest vorgegeben. § Info: Bei MIT Transaktionen kann es je nach PSP unterschiedliche AGBs geben. So gibt es welche, die MIT nur unterstützen, wenn der Kunde oder die Kundin nicht „verfügbar“ ist für eine SCA |
Recurring Payments Beispiel: Uber
Subscription: Netflix, Spotify. |
Zeitpunkt im Kaufprozess: Die PSD2 / SCA Überprüfung erscheint zu dem Zeitpunkt, wenn der Kunde oder die Kundin eine Kreditkarte hinterlegt (Kann / muss aber nicht) oder einen Betrag auf der Karte abbuchen / reservieren möchte.
Die Umsetzung ist abhängig vom Payment Service Provider (PSP). Meist wird entweder ein Iframe / Redirect oder ein JavaScript vom PSP auf der Seite eingebunden, dass diese Logik für einen Shop kapselt.
Das rechtliche Anforderungen wie PSD2 einen großen Einfluss auf die IT-Architektur und den Implementierungsaufwand für Systeme haben, konnten wir bereits in Projekten sehen und miterleben. Dadurch sind uns mögliche Herausforderungen bekannt. Es lohnt sich, sich schon so früh wie möglich über rechtliche Anforderungen zu informieren und die Architektur der Systeme dementsprechend aufzubauen.
Beispiele zum Nachlesen:
Adyen:
- Iframe / Redirect: https://docs.adyen.com/checkout/3d-secure/redirect-3ds2-3ds1
- JavaScript: https://docs.adyen.com/checkout/3d-secure/native-3ds2
Go Acoustic
- Iframe / Redirect: https://docs.ips.payments.goacoustic.com/api/#create-hosted-payment-session
Co-Autor: Sebastian Bitz
