Wie Kartentokenisierung wirklich funktioniert

Ein Satz, dann die Details

So funktioniert eine gespeicherte Karte, in einem Satz. Die echte Kartennummer liegt nie in deinem Shop. Sie liegt in einem Tresor bei deinem Zahlungsdienstleister, und dein Shop hält nur einen Token, eine bedeutungslose Referenz, die der Dienstleister gegen die Karte eintauschen kann, wenn du eine Zahlung auslöst. Alles Weitere in diesem Artikel entfaltet nur diesen einen Satz, denn fast jeder Vorteil daran, den eigenen Payment Stack zu besitzen, folgt aus ihm: deine leichte Pflicht unter den Kartensicherheitsregeln, deine Freiheit, das Shopsystem zu wechseln, ohne Kartendaten umzuziehen, und die schlichte Tatsache, dass eine gestohlene Kopie deiner Datenbank für einen Dieb wertlos ist.

Ich baue Shops auf Solidus, dem quelloffenen Rails Framework für ecommerce, und verdrahte jeden mit einem Dienstleister, der dem Kunden gehört. Deshalb denke ich viel darüber nach, wohin die Kartennummer geht und, wichtiger, wohin sie nicht geht. Das hier ist die gut lesbare Erklärung des Mechanismus, damit du selbst siehst, warum das eigene Dienstleisterkonto dir Portabilität gibt und warum es deine Pflichten klein hält. Es ist das Gegenstück zu meinem Text darüber, wie man gespeicherte Karten tatsächlich zwischen Anbietern bewegt, der Migration von Zahlungstoken und gespeicherten Karten; hier bleibe ich beim Wie und beim Warum, und die Mechanik des Umzugs lasse ich dort. Die Unternehmen in den Beispielen sind erfunden. Jede fremde Tatsache trägt eine Fußnote zu einer primären Quelle.

Die Kartennummer ist der gefährliche Teil

Die lange Nummer auf der Kartenvorderseite ist die Primary Account Number, fast immer kurz PAN. Der Sicherheitsstandard der Kartenindustrie, PCI DSS, behandelt sie als Kern einer Kategorie namens Account Data, neben dem Karteninhabernamen, dem Ablaufdatum und dem Service Code, und getrennt davon die gefährlicheren Sensitive Authentication Data wie der volle Magnetstreifeninhalt und der drei oder vierstellige Prüfcode.¹ Die Regeln zur PAN sind streng: Du darfst sie nur speichern, wenn du sie nach dem Standard schützt, und du darfst den Prüfcode nie behalten, sobald eine Zahlung autorisiert wurde.¹

Das ist die ganze Begründung für Tokenisierung. Die PAN ist das, was sich zu stehlen lohnt, das, was du schützen musst, und das, was Papierkram, Verschlüsselung, Scans und Audits hinter sich herzieht. Der nützlichste Zug für einen Shop ist also einfach: sie gar nicht erst zu halten. Ein Feld, das deine Systeme nie berühren, ist ein Feld, das du nie schützen, protokollieren, verschlüsseln oder nachweisen musst. Tokenisierung ist der Mechanismus, der einen Shop eine wiederkehrende Kundin immer wieder belasten lässt, während er keine der gefährlichen Daten hält.

Was ein Token ist, und warum er zu einem Tresor gehört

Wenn eine Kundin eine Karte speichert, erhält dein Shop die Kartennummer nicht. Der Dienstleister erhält sie, legt sie in seinem Tresor ab und gibt deinem Shop an ihrer Stelle einen Token zurück. In der Praxis speicherst du eine kurze, undurchsichtige Referenz plus ein wenig unkritisches Detail, das du zur Anzeige behalten darfst, etwa die Kartenart, die letzten vier Ziffern und das Ablaufdatum, damit die Kundin beim nächsten Checkout "Visa endet 4242" sieht.² Um später zu belasten, schickt dein Shop den Token an den Dienstleister, und der Dienstleister, der als Einziger seinen eigenen Tresor lesen kann, tauscht den Token zurück in die Karte und autorisiert die Zahlung.

Zwei Dinge an diesem Token sind für den Rest des Artikels wichtig. Erstens ist er für sich genommen bewusst nutzlos. Würde jemand jeden Token in deiner Datenbank kopieren, hielte er eine Liste von Referenzen, die niemand außer deinem Dienstleister einlösen kann, und dein Dienstleister löst sie nur für dein Konto ein. Es gibt keine Kartennummer zum Abgreifen. Zweitens ist ein Token spezifisch für den Tresor, der ihn ausgegeben hat. Ein Token, den ein Dienstleister erzeugt hat, bedeutet einem anderen nichts, denn nur der ausgebende Tresor hält die Zuordnung zurück zur PAN. Manche unterscheiden zwischen einem flachen Gateway Token, der eigentlich nur eine Referenz auf eine Karte ist, die das Gateway für dich hält, und dem tieferen Tresor dahinter, aber das Prinzip ist in jeder Tiefe gleich: Die sensiblen Daten liegen im Tresor des Dienstleisters, und der Token ist ein Pfandschein darauf. Genau deshalb ist ein Anbieterwechsel eine echte Operation und kein Kopieren und Einfügen, und genau das ist Thema des oben verlinkten Migrationsartikels. Hier zählt die erfreuliche Seite: Weil der Tresor dem Dienstleister gehört und der Token in deinem Konto bei diesem Dienstleister liegt, funktioniert der Token so lange, wie dieses Konto dir gehört.

Wie die Nummer in den Tresor kommt, ohne meinen Server zu berühren

Wenn der Shop die Kartennummer nie erhält, wie kommt die Nummer dann von der Tastatur der Kundin in den Tresor des Dienstleisters? Die Antwort ist das wichtigste Stück Checkout Technik überhaupt, und sie ist der Grund, warum ein gut gebauter Shop fast keine PCI Last trägt.

Die Kartenfelder auf der Checkout Seite gehören nicht dem Shop. Sie werden vom Dienstleister ausgeliefert, meist als kleiner eingebetteter Rahmen, manchmal Hosted Fields genannt oder, in der Benennung eines bekannten Dienstleisters, ein Payment Element.³ Die Kundin tippt die Kartennummer in ein Kästchen, das wie Teil deiner Seite aussieht, aber in Wahrheit ein Fenster auf die eigene Domain des Dienstleisters ist. Die Nummer reist direkt vom Browser zum Dienstleister und wird gar nie an den Server des Shops gesendet. Was zum Shop zurückkommt, ist der Token. Der Dienstleister, der diesen Ablauf betreibt, sagt es klar: Diese Integrationen lassen dich "securely collect and transmit payment information directly to Stripe without it passing through your servers, reducing your PCI obligations."²

Das hält einen Shop auf der leichtesten Selbstauskunft unter PCI DSS, jener namens SAQ A, die einem Onlinehändler offensteht, der den Umgang mit Kartendaten vollständig an geprüfte Dritte ausgelagert hat, sodass seine eigenen Systeme sie nie speichern, verarbeiten oder übertragen.⁴ Die ganze Landschaft aus Stufen und Fragebögen erkläre ich in PCI DSS erklärt, aber die Kernaussage ist, dass diese eine Design Entscheidung, getroffen bevor eine Zeile Checkout Code geschrieben ist, einen Shop mit dem kürzesten Fragebogen von einem trennt, der sich Hunderte Kontrollen aufhalst. Eine neuere Einschränkung ist gut zu wissen: Seit dem 1. April 2025 muss selbst ein Händler mit eingebettetem Anbieterrahmen bestätigen, dass die Skripte auf seiner Zahlseite nicht zum Angriff auf die Zahlung genutzt werden können, weshalb eine saubere Checkout Seite mit verwalteten Skripten nun auch im leichten Fall zählt.⁵ Die Richtung bleibt gleich: Halte die Karte von deinem Code fern und die Zahlseite ordentlich.

Netzwerk Token: die Kartennetze haben ihre eigenen

Der bisher beschriebene Token wird von einem Dienstleister ausgegeben. Es gibt eine zweite, tiefere Art, ausgegeben von den Kartennetzen selbst. Visa und Mastercard betreiben je einen Dienst, der die Kartennummer durch einen Netzwerk Token ersetzt, eine Zugangsberechtigung auf Netzebene, die für die PAN einsteht und für eine Card on File Vereinbarung gespeichert werden kann.⁶⁷ Es lohnt zu verstehen, wie sich diese von einem Dienstleister Token unterscheiden, denn in diesem Unterschied taucht echtes Geld auf.

Ein Dienstleister Token zeigt in den Tresor eines Dienstleisters. Ein Netzwerk Token zeigt in den Tokenisierungsdienst des Netzes selbst, der näher an der Kartenbank sitzt. Diese Nähe bringt zwei Dinge. Das erste ist Kontinuität. Wird die Karte einer Kundin neu ausgegeben, verloren, ersetzt oder läuft sie schlicht ab, dann wird eine einfach gespeicherte PAN schal und die nächste Belastung scheitert. Ein Netzwerk Token wird stattdessen vom Netz aktuell gehalten. Visa beschreibt, dass Zugangsdaten "automatically refreshed across channels to help maximise revenue from returning customers" werden, und Mastercard beschreibt "issuer life cycle management notifications", die durch seine Card on File Tokenisierung fließen, damit die gespeicherte Berechtigung gültig bleibt.⁶⁷ Ein Dienstleister fasst die Wirkung aus Händlersicht zusammen: Netzwerk Token "serve as more secure substitutes for card numbers" und lassen dich "process payments with the most up to date credentials, even if the underlying card data has changed, improving success rates."⁸

Das zweite ist eine höhere Autorisierung. Weil ein Netzwerk Token Netz und Bank Vertrauen trägt, das eine roh getippte Nummer nicht hat, genehmigen Banken mehr davon. Visa berichtet von einem "8% uplift in authorisation rates across Europe when compared to ecommerce PAN transactions" und davon, dass Netzwerk Tokenisierung "reduce fraud by an average of 28%" könne, wobei "payment data never touches your own or your merchants' internal systems."⁶ Mastercard verknüpft seine Card on File Tokenisierung ebenso mit besseren Genehmigungsraten.⁷ Das sind die eigenen Zahlen der Netze, auf ihre eigene Art gemessen, also nimm sie als anbietereigen und der Richtung nach wahr, nicht als Versprechen für genau deinen Shop.

Nun der ehrliche Teil, denn hier geht es um Architektur und nicht um Verkauf. Netzwerk Token sind nicht frei von Abwägungen. Token über die Netze aktuell zu halten kann eigene Gebühren tragen, etwa eine Visa Updater Gebühr oder eine Mastercard Kontinuitätsgebühr, die ein Dienstleister weitergibt und die den Vorteil anknabbert.⁸ Der Gewinn schwankt zudem nach Markt, Kartenmix und Bankverhalten. Netzwerk Token sind eine starke Voreinstellung für einen Card on File Shop, aber ein Werkzeug mit Kosten, kein Zauber.

Warum das eigene Konto der ganze Punkt ist

Hier trifft der Mechanismus auf die Positionierung, und das ist der Grund für diese Serie. Der Tresor gehört dem Dienstleister. Der Token gehört dem Konto bei diesem Dienstleister. Die Frage, die alles entscheidet, ist also die Frage, wessen Konto es ist.

Gehört das Dienstleisterkonto dir, auf den Namen deiner Firma, mit eigenem Vertrag und eigenen Schlüsseln, dann gehören die Token dir. Du kannst das Shopsystem neu bauen, von einem Framework auf ein anderes wechseln, headless gehen, eine App vor denselben Dienstleister setzen oder den Shop ganz ersetzen, und jede gespeicherte Karte funktioniert weiter, weil nichts davon den Tresor oder das Konto berührt, in dem die Token liegen. Die Kartendaten ziehen nicht um, weil sie sich nie bewegen: Sie waren immer beim Dienstleister, und der Dienstleister gehört weiter dir. Das ist der mechanische Grund, warum ein so gebauter Shop portabel ist, und ich verfolge den Punkt in Zahlungsdaten, die mit umziehen weiter und, für die wiederkehrende Seite, in Abonnements, die wirklich dir gehören.

Gehört das Konto stattdessen der Plattform, dann gehören die Token der Plattform. Ein plattformverwaltetes Zahlungsprodukt bindet Shopsystem, Gateway und Tresor unter der eigenen Händlerbeziehung der Plattform zusammen, sodass die gespeicherten Karten in einem Konto liegen, das du nicht kontrollierst. Die Plattform zu verlassen heißt dann, den Tresor zu verlassen, was genau das Migrationsproblem ist, das die erste Hälfte dieser Serie dir ersparen soll und das ich konkret in von einer gehosteten Plattform wegwechseln behandle. Der Motor unter den Zahlungen einer Plattform mag sogar ein fähiger Dienstleister sein, aber ohne Konto auf deinen Namen bekommst du den Motor ohne das Eigentum, und das Eigentum ist der Teil, der deine Kundschaft portabel macht. Das ist das ganze Argument der Serie in einem Mechanismus: Besitze das Konto, und die Token sind ein Vermögenswert, den du behältst; miete es, und sie sind eine Geisel.

Ein Wort zur starken Kundenauthentifizierung

Ein weiteres Stück gehört in einen ehrlichen Bericht, denn es prägt, was deine europäische Kundschaft sieht. Nach der zweiten EU Zahlungsdiensterichtlinie brauchen die meisten elektronischen Kartenzahlungen eine starke Kundenauthentifizierung, kurz SCA: Die Käuferin weist sich mit zwei von drei unabhängigen Elementen aus, etwas, das sie weiß, etwas, das sie hat, und etwas, das sie ist, und bei einer Fernzahlung ist die Authentifizierung dynamisch an genau diesen Betrag und Empfänger gebunden.⁹¹⁰ Im Alltag ist das die Aufforderung in der Bank App oder der Einmalcode beim Checkout.

Tokenisierung und SCA treffen sich in dem Moment, in dem eine Karte zum ersten Mal gespeichert wird. Eine Card on File Vereinbarung einzurichten ist eine Handlung der Kundin, also braucht sie an dieser Stelle in der Regel SCA, weshalb das erstmalige Speichern einer Karte die App Aufforderung auslösen kann. Danach fällt eine Zahlung, die die Kundin nicht aktiv auslöst, eine echte vom Händler ausgelöste Belastung unter der bereits erteilten Vereinbarung, aus der laufenden SCA Pflicht heraus, weshalb eine spätere Nachbestellung oder eine Verlängerung ohne erneute Authentifizierung laufen kann.¹⁰ Die praktische Folge für einen europäischen Shop ist klein, aber real: Rechne mit dem Authentifizierungsschritt, wenn die Karte erfasst wird, gestalte das Speichern so, dass die Kundin anwesend und dafür bereit ist, und verstehe, dass der Nachweis dieser Authentifizierung Teil dessen ist, was eine gut gebaute Integration mitträgt. Die neueren Regeln PSD3 und die Zahlungsdiensteverordnung steckten 2026 noch im EU Gesetzgebungsverfahren und verfeinern dies eher, als es umzuwerfen, die obige Lage ist also die aktuelle, gegen die du bauen solltest.

Ein durchgerechnetes Beispiel: eine Karte durch einen Linzer Shop

Lindwurm Wohnen ist ein erfundenes Unternehmen für Wohnen und Kaffee in Linz, das unter lindwurmwohnen.example handelt, mit einem Solidus Shop, der an einen Dienstleister verdrahtet ist, der dem Unternehmen gehört. Folge einer Karte hindurch.

Eine Kundin, die eine Mühle und einen Beutel Bohnen kauft, erreicht den Zahlschritt. Die Kartenfelder, die sie sieht, werden im eingebetteten Rahmen des Dienstleisters ausgeliefert, sodass die Kartennummer beim Tippen vom Browser direkt zum Dienstleister geht und die Server von Lindwurm Wohnen nie erreicht.² Weil sie "diese Karte für das nächste Mal speichern" angehakt hat, legt der Dienstleister die Karte in den Tresor, und, da dies die EU ist, zeigt ihre Bank eine App Aufforderung, die neue Vereinbarung zu authentifizieren.¹⁰ Sie bestätigt. Der Dienstleister gibt dem Shop einen Token zurück, und Lindwurm Wohnen speichert diesen Token zum Kundendatensatz zusammen mit "Visa endet 4242" und dem Ablaufmonat, dem einzigen Kartendetail, das es zur Anzeige behalten darf.² Nirgends in der Datenbank von Lindwurm Wohnen steht eine Kartennummer.

Drei Monate später kommt sie für mehr Bohnen zurück und tippt auf Nachbestellen. Der Shop schickt den gespeicherten Token an den Dienstleister, der Dienstleister löst ihn gegen seinen Tresor ein und belastet die Karte, und weil dies eine vom Händler ausgelöste Belastung unter der bereits erteilten Vereinbarung ist, wird sie nicht erneut zur Authentifizierung gebeten.¹⁰ Ein Tipp, keine Kartenfelder, keine SCA Aufforderung, und weiterhin keine PAN irgendwo im Shop.

In der Zwischenzeit hat ihre Bank nach einem Betrugsschreck die Karte neu ausgegeben und die Nummer geändert. Hätte sich Lindwurm Wohnen auf eine einfach gespeicherte Karte gestützt, wäre diese Nachbestellung auf einer toten Nummer gescheitert. Weil der Dienstleister die Karte als Netzwerk Token eingetragen hatte, hielt das Netz die Berechtigung aktuell und die Belastung ging auf den neuen Kartendaten durch, ohne dass jemand einen Finger rührte.⁶⁸ Ein Jahr später baut Lindwurm Wohnen sein Shopsystem auf einem neuen Frontend neu und ergänzt später eine App, beide auf dasselbe Dienstleisterkonto gerichtet. Jede gespeicherte Karte, auch diese, funktioniert durch all das weiter, weil Tresor und Konto sich nie bewegt haben. An keiner Stelle berührte eine Kartennummer den Shop, und an keiner Stelle berührte ein Shopwechsel eine Karte.

Dieses Beispiel ist die ganze These im Kleinen. Die sensiblen Daten gingen in den Tresor und blieben dort. Der Shop hielt einen wertlosen Token. Das Netz hielt die Berechtigung frisch. Und weil das Konto der Firma selbst gehörte, ließ jede Änderung an ihrer Software die gespeicherten Karten der Kundschaft unberührt.

Die ehrliche Position

Ich tue nicht so, als wären Tokenisierung und ein eigenes Dienstleisterkonto kostenlos. Ein eigenes Konto zu führen heißt, dass du die Händlerbeziehung, die Rückbuchungen und deinen Anteil an PCI DSS trägst, der für einen gehosteten, tokenisierten Shop das leichte SAQ A ist, aber deine Verantwortung bleibt und nicht die einer Plattform.⁴ Ein Dienstleister verlangt Gebühren, und das ist eine echte Zeile in deinen Kosten. Europäische Karten bringen SCA, das einen Schritt ergänzt, den deine Kundschaft manchmal erledigen muss.⁹ Netzwerk Token können eigene Netzgebühren tragen, die ihren Vorteil beschneiden.⁸ Und ein einzelner Dienstleister ist ein einzelner Punkt, den du einplanen musst, mit einer nüchternen Antwort auf die Frage, was du tust, falls er dich je im Stich lässt. Nichts davon ist versteckt, und nichts davon ist ein Grund, den eigenen Stack nicht zu besitzen. Es ist der Preis, ihn zu besitzen, und es ist ein gutes Geschäft, denn die Alternative ist, keine dieser Pflichten und auch keine der Kontrolle zu halten und die Kosten erst an dem Tag zu entdecken, an dem du zu gehen versuchst.

Was ich nicht bin, ist Wiederverkäufer irgendeines Dienstleisters, und ich nehme von keinem eine Provision. Das Argument hier dreht sich darum, wo die Kartennummer liegt und in wessen Konto die Token sitzen, nicht um eine Marke. Wähle den Dienstleister, der zu deinem Markt und deinem Kartenmix passt, eröffne das Konto auf deinen eigenen Namen und baue den Checkout so, dass die Nummer deinen Code nie berührt. Die Portabilität und die leichten Pflichten sind Folgen dieses Designs, nicht eines Logos.

Was jetzt zu tun ist

Arbeite diese Punkte der Reihe nach ab. Finde heraus, auf wessen Namen dein Zahlungskonto heute tatsächlich läuft, denn wenn es der Plattform gehört, sind deine gespeicherten Karten nicht portabel, egal was sonst stimmt. Sieh nach, wohin die Kartennummer in deinem jetzigen Checkout geht, und wenn etwas davon deine eigenen Server erreicht, ist das das Erste, was du änderst. Wenn du wiederkehrende Zahlungen nimmst, frage deinen Dienstleister, ob er Karten als Netzwerk Token einträgt, denn daher kommen die Kontinuität und die höheren Genehmigungen. Und behalte die ehrlichen Abwägungen im Blick, die Gebühren, den SCA Schritt, den einzelnen Dienstleister, damit die Entscheidung mit offenen Augen fällt.

Wenn du genau sehen willst, wohin die Kartendaten in deinem Shop gehen, in wessen Konto deine Token liegen und ob eine kleine Änderung deine Kundschaft portabel machen würde, buche den kostenlosen Workshop und wir kartieren es gemeinsam, und die ersten zwei Wochen der Arbeit gehen auf mich.

Footnotes

1. PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1, Juni 2024, Abschnitte zu Account Data, zur Primary Account Number und zum Verbot, Sensitive Authentication Data nach der Autorisierung zu speichern, verfügbar in der PCI SSC Document Library, abgerufen am 14. November 2026, https://www.pcisecuritystandards.org/document_library/?category=pcidss ↩ ↩²

2. Stripe, Integration security guide (Integrationen mit geringem Risiko erheben und übertragen Zahlungsinformationen direkt an Stripe, ohne dass sie deine Server durchlaufen, sowie die unkritischen Kartendetails, die du speichern darfst), Stripe Dokumentation, abgerufen am 14. November 2026, https://docs.stripe.com/security/guide ↩ ↩² ↩³ ↩⁴

3. Stripe, The Payment Element (eine einbettbare UI Komponente, die Kartendetails im Frontend erhebt), Stripe Dokumentation, abgerufen am 14. November 2026, https://docs.stripe.com/payments/payment-element ↩

4. PCI Security Standards Council, Self Assessment Questionnaire Instructions and Guidelines (SAQ A Eignung für Händler, die den Umgang mit Kartendaten vollständig an geprüfte Dritte auslagern), verfügbar in der PCI SSC Document Library, abgerufen am 14. November 2026, https://www.pcisecuritystandards.org/document_library/?category=saqs ↩ ↩²

5. PCI Security Standards Council, FAQ clarifies new SAQ A eligibility criteria for ecommerce merchants (das Kriterium zum Skriptschutz und das Datum 1. April 2025), PCI Perspectives Blog, abgerufen am 14. November 2026, https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants ↩

6. Visa, Token Management Service (Netzwerk Tokenisierung: Zahlungsdaten berühren nie die Händlersysteme, Berechtigungen werden automatisch aufgefrischt, ein Plus von 8 % bei den Autorisierungsraten in Europa gegenüber ecommerce PAN Transaktionen und ein Rückgang von Betrug um durchschnittlich 28 %), Visa Acceptance Solutions, abgerufen am 14. November 2026, https://www.visaacceptance.com/en-gb/solutions/payment-services/token-management-service.html ↩ ↩² ↩³ ↩⁴

7. Mastercard, Card on File Tokenization (Ersatz von Account PANs durch Token, issuer life cycle management notifications über Card on File und bessere Genehmigungsraten), Mastercard Developers, abgerufen am 14. November 2026, https://developer.mastercard.com/product/card-on-file-tokenization/ ↩ ↩² ↩³

8. Stripe, Payments optimization (Netzwerk Token sind sicherere Stellvertreter für Kartennummern, die Zahlungen mit den aktuellsten Berechtigungen verarbeiten, selbst wenn sich die zugrunde liegenden Kartendaten geändert haben, sowie die Netzgebühren wie die Visa Updater Gebühr und die Mastercard Kontinuitätsgebühr, die anfallen können), Stripe Dokumentation, abgerufen am 14. November 2026, https://docs.stripe.com/payments/analytics/authorization-boost ↩ ↩² ↩³ ↩⁴

9. Europäische Union, Richtlinie (EU) 2015/2366 über Zahlungsdienste im Binnenmarkt (PSD2), Artikel 97 zur Pflicht der starken Kundenauthentifizierung bei elektronischen Zahlungsvorgängen, EUR-Lex, abgerufen am 14. November 2026, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32015L2366 ↩ ↩²

10. Europäische Union, Delegierte Verordnung (EU) 2018/389 zur Ergänzung der PSD2 mit technischen Regulierungsstandards für die starke Kundenauthentifizierung (zwei oder mehr Elemente aus Wissen, Besitz und Inhärenz, die dynamische Verknüpfung einer Fernzahlung mit Betrag und Empfänger sowie die Ausnahmen), EUR-Lex, abgerufen am 14. November 2026, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32018R0389 ↩ ↩² ↩³ ↩⁴